[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freedesktop-openicc
Subject:    Re: [Openicc] color management on mobile
From:       Chris Murphy <lists () colorremedies ! com>
Date:       2014-04-30 22:32:55
Message-ID: 6E257935-FF5F-4B31-A3BF-A360AAD900AA () colorremedies ! com
[Download RAW message or body]


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

> 
> ----- Chris Murphy <lists@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

_______________________________________________
openicc mailing list
openicc@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/openicc


[prev in list] [next in list] [prev in thread] [next in thread]