Re: Color management in web browsers
Re: Color management in web browsers
- Subject: Re: Color management in web browsers
- From: Tom Lianza <email@hidden>
- Date: Wed, 04 May 2011 09:39:07 -0400
- Thread-topic: Color management in web browsers
I did a review of browsers on the web using a number of tools that I have at
my disposal. I used my mac and looked and the ICC HtML page and PDF page.
All browsers that defaulted to ADOBE PDF reader, were Version 2 and version
4 compatible. Safari did well with V2 and V4 profiles being respected on
input in HTML. FireFox worked with V2 profiles. While the two browsers
honored the input profiles, there is no data on how they interacted with the
display profile. I think that the PDF viewer was rendering to sRGB without
regard to the display profile. Safari seemed to be using the display
profile, but it could have just as easily used monitor RGB which would be
really bad in a wide gamut display environment.
I have requested that some of the ICC member companies put together an ICC
best practices for the Web guide.
A short list of obvious problems that I have seen in color managed display
environments is inconsistent use of black point compensation and absolutely
random use of rendering intent. This point of disconnect will give
different appearance for well calibrated and characterized displays.
>The most widely cited example
> would be internet purchases of any sort of item that has a color
> appearance.
This argument is a huge red herring. First, the cost of return due to color
deviation is statistically built into the price of the product. Vendors
don't lose money, they make money on this. The problem would still be there
because almost no consumers use color management on their displays. If you
can't demonstrate that the displays are color managed in the field, how does
this argument hold up? Not well.
>
> That seems to fly in the face of many browsers having such a capability,
> not to mention the power of modern GPU's. Even a 3D lookup
> is a minor overhead when encoded as a GPU texture operation.
>
My argument has nothing to do with speed of processing, it has to do with
managing the pixel path and synchronization of display. It is completely
normal to have an video window running simultaneously with still image
advertising on an HTML formatted page. It is the decision to figure out
which elements get CM'd and which do not that impacts the process.
> I understand from recent feedback that (for instance) the
> accuracy of EDID monitor information is better than it has been
> in the past, and provides a starting basis to apply color
> management techniques to the new challenges of wide gamut monitors,
> even in situations where no instrument is available.
This is true only in the simplest sense. Modern monitors have different
EDIDs for Digital and Analog connections as well as different color spaces.
For monitors with Color Space functionality, the EDID should change with
change of color space. The EDID that is contained in the OS descriptor, may
or may not be updated when color space is changed, also a mechanism has to
be provided for registering the profile when a user changes the display via
the OSD. There are no standards in this area.
>I get the impression that the continuing problems with the web and color
> are to do with the default non-tagged RGB _not_ being interpreted as
> sRGB (the de-facto standard) by various applications that participate
> in accessing the WWW.
That's the wrong impression. The W3C spec is clear: all RGB is sRGB. The
real problem is at the display side. The latest round of display GPUs from
NVIDIA and ATI all provide Matrix Shaper capability. There is no common API
on the windows platform for that functionality and it going to be very hard
to figure out what is going on under the hood on non-color managed displays
and it is very unclear how this capability is going to be exploited by the
Video Card vendors. One thing is clear the VCGT tag is not enough. Modern
displays often have 6 Axis color control which renders a V2 profile useless.
In my opinion, the first place to attack is display variability. If you
look at the current CM mess, it will take years to manage to cross all the
boundaries of the standards organizations to get full color management
implemented in all browsers. While safari appears to be color managed, you
still have the issue of display color management and it is not clear how
that is handled in the application and it certain that less than 1% of the
viewing audience has any form of color management software. We have Web
related activities within the ICC but we really don't have a formal Web
group set up yet and I will discuss that with the steering committee. In
the mean time, we are working on tools for photographers to test their
workflows and to get a better idea of the state and magnitude of the
problem.
Regards,
Tom Lianza
On 5/1/11 11:34 PM, "Graeme Gill" <email@hidden> wrote:
> Tom Lianza wrote:
>> I do not believe, personally, that General Color Management should be part
>> of the world wide web. Color management addresses a very small (but vocal)
>> population of users.
>
> Hi Tom,
> I'm not sure how you come to that conclusion. While I'm
> sure it's true that for very many uses of the WWW color is not critical,
> it is of interest to a far wider audience than just color
> specialists or photographers. The most widely cited example
> would be internet purchases of any sort of item that has a color
> appearance.
>
>> Under the best of conditions, color management imparts
>> a performance hit which for most web applications and browsers, is too
>> onerous for general distribution.
>
> That seems to fly in the face of many browsers having such a capability,
> not to mention the power of modern GPU's. Even a 3D lookup
> is a minor overhead when encoded as a GPU texture operation.
>
>> Most important, for color management to
>> work, as defined today, the OS cm system would have to work well, and the
>> user needs a calibrated display. That alone should put a nail in the color
>> managed web coffin.
>
> These are obstacles, but it wouldn't seem to advance the possibility
> of solving these problems to just throw up our hands about it.
> I understand from recent feedback that (for instance) the
> accuracy of EDID monitor information is better than it has been
> in the past, and provides a starting basis to apply color
> management techniques to the new challenges of wide gamut monitors,
> even in situations where no instrument is available.
>
>> Both sRGB and the current Rec. 709 standard for HDTV share the same
>> primaries and similar transfer functions. Hence, properly rendered content
>> should look quite acceptable on a properly adjusted display. Even on a
>> poorly adjusted display, the content will look "as it should". Given the
>> legacy of sRGB images and current video content being produced to Rec. 709,
>> why would anyone, in their right mind, wish to upset the current situation
>> which fits the needs of nearly 100% of the consumers. The web is the
>> equivalent of a "standard printing condition", it is output referred and it
>> was never envisioned to convey color in an editable form for reuse in other
>> environments. This is the wrong venue for color management.
>
> I get the impression that the continuing problems with the web and color
> are to do with the default non-tagged RGB _not_ being interpreted as
> sRGB (the de-facto standard) by various applications that participate
> in accessing the WWW. Given that ICC profiles and raster format
> tags are pretty well established standards, there is no reason why
> such images should not also be rendered in a reasonable way. I don't
> see anything at all that makes images or color value accessed via a browser
> any different from any other image that is being viewed on a user platform.
>
>> Does that mean that there is no solution? Well, the Web Kit is open source
>> and anyone can build a color managed browser if they had the time and money
>> to do so. The question would be, would any one pay 250 bucks for a color
>> managed web browser that offered display calibration and calibrated
>> printing? It would probably take two thousand users to cover the cost of
>> such a development. Is there anyone on this list that would actually pay for
>> the problem to get solved?
>
> I would ascribe the problems more to the ignorance and non-interest of
> the general run of software developers and their management. Too many
> people I suspect, continue to think "RGB is RGB, isn't it ?", and
> don't understand why there should be anything more to it than that.
>
>> Before we whine about the lack of color management on the web or handheld
>> devices, we need to consider the market need and demand. The fact is, that
>> color management does not normally make the image look "better" to most
>> people. Absent that demand, you will not see any work in this area, from the
>> major industry players.
>
> I think it's a matter of frustration to many people that do want some degree
> of accuracy and consistency in color reproduction, that the necessary
> technology
> and standards are well in place, but they are not made use of due to the
> apparent ignorance, "laziness" and belligerence of mainstream product
> developers
> when it comes to dealing with color.
>
> Graeme Gill.
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Colorsync-users mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
The information contained in this e-mail and any accompanying attachments may contain information that is privileged, confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. The company accepts no liability for any damage caused by any virus transmitted by this email or any attachments.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Colorsync-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden