Color management issues
dacap opened this issue · comments
When the color management (CM) was added, was mainly focused to render images with custom ICC correctly, and convert those profiles to sRGB. There are still issues handling monitor color profiles (because lack of time and hardware to fully test this in all platforms).
Here's a list of issues we've received so far about the current CM feature:
-
One user reported that the issue was still persistent on macOS:
-
Some issues were solved but we don't know what the user exactly did
(if enable CM or disable it): -
Completely wrong colors on Windows fixed disabling CM:
-
Issues copying/pasting images between programs:
-
Latest reports on Windows (color in color bar doesn't match color on canvas):
Regarding latest reports on Windows:
[1] https://community.aseprite.org/t/wrong-colors-on-palette-selector-if-color-managed/21945
[2] https://community.aseprite.org/t/color-on-palette-panel-didnt-same-as-drawing-on-the-canvas-when-use-color-management/15751
I am no developer, so forgive me all that is naive. Yet, I "understand" CM, thus hope my considerations may help
R E S U M E
- Bug = under
Color Management (CM)
color inColor Bar
* is wrong & doesn't match correct color inSprite Editor
(i.e. onCanvas
)- *more specifically, in
Palette
&Foreground/Background Color Boxes
- *more specifically, in
- Bug Cause = color appearance for
Color Bar
essentially undergoes CM-adjustment procedure twice, instead of just once
(see 5. for details) - Bug is significant
- sRGB-benchmarks and thus CM are required professionally
- Bug partly ruins CM experience & limits features use
- Bug has "simple" fix potential
- Correct rendering in
Sprite Editor
implies that incorporatedCM Module
is already realized properly with the only mentioned exception application
- Correct rendering in
D E T A I L S
- Applies to:
- at least Windows 10, 11 (didn't test other OS)
- all Aseprite v1.3+ (tested on v1.3.0, v1.3.5, v1.3.6)
- Bug demonstration
- just see attached giff
- Bug occurs if and only if:
- CM is applied (with
Display Profile
utilisied), i.e. the following setting is chosen:Preferences
→Color: Color Management:
“on”
→Window Color Profile:
“Use Current Monitor Profile”
or, equivalently,“Use Display Profile: <…>”
to clarify it explicitly- Note:
the above along with →Working RGB Space:
"sRGB"
are the only correct settings for viewing colors as close to sRGB-benchmarks as possible on "non-sRGB" displays (which is the purpose of CM)
- Note:
- bug is evident only when
Display Profile
is "non-sRGB"
- CM is applied (with
- Bug formal description
= anycolor code
(as(R,G,B)
/HEX
/ …) is:- (+) correctly rendered in
Sprite Editor
(i.e. when placed onCanvas
) & inColor Picker Area
- i.e. color appears as* sRGB-benchmark for this color code
*more specifically, "exactly as it should be assigned byCM Module
"
- i.e. color appears as* sRGB-benchmark for this color code
- (-!) …while incorrectly rendered (different) in
Palette
&Foreground/Background Color Boxes
- i.e. color appears not as sRGB-benchmark
- moreover, also not as respective "non-CM"-color, i.e. that would be caused directly by the
Display Profile
on the given color code
(see 5. for details) - thus, an actual
color code
of this resulting color is in fact different from the given one (w.r.t. anycolor space
)- which can be easily verified by an
Eyedropper Tool
on a screenshot
(as was done in the bug demonstration)
- which can be easily verified by an
- (+) correctly rendered in
- BUG CAUSE & SOLUTION DIRECTION
= anycolor code
is displayed incorrectly inPalette
&Foreground/Background Color Boxes
since it undergoes CM-transformation for rendering twice instead of just once- i.e., all
color codes
are generally CM-transformed, but then same algorithm is excessively applied (to already changed forms) before showing them inColor Bar
- Key Logic
- simply speaking, what
CM Module
does is it uses info fromDisplay Profile
to temporarily (while viewing) replace anycolor code
in the image by a specifically transformed one. Such that when the latter is input in Display (Profile) the resulting output will be closest possible to sRGB-benchmark of the initialcolor_code
(here I may also note a constraint condition that allcolor codes
must still result in unique colors - to cover all possible sRGB space approximation…yet this is insignificant for the discussion)- lets denote this by:
(R0,G0,B0)
–CM
→(R1,G1,B1)
such thatDP(R1,G1,B1)
= sRGB-benchmark for(R0,G0,B0)
- lets denote this by:
- so, what happens with color appearance in
Palette
&F/B Color Boxes
is that respectivecolor codes
, while already being in the required “form” (probably after the same step theSprite Editor
visualisation undergoes), are transformed once again by the sameCM Module
“algorithm”. As a result, final color appearance is not corresponding to the target sRGB-benchmark due to “over-adjustment”- in notations:
(R1,G1,B1)
–CM
→(R2,G2,B2)
, thusDP(R2,G2,B2)
≠ sRGB benchmark for(R0,G0,B0)
- in notations:
- simply speaking, what
- "Proof" (by equivalent example):
- same happens if you take a
Printscreen
from the (image in) color-managed application (provided a "non-sRGB"Display Profile
). Then resultingScreenshot
-image will have the same color appearance (as was shown in the source app) when viewed in "non-CM"-app, but that exact “double-adjusted” appearance when viewed in "CM"-app- this is because a 'Screenshot'-image has all (
pixels
)color codes
determined as, simply speaking, how they "enter the Display (Profile)" - so, in our example, the 'Screenshot' from "CM"-app will already have all
color codes
transformed ( as(R1,G1,B1)
) and thus will be "double-adjusted" when subsequently viewed in "CM"-app (as(R2,G2,B2)
)
- this is because a 'Screenshot'-image has all (
- more specifically, when I took a
Printscreen
from Aseprite (under CM) and viewed the resultingScreenshot
-image in Krita (under CM) - I noticed that all colors "from" AsepriteCanvas
changed to exactly how they appeared directly in Aseprite App’sPalette
&F/B Color Boxes
.
This proves the point
- same happens if you take a
- Note:
In above explanations I impliedTarget (Working) Color Space
beingsRGB
, which corresponds to Aseprite context. Yet, described logic is expandable to any targets, but with careful minor elaborations
- i.e., all
- Note on another discrepancy
- strictly speaking, color in
Sprite Editor
(onCanvas
) is also a bit "off" from the inputedcolor code
- see first of the attached images
- strictly speaking, color in
- Testing Reproduction
- my results are reproducable by anyone provided with a proper* "non-sRGB" 'Display Profile'
- which is yet a huge restraint
- *proper = precisely
characterised
(via Colorimeter) & capable of accurately simulatingsRGB
underCM Module
- I made exhaustive testing, so quite sure at least in intuition
- my
Display Profile
is “non-sRGB”, approximately AdobeRGB in coverage. Yet, it is accuratelycharacterized
, including calibration to sRGB. As a result, under properCM module
operation, it is able to produce 99-100% sRGB colors accuracy- but, I stress that only under proper CM. Simply speaking, 2^24 bits for colors are otherwise distributed across much larger color gamut and do not coincide with sRGB-ones
- in Photoshop/Krita under CM (with my actual
Display Profile
andsRGB Working Space
) all colors fully correspond to “pure sRGB” display reference
- Google Drive link to my Display Profile ICC file
- my
- to show the mentioned "double-adjusted" appearance equivalence of the direct Aseprite app
Color Bar
and theScreenshot
from AsepriteCanvas
(when viewed in CM-app) - I attached two respective images- on the first one you can also see the small discrepancy mentioned in 6.
- technically speaking, of course those are both
Screenshots
...but I made specific preparations to each. So, if you can view them "under sRGB" you will see them exactly as on my Display...and even for arbitrary viewingDisplay Profile
my point will be evident
- Google Drive link to Aseprite source file [sRGB] & Aseprite source file [my Display Profile embedded]
- my results are reproducable by anyone provided with a proper* "non-sRGB" 'Display Profile'
Thank you very much for your exhaustive report @alwsmog ! We were also able to reproduce the issue on Macos. We will solve it soon.