Re: Color management in web browsers
Re: Color management in web browsers
- Subject: Re: Color management in web browsers
- From: MARK SEGAL <email@hidden>
- Date: Sun, 01 May 2011 08:55:55 -0700 (PDT)
Tom,
What I reject in principle is your apparent view that because a small segment of
the market is affected by these issues their concerns can be set aside.
You are in the colour management business. That business caters to the people
who want colour management, not to whatever percentage of the world doesn't even
know what the term means. By definition your market is a small microcosm of all
the people who look at screens of whatever type. So if that's your market,
that's who you need to satisfy.
By "you" I don't mean you personally - I mean the colour management industry as
a whole, and the committees who advise it.
My display is VERY well colour-managed. Maybe that's the problem - it allows me
to see what's really going on. I do not post ARGB(98) images on a web browser.
I'm talking sRGB.
To be clear, what I mean by "standards" is that I want reasonable consistency
between the colours I create in a Lightroom gallery and how those galleries look
in a web-browser at least on the same colour-managed display (I know they won't
look the same on someone else' non-managed display, but that isn't the
industry's problem, it is the users'.). I get that in Safari, but not in Firefox
and IE. So you are telling me the problem is my display and not the browsers?
How could that be if my display is well-managed, the galleries are created
"web-correct" in sRGB, and they look fine in one browser but not two others? Is
it possible that these browsers are not standards-compliant in terms of how they
render colour? And have you looked into why it can happen that galleries created
with Adobe Flash are even less colour-reliable than standard HTML-based
galleries?
At the bottom of all these questions, the basic issue here is that getting any
kind of consistency between a colour-managed workflow at the (colour-management
aware) photographer's end and what comes out on a web browser is a crap-shoot.
The whole purpose of colour management is that it should be consistent and
predictable. It isn't pilot error, so the industry needs to address why this is
happening, and solve it.
Mark
________________________________
From: Tom Lianza <email@hidden>
To: MARK SEGAL <email@hidden>; edmund ronald <email@hidden>
Cc: ColorSync Users Mailing List <email@hidden>
Sent: Sun, May 1, 2011 9:03:40 AM
Subject: Re: Color management in web browsers
Re: Color management in web browsers Mark and all,
Every wide gamut display that I know of, has an adjustment to Rec.709/sRGB
primaries. Mark, if you carefully prepared your images to CMYK/Fogra39
standards, and someone printed them incorrectly, say to SWOP standards who is at
fault? In your own home, you can adjust your TV to many different looks, none of
which are “standard” because you don’t have the proper tools to set up for the
standard. If you are posting ADOBE RGB images to the web, you are violating the
WEB standard. If sRGB images appear over-saturated and unbalanced, the problem
is with the display calibration, it has nothing to do with a web browser and
definitely nothing to do with standards.
The point is not that “people with standards” are being ignored. The fact is
that some people want to ignore the standard or “improve” the standard without
taking the time to understand the standard, or work on these committees that
produce the standards.
A small fraction of one percent of displays are calibrated today. Even at the
high end, the attach rate for calibration is at best 10% on a model by model
basis. Those who calibrate or set their displays properly will see consistent
display of images, if those who, “carefully controlled hue and saturation for
sharing on the internet” rendered perceptually to sRGB. To be frank, in my own
workflow on the Mac, with an Epson R2400 and HP dreamcolor display, I convert to
profile using the ICC V4 sRGB and print to the printer using the Epson sRGB
setting (printer color management). Setting the dream color to sRGB and
printing to an sRGB standard gives very predictable results in a print path that
is very broken from a color managed standpoint. If I take that mapped image and
put it on the web, it will print reliably on any consumer image printer, because
their default assumption is sRGB. The WEB is output referred, there is a
standard assumption that colors will be mapped in a standard form. If you
depart from this standard, you will get unpredictable results.
The whole sRGB issue has been looked at within the ICC. If you go to
www.color.org and select the “New v4 sRGB profile” link on the right side, you
will see that there are a number of profiles that can be used. The V4 profile
perceptual intent utilized many observers and may output devices in its testing.
If you read the referenced white papers, you will see that it is not a trivial
issue to follow standards.
The web browser is not like an application that runs on your computer. Because
of security standards on the desktop, the browser has no direct access to
memory, files, or display settings. That is all handled by the OS. Whey you
pull down the file menu to print, you inherit all the capabilities that the OS
allows you to inherit, it is not up to the browser. Display color management
is not part of the browser either. The real problem is display calibration at
the end user site.
Mark, I honestly don’t know what principle you are rejecting. If the receiver
has properly adjusted the display for sRGB viewing and you have properly
rendered your images to sRGB, then you have both followed the standard. If you
want to do something else, you are not following the standard. If you want to
change the standard, then you will have to discuss this with the HTML standard
folks and the W3C folks. Don’t blame the vendors for ignoring your vision of
what the standards should be. They don’t write the standards.
Now, if someone said we should revisit the sRGB specification with respect to
the web and latest display technologies, I would work on that problem. The sRGB
spec was CRT display based and there is reason to look at the new technologies
given that the CRT is gone. I think that you find, that there won’t be much
departure from the original sRGB with respect to primaries. There is too much
legacy in video and still photography which both shared those primaries.
Regards,
Tom
On 4/30/11 1:12 PM, "MARK SEGAL" <email@hidden> wrote:
I find this quite astonishing. If I carefully prepare images for web-browsing
which have carefully controlled tonality, hue and saturation for sharing on the
internet, and the result ends-up being over-saturated and unbalanced, as I see
happening in Firefox and Internet Explorer - but interestingly not Safari - I'm
not happy. There seems to be an assumption in certain decision-making quarters
that people with standards are such a small part of the market that their needs
should be ignored. I reject this in principle.
>
>Mark
>
>
________________________________
From:edmund ronald <email@hidden>
>To: Tom Lianza <email@hidden>
>Cc: ColorSync Users Mailing List <email@hidden>
>Sent: Sat, April 30, 2011 11:52:17 AM
>Subject: Re: Color management in web browsers
>
>Tom,
>
> Does this mean that the ICC has no interest in defining guidelines
>and standards for web and on-screen display color management ?
>
>Edmund
> _______________________________________________
>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