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.

Rethink the default ink. Now that fg/bg colors have alpha channel, a "Set Alpha" as default ink looks more proper for pixel-art (it could be called like "Simple ink", it just replace the RGBA values in the pixel), and the old "Default ink" should be called something like "Composite ink" with the "Opacity" slider visible.

Rethink eyedropper and "Grab alpha" option. Actually this option set the "Opacity" slider, but now it could indicate to set the alpha channel of fg/bg colors. We could have three modes: "RGBA" (all channels are picked), "RGB" (only color is picked), and "Alpha" (only Alpha is picked), also a combobox to select "Composite" or "Current Layer" to pick colors from the whole sprite composition (with layer blend modes applied) or from the current layer image (without applying opacity/blend modes).

This comment has been minimized.

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 it's already done.)

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.

This include several changes:
- Color::getIndex() can return palette values with alpha != 255
- Fix Transparent and Blurs ink for indexed images to make better use
of palette entries with alpha values
- Fix bilinear resize algorithm for indexed images with alpha
- New RgbMap with four parameters: R, G, B, A
- Add one extra color scale function used in the alpha channel of the
new RgbMap
- Fix color curve, convolution matrix, invert color, and median filters
to take care of this new alpha channel on indexed images
- Fix ordered dithering and quantization
Related to #286

…alues)
Now that we have alpha channel in color selector and palette entries, it's
nice to have as a default ink a more pixel-art friendly, i.e.
an ink that just replace RGBA values instead of doing alpha compositing.
Issue #286