[Openicc] color management on mobile

Chris Murphy lists at colorremedies.com
Wed Apr 30 15:32:55 PDT 2014


On Apr 30, 2014, at 2:44 PM, glennrp at comcast.net wrote:

> 
> ----- Chris Murphy <lists at colorremedies.com> wrote:
>> Firefox 29 on Android 4.3 passes the ICC v2 test here:
>> http://color.org/version4html.xalter
>> 
>> I don't know when this behavior started. Maybe it was working with Firefox 28 during Libre Graphics Meeting and I was somehow confusing it with Chrome. It definitely does not pass the test with Chrome on Android.
>> 
>> I'm going to guess that the display profile they're using is sRGB. So anything untagged or tagged sRGB is not transformed. Anything tagged other than sRGB is transformed.
> 
> Firefox has a setting in about:config, "gfx.color_management.mode".
> 
>   0: no color management
>   1: everything is color managed
>   2: (default) only tagged images are color managed
> 
> This arrangement has persisted for more than a decade but I thought it
> was going to be a temporary situation.

Only recently has this done anything on Android though. I just don't know what version it started working.

gfx.color_management.mode defaults to 0 on Android. When I set it to 1 or 2 it doesn't immediately pass the color.org test, I had to force quit the app and relaunch then go to color.org again.

gfx.color_management.enablev4 also seems to work after a force quit and restart.



> See bugzilla.mozilla.org, 
> Bug 621474 - Image displays incorrect with wrong color (png)

That's a different issue altogether. I'm only talking about the surprising fact *any* type of transform is even an option on any mobile platform with any browser.

Thus far I'm only aware of Firefox on Android having this ability. I don't see the behavior, or know of a way to change it, with Chrome on Android. And I'm unaware that it's possible at all with Safari, Chrome, or Firefox on iOS. So maybe someone can test that and report back.

As for this bug, it represents a much bigger problem. The idea has been that we need and want to assume all untagged RGB images are sRGB images; but in reality what we're doing is treating them as displayRGB by not doing any kind of transform when displaying these images.

Since display technologies are diverging from sRGB, rather significantly in some cases, especially with respect to the blue primary, we're rapidly running into the situation where when we finally make a change to do system wide display compensation, it will noticeably impact many users.

Whereas if we'd pulled the trigger on this display compensation before display technologies had widely departed in a meaningful way from sRGB; as they depart from sRGB, display compensation when assure no one noticed it in a meaningful way.

But now we might have dragged feet on this long enough that even if assuming untagged are sRGB is what we want and say we need to do, we might actually see meaningful user revolt if that switch is flipped. It'll just be too big of a change.


Chris Murphy


Chris Murphy



More information about the openicc mailing list