Open Bug 1638048 Opened 4 years ago Updated 8 days ago

Color eyedropper (color picker) copies wrong colors with full color management enabled

Categories

(DevTools :: Inspector, defect, P3)

Product:
DevTools
Component:
Inspector
Version:
77 Branch
Platform:
Desktop
macOS
Type:
defect

Tracking

(Not tracked)

People

(Reporter: me, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

What were you doing?

  1. Open DevTools
  2. Click "Grab a color" button in the inspector tab
  3. Click background of any element with #fff background

What happened?

Color is copied as #feffef (the visible color)

What should have happened?

Color is copied as #fff (the css color)

Anything else we should know?

Setting gfx.color_management.mode to 0 fixes it

Thanks a lot! 😭😭😭 Worked perfectly.

I'm not able to reproduce. From looking at the code that handles the gfx.color_management.mode pref, this seems to trigger pre-multiplication of alpha. If you are placing the eyedropper on something with a CSS color of #ffffff, and you're getting #feffef, that implies a pre-multiplication of the color by some kind of light-purple mostly-transparent color. Very specific. Would you please provide a testcase of the content with the #fff color, and detail your steps to reproduce?

Flags: needinfo?(me)
  1. Open Firefox 77 Developer Editition on macOS 10.15
  2. Set gfx.color_management.mode to value 1
  3. Restart Firefox for gfx.color_management.mode to take effect
  4. Open https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/3.5/ICC_color_correction_in_Firefox
  5. Press F12, click "Grab Color", hover on the page background, it should be something else than #ffffff

I'm using the built-in TrueTone display of a MacBook and have color profile "Generic RGB Profile" set in the OS. I noticed this because 77 enabled the color management by default (https://bugzilla.mozilla.org/show_bug.cgi?id=455077).

Edit: Some more testing results:

#ffffff becomes #fefffe
#eeeeee becomes #e9e9e9
#333333 becomes #262626

Flags: needinfo?(me)

The severity field is not set for this bug.
:gl, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(gl)

I still can't reproduce; not in Nightly, not in DevEdition 77.0b9. It looks like we have problems in this area. The bug that turned this pref on was recently backed out in Bug 1639574. I think we should leave this bug open and retest when the feature is turned on again when Bug 455077 lands (again).

Severity: -- → S3
Depends on: 455077
Priority: -- → P3

Guess-> Eye dropper is copying post-transform RGB, rather than pre-transform.

There's more than one way to do this correctly.

One idea is to make the pasteboard CIE L*a*b* (device independent color), so that it always contains color appearance, no matter the source or destination. But it's a bit of a trap. The difficulty is that if the source object is sRGB and the destination is sRGB, this means two transforms: sRGB->Lab for copy, and then Lab->sRGB for the paste. And with an 8bpc image you'll get quantization, and inevitably some RGB values will have an "off by one" type of error that'll just aggravate people even if they can't see the effect.

If source=destination, do no transforms. Instead copy/paste the original raw values (not the display compensation values).

If source!=destination, transform between those two spaces during the copy/paste, don't include the display profile used for display compensation.

I will not be surprised if all browsers do this wrong. And also that platforms handle color differently as well. Does the system pasteboard include the color space of the pixel values? I don't know for sure if any platform does that, including macOS.

The most common case is going to be sRGB source pasted into an sRGB destination. It'll be sRGB due to assumption, because neither will be tagged as some other color space. So you'll want to do the expected thing there first. And then possibly consider all other scenarios as edge cases worth optimizing for rather than than as disqualifying if not perfectly handled.

And you probably don't want to trust display profiles for any of your transforms, except the ones going to that display for display purposes. Display profiles aren't necessarily well behaved, because they describe a real device. sRGB is predicated on real devices but ultimately it's a synthetic color space that has very consistent and predictable properties.

Some more testing done. I only see the issue when both Firefox's and OS's color management are enabled:

  • Firefox CM on, macOS CM on gives wrong colors in the picker
  • Firefox CM off, macOS CM on is fine
  • Firefox CM on, macOS CM off is fine
  • Firefox CM off, macOS CM off is fine

"macOS CM off" here means the default "Color LCD" display profile. "on" means "Generic RGB Profile". Firefox needs to restart every time for any changes to take effect.

macOS "Generic RGB Profile" isn't useful for anything on the internet. It's using P22 chromaticities, and the TRC is defined by a gamma 1.8 function. That should be set to sRGB. And "Color LCD" is a profile created on-the-fly by the display manager and ColorSync, from the display reported primaries via EDID. This can be reliable, or very unreliable, depends on whether the EDID reported primaries are close to the actual primaries of the display.

Summary: Color eyedropper copies wrong colors with full color management enabled → Color eyedropper (color picker) copies wrong colors with full color management enabled

I'll have to note that I'm not using those OS color profile for any actual color work, it's more of a personal preference. That said, I do care about the color picker representing original source colors when inspecting web sites (and their images) for development work.

Flags: needinfo?(gl)

This is not a bug. Just like Chrome, Color Picker will copy the color after color managment from source profile to display profile. The only color that is usually the same during color managment is black, i.e. "0, 0, 0".

Of course in Photoshop there is an info panel that shows values before color managment, but IMHO, it is a waste of time. Soon many will switch to hardware 3D LUT and it will not matter anymore.

(In reply to val.zapod.vz from comment #10)

This is not a bug. Just like Chrome, Color Picker will copy the color after color managment from source profile to display profile.

Negative.

Showing RGB values in local display space is precisely what color management is trying to avoid. The color picker values should show RGB values in a device independent color space, and the various "standard" RGB's like sRGB/Rec 709, Rec 2020, and so on, are what the RGB's should be predicated upon. The actual RGB values in the file, tagged with one of those color spaces, is what a color picker UI should show. If the color picker RGBs are based on post-transform to display space, then everyone sees different RGB values for the same color appearance.

Of course in Photoshop there is an info panel that shows values before color managment, but IMHO, it is a waste of time. Soon many will switch to hardware 3D LUT and it will not matter anymore.

The day ICC transforms are done in hardware for most users, I'll eat my hat. Until the hardware can accept arbitrary source spaces and intelligently map them to a display profile for the attached display, hardware 3D LUTs have nothing to do with color management except insofar as they can help make the display more consistent (i.e. calibration, not characterization).

The day ICC transforms are done in hardware for most users, I'll eat my hat

You can start right now. My LG C9 supports xvYCC (BT.709 EOTF, BT.1886), sYCC (EOTF from sRGB) and BT.2020 with BT.1886 and HDR with different color spaces inside. Pretty much everything is done by it. With insane 3DLUT calibrated by Calman to deltaE 2000 of 0.5 and DeltaIPT of 3 or less, DeltaIPT means that HDR is also free of errors, as deltaE 2000 is not good for HDR, more like total garbage.

arbitrary source spaces

But 3DLUT can do it. Sigh. And even more.

should show RGB values in a device independent color space

What about CMYK and YCCK in JPEG? Are you proposing XYZ? XYZ will have to be delinearize everything? Also HDR will only have the same XYZ values as if the same output display. I mean it is all doable, sure.

I only see the issue when both Firefox's and OS's color management are enabled

Not the case here on Fedora 33. If I disable the color profile in Gnome for my monitor, the color picker still picks a different color. Color profile + CM has been set up / enabled in Firefox.

Soon many will switch to hardware 3D LUT and it will not matter anymore.

I also regard that as wishful thinking. Color management is not something that your average consumer is even aware of, so they're not likely to look for it in a new display, especially since manufacturers like to charge a premium for it.

I also regard that as wishful thinking.

No, it is not. BT.2020 primaries handling requires 3DLUT on the device anyway, so it is safe to assume all HDR monitors have some kind of 3DLUT. In my case there is full access to 33^3 3DLUT, official, google Calman for LG.

You need to log in before you can comment on or make changes to this bug.