Proper RGBA support #286

Closed
aseprite-bot opened this Issue Aug 20, 2014 · 7 comments

Comments

Projects
None yet
2 participants

From DocHoncho@gmail.com on November 22, 2013 01:56:29

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: http://code.google.com/p/aseprite/issues/detail?id=286


Some subtasks:

  • Add alpha channel in color bar and color selector
  • Save alpha channel in .ase files
  • Load/Save 8-bit png files with different alpha values per palette entry
  • Fix RGB <-> Indexed conversion when alpha is present in the palette
  • Review doc::RgbMap and doc::Palette::findBestfit() when alpha is present in the palette
  • Add an option in color quantization/create palette command to generate color entries with alpha
  • 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).

aseprite-bot added this to the v1.2 milestone Aug 20, 2014

From DocHoncho@gmail.com on November 21, 2013 20:57:26

Issue #231 has been merged into this issue.

From davidcapello on November 22, 2013 02:51:51

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).

From davidcapello on November 22, 2013 20:52:54

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 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.

Labels: Milestone-1.0

From DocHoncho@gmail.com on November 22, 2013 21:33:30

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.

From davidcapello on January 26, 2014 08:34:13

Issue #134 is related to this one.

From davidcapello on January 26, 2014 08:35:02

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

This was referenced Aug 20, 2014

dacap self-assigned this Jun 19, 2015

@dacap dacap added a commit that referenced this issue Jun 30, 2015

@dacap dacap Add support to save .ase files with more than 256 palette color entries
We've added a new chunk type in .ase files to save palettes with alpha
channel, color name, and palettes with more than 256 colors.

Related to #668, #467, and #286
7a63476

@dacap dacap modified the milestone: v1.1, v1.2 Jun 30, 2015

@dacap dacap added a commit that referenced this issue Jul 2, 2015

@dacap dacap Add support for alpha channel in RgbMap and Palette::findBestfit()
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
372d604

@dacap dacap added a commit that referenced this issue Jul 2, 2015

@dacap dacap Adjust default ink to be more pixel-art friendly (just replace RGBA v…
…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
d80b984
Owner

dacap commented Jul 2, 2015

Implemented: 48541af

dacap closed this Jul 2, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment