Wrong colors on palette/selector (if color managed)

Bug Reports
6

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 in Color Bar * is wrong & doesn’t match correct color in Sprite Editor (i.e. on Canvas)
    • *more specifically, in Palette & Foreground/Background Color Boxes
  • 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 incorporated CM Module is already realized properly with the only mentioned exception application

D E T A I L S

  1. 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)
  2. Bug demonstration
    • just see attached giff
  3. 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)
    • bug is evident only when Display Profile is “non-sRGB”
  4. 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)
  5. 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
  6. 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
  7. 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
      • Google Drive link to my Display Profile ICC file
    • 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
    • Google Drive link to Aseprite source file [sRGB] & Aseprite source file [my Display Profile embedded]

Image 1 Direct Aseprite App Appearance
Image 2 Screenshot from Aseprite viewed in CM-app Appearance