Navigation Menu

Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Proper RGBA support #286

Closed
8 tasks done
aseprite-bot opened this issue Aug 20, 2014 · 7 comments
Closed
8 tasks done

Proper RGBA support #286

aseprite-bot opened this issue Aug 20, 2014 · 7 comments
Assignees
@dacap
Labels
feature Feature request, or something should be improved imported medium priority ui
Milestone
v1.1

Comments

@aseprite-bot
Copy link
Collaborator

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:

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 aseprite-bot added this to the v1.2 milestone Aug 20, 2014
@aseprite-bot
Copy link
Collaborator Author

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

Issue #231 has been merged into this issue.

@aseprite-bot
Copy link
Collaborator Author

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

@aseprite-bot
Copy link
Collaborator Author

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

@aseprite-bot
Copy link
Collaborator Author

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.

@aseprite-bot
Copy link
Collaborator Author

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

Issue #134 is related to this one.

@aseprite-bot
Copy link
Collaborator Author

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

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

@aseprite-bot aseprite-bot mentioned this issue Aug 20, 2014
Closed
@dacap dacap mentioned this issue Jun 15, 2015
Open
@dacap dacap self-assigned this Jun 19, 2015
dacap added a commit that referenced this issue Jun 30, 2015
@dacap
Add support to save .ase files with more than 256 palette color entries
7a63476 
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
@dacap dacap modified the milestones: v1.1, v1.2 Jun 30, 2015
dacap added a commit that referenced this issue Jun 30, 2015
@dacap
Add alpha channel to palette/color bar/color selector (issue #286)
318bc2e
dacap added a commit that referenced this issue Jul 2, 2015
@dacap
Add support for alpha channel in RgbMap and Palette::findBestfit()
372d604 
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
dacap added a commit that referenced this issue Jul 2, 2015
@dacap
Add alpha channel in quantization (related to #286)
e9308c2
dacap added a commit that referenced this issue Jul 2, 2015
@dacap
Adjust default ink to be more pixel-art friendly (just replace RGBA v…
d80b984 
…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
dacap added a commit that referenced this issue Jul 2, 2015
@dacap
Modify eyedropper tool to pick colors with alpha and support several …
be67796 
…modes

Issue #286
@dacap
Copy link
Member

dacap commented Jul 2, 2015

Implemented: 48541af

@dacap dacap closed this as completed Jul 2, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@dacap dacap

Labels
feature Feature request, or something should be improved imported medium priority ui
Projects
None yet
Milestone
v1.1
Development

No branches or pull requests
2 participants
@dacap @aseprite-bot