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
Proper RGBA support #286
Comments
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:
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 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
Implemented: 48541af |
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 Grid settings improvements #58 : Grid opacity value and grid color/opacity in settingsIt 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:
The text was updated successfully, but these errors were encountered: