Issue resume: (*) (At least) on Windows 10, 11 (didn’t test other OS) (!) Almost guaranteed on any Aseprite version (tested on v1.3.0, v1.3.5, v1.3.6) (+) Colors properly rendered on Canvas [under Color Management (CM)] (-) But at the same time are visualised wrongly on Palette/Color selector (!) It is a clear oversight that the latter render seems to be a “different process”. And thus, there is hope that a fix may be simple (show “as on canvas”) (!!) This is a universal issue, as indicated by another bug report. Suggested solutions are wrong in principle, which I will briefly explain below (!!) Issue is super urgent, since working CM is required in professional applications
Please, skip answering if not familiar with topic!
Facts to bear:
sRGB colors are usual target. If artist’s Display Profile doesn’t match sRGB, then CM is a MUST.
Thus, in [Edit → Preferences → Color:] the following options MUST be chosen:
[Window Color Profile: “Use Current Monitor Color Profile”] (or, equivalently, “Use Display Profile: …” - thus clarifying it explicitly)
[Working RGB space: “sRGB”]
Under proper CM my display is capable of 99-100% sRGB colors accuracy
However, with such settings, even though colors appear properly on canvas (i.e. correspond to sRGB benchmark of the respective color codes) - they are visualised wrongly on palette/color selector (i.e. are evidently different).
More specifically, they appear NOT as simple “non-CM” colors, but as somehow “over-adjusted” (if it makes sense).
The only simple (&wrong) “solution” is to disable CM (or, equivalently, set Window Color Profile to “sRGB”). Then colors will be same on canvas as on palette/color selector, but will not correspond to sRGB benchmarks (in case of working with “non-sRGB” displays)
This issue basically makes me leave Aseprite and also suggest everyone else to leave :D. If not utilising CM properly it is then a non-professional application, since “wider-than-sRGB” screens nowadays are “the standard” in design.
As you might know we are a small team and we add features/fixes in our possible human times (we are not even able to read all posts/bug reports). The color management feature is not fully completed yet. In the past there wasn’t any option related to color management, and generally sRGB is the common denominator.
To fix these issues we’ll need some help. Generally these problems are reported on Windows, I don’t remember receiving an issue about this on macOS after we added the color management option, but it’s probable that the issue exists in all platforms.
Something that you might share with us is an example image (a .aseprite file) with the ICC of your monitor embedded, a screenshot of your color management preferences, and which specific color/pixel you see different. If you can replicate a screenshot showing the problem that would help too.
CM is applied (with Display Profileutilisied), 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)
bug is evident only when Display Profile is “non-sRGB”
Bug formal description = any color code (as (R,G,B) / HEX / …) is:
(+) correctly rendered in Sprite Editor (i.e. when placed on Canvas) & in Color Picker Area
i.e. color appears as* sRGB-benchmark for this color code
*more specifically, “exactly as it should be assigned by CM Module”
(-!) …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. any color space)
which can be easily verified by an Eyedropper Tool on a screenshot
(as was done in the bug demonstration)
BUG CAUSE & SOLUTION DIRECTION
= any color code is displayed incorrectly in Palette & 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 in Color Bar
Key Logic
simply speaking, what CM Module does is it uses info from Display Profile to temporarily (while viewing) replace any color 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 initial color_code
(here I may also note a constraint condition that all color 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 that DP(R1,G1,B1)= sRGB-benchmark for (R0,G0,B0)
so, what happens with color appearance in Palette & F/B Color Boxes is that respective color codes, while already being in the required “form” (probably after the same step the Sprite Editor visualisation undergoes), are transformed once again by the same CM 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), thus DP(R2,G2,B2)≠ sRGB benchmark for (R0,G0,B0)
“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 resulting Screenshot-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))
more specifically, when I took a Printscreen from Aseprite (under CM) and viewed the resulting Screenshot-image in Krita (under CM) - I noticed that all colors “from” Aseprite Canvas changed to exactly how they appeared directly in Aseprite App’s Palette & F/B Color Boxes.
This proves the point
Note:
In above explanations I implied Target (Working) Color Space being sRGB, which corresponds to Aseprite context. Yet, described logic is expandable to any targets, but with careful minor elaborations
Note on another discrepancy
strictly speaking, color in Sprite Editor (on Canvas) is also a bit “off” from the inputed color code
see first of the attached images
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 simulating sRGB under CM 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 accurately characterized, including calibration to sRGB. As a result, under proper CM 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 and sRGB Working Space) all colors fully correspond to “pure sRGB” display reference
to show the mentioned “double-adjusted” appearance equivalence of the direct Aseprite app Color Bar and the Screenshot from Aseprite Canvas (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 viewing Display Profile my point will be evident
