Dan Margulis Applied Color Theory

RGB to RGBConversions

   Date: Thu, 14 Oct 2004 22:46:52 -0000
   From: "David Riecks"
Subject: RGB to RGB conversions, is rendering intent critical?

Here's a question that's stumping me.

A large stock agency is claiming that when making a conversion from a Photographers preferred colorspace (such as AdobeRGB or Colormatch RGB) to their proprietary colorspace, that it must be done using the Perceptual rendering intent.

I know that when converting from RGB to CMYK, that Relative Colormetric is usually the first choice for Rendering intent, so their request threw me for loop.

I just took an RGB image and did two different conversions to the same RGB destination color space. Then dragged one onto the other (holding shift key to pin register). When I click the layer on/off I can't see a difference. I change the layer mode to difference and the image is entirely black... a sign that the layers are identical (or so I seem to recall).

I made a couple of spot checks of some of the more saturated sections and came up with the same RGB values in both layers.

My conclusion would be that rendering intent does not make a difference when converting from one RGB colorspace to another, but maybe I'm missing something.

Anyone care to enlighten me, or confirm my suspicions?

 TIA,

 David
___________________________________________________________________________

   Date: Thu, 14 Oct 2004 17:46:29 -0600
   From: Andrew Rodney
Subject: Re: RGB to RGB conversions, is rendering intent critical?

on 10/14/04 4:46 PM, David Riecks wrote:

A large stock agency is claiming that when making a conversion from
a Photographers preferred colorspace (such as AdobeRGB or Colormatch
RGB) to their proprietary colorspace, that it must be done using the
Perceptual rendering intent.

It1s astounding how clueless some of these agencies are, even HUGE one1s! I can tell you horror stories about how Getty is advising their photographers to handle files. Anyway, ALL conversions from working space to working space or using a Matrix profile uses the Relative Colorimetric (or if you1re looking for something ugly, it1s cousin Absolute Colorimetric) intent. The ONLY table in those profiles is the RelCol table (which is what Absolute is also using). So if you pick Perceptual in say Photoshop, you1re getting RelCol anyway.

I just took an RGB image and did two different conversions to the
same RGB destination color space. Then dragged one onto the other
(holding shift key to pin register). When I click the layer on/off I
can't see a difference.

Because they are identical. You got RelCol with both.

My conclusion would be that rendering intent does not make a
difference when converting from one RGB colorspace to another, but
maybe I'm missing something.

Yes, with simple Matrix profiles. Printer profiles are more complex, larger and do contain the other tables that would allow you to use the other rendering intents.

 Andrew Rodney
http://digitaldog.net/
___________________________________________________________________________

   Date: Thu, 14 Oct 2004 20:07:24 -0400
   From: Henry Davis
Subject: Re: RGB to RGB conversions, is rendering intent critical?

David,

This sounds like a "workflow" issue for the agency.  To make the best choice for rendering, each image would need to be evaluated - one at a time.  Presumably, this agency has volume concerns that make such an approach impractical.  It's is a pity, though, that since their business is images, they cannot offer the best that an image can be.  I have encountered  specs from a number of high profile agencies that come as a surprise.

There wasn't a description given for their proprietary space.  I also wonder if they receive image files that have been goosed up on saturation or otherwise ill-prepared.  If their workflow is automated, then it is probably aimed at doing the least harm to the most images.

 Henry Davis
___________________________________________________________________________

   Date: Thu, 14 Oct 2004 20:07:51 EDT
   From: Dan Margulis
Subject: Re: RGB to RGB conversions, is rendering intent critical?

Andrew Rodney writes,

I can tell you horror stories about how Getty is advising their
photographers to handle files.

I, for one, would be interested to hear them, and suspect others would be as well.

Dan Margulis
___________________________________________________________________________

   Date: Thu, 14 Oct 2004 18:41:50 -0600
   From: Andrew Rodney
Subject: Re: RGB to RGB conversions, is rendering intent critical?

I had a photographer contact me today who was asking about Getty1s 3demand2 that all files uploaded be in a working space they supply called 3Tiff RGB.2 It1s a pretty old color space dating back to Heidelberg1s days (it was created in 1997), has a pretty small gamut (in some areas less then sRGB). This space has a 1.89 gamma which is a bit odd (2.2 is far more perceptually even) and Getty recommends users calibrate their displays to a gamma 1.89 in the incorrect assumption that the display gamma and the working space gamma should match (they don1t need to at all). A 2.2 gamma is much better for both working space and display gamma. Converting files in something more appropriate for pro captures like Adobe RGB (1998) to this space results in some nasty looking histograms and issues in shadows probably due to the odd gamma of the working space mismatches. Getty users would be better served with sRGB. It1s gamma is more appropriate and it1s a slightly larger color gamut. It will preview reasonably well in non ICC aware applications (like a web browser). It1s smaller then CMYK gamut but at least it1s more a standard than this odd working space. On an non calibrated display, this Tiff RGB spaces should look kind of odd. I1m told that Getty uses this space to scan into from their drum scanner (an Heidelberg). I1d probably recommend Adobe RGB (1998) but in this case, even s(Satanic)RGB makes more sense.

Andrew Rodney
http://digitaldog.net/
___________________________________________________________________________

   Date: Fri, 15 Oct 2004 09:18:36 -0000
   From: "lwb_guitar"
Subject: Re: RGB to RGB conversions, is rendering intent critical? (slightly OT)

 I don't want to cause the thread to drift too much so please reply in a different thread if you feel it necessary ...

My observation at least regards rendering intent, so anyway. A while ago I converted a bunch of images to CMYK (using the old Kodak SWOP Press profile, which very closely matches my print shop's output) using the perceptual rendering intent (my logic being that that's the default intent for that particular CMYK profile so should work well with it, and that the images were quite saturated gallery shots and the perceptual intent's gamut handling would serve them well). All of the images got a lot lighter and more contrasty -- to the point where detail in highlights was lost. This made some sense to me as I guessed the perceptual intent was compensating for the general drop in contrast going from screen to paper, but it was quite extreme. The client rejected the first digital proofs as 'too contrasty' and I had to go back and re-separate all the images -- this time I used RelCol, which, on-screen, didn't noticeably change the image going from RGB to CMYK (ie, the highlights stayed where they were).

Is this contrast bump normal with the perceptual intent? I guess it would work well with most photographic-type images, but with my shots (lots of white wall, which lost detail) it was a problem.

Robert Johnston
___________________________________________________________________________

   Date: Fri, 15 Oct 2004 07:01:48 -0700
   From: Doug Walker
Subject: Re: RGB to RGB conversions, is rendering intent critical?

Andrew,

How in the world can Getty be so far off the path.  Don't they read and study this stuff?   I cannot imagine this?  Please help me understand?

 Doug Walker, FP
___________________________________________________________________________

   Date: Fri, 15 Oct 2004 11:38:23 -0400
   From: Henry Davis
Subject: Re: RGB to RGB conversions, is rendering intent critical?

In my opinion, one gross failure in the marketing of color management was the opportunities that were lost with regard to clarifying a complicated subject.  So much noise was disseminated about easy, perfect, push button color that the masses were misled into believing that some magic had solved all color issues.  To have told people that they would have to put their boots on, grab a shovel and work real hard at first, understanding color correction, and then learning color management would have been too much to ask.

From this grew the situation that now exists.  It's not just Getty.  Color is being mis-handled in even more clever and sophisticated ways by people who have never made it their passion to understand color at this level.  I am not anti-color management, but this mis-information has let a lot of horses out of the barn.  What push-button color offers, for lots of designers and print brokers, is just a more interesting blame game.

Besides the color management topic, there are other issues.  I recently was told by a photographer that his agency currently requires larger than 100Mb files as their standard for all submissions.  Photographers hoping to play this game have more time and resources on their hands than I would have thought!  Some of these specs aren't just wrong, they are cruel.

End of opinion.
 
Henry Davis
___________________________________________________________________________

    Date: Fri, 15 Oct 2004 11:23:40 -0500
   From: David Riecks
Subject: Re: RGB to RGB conversions, is rendering intent critical?

 Quoting Henry Davis:

Besides the color management topic, there are other issues.  I recently
was told by a photographer that his agency currently requires larger
than 100Mb files as their standard for all submissions.  Photographers
hoping to play this game have more time and resources on their hands
than I would have thought!  Some of these specs aren't just wrong, they
are cruel.

Henry:

That would be Photonica. The reason for that, from what I gathered, after talking with one of their art directors at last years PhotoPlus, is that this request was marketing driven. In other words, their sales and marketing people get a lot of concern from the clients (end users) about filesize/resolution. So the marketing people saw this as a way to "differentiate" themselves from the crowd using the "bigger is better" mentality.

I agree, it makes little sense, as what's happening in many cases is that photographers are taking digital camera files of 18 or 30+ mb, and interpolating them up to this 100mb standard.

It's not "real" data, anymore than those "enlarged dupes" on 120 film were (when stock agencies enlarged 35mm slides to 6 x 9 cm). The dirty secret is the the vast majority of stock uses are 1/4 page or less, so starting with a 100mb file means more work to bring the image back down to a manageable level.

Given the increase in direct-to-plate printing and stochastic screening, many printers are actually requesting "less" data (ie 240 rather than 300ppi) so this, to me anyway, makes no sense.

David
  ___________________________________________________________________________

   Date: Fri, 15 Oct 2004 08:12:25 -0600
   From: Andrew Rodney
Subject: Re: RGB to RGB conversions, is rendering intent critical?

 on 10/15/04 8:01 AM, Doug Walker wrote:

How in the world can Getty be so far off the path.  Don't they read and
study this stuff?   I cannot imagine this?  Please help me understand?

I wish I knew. I'm hoping to meet with someone representing them at PhotoEast next week in New York and try to unravel the logic.

They just need a copy of Chromix ColorThink I guess.

 Andrew Rodney
http://digitaldog.net/
___________________________________________________________________________

   Date: Fri, 15 Oct 2004 14:48:30 -0700
   From: Dennis Dunbar
Subject: Re: RGB to RGB conversions, is rendering intent critical?

As Andrew explained it is much too often that many organizations show their ignorance instead of their expertise. Several years ago I consulted with a shooter who was with a stock agency (Westlight) that has since been swallowed by one of the giants. When they "adopted" color management they required photographers to use an RGB space they had custom made for them, (I've forgotten the name). Something sounded odd about this custom space, the white point, primaries and gamma were all rather odd settings. As I investigated this I was told they had a "Color Scientist" come in and design this space. Further into the explanation I realized this odd space was designed so images looked acceptable on their non-calibrated monitors.

These experiences just serve as a reminder that keeping yourself educated about the many aspects of our work is even more important now than it ever was before.

Dennis Dunbar
___________________________________________________________________________

   Date: Wed, 20 Oct 2004 16:42:00 +0930
   From: Peter Fakler
Subject: Re: RGB to RGB conversions, is rendering intent critical?

David Riecks wrote:

 A large stock agency is claiming that when making a conversion from
 a Photographers preferred colorspace (such as AdobeRGB or Colormatch
 RGB) to their proprietary colorspace, that it must be done using the
 Perceptual rendering intent.

David, Andrew & all

Now what really stumps me: Why would the agency want photographers to convert their images to a “proprietary” RGB space?

I thought Adobe RGB has become something of a standard with stock distributors?

Peter Fakler
___________________________________________________________________________

   Date: Wed, 20 Oct 2004 05:06:03 -0600
   From: Andrew Rodney
Subject: Re: RGB to RGB conversions, is rendering intent critical?
 
on 10/20/04 1:12 AM, Peter Fakler wrote:

 Now what really stumps me: Why would the agency want photographers to
 convert their images to a “proprietary” RGB space?
 
TIFF RGB? I know all about it. First, hopefully they will make this awful space go away (it1s about as wide as sRGB). Second, all working space conversions use a Relative Colorimetric intent no matter what you pick in Photoshop since this is the only table in a simple matrix profile. Oh, you could pick Absolute Colorimetric since it shares the same table (and you1d get an ugly conversion). They are not getting perceptual!

Andrew Rodney
http://digitaldog.net/  
___________________________________________________________________________

   Date: Wed, 20 Oct 2004 21:35:37 +0930
   From: Peter Fakler
Subject: Re: RGB to RGB conversions, is rendering intent critical?
 
Andrew Rodney wrote:

So all of Getty’s digital images are prepared in / converted to this “TIFF RGB”? Like, what, a few millions of them? I presume they don’t embed a profile either? Getty Images is the biggest player in stock photography. Are they blinded by their success? - Dan must be rubbing his hands in glee...

Peter Fakler
  —
http://ozimages.com.au/portfolio/pfakler.asp
___________________________________________________________________________

   Date: Fri, 22 Oct 2004 10:23:19 -0600
   From: Chris Murphy
Subject: Re: RGB to RGB conversions, is rendering intent critical?

On Oct 14, 2004, at 4:46 PM, David Riecks wrote:

 My conclusion would be that rendering intent does not make a
 difference when converting from one RGB colorspace to another, but
 maybe I’m missing something.

You’re not, it’s actually a little perplexing. A very user friendly implementation of color management would know in advance if the different rendering intents make a difference in a conversion, and not display four options that will only get you two different results. Instead, it should show two options.

CMM’s are expected to do all kinds of things. They’re actually quite complex, doing more than just simple interpolation between data points in a profile. They defer significantly to the gamut mapping dictated by the source and destination profiles. But matrix profiles don’t have gamut mapping built into them. They have a simple definition of color space, basically just primaries, tone response for each channel and white point.

The CMM can become much more involved in gamut mapping when either source or destination profiles are simple matrix profiles. That many of them don’t generate different results depending on the rendering intent doesn’t mean they can’t. So the suggestion of using the perceptual rendering intent is not wrong. Generally, it means you will get the same result as if you’d selected relative colorimetric. And if/when we get CMMs that differentiate between rendering intent settings and apply different gamut mapping models, it’s probably not a bad idea there either because this kind of gamut mapping is dynamic. If properly implemented it would use more gamut compression when mapping from a large source space to a smaller destination space. When this might happen I don’t know, and what roll ICC spec v4 profiles and CMMs play in this I’m not sure either. But through testing, eventually we’ll figure out what makes the most sense regardless of what theories say we ought to do.

Chris Murphy
Color Remedies (TM)
www.colorremedies.com/realworldcolor
___________________________________________________________________________

   Date: Fri, 22 Oct 2004 10:29:37 -0600
   From: Chris Murphy
Subject: Re: Re: RGB to RGB conversions, is rendering intent critical? (slightly OT)

On Oct 15, 2004, at 3:18 AM, lwb_guitar wrote:

 Is this contrast bump normal with the perceptual intent? I guess it
 would work well with most photographic-type images, but with my shots
 (lots of white wall, which lost detail) it was a problem.

Perceptual rendering intent behavior is up to the manufacturer of the profile. They can incorporate any flavoring they want. Either you like it for some images or you don’t. Since this is SWOP based, it does make some sense that it would lighten the separation somewhat, because Relative Colorimetric assumes paper white has an L* of 100, which in SWOP it not the case. A #5 groundwood is rather gray and a little yellow. Therefore Relative Colorimetric separations have a tendency to be a little too heavy on #5 stock.

That your highlight detail is getting clobbered isn’t a good thing. It could be from questionable measurement data, or the contrast boost applied to this intent was too aggressive. Regardless, it’s not good.

Chris Murphy
Color Remedies (TM)
www.colorremedies.com/realworldcolor
___________________________________________________________________________

   Date: Tue, 2 Nov 2004 07:28:16 EST
   From: Dan Margulis
Subject: Re: RGB to RGB conversions, is rendering intent critical?

Before I left for Asia, Peter Fakler wrote,

So all of Getty’s digital images are prepared in / converted to this
“TIFF RGB”? Like, what, a few millions of them? I presume they don’t
embed a profile either? Getty Images is the biggest player in stock
photography. Are they blinded by their success? - Dan must be rubbing
his hands in glee...

The situation is more ironic than gleeful. Both Getty and the other company mentioned earlier that follows the same line have, as far as we know, a system that works well for them internally, but isn’t necessarily compatible with anyone else’s.  Both say to their suppliers, “We are too lazy, or too stupid, or both, to be able to deal with anyone’s RGB definition other than our own. We will not adapt to you, although it would be a snap to do so; instead, you must adapt to us, converting every file on your own system and generating a second file that is of use only to us. If you have trouble keeping the two sets of files straight, or accidentally send us or some client the wrong version, that’s your problem.”

This stance is quite properly condemned by everyone who contributed to the thread. I would point out, however, that only last year, when I attacked two other groups for doing exactly and precisely the same thing, certain color management apologists had a fit. Reason: although the groups doing it were just as lazy and just as stupid and just as burdensome to those sending its files as Getty is, the definition they were imposing on the world was Adobe RGB. And, in one case, the group had put up a web page saying how strongly they supported ICC color management, in much the same way that the Bush administration claims to be strong environmentalists.

http: //www.ledet.com/margulis/ACT_postings/DailyLife/ACT-Deliver-in-LAB.htm

If a group can’t deal with anybody else’s properly profiled RGB files, it’s an anti-ICC color management group, regardless of how strongly it claims to support it.

Dan Margulis
___________________________________________________________________________

   Date: Tue, 02 Nov 2004 07:56:06 -0700
   From: Andrew Rodney
Subject: Re: RGB to RGB conversions, is rendering intent critical?

on 11/2/04 5:28 AM, Dan Margulis wrote:

 The situation is more ironic than gleeful. Both Getty and the other company
 mentioned earlier that follows the same line have, as far as we know, a system
 that works well for them internally, but isn’t necessarily compatible with
 anyone else’s.  
 
The issue is the space they have decided on. It1s got a real small color gamut with a silly gamma.

 Both say to their suppliers, "We are too lazy, or too stupid, or
 both, to be able to deal with anyone’s RGB definition other than our own. We
 will not adapt to you, although it would be a snap to do so; instead, you must
 adapt to us, converting every file on your own system and generating a second
 file that is of use only to us."
 
If the files in question were in Adobe RGB (1998) the basic scenario would be no different in terms of providing a fixed RGB recipe. The recipe would be a lot better (more robust) and flexible.

 Reason: although the groups doing it were just as
 lazy and just as stupid and just as burdensome to those sending its files as
 Getty is, the definition they were imposing on the world was Adobe RGB.
 
Every capture device on this planet produces some flavor of RGB. That being the case, if you1re going to supply RGB, you have to have it in some defined color space with an embedded profile. Adobe RGB (1998) is a vastly better vessel then Tiff RGB or sRGB for reasons that have been discussed too many times here. Some would prefer a wider gamut space (ProPhoto perhaps) or even the capture space from the scanner or camera. Considering that for many, an RGB color space has to be decided upon for a huge group of images and users, the issue isn1t ensuring the files are all in one space but which space. To that end, there is simply no question that Adobe RGB (1998) is a better space then Tiff RGB if the gamma and color gamut of the space is of any concern.

There is no capture device that produces LAB. You have to convert from some flavor of RGB. Converting from Tiff RGB to LAB buys you nothing (no increase in color gamut, a loss of time and bits). The only advantage is you don1t need to embed a profile since LAB (at least in the last few years thankfully) is self defining. Asking Getty to convert all their files into LAB is as silly as converting into Tiff RGB.

Andrew Rodney
http://digitaldog.net/  ___________________________________________________________________________

   Date: Wed, 3 Nov 2004 19:33:59 +1030
   From: Peter Fakler
Subject: Re: RGB to RGB conversions, is rendering intent critical?

Perhaps I should point out, now this thread has been revived, that after a little research I discovered that Getty actually seem to go to rather great lengths explaining to their customers what they need to do in order to get their images displayed (and hopefully printed) as they should. They - in contrast to other stock photo distributors - obviously do embed profiles. Here’s a link to a PDF file:

http: //creative.gettyimages.com/source/services/ColorResources.aspx

I wonder though what the real life implications of their using a rather odd RGB space are. Andrew says TIFF RGB has a smaller gamut even than sRGB. Coincidentally last week’s cover photo of TIME magazine was licensed from Getty. It’s a sunrise - symbolising the morning after election day - which I assume looked quite bright in reality. On the magazine, however, the colors seem rather subdued. Now, of course that effect could easily have been achieved in prepress, but I do wonder whether the magazine might have chosen the image because perhaps it wasn’t as vibrant as other sunrise shots to begin with, and, if yes, if that might have anything to do with Getty’s use of a small gamut space that couldn’t have held a more vibrant sky...? In other words, if that is as saturated as TIFF RGB gets? And if the latter were the case, shouldn’t that cause Getty to miss out on sales of many images conveying brighter messages?

Peter Fakler
  —
http://ozimages.com.au/portfolio/pfakler.asp
___________________________________________________________________________

   Date: Wed, 03 Nov 2004 08:41:00 -0600
   From: David Riecks
Subject: Re: RGB to RGB conversions, is rendering intent critical?

Peter:

While Getty does explain to client "how" they can use the embedded profile, the bigger questions are:

1) do the clients read this information?
2) are the clients at a sufficient knowledge level to “use” this information properly?
3) does their existing workflow honor embedded profiles?

If clients ignore the information, don’t understand color management and routinely ignore embedded profiles then I’m not sure if Getty’s solution is a good one. As Andrew Rodney said, in such a situation sRGB may be a better bet.

Also, do note that the embedded profiles are dropped for all of the images going on their website (previews and thumbnails)!  The file you license presumably has the embedded TIFFRGB profile, but if you were looking at the image onscreen previously (without the profile) you might be in for a different view when opened in photoshop. ;-)

David

David Riecks  (that’s “i” before “e”, but the “e” is silent)
http://www.asmp.org/commerce/digitalps.php
Chairman, ASMP Digital Photography Standards & Practices committee
Chairman, SAA Imaging Technology Standards Committee
___________________________________________________________________________

   Date: Wed, 3 Nov 2004 10:30:37 -0600
   From: Maris Lidaka
Subject: Re: RGB to RGB conversions, is rendering intent critical?

Thank you for this information, Peter. I may disagree with Getty, but thanks to you I know how I can deal with Getty.
___________________________________________________________________________

   Date: Wed, 3 Nov 2004 11:56:57 EST
   From: Dan Margulis
Subject: Re: RGB to RGB conversions, is rendering intent critical?

Peter Fakler writes,

Coincidentally last week’s cover photo of TIME magazine was
licensed from Getty. It’s a sunrise - symbolising the morning after
election day - which I assume looked quite bright in reality. On the
magazine, however, the colors seem rather subdued. Now, of course that
effect could easily have been achieved in prepress, but I do wonder
whether the magazine might have chosen the image because perhaps it
wasn’t as vibrant as other sunrise shots to begin with, and, if yes, if
that might have anything to do with Getty’s use of a small gamut space
that couldn’t have held a more vibrant sky...? In other words, if that
is as saturated as TIFF RGB gets?

No, there’s plenty of brighter colors available in any RGB. The problem with that picture is that they couldn’t cope with the traditional problem of sunrise/sunset images: how do we make the sun as light as possible (which means, white, since 255r255g255b/0c0m0y are the lightest colors we can make) and still retain a feeling of yellowness surrounding it? Because if the sun winds up white, it takes a long time to get dark enough to support a real yellow.

Time used a traditional, inferior solution: they (either explicitly, or in effect) selected out the sun and one small cloud, made them white, then reversed the selection and flooded the image with yellow-orange. As a result, there’s this huge jump from a pure white sun to an edge of around 0c10m80y. The addition of all this yellow-orange makes the blue sky a nasty purple color. Overall, it’s an extremely flat image which has had two areas of pure white artificially added.

I wrote about this particular problem a few months ago. The solution is to do sunset images in LAB—it allows us to specify yellows that are beyond the RGB gamut around the sun, but they convert very nicely and create a natural-looking yellowness.

And if the latter were the case, shouldn’t that cause Getty to miss out on
sales of many images conveying brighter messages?

I gather that this RGB is something similar to sRGB, which is fairly close to the gamut of most CMYK and most monitors. Therefore, the prospective buyer would never know that these “brighter” colors existed, since he would have no way of seeing them on screen or in print.

The problem isn’t whether they’ve chosen a narrow- or wide-gamut RGB for their own use, the problems are: 1) they’re apparently asking clients to adjust to an RGB that nobody else uses, and most clients aren’t sophisticated enough to know how to do it; 2) they’re forcing their photographers to use it also, when they could very easily just accept it in whatever RGB the photographer has decided to use and convert it themselves.

Dan Margulis
___________________________________________________________________________

   Date: Thu, 4 Nov 2004 12:05:08 +1030
   From: Peter Fakler
Subject: Re: RGB to RGB conversions, is rendering intent critical?
 
So wouldn’t it be better if the industry agreed on standards?

Microsoft et al. apparently have succeeded in pushing sRGB as the standard for the web (internet), which seems to be a good thing, no?

Wouldn’t it be good for the stock photo industry to agree on a standard color space for digital images as well?
 
Peter Fakler
___________________________________________________________________________

   Date: Wed, 3 Nov 2004 22:13:18 -0700
   From: Ron Kelly
Subject: Re: RGB to RGB conversions, is rendering intent critical?

Peter:

Yes, that could be a very productive idea.

Until Microsoft decides to submarine the new standard as they have so many times already. What we get is really the Microsoft standards; resistance is futile.

Maybe now you’ll understand how we in Canada feel given the US elections; Dubya is running the show down there but we’re not all that enthusiastic up here. Go figure.

Another Four Years; enjoy.

Ron Kelly
___________________________________________________________________________

   Date: Thu, 04 Nov 2004 07:08:57 -0700
   From: Andrew Rodney
Subject: Re: RGB to RGB conversions, is rendering intent critical?

on 11/3/04 6:35 PM, Peter Fakler wrote:

Microsoft et al. apparently have succeeded in pushing sRGB as the
 standard for the web (internet), which seems to be a good thing, no?
 
Until the web is color managed, yes. Right now there are only a few browsers, mostly if not totally on the Mac that are able to be color managed (they either recognize embedded profiles in web graphics or assume sRGB for untagged files). And in a way, until modern display technology makes leaps and bounds in the gamut they can produce (and we1re getting there), assuming sRGB as the 3typical PC CRT display2 works pretty well for the masses.
 
 Wouldn’t it be good for the stock photo industry to agree on a standard
 color space for digital images as well?
 
Much harder. Since a stock image has multiple if not thousands of possible output uses. The working space will have a role in what happens upon output. To what device? So a standard for the web is a lot simpler.

Andrew Rodney
http://digitaldog.net/
___________________________________________________________________________

   Date: Fri, 05 Nov 2004 19:26:53 -0500
   From: Dan Margulis
Subject: Re: RGB to RGB conversions, is rendering intent critical?

Peter Fakler writes,

Wouldn’t it be good for the stock photo industry to agree on a standard color space for digital images as well?

It would be good for *everybody*, as the color management community, however tardily, has finally realized. There has to be a universal RGB, and those who don’t care to use it have to be responsible for seeing that their personal definition of RGB doesn’t get them into trouble down the line. It doesn’t matter what the standard is, it could be Apple RGB or Adobe RGB for all I care, but as it happens sRGB has won out.

This is the ultimate repudiation of the 1998 decision to *eliminate* just such a standard in the name of the ICC revolution. The standard was Apple RGB, or something very close to it. People could use, with some difficulty, any other RGB definition they liked, but it would be up to them to see that anyone they passed the file to understood what was going on. The remaining 99 percent of users could just give “Photoshop RGB” without any danger.

In Photoshop 5, this sensible system was torpedoed. The old default was eliminated and people were invited to change to any of a number of different RGB definitions. The whole concept was described by Andrew Rodney and other ICC zealots at the time as “genius” because an embedded profile would ensure an unambiguous transfer of RGB files regardless of definition, and because they believed that Adobe could dictate workflow to the market.

Those who knew anything about how the world works realized at the time that this naive idea would never work, because embedded profiles would catch on as a way to pass files among strangers. Instead of a situation where 99% of RGB transfers between strangers were safe and required no discussion, Adobe had substituted a workflow that required human intervention in *every* RGB transfer to make sure that the recipient knew how to handle it. Chaos resulted, but Andrew and the others insisted that this was the wave of the future and that resistance was futile. In 2000, I wrote,    

"I suspect that eventually the [Conventional Color Management Wisdom] will evolve to the point that it will understand that in this area, agreement is better than disagreement. I don’t endorse sRGB, but if everyone in the world used sRGB, that would be a far superior state of affairs to today’s sorry one. I reiterate a statement from Professional Photoshop 5 [1998]: 'To trash a nearly universal standard in favor of such an every-man-for-himself situation is a blunder, no matter the rationale. But to replace it in the name of device independence, that takes a calibrationist.'"

The ICC partisans nevertheless clung stubbornly to the idea that without an embedded profile, an RGB file is "mystery meat," no matter how obvious it became that the idea of universal acceptance of embedded profiles had gone the way of John Kerry. This year, after Apple, in accordance with this theory, treated untagged RGB as meaningless mystery meat in its Safari browser, the more sensible color management advocates realized the error of their ways. Bruce Fraser finally adopted the position that an untagged file should be considered an sRGB file. And just a couple of days ago on the ColorSync list, David Tobie, a prominent ICC apologist, opined,

"I think we may need to just get over it and accept the value of a universal untagged standard, with proper treatment for tagged files."

While these sentiments come more than six years too late to do much good, they are certainly welcome.

Dan Margulis
___________________________________________________________________________

   Date: Fri, 05 Nov 2004 18:26:44 -0700
   From: Andrew Rodney
Subject: Re: RGB to RGB conversions, is rendering intent critical?

on 11/5/04 5:26 PM, Dan Margulis wrote:

As usual, when discussing color management (or 3obscure2 color models like RGB), Dan simplifies the reality.

 There has to be a universal RGB, and those who don’t care to use it have to be
 responsible for seeing that their personal definition of RGB doesn’t get them
 into trouble down the line. It doesn’t matter what the standard is, it could
 be Apple RGB or Adobe RGB for all I care, but as it happens sRGB has won out.
 
That1s like suggesting there has to be a universal CMYK. RGB can come from any number of input or output devices. There are just as different from each other as all the flavors of CMYK (which can only be an output color space).

 This is the ultimate repudiation of the 1998 decision to *eliminate* just such
 a standard in the name of the ICC revolution. The standard was Apple RGB, or
 something very close to it.
 
Until Photoshop 5, no one knew what Apple RGB was. It was 3supposed2 to represent the Apple 13 display of years gone past. Anyone that thinks that every Apple 13 display (with NO modification of the on board controls) produced identical color from the same set of numbers deserves beach front property in New Mexico. Every 13 inch Apple display was different. Prior to Photoshop 5 any number of users could send identical files to any number of these displays and see different color from the same set of numbers. What1s wrong with this picture? Well for one, it1s the problem with both RGB and CMYK which is the fact they are both a device dependent color spaces. You want device independence, you need a color model that1s totally synthetic and doesn1t respond based on any real world physical device. LAB which is so lovely mentioned on this very color theory site is such a color model.
 
 People could use, with some difficulty, any other RGB definition they liked,
 but it would be up to them to see that anyone they passed the file to
 understood what was going on. The remaining 99 percent of users could just
 give “Photoshop RGB” without any danger.
 
And 100% saw different color from the same numbers.
 
 In Photoshop 5, this sensible system was torpedoed. The old default was
 eliminated and people were invited to change to any of a number of different
 RGB definitions. The whole concept was described by Andrew Rodney and other
 ICC zealots at the time as “genius” because an embedded profile would ensure
 an unambiguous transfer of RGB files regardless of definition, and because
 they believed that Adobe could dictate workflow to the market.
 
It is genius. You just don1t get it yet. What Adobe did was first say that we need to divorce the display with all it1s different possible behaviors, kinks and idiosyncrasies from how we view and edit our files. We need some kind of method of viewing on a device that can ONLY deal with RGB (our displays), a device independent color space, both RGB and CMYK files could be viewed on. That means coming up with synthetic RGB spaces. Cousins to LAB if you will. Quasi-Device Independent RGB spaces we edit our files in that is totally independent of our individual displays. Spaces that are not based on any device. OK, which one? Apple RGB? What if you want a wider gamut container to convert from your capture device that can be used on an output device? OK, Wide Gamut RGB? Too wide for some users since the display has a fixed gamut and it contains colors we can1t preview. How about sRGB? Again, too small for some.

Dan, there ARE NO PERFECT RGB working spaces. If there were, we1d only use one. It1s simply insane to suggest that one RGB space be perfect for all users to convert their original data into. It1s like suggesting we have one CMYK space because it1s easy, and everyone should then attempt to screw around with all the different printers on the planet to work with that single CMYK space correctly. How is CMYK immune fro all this?

Embedded profiles do make RGB and CMYK mystery meat have a meaning. What does R200/G89/B82 look like? It can look vastly different in any number of situations. Numbers don1t tell us what a color looks like! I1d expect that someone that discusses color theory would make this clear.

 Those who knew anything about how the world works realized at the time that
 this naive idea would never work, because embedded profiles would catch on as
 a way to pass files among strangers.
 
You can put your hands over your ears and eyes and hum loudly and say this but it isn1t true, doesn1t have to be true and as yet, you1ve never told anyone a better alternative. One that ensures I can send a file full of nothing more than numbers to hundreds of users and they will all see and output the numbers identically. Again, a digital image without an embedded profile is just a big pile of zero1s and ones. That1s all computers understand. It1s no different if we1re talking about an RGB or CMYK file or an Excel spreadsheet.
 
 Instead of a situation where 99% of RGB transfers between strangers were safe
 and required no discussion, Adobe had substituted a workflow that required
 human intervention in *every* RGB transfer to make sure that the recipient
 knew how to handle it. Chaos resulted, but Andrew and the others insisted that
 this was the wave of the future and that resistance was futile.
 
You can ignore the facts that numbers without meaning will look and output differently on every users system and suggest that somehow that1s a useful and good workflow. How many sensible people on this list would agree? How many will allow me to send them both an untagged RGB and CMYK document and agree to have those numbers appear on screen or output identically to all the others who receive those files?
 
 The ICC partisans nevertheless clung stubbornly to the idea that without an
 embedded profile, an RGB file is “mystery meat,” no matter how obvious it
 became that the idea of universal acceptance of embedded profiles had gone the
 way of John Kerry.
 
How on earth do we ensure that all the RGB data being created ends up in sRGB? In fact, without an input profile that describes the original RGB data crated by the scanner or digital camera, how can we convert into sRGB? What if a lot of users need a space that has a wider gamut? What if I have this universal sRGB file on my Mac and my PC but the software doesn1t understand what sRGB is? They will simply look different from each other. How was funneling the color into sRGB help us here?
 
 This year, after Apple, in accordance with this theory, treated untagged RGB
 as meaningless mystery meat in its Safari browser, the more sensible color
 management advocates realized the error of their ways. Bruce Fraser finally
 adopted the position that an untagged file should be considered an sRGB file.
 
Only if they really ARE in sRGB. How can you be sure? The idea here is to use untagged files in an environment where color management doesn1t yet exist in 90%+ usage; the internet. So we have to pop images on the web and most users are ONLY outputting that to their displays (most not calibrated) in web browsers that don1t1 work like Photoshop and just send the numbers to the screen. There1s no reason to worry about someone needing a wider gamut color space, the output is fixed (like a press, why not universal CMYK?). The best solution at this time is to ensure all files are actually IN sRGB and upload them to a web page and no, you don1t need an embedded profile because:

A. The file is in it1s output space and B. The profile even at 4K takes up space that we don1t want on the web (folks are still on dial up, bandwidth is an issue).

This is no different then when I send a color managed file to a press I1ve profiled. No need to embed the profile. The numbers are correct for that output. The profile only adds size to 1000 images going into my book and no one will open, view or convert that data. It1s NOT CMYK mystery meat since it1s fixed to go to the output device with the correct set of numbers. It1s only CMYK mystery meat IF someone at the printers does what they are instructed not to do; open, view and alter those numbers. Again, you1re misunderstanding or quoting Bruce.
 
  And just a couple of days ago on the ColorSync list, David Tobie, a
 prominent ICC apologist, opined,
 
 “I think we may need to just get over it and accept the value of a universal
 untagged standard, with proper treatment for tagged files.”
 
FOR THE WEB. You1re again either not reading the entire post or misunderstanding Tobie.

What would be useful would be color aware browsers. They are far and few between (non exist that I know of on the PC).
 
Andrew Rodney
http://digitaldog.net/
___________________________________________________________________________

   Date: Mon, 8 Nov 2004 12:01:50 -0700
   From: Chris Murphy
Subject: Re: RGB to RGB conversions, is rendering intent critical?

On Nov 5, 2004, at 5:26 PM, Dan Margulis wrote:

 Those who knew anything about how the world works realized at the time
 that this naive idea would never work, because embedded profiles would
 catch on as a way to pass files among strangers. Instead of a
 situation where 99% of RGB transfers between strangers were safe and
 required no discussion, Adobe had substituted a workflow that required
 human intervention in *every* RGB transfer to make sure that the
 recipient knew how to handle it. Chaos resulted, but Andrew and the
 others insisted that this was the wave of the future and that
 resistance was futile.

And it has been proven that resistance was futile, because like it or not this is how people work today and if they ignore embedded profiles they do so at their own peril to the point where they become active saboteurs. The way things were before is that you only got this “safe, no discussion” transfer method if you were willing to give up any sense of similarity between display and print.

Now, total capitulation to the notion of fully embedded workflows being the saving grace is also proven futile. But that’s primarily due to Adobe first making it the default to ignore embedded profiles even in RGB images until Photoshop CS, and even in CS it’s a single option to go from honoring embedded RGB profiles to ignoring all them (or converting based on them). These are very extreme options to put into the hands of the average user.

It’s fair to argue the decisions that were made to transition away from the old paradigm to a new one were, in hindsight, not all good decisions. But it’s not fair to imply that the old way itself was without flaws that desperately needed fixing.

 The ICC partisans nevertheless clung stubbornly to the idea that
 without an embedded profile, an RGB file is “mystery meat,” no matter
 how obvious it became that the idea of universal acceptance of
 embedded profiles had gone the way of John Kerry. This year, after
 Apple, in accordance with this theory, treated untagged RGB as
 meaningless mystery meat in its Safari browser, the more sensible
 color management advocates realized the error of their ways.

Actually it’s worse than that. In some cases “Monitor RGB” is assumed as source (which means it’s different on every machine as well as being different day to day on the same machine if you change displays or recalibrate/reprofile), and in other cases it’s assumed to be Generic RGB. The general rule of thumb, for which I’m sure there are exceptions, untagged RGB in a PDF is assumed to be Generic RGB, unless it’s a raster PDF, and everything else (JPEG, TIFF, etc.) are assumed to be Monitor RGB. Safari isn’t the only application affected by these series of assumptions.

Apple seems bent on insisting its decisions are right, everyone else is wrong, and they’re thus far unwilling to demonstrate how they came to their conclusions. They haven’t provided a compelling case at all.

Chris Murphy
Color Remedies (TM)
www.colorremedies.com/realworldcolor
___________________________________________________________________________

   Date: Mon, 8 Nov 2004 12:22:49 -0700
   From: Chris Murphy
Subject: Re: RGB to RGB conversions, is rendering intent critical?

On Nov 5, 2004, at 6:26 PM, Andrew Rodney wrote:

 Dan, there ARE NO PERFECT RGB working spaces. If there were, we’d only  use
 one. It’s simply insane to suggest that one RGB space be perfect for  all
 users to convert their original data into. It’s like suggesting we  have one
 CMYK space because it’s easy, and everyone should then attempt to screw
 around with all the different printers on the planet to work with that
 single CMYK space correctly. How is CMYK immune fro all this?

My understanding of Dan’s position is that there should be no RGB mystery meat. That is, if there is an untagged file, every OS and application should have long ago agreed on how to handle such images instead of allowing each application, OS, or user to specify something else as the assumed source. The exact assumed source is not as important as the consistency. Therefore it’s agreed that there’s no such ideal space, and that’s actually a major point: IF you do not like it, then don’t distribute untagged files.

It’s not one of mandating conversions to sRGB, or mandating sRGB workflows (or any other space), just that there is effectively no untagged image. Something is assumed and that something is the same everywhere, or that vendor gets castrated. (A figure of speech of course.)

The previous notion was “if you don’t like random disasters, embed a profile.” The one he’s talking about is “if you don’t like xxxx space, which will be assumed if the file is untagged, then tag the RGB image with something else.”

I assume he agrees with threats of dismemberment for all OS/applications that subsequently ignore embedded profiles in favor of xxxx space. Because if we don’t have some implied violence it seems people these days just don’t get along.

To me it makes sense these space should be sRGB because it’s expected to remain the target space for the average display for at least the rest of this decade. It will be vastly easier to shift to its successor if there is already a precursor in place.

I find myself pondering if there are examples of why we need to have a user definable (i.e. non-sRGB) assumed source space. For CMYK clearly we need to have assumed source space workflows because we don’t want to have to embed upwards of 3MB of profiles in 1000 images destined for the same page layout document where that profile can be assumed once for all 1000 images. For RGB I’m less concerned because the appropriate spaces to use are less than 4K in size. If it’s valuable, I think it’s for the vast minority and therefore should be an advanced as well as “secret” feature out of the prying eyes of average Joe User.

And sRGB makes the most sense for this because it’s well documented, has reasonable licensing terms, and has some basis in reality that can be demonstrated. Apple RGB and Generic RGB each have two definitions. Generic RGB’s two definitions are not backed by documentation as to why they should exist, let alone be used.
 
Chris Murphy
Color Remedies (TM)
www.colorremedies.com/realworldcolor
___________________________________________________________________________

   Date: Mon, 8 Nov 2004 12:13:18 -0800
   From: Roger Howard
Subject: Re: RGB to RGB conversions, is rendering intent critical?

On Nov 8, 2004, at 11:01 AM, Chris Murphy wrote:

 Actually it’s worse than that. In some cases “Monitor RGB” is assumed
 as source (which means it’s different on every machine as well as being
 different day to day on the same machine if you change displays or
 recalibrate/reprofile), and in other cases it’s assumed to be Generic
 RGB. The general rule of thumb, for which I’m sure there are
 exceptions, untagged RGB in a PDF is assumed to be Generic RGB, unless
 it’s a raster PDF, and everything else (JPEG, TIFF, etc.) are assumed
 to be Monitor RGB. Safari isn’t the only application affected by these
 series of assumptions.

John Gnaegy just explained that all Apple tools assume Monitor RGB for untagged elements (but third parties are free to invoke Default RGB) - is this not the case? I hope John at least knows what his company’s apps are doing with color.

 Apple seems bent on insisting its decisions are right, everyone else is
 wrong, and they’re thus far unwilling to demonstrate how they came to
 their conclusions. They haven’t provided a compelling case at all.\

I disagree with this final assessment; I think the logic of Monitor RGB for browser elements has been explained, most recently by me - I believe it’s clearly an artifact of the reality that if we went this way - assuming sRGB for untagged images in Safari today - then design continuity would be broken with any non-image content. That means HTML elements, Quicktime, Flash, and Java; until those (and *all*) media in OSX is color managed, so that we can apply the same policy (assume sRGB for untagged elements) then switching to sRGB for just images is even worse. I’m all for sRGB as the baseline assumption, but it has to be consistent for ALL elements that display color; when Quicktime, Flash, Java, HTML, etc elements can all have the same color policy I’ll be all for it. Until then, an RGB value in HTML, Quicktime, Flash, etc, has to render the same - and the only way to do that is with Monitor RGB.

In a nutshell - I believe assuming sRGB for untagged elements from the Web (at least - just trying to contain the scope of this thread!) is the proper behavior; when Apple can apply this policy to ALL elements that are rendered in the browser, then I’ll be all for it. Right now, many technologies like Quicktime and Flash render direct to the screen, with no color matching, so effectively they are being displayed in Monitor RGB; if Apple can fix this (surely they can for Quicktime at least) then they should; but we can’t break color matching between elements in a browser, or Web color mgmt will be taking a big step backwards in public opinion (if you want to see Web designers flee from the Mac even more, go for it).

-R
___________________________________________________________________________

   Date: Mon, 08 Nov 2004 13:59:08 -0700
   From: Andrew Rodney
Subject: Re: RGB to RGB conversions, is rendering intent critical?

on 11/8/04 12:22 PM, Chris Murphy wrote:

 To me it makes sense these space should be sRGB because it’s expected
 to remain the target space for the average display for at least the
 rest of this decade.

Maybe, at least for consumers. I was at a meeting of the ICC Saturday and Tom Lianza had a very interesting presentation suggesting that due to the on-coming wider gamut display technology as well as the assumption of the luminance of sRGB behaving displays, sRGB will be a standard assumption that will go the way of the do-do bird. How long that will take is up to debate. It will eventually happen.

 It will be vastly easier to shift to its successor
 if there is already a precursor in place.

The suggestion was that should be Adobe RGB (1998).

Andrew Rodney
http://digitaldog.net/
___________________________________________________________________________

   Date: Tue, 9 Nov 2004 12:12:52 -0700
   From: Chris Murphy
Subject: Re: RGB to RGB conversions, is rendering intent critical?

On Nov 8, 2004, at 1:59 PM, Andrew Rodney wrote:

 Maybe, at least for consumers.

In what instance would there be a professional exemption? What is the scenario, in a professional context, where we’d see an untagged TIFF or JPEG? I can think of only one scenario where it’s fairly easy for this to happen and that’s scanning. We still have untagged data sent by scanner plug-ins into Photoshop which then leaves that document untagged, and that’s a rather straightforward problem to solve. If the plug-in vendors aren’t going to use an API that’s existed for years and at least three incarnations of Photoshop to tag incoming data, then it’s going to be assumed to be sRGB. If someone doesn’t like it, they need to write their software correctly.

In the cases where sRGB is not a good assumption, but is assumed anyway because of this across the board rule, at least we have something consistently bad in the same way rather than randomly bad which is where we are at today.

 The suggestion was that should be Adobe RGB (1998).

It’s great there is some foresight being considered. But in the what about the here and now? Do we get to just wish upon a star and hope this problem will be solve a decade from now when there isn’t even the slightest effort to come up with a solution for the problem today? Is it at all logical to think the problem will be easier to solve a decade from now?

1. Why Adobe RGB (1998) when in 2008, the earliest date at which this would matter, Adobe RGB (1998) will be ten years old?

2. There is a difference between the color space of the display, and the color space to assume for untagged images. The two don’t become related immediately upon the introduction of new wider gamut displays. It makes no sense to start assuming everything untagged is suddenly Adobe RGB (1998) when most things will still display, capture, and print with some loose semblance of sRGB.

3. Today we are already faced with three officially recognized assumed source profiles to use for untagged content. sRGB, Display RGB, and Generic RGB.

On Windows, for display purposes it’s Display RGB, so that there is a null transform. But for printing, it’s usually sRGB. On the Macintosh, for display purposes it’s Display RGB, in order to get the null transform, but for printing it’s usually Generic RGB depending on the application and print driver settings at the time. Fact is, we have competing assumptions that are not interoperable and it has caused an interoperability problem.

The choices for color spaces has exploded, making the handling of files vastly more complicated because the expectation is that the user will have to choose a space that does the best job with a particular untagged image.

In any event, we should be having this discussion now, and getting the behavior inserted into the next major releases of operating systems. The longer we wait the bigger the problem will be when we have a huge stack of legacy untagged images and no mechanism to differentiate those from the new stack of untagged images which will eventually need a different source space. We already have a problem today, it will only get worse in the future. What specific space to use is by far the easiest question to answer. The model of assumption and under what cases there are exceptions, is not as easy.
 
Chris Murphy
Color Remedies (TM)
www.colorremedies.com/realworldcolor
___________________________________________________________________________

   Date: Tue, 09 Nov 2004 12:41:26 -0700
   From: Andrew Rodney
Subject: Re: RGB to RGB conversions, is rendering intent critical?

on 11/9/04 12:12 PM, Chris Murphy wrote:

 In what instance would there be a professional exemption?

A professional using one of the newer displays that are producing Adobe RGB (1998) gamuts. According to Tom, sRGB assumes a certain luminance that’s way too low for today’s assumption of sRGB (based on CRT behaving displays).

 What is the scenario, in a professional context, where we’d see an untagged TIFF or
 JPEG?

Well from a heck of a lot of digital cameras where the matrix was set to capture sRGB and there’s no embedded profile or metadata. I suspect there are a few pro users who don’t embed profiles (based on some of the sampling I’ve heard around these parts...)

 In the cases where sRGB is not a good assumption, but is assumed anyway
 because of this across the board rule, at least we have something
 consistently bad in the same way rather than randomly bad which is
 where we are at today.

I don’t disagree at least today. I’m suggesting that in 3-5 years, maybe less, the assumption could be made for Adobe RGB (1998) when it’s common for displays to handle that color space.

Andrew Rodney
http://digitaldog.net/
___________________________________________________________________________

   Date: Tue, 9 Nov 2004 14:31:36 -0700
   From: Chris Murphy
Subject: Re: RGB to RGB conversions, is rendering intent critical?

On Nov 8, 2004, at 1:13 PM, Roger Howard wrote:

John Gnaegy just explained that all Apple tools assume Monitor RGB for
untagged elements (but third parties are free to invoke Default RGB) -
is this not the case? I hope John at least knows what his company’s
apps are doing with color.

Untagged RGB content in PDF’s is assumed to be Generic RGB. Untagged RGB content submitted by an application for printing is assumed to be Generic RGB.

I disagree with this final assessment; I think the logic of Monitor RGB
for browser elements has been explained, most recently by me - I
believe it’s clearly an artifact of the reality that if we went this
way - assuming sRGB for untagged images in Safari today - then design
continuity would be broken with any non-image content. That means HTML
elements, Quicktime, Flash, and Java; until those (and *all*) media in
OSX is color managed, so that we can apply the same policy (assume sRGB
for untagged elements) then switching to sRGB for just images is even
worse.

I’m referring to the colossal mistake Apple made from the beginning with Mac OS X to preserve the legacy 1.8 display gamma, and their instance on using Generic RGB as an assumed source whenever they don’t use Display RGB. Both of these decisions were, in my opinion, made in a vacuum. Apple has not demonstrated how they came to their conclusions, other than one of ideology.

That error has led them to into the current situation where the fixes aren’t as easy. The easiest solution at this point is just a basic gamma correction. A couple of developers told me that this could be done using OpenGL which is what QuartzExtreme is based on. Any series of objects for rendering could have a gamma correction applied to it. This is the minimum requirement by the W3C. They do not require a full color space transform. The difference between the average unaltered Macintosh display behavior and sRGB is that of display gamma, not so much the primaries. I’m not a programmer so I don’t know if Apple could do this.

Next in line would be to teach OpenGL color management, and have all of these transforms occurring at the rendering level within graphics card. It makes sense to off load display compensation onto the GPU. I know this has been talked about, but I don’t know the status of it. It seems to me this would be a great way for the OS to take control of color and do things uniformly for all applications. If the app doesn’t specify a source space, then the OS assumes sRGB. And actually Apple could then give all of its UI content an exemption, to avoid every single element being color managed. I wouldn’t mind seeing this as a choice, but I’d like to know what the performance impact would be. It would come in handy for dual display usage, to have all elements compensated for.

Next is dump the 1.8 legacy gamma altogether - but I suspect this will fade into irrelevance rather than suddenly go away. The UI people would have a cow because they’d have to redesign the entire UI for the new display gamma.

In a nutshell - I believe assuming sRGB for untagged elements from the
Web (at least - just trying to contain the scope of this thread!) is
the proper behavior; when Apple can apply this policy to ALL elements
that are rendered in the browser, then I’ll be all for it. Right now,
many technologies like Quicktime and Flash render direct to the screen,
with no color matching, so effectively they are being displayed in
Monitor RGB; if Apple can fix this (surely they can for Quicktime at
least) then they should; but we can’t break color matching between
elements in a browser, or Web color mgmt will be taking a big step
backwards in public opinion (if you want to see Web designers flee from
the Mac even more, go for it).

It isn’t necessary for all content to be color managed. Where you break color matching between elements is when GIF/JPEG/TIFF/PNG appear right next to HTML defined color such as a background, or possibly text. A movie or flash content on a background not being color managed is far less of a problem, and one that would cost Macintosh users and online merchants less money than the scenario we have now. Right now, products look different on a Macintosh than intended, and online merchants as of a couple years ago at least reported color as being the number one reason for product returns. And this occurs on the platform hailed as the pre-emanate platform for managing color.

And Safari isn’t the only area where ideology won over rationality. The printing subsystem makes assumptions that are perverse to the basic concepts of color management. It will be interesting to see if these problems get cleaned up in Tiger before Apple goes leaping off on wild development projects like Quartz Filters (which have significant portions that flat out don’t work at all).

PDF/X-3 support is a great idea, but if you’re going to claim you make conforming PDF/X-3 files, then you should do it. Apple claims it, but it’s not at all conforming PDF/X-3. Yet another standard Apple ignores, and for the entire product life cycle of Mac OS X 10.3.x this feature has been broken, and appears as though it will remain broken. They’ve done a disservice to the industry by doing this, the silver lining is that no professional trusts Apple to do these sorts of things correctly so they’re unlikely to use it or get hurt by it. But they’ve demonstrate once again they can’t get it right and are unwilling to remove broken things from the OS when they’re also unwilling to fix them until users are willing to fork over the dough for yet another update.

New features are great, but the core elements need to work properly and not violate basic color management philosophy. That should be the first rule, and then build features on top of that. Features don’t matter if the basic foundation is flawed.
 
Chris Murphy
Color Remedies (TM)
www.colorremedies.com/realworldcolor
___________________________________________________________________________

   Date: Tue, 9 Nov 2004 14:53:51 -0700
   From: Chris Murphy
Subject: Re: RGB to RGB conversions, is rendering intent critical?

On Nov 9, 2004, at 12:41 PM, Andrew Rodney wrote:

A professional using one of the newer displays that are producing Adobe RGB
(1998) gamuts. According to Tom, sRGB assumes a certain luminance that’s way
too low for today’s assumption of sRGB (based on CRT behaving displays).

I don’t buy the argument that the color space used as an assumed source space for untagged content suddenly changes because we get new displays. That we have new displays on the way with a substantially different gamut means that untagged images will look different  unless we assume something. It makes vastly more sense to assume sRGB for such content even when the user is using a wide gamut display. They will not be harmed. If you assume Adobe RGB (1998) for images that aren’t Adobe RGB (1998) images, everyone is harmed even those with such displays.