Proper RGBA support

[GoogleCodeExporter]

*What do you need to do?*

Allow for "proper" RGBA, where the alpha or opacity of a color is chosen with a 
slider in the color picker and could be stored in a palette.  

This would also allow for easy implementation of a few other requested 
features, namely:

* Issue 58: Grid opacity value and grid color/opacity in settings
* Issue 141: Eraser opacity support
* Issue 231: Actually, this issue is basically asking for the same thing.

It would also allow any feature which uses a color to use alpha values with out 
any extra work.

As mentioned in issue 231, the hex codes would be 8 digits, #rrggbbaa, however 
it would be useful to construct the hex color string in such a way that colors 
with 255 alpha would be written as #rrggbb.  

*How would you like to do it?*

The internal pixel representation already uses RGBA, so most of this would 
merely be exposing that functionality within the user interface.

The current method of using a separate opacity value (which could still be 
useful if thought of as "Brush Opacity" rather than the color alpha value) is 
somewhat clunky, and the color picker doesn't know how to pick up a 
semi-transparent color value.

The current opacity setting could be rolled into a brush specific setting which 
would multiply the alpha of whatever color being painted by the opacity of the 
brush, so a color such as #ff00007f (red w/ 50% alpha) painted with a 50% 
opacity brush would paint #ff00003f (red w/ 25% alpha).  This type of brush 
would be more useful for some of the ink types other than default, although to 
be honest I'm not entirely certain how some of them work in the first place.  
For blur anyhow it could control how "strong" the blur effect is.

Indexed color images would keep the current RGB color picker.  The exact 
implementation of the color pickers can go in several different ways.  One way 
would be to simply add versions with an alpha slider to the current pickers, 
that is, there would be Index, RGB, RGBA, HSB, HSBA, etc.  Another would be to 
replace the RGB and HSB with the alpha versions.  Any suggestions in this 
regard are welcome.

This would also affect the ramp function in the palette editor, since it would 
need to accommodate colors with various alpha values and blend between them.  
Chances are the changes to the current ramp algorithm would be minimal.

I would welcome any feedback about this suggestion.  There are a lot of 
possibilities, and quite likely affects more areas than I've thought of as yet.

Original issue reported on code.google.com by DocHoncho@gmail.com on 22 Nov 2013 at 4:56

[GoogleCodeExporter]

Issue 231 has been merged into this issue.

Original comment by DocHoncho@gmail.com on 22 Nov 2013 at 4:57

[GoogleCodeExporter]

I was thinking a lot about this issue (rewritting the whole color management), 
I'll try to write my thoughts later (it will take me some time to think about 
it).

Original comment by davidcapello on 22 Nov 2013 at 10:51

[GoogleCodeExporter]

Original comment by davidcapello on 22 Nov 2013 at 10:51

[GoogleCodeExporter]

Some things about this issue.

The color management was rewritten several times. I think that I've changed the 
color bar at least three times. And I haven't found that sweet spot where it 
does "just the right thing". So this is The Issue that I want to fix from the 
very early years of ASE/Aseprite. 

There were an ASE version (v0.3.1) where you were capable to select RGBA 
colors. Then I changed it to RGB (opaque colors) and added the Opacity sliders 
(to be more "user friendly"). Finally I saw that the RGBA is "a must" to modify 
pixels in a controlled way, and the Opacity slider cannot solve all the 
problems. (I've found myself using color curves, F9 key, to modify Alpha values 
in the skin.png, such a pain).

Basically this is a problem between "simple UX" vs "versatility" vs "user 
expectation" (and "Photoshop users expectation"). At the moment, my point of 
view is that Opacity slider is not as useful in pixel art as it is in photo 
retouching software, so it's much better to have and handle RGBA color entries 
in the palette/color bar. (Also there are PNG files with Indexed color that use 
different Alpha values in each palette entry, they are not correctly loaded on 
Aseprite.)

In conclusion, both things are necessary: RGBA in color selection/palette, and 
the opacity slider. So we *must* put Alpha back to color selection. Anyway it 
is a *huge* change. I can think about several places to touch/things to do:

* First of all, app::Color doesn't have Alpha, so we have to add the Alpha 
channel right there (independently from app::Color::m_type, the alpha must be 
outside app::Color::m_value union, so it's another field).

* In every single place where an app::Color is used (find/grep), we've to check 
that its Alpha isn't ignored.

* All places where Opacity is consulted (app::IToolSettings::getOpacity()), we 
have to merge the Alpha of the active color with the Opacity slider (e.g. we 
can use INT_MULT(alpha, opacity, tmpvalue) macro defined in raster/blend.h).

* Take care of Alpha in sprite and palette serialization (almost all palette 
formats do not support Alpha per color entry). So we will need some warning 
messages.

* The editor's MovingPixelsState state uses a special color to know what is the 
"transparent color" of the selection, that should be reviewed (e.g. can a 
semi-transparent color be completelly ignored in the paste operation?). (This 
transparent color must be moved to the new ContextBar, this is a thing "to do", 
at least in my head.)

* Review the replace color command.

* Finally -maybe not yet in this issue- we've to add support to save Indexed 
PNG files with Alpha.

Surely a lot of things are missing in this short list, but I think it's a 
monumental task (I don't want to delay 0.9.6 with this issue, the timeline is 
high-priority). Maybe we can divide the task in several steps so you can do 
something with a smaller impact at the very beginning.

Original comment by davidcapello on 23 Nov 2013 at 4:52

• Added labels: Milestone-1.0

[GoogleCodeExporter]

Indeed, I started looking into some of the required changes, starting with the 
sliders, then into Color, and kind of getting bogged down in there.

I've got a branch with a few changes, but not being sure whether opaque Rgb was 
to be kept I opted to add Rgba as a separate color type with its own m_value 
struct. 

I didn't really do a whole lot so I'll go ahead and set that branch aside for 
now.   

Original comment by DocHoncho@gmail.com on 23 Nov 2013 at 5:33

[GoogleCodeExporter]

Issue 134 is related to this one.

Original comment by davidcapello on 26 Jan 2014 at 4:34

[GoogleCodeExporter]

And issue 323 contains a possible (pretty nice) way to edit alpha values 
directly.

Original comment by davidcapello on 26 Jan 2014 at 4:35

[GoogleCodeExporter]

Original comment by davidcapello on 26 Jan 2014 at 4:35

[GoogleCodeExporter]

Original comment by davidcapello on 10 Apr 2014 at 1:05

• Added labels: Milestone-1.1
• Removed labels: Milestone-1.0

[GoogleCodeExporter]

Original comment by davidcapello on 10 Apr 2014 at 1:09

• Added labels: Milestone-1.2
• Removed labels: Milestone-1.1