# My Rant on Opacity, Transparency, and hex values

**URL:** <https://forum.kirupa.com/t/my-rant-on-opacity-transparency-and-hex-values/318694>\
**Category:** flash\
**Created:** [January 27, 2011, 11:53am UTC](https://forum.kirupa.com/t/my-rant-on-opacity-transparency-and-hex-values/318694 "2011-01-27T11:53:06Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![IQAndreas](https://avatars.discourse-cdn.com/v4/letter/i/f08c70/32.png) [@IQAndreas](https://forum.kirupa.com/u/IQAndreas)\
**Post date:** [January 27, 2011, 11:53am UTC](https://forum.kirupa.com/t/my-rant-on-opacity-transparency-and-hex-values/318694/1 "2011-01-27T11:53:06Z")

</div>

[whisper]NOTE: I often mix up weather opacity means “fully visible” or “fully invisible”. Is Opacity the same as alpha, or the opposite? Just to be safe, I’m using the word “transparency” instead.[/whisper]

Let’s say you ask for a color, and I hand you **0x52BD86**

Assuming you were wanting a “regular” color, I just handed you a nice little bluish color.  
However, assuming you wanted a “32 bit” color (that is, including an alpha channel) I just handed you a completely transparent color ( **0x0052BD86** to be precise), so it really doesn’t matter what the visible color was, it’s still going to be invisible.

That’s why AS3 BitmapData has separate methods “setPixel” and “setPixel32”.

Would it not be better to have the first 8 bits be a “transparency” value, so instead of 0 being invisible and 255 fully visible, flip them, making 0 completely visible, and 255 completely transparent?

That way, if I hand you **0x52BD86** , you can basically assume I mean completely visible. Then we won’t even need separate functions for 32 bit colors.

But, this probably goes deeper than AS3, and likely would mean changing the way color is treated throughout the last couple of years, or? Is there any reason they created the alpha bits like that?
