The Color Space Conundrum or "Preserving fine tones in hues you can't even see!"

The Color Space Conundrum or "Preserving fine tones in hues you can't even see!"

John_Nevill said:

On the colouspace debate, I just view them as boundaries on gamnut. Perhaps i'm oversimplifing it, but monitors and printers wont actually show some of these wide gamuts, so aren't we working perceptionally with colours that are visually being forced into the limited rendering intents of such output devices?
I equally find it difficult to visualise an image which someone puts on the web (in sRGB) and says its a result of a wider colourspace. The wider colouspace may have got you there, but the final output is surely compressed and cant truly represent the wide gamut.

Click to expand...

Correct, the final output is compressed or clipped and cant truly represent the wide gamut, but
the advantage of ProPhoto (and other wide color spaces) isn't about retaining all those out-of-gamut colors per se, it's about maintaining the distinctions between them, so that you can map them into printable space as gradations rather than blobs.

Wide color spaces isn't the only option you have to prevent clipping of printable camera colors, here's a text I wrote on PhotoGamut RGB: http://www.outbackphoto.com/tforum/viewtopic.php?TopicID=1658

Thanks for the link Herman,

Although, the colourspace you mention (PhotoGamut) differs as its not really a colourspace but a LUT profile which maps input to output, e.g. dSLR or printer profile.
I still find it hard to grasp how a true colourspace (Prophoto or DonRGB etc) aids in colour graduation, surely this is function of bit depth?

Hi Herman,

You have made such an important point about retaining gradations between edge colors!

The reference your post provides is helpful and fascinating. It's counterintitive that the larger space could end up giving more posterization!



Here a file output in the smaller Photogamut RGB space is clean with good tonality in the shirt fold, whereas the much larger Prophoto RGB space causes posterization! (Still in the central portions of the upper picture, the shadow areas seem blocky/posterized, but this may be a jpg artifact.)

I wish you had 3D maps to show how this comes about!

Asher

Sean DeMerchant said:

Unless something has changed from the last version, simply download it, install it, and run. It will run as a demo for a period of time.

Click to expand...

i guess something has changed because i downloaded it from asher's link, installed it, and it won't open without a registration #...

Asher Kelman said:

...The reference your post provides is helpful and fascinating. It's counterintitive that the larger space could end up giving more posterization!...

Click to expand...

Hi Asher,

I can understand very well that this may come over as being counterintuitive .
This issue has been discussed on the Net extensively. Among others, there is an interesting article to be found at Michael Reichmann's site:
http://www.luminous-landscape.com/tutorials/prophoto-rgb.shtml

Basically, the chances are that you will run into some quantization and tone mapping problems if you are coming from a very wide space such as ProPhoto when compressing it into a limited space such as sRGB for printing or viewing it on the monitor. So unless there is a real need for it, it is not always a good idea to use the largest available colour space.

Regards,

Cem

First off, the example image was in 16-bit.

The posterization in the ProPhoto RGB version is caused by converting to a printer space using relative colorimetric intent. The out-of-gamut colors in the ProPhoto example are clippped along the edge of the printer profile's gamut. This is expected behavior. A perceptual conversion to the printer space would have yielded better results.

The example I posted on Outback Photo merely shows that a relative colorimetric conversion to PhotoGamut RGB leads to somewhat unexpected results. I would have expected CLIPPED colors in PhotoGamut RGB too because of the use of the relative colorimetric intent.

The fact that some colors are not clipped maybe due to:
- RawShooter didn't perform a relative colorimetric conversion to PhotoGamut RGB.
Conversions to MATRIX profiles are ALWAYS relative colorimetric. Matrix profiles are described by RGB primaries, TRC's and white/black point and just do not include a perceptual rendering intent.
PhotoGamut RGB on the other hand is a LUT based working space that contains perceptual tables and I just don't know how RawShooter handled the conversion.
- The relative colorimetric intent as implemented in the colorimetric tables of the PhotoGamut RGB profile does not map colors colorimetrically, but includes some gamut compression.

I wrote this in 2004 and didn't further investigate the issue.

> Although, the colourspace you mention (PhotoGamut) differs as its not really a colourspace but a LUT profile which maps input to output, e.g. dSLR or printer profile.

Hi John,
What do you think a regular, matrix based, profile/working space does? Both PhotoGamut RGB and Matrix based profiles are bi-directional. Both are valid ICC profiles. They are only described differently.

> I still find it hard to grasp how a true colourspace (Prophoto or DonRGB etc) aids in colour graduation

By doing a perceptual conversion to a printer space (gamut compression).

Take a look at the graph below John.

It'll show the gamut of Adobe RGB and also an Epson R800 printer. You'll see that the R800 gamut exceeds that of Adobe RGB in yellow/green/orange.

When converting your raw image to Adobe RGB, those printable yellow/green/orange colors are just gone.

The graph also shows that the gamut of a Nikon D70 exceeds that of Adobe RGB and Epson R800. When working in a wide space like ProPhoto RGB, that retains all D70 colors, a perceptual conversion to the R800 space will retain some of the gradation because ALL captured D70 colors are compressed into the R800 space. This means that also in-gamut colors are shifted to make room for out-of-gamut color. A relative colorimetric conversion would map all in-gamut colors exactly, and ALL out-of-gamut D70 colors along the edge of the R800 space.



Herman

What this says to me is that one might benefit from experiment.

For a major valuable print with great tones and the finest hues, it might be then worthwhile to test several color spaces so as to determine which might render the ultimate print.

Mapping 3d color spaces with wider than monitor-evident color gamut is a challenge. We can only approach solutions. So in practice, perhaps, we might do better re-working the file using smart objects to redo everything we have done in CS2. We can print and see which color space gae the best output.

"Smart objects" in CS2 allow us to replace the original images after the fact, if all the layers are intact.

Now this sounds great, but if the color space were changed, then the meanings of all the curves would change! So how do we do this without re-doing all the PS work?

Asher

Thanks Herman, I read your outback post and then decided to put Asher's example to test and noticed significant saturation variations. As you state, using a colourmetric renderinng intent just clips colours similarly to what Asher shows, hence less colour variation

So a wider gamut will in effect provide more headroom which will result in less clipping at the RAW conversion stage, yeilding broader colour data which ultimately compresses better when sent to the printer. However, bit depth will still govern the overall resolution of colour graduation.

So in my new quest to move to wider gamut.

Am I right in saying that the best method would be to overlay the 1DMkIIN, Epson 2100 and Eizo LCD profiles in a gamut viewer, and look for a working colourspace which comfortably encompasses them all but doesn't push the boundaries too far?

Likewise, should one always use perceptual rendering intents when moving to a narrower gamut?

EDIT: I believe you answered the questions in your revised post!

I think John, one might frame the question this way:

What is required to keep peripheral tonal and hue gradations from being degraded in a printer gamut to stuccato posterized blobs instead of the delicate smoothness of the original files?

There is richness and quaility to be mined here, I imagine.

So, Herman, what do we now do and at which stages?

One caveat to keep in mind is that for each color space, all of the curves and blending need to be reworked as they have different meanings in different color spaces. So one could, it seems use smart objects to save design time, overall, but one has to optimize each layer to the new color space.

Asher

John,

There's a good read on the subject here: http://www.adobe.com/digitalimag/pdfs/phscs2ip_colspace.pdf

It's a technical document written by Andrew Rodney for Adobe.

You'll also find some excellent articles about color spaces, rendering intents etc. on Sean T. McHugh's "Cambridge in Colour" http://www.cambridgeincolour.com/tutorials.htm.

There's also lots of info listed on the "Color management links exhange" on Outback Photo forum: http://www.outbackphoto.com/tforum/viewtopic.php?TopicID=1930

Herman

I have many examples where using anything BUT a wide gamut working space like ProPhoto RGB will produce banding with tiny edits in saturation and elsewhere. I can provide a link to a .DNG file you can try this on or better, shoot this yourself using saturated yellows and greens which are especially prone to damage from smaller spaces (even Adobe RGB (1998)). Shots of yellow lilies showed this off quite easily from several Canon DSLR captures and rendered in ACR.

Hi Andrew,

Could you give the reference?

Asher

Asher Kelman said:

Hi Andrew,

Could you give the reference?

Asher

Click to expand...

You want access to the DNG? Its on my public iDisk:

My public iDisk:

thedigitaldog

Name (lower case) public
Password (lower case) public

Public folder Password is "public" (note the first letter is capitalized).

To go there via a web browser, use this URL:

http://idisk.mac.com/thedigitaldog-Public

As to what to do with the .DNGs:

You can acquire and see what ProPhoto RGB brings to the party.

I acquired both through Adobe Camera RAW using Camera RAW defaults. Bring one in as
ProPhoto RGB 16-bit. Bring one in as Adobe RGB (1998) and for torture sRGB. Do a small
saturation move (plus or minus) of say only +7 on each, view the images at 100%. What do
you see? Try Channel Mixer and other edits that affect color/tone.

Both images were shot at ISO 100 on a Canon 5D but I have another file from Jeff Schewe
from a Mark II that shows the same issues in yellows and greens.

Convert the Adobe RGB (1998) file to LAB and do the saturation move too (interesting but
requires a conversion getting us back full circle to doing this in 8-bit or high bit). No need
for this move if you stick with the ProPhoto RGB file. Additionally, viewing the image in
ColorThink shows it clips in Adobe RGB (1998) and that Adobe RGB (1998) is also too
small a color space for output to an Epson running K3 inks (the gamut of the inks in useful
areas is larger). Have fun.