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: Sun, 01 May 2011 20:43:20 -0400
- Thread-topic: Color management in web browsers
Hi Mark
“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. “
Mark, that is not the reason the problem is not addressed. It was NEVER
part of the Web specification, that is the reason it is not addressed.
My own feeling is that color management “on the web” will not be handled by
a browser, but by a web application. There are solutions to this, but they
won’t be free.
“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.”
This makes absolutely no sense. Browsers are supposed to display pixel for
pixel color, there should be no “rendering”. If images are converted to
sRGB they should all appear alike on each browser. Color management has
nothing to do with this. I noted that Google chrome uses Quicktime to
preview a tif file in a browser window. There, all bets are off. How does
quicktime manage color? It certainly has nothing to do with the browser
because Chrome is not color managed.
Try running the HTML test on the ICC web site: www.color.org on the right
hand side of the page, there is a link that says “is your system version 4
ready” Load the HTML page into each browser and check the result. That
will tell you if the browser respects profiles in HTML. You can run the
same test for PDF.
Please tell me how you link to a Lightroom gallery in a web browser. I
would like to test this path with some tools that I have.
Regards,
Tom
On 5/1/11 11:55 AM, "MARK SEGAL" <email@hidden> wrote:
> 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 <http://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.
>
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