ProPhoto RGB used better in a flexible workflow?

[Dennis]

Personally, I think the benefits of ProPhoto are largely overstated.

I see use in PrpPhotoRGB only when dealing with images, with have great portions of much detail in very saturated colors, like with those flower pictures.

[Hendrik]

The most important point you made above is the one about the K3 inkset. Since that point is correct the remainder of Daalder's argument for not using ProPhoto largely (but not unexceptionally) falls apart provided one works in 16-bit depth.
[a href=\"index.php?act=findpost&pid=67697\"][{POST_SNAPBACK}][/a]

The question is, are those OOG colors that much important? The article describes it perfectly. I check for OOG colors and adjust my working color space to what’s needed at that moment. Maybe when there are many important OOG colors I will use ProPhoto RGB and sacrifice some fine control. The tools in PS are not changing when you work in larger color spaces or when you use 16-bit (as I also always use).

Is the gamut of the K3 ink set really that much bigger compared to the 2100? …I remember something that the gamut isn’t much bigger, only the number of possible colors. I can’t find that article unfortunately.

[Stephen Best]

The question is, are those OOG colors that much important? The article describes it perfectly. I check for OOG colors and adjust my working color space to what’s needed at that moment. Maybe when there are many important OOG colors I will use ProPhoto RGB and sacrifice some fine control. The tools in PS are not changing when you work in larger color spaces or when you use 16-bit (as I also always use).

Is the gamut of the K3 ink set really that much bigger compared to the 2100? …I remember something that the gamut isn’t much bigger, only the number of possible colors. I can’t find that article unfortunately.
[a href=\"index.php?act=findpost&pid=67703\"][{POST_SNAPBACK}][/a]

You also need to take into account the output space. If you can't print it, there's little point in retaining it ... though starting in a larger space may be useful when you're trying to pull those colours back.

The K3 inkset is much improved in the reds.

[Mark D Segal]

K3 has a wider gamut than original Ultrachrome. Therefore it will reproduce colours that original ultrachrome cannot reproduce, provided those colours are in your file. As printer technology keeps advancing, printer gamuts will continue to improve. If you think you will ever want to reprint any of those files on better printers in the future, it is a good insurance policy to have the data that will allow you to take advantage of the improved technology.

[Hendrik]

K3 has a wider gamut than original Ultrachrome. Therefore it will reproduce colours that original ultrachrome cannot reproduce, provided those colours are in your file. As printer technology keeps advancing, printer gamuts will continue to improve. If you think you will ever want to reprint any of those files on better printers in the future, it is a good insurance policy to have the data that will allow you to take advantage of the improved technology.
[{POST_SNAPBACK}][/a]

You are absolutely correct, therefore the decision to discard any colors should be taken also with future output devices in mind.

I think there is an agreement in this thread.  

The article from [a href=\"http://www.jeremydaalder.com/singleArticle.php?articleID=6]Jeremy Daalder[/url] is still valid. The benefits are maximized when you choose a color space which does not clip any (important) tones, i.e. is just large enough to contain the most saturated tones in a scene, but is no larger. This way you keep the maximum amount of fine control available.

Thank you all for the input so far.

[Dennis]

The question is, are those OOG colors that much important?

That depends on your image. In a "normal" shot propably not. But if you do macro and shoot flowers, they can becom important. You remember my picture above? It's a yellow flower and it's completely OOG. I would consider the OOG colors very important in this case.

In my experience, it's very easy to capture colors in the reds and yellows, which are out of sRGB and even AdobeRGB. This is a case, where the use of ProPhotoRGB could make sense.

But actually, I find it more difficult, to convert the colors to ProPhotoRGB and then try getting them somehow into a CMYK gamut, than converting them to AdobeRGB (with an exposure setting, so that there's no clipping of the important regions), desaturating them a bit using gamut warning and afterwords correcting the channels in CMYK again. To bring the colors into AdobeRGB often means to darken the mage considerably more, than you'd need it with ProPhotoRGB. But in 16bit mode, that's not a problem.

So, IMHO, there might be an advantage using ProPhotoRGB with very saturated colors, but actually I am not sure, how to use it.

[Mark D Segal]

You can tinker with the appearance of colours that have been squeezed into gamut by using a Selective Color Adjustment Layer, selecting the problem color and tweaking the relevant C,M,Y,K values until you get a more pleasing result. For example if the problem is red, decreasing cyan, and increasing yellow can help to re-simulate the richer red you lost, but it could wipe out some detail as well, which can often be rescued with an HSB Adjustment Layer reducing red saturation. In general, some creative playing around with Selective Color and HSB Adjustment Layers can really help modify what Photoshop does to colors it has forced into gamut in a way you might not like very much.

[PeterLange]

It's probably due to the chromatic adaptation transform from ProPhoto (D50) to sRGB (D65), that shifts OOG *AND* and in-gamut colors.

Only problem is that I can't reproduce this in Photoshop. I can't see a difference between absolute and relative colorimetric conversion in PS. In ColorThink the distinction is obvious. Any further clues?

Hermie,

I’d expect that an isolated conversion D50 > D65 warms up an image by enhancing the red channel while downscaling the blue numbers.  However, in the context of this ‘warm’ red flower, and downsizing from pRGB to sRGB, these differences seem to get almost lost.  Nonetheless, subtle differences can be amplified as follows; mainly for the less saturated colors:

Duplicate the pRGB file (16 bit), convert one file RelCol and the other one AbsCol to sRGB, create an overlay in Difference blend mode, flatten the layers (now you could convert back to pRGB, but it’s not necessary here), and finally add a Levels’ adjust layer to move the highlights slider (input) down to 25 or so.


However, it is more than strange – but it can be clearly shown similarly – that the overall numerical difference between (a.) the original file in pRGB, and (b.) another file converted pRGB > sRGB > pRGB (everything RelCol), is even considerably smaller… As you say, such subtle differences should not be visible…

Any further clues?

Peter

--

[Dennis]

However, it is more than strange – but it can be clearly shown similarly – that the overall numerical difference between (a.) the original file in pRGB, and (b.) another file converted pRGB > sRGB > pRGB (everything RelCol), is even considerably smaller… As you say, such subtle differences should not be visible…

Any further clues?

The differences, that show up in the difference overlay, are as subtle, as the saturation exceeds the range of sRGB. If you exaggerate it and push the colors to the border of ProPhotoRGB using the saturation slider in ACR, the difference overlay gets more contrasty.

I just tried it with a yellow and a red flower, and the difference overlay looks like I would expect it, without adjustment. You didn't leave the "Desaturate Monitor Colors by..." checked, accidentially?

[Hermie]

Hermie,

I’d expect that an isolated conversion D50 > D65 warms up an image by enhancing the red channel while downscaling the blue numbers.  However, in the context of this ‘warm’ red flower, and downsizing from pRGB to sRGB, these differences seem to get almost lost.  Nonetheless, subtle differences can be amplified as follows; mainly for the less saturated colors:

Duplicate the pRGB file (16 bit), convert one file RelCol and the other one AbsCol to sRGB, create an overlay in Difference blend mode, flatten the layers (now you could convert back to pRGB, but it’s not necessary here), and finally add a Levels’ adjust layer to move the highlights slider (input) down to 25 or so.
However, it is more than strange – but it can be clearly shown similarly – that the overall numerical difference between (a.) the original file in pRGB, and (b.) another file converted pRGB > sRGB > pRGB (everything RelCol), is even considerably smaller… As you say, such subtle differences should not be visible…

Any further clues?

Peter

--
[a href=\"index.php?act=findpost&pid=67735\"][{POST_SNAPBACK}][/a]

Peter,

My reasoning was based on a graph in ColorThink 2.1.2 that shows the transition of bjanes image colors from pRGB to sRGB.

I couldn't see/reproduce this effect in Photoshop.

Next, I tried ColorThink Pro 3 instead of ColorThink 2.1.2 and guess what, I just can't reproduce the ColorThink 2.1.2 graph behavior. So maybe it's a bug in 2.1.2?
I'll ask Steve Upton.

Notice the effect on the in-gamut colors in 3rd graph.







Herman

[Hendrik]

...
Notice the effect on the in-gamut colors in 3rd graph.

...
Herman
[a href=\"index.php?act=findpost&pid=67760\"][{POST_SNAPBACK}][/a]

This is not what I expect with RelCol rendering. The in-gamut colors should stay at the same place.  

[span style=\'font-size:8pt;line-height:100%\'][off-topic] Wow, I played with ColorThink 2.2 for a moment since I was interested, but what a buggy program. Crashed three times within 30 minutes and got many n01 errors. I also didn’t know that sRGB gamut exceeds ProPhoto RGB gamut on some places (image).   [/off-topic][/span]

[PeterLange]

Notice the effect on the in-gamut colors in 3rd graph.

Hermie,

Let’s start simple.

I’ve just created a single neutral gray patch in ProPhoto RGB:
RGB= 220, L*= 90

Further, I’ve created a D65 version of ProPhoto RGB via the custom profile function:

RelCol, regular D50 > D65 ProPhoto RGB gives:
RGB= 220, L*= 90
Conclusion: The numbers do not change. Photoshop balances the L* axis itself.  L* 100 is always RGB 255 independent from D50/D65 and the working space in general.

AbsCol, regular D50 > D65 ProPhoto RGB gives:
RGB= 222, 218,188
L*= 90, a*= 2, b*= 16
Conclusion: Color is created relative to the new position of the L* axis. Accordingly, subsequent RelCol conversion to the monitor profile brings this warm gray on screen.

Of course I could be wrong (!), but in above plots it seems that the L* axis does not move.  That way things are the other way round: colors & Lab coordinates move with RelCol, not with AbsCol.  Finally, I guess that this is such a ‘definition thing’.


Admittedly, this doesn’t answer the question about bjanes’ red flower and possible image degradation from conversion pRGB > sRGB; in particular how to quantify it on a monitor independent basis (?).

Peter

--

[Hermie]

Peter,

To start with your last remark:

> Admittedly, this doesn’t answer the question about bjanes’ red flower and possible image degradation from conversion pRGB > sRGB; in particular how to quantify it on a monitor independent basis (?).

The 1st part of the screen dump below shows the deltaE resulting from rel.col. conversion from pRGB to sRGB.
The 2nd part shows the deltaE-2000.

The small deltaE window explains the colors used to represent deltaE ranges.

Color worksheets are created with ColorThink Pro 3.



Herman

[Hermie]

Peter,

> Of course I could be wrong (!), but in above plots it seems that the L* axis does not move. That way things are the other way round: colors & Lab coordinates move with RelCol, not with AbsCol. Finally, I guess that this is such a ‘definition thing’.

You were correct in your observation that the L* axis does not move.

In ColorThink 2.1.2 all graphing is done in D50 Lab. Notice that the white of the sRGB wireframe appears somewhat skewed vs. D50 L* axis (absolute rendering of sRGB white vs. D50 L* axis).

In ColorThink Pro 3 there are more graphing options included.

Herman

[Hendrik]

I must confess, …I lost it here.   I shall try to read some more about this topic, without asking to many silly questions. One question I must ask …


Why are the in-gamut colors also remapped with RelCol rendering? …or is it that the colors are visibly unchanged, but the actual RGB numbers are changed and therefore re-located in the color space? I noticed that with AbsCol rendering the in-gamut colors are unchanged.

[PeterLange]

Hermie, Dennis and Hendrik,

Still referring to bjanes' red flower in ProPhoto RGB and the question about possible image degradation from conversion to sRGB, the following tests might be interesting though the results are somehow slightly contradictive:

I.) Numerical Difference

File (a.) left in pRGB
Copied file (b.) converted pRGB > sRGB > pRGB,
everything RelCol
/> Create an overlay of both files in Difference blend mode
/> Flatten the layers and update the histogram

On my screen the resulting image looks very dark (not to say largely black).  The average RGB = 1.19 level (deviation 3.12).  This seems to be in line with above Delta E plots.  All in all the numerical difference caused by this conversion pRGB > sRGB seems to be quite low.

Even if it would be higher (e.g. with a more saturated flower), said conversion can be seen as a reduction of color saturation by purpose. I mean, for any reason which shall not be questioned here, ‘we’ want to have this image ‘in’ this smaller gamut. So something has to change, at least as far as oog colors are concerned. Some changes in particular on the color channels a &b simply belong to this conversion.  Accordingly, parts of the Delta E can not really count regarding the loss of details. Or?

Anyway, in this case here there’s only a minor numerical difference. So where is the major loss from conversion ?


II.) Perceivable Difference

Again the idea is to bypass any possible gamut limitations of the monitor, now without relying on the implementation of the Desat-Monitor-Colors function:

File (a.) left in pRGB
Copied file (b.) converted pRGB > sRGB > pRGB

/>  With both files (separately) add a Hue/Sat.-layer and set the saturation slider down to minus50%.  Change this layer to Saturation blend mode, respectively.
/>  Flatten the layers.
/>  Create an overlay of both files in Normal blend mode
/> Toggle the upper layer to watch for perceivable image degradation.

Results are quite interesting.  Yes, there is a some degradation and loss of details (in particularly bottom left).  But, it’s not at all that the whole fine structure would have been wiped out.  The appreciated reader might wish to check and judge this effect.

Somewhere it should be mentioned that this is not the fault of ProPhoto RGB.  There’s a basic input/output mismatch (in this case with sRGB for output) along the whole digital imaging chain, at least for those of us who occasionally capture colorful flowers, etc.



Just two further thoughts:

Finally I tend to accept the second test, at least in the sense of a worst case representation.  On this basis it might be interesting to think again about possible improvements, how to fine-tune the conversion regarding the maintenance of fine details (of course without intending to sacrifice other attributes).  Or, probably more efficient, given that many details are silently still present in sRGB something like an USM + Saturation Mask seems to point in right direction…  

Regarding channel clipping of the histogram (due to RelCol as opposed to exposure) I’d still say that this greatly overemphasizes the problem.  Or, the other way round, the conversion pRGB > sRGB is not so damaging as one might expect.  Bottom line for me is to be careful with any global saturation slider on a pRGB-basis (like in ACR). For example, with some vibrant flowers as part of a landscape, it’s probably better to limit any further increase of saturation e.g. via selections /masks in Photoshop; e.g. to facilitate a deeper blue for the sky.


Sorry for this long post.

Have a nice weekend! Peter

--

[Hermie]

> Why are the in-gamut colors also remapped with RelCol rendering? …

Hendrik,

This is because of the way how graphing is implemented in ColorThink 2.1.2. ColorThink Pro 3 works a bit different.

This post on the ColorThink forum explains what is happening:
http://www.colorforums.com/viewtopic.php?t=286

Poster 'Kratzy974' writes in above thread:
"The White of the D65 Spaces are rotated to be viewed in a D50 . So the 100,0,0 value is moved to 100, x, y, where x and y are the difference values between the Colortemperature. Just open a sRGB, and you see what I mean. That is fully correct, and I don't want to argue against that. But :
The problem with the rel Colormetric calculation is, that if I view an Image (from sRGB) with Whitepoint away from 100,0,0. Then I use rel Colormetric to a D50 space : the grey line isn't rotated, so the bright values are mapped to the gamut of the D50 colorspace. This looks wrong (also with perceptual...). "

In the example that I posted it's exactly the other way around. We're going from D50 to D65.

Herman

[bjanes]

Question: It this a sensible workflow? I want to convert my RAW images to a large color space, say ProPhoto RGB and check with PS the out-of-gamut colors in a smaller color space like Adobe RGB. When there are no out-of-gamut colors I can safely convert my RAW image to Adobe RGB without losing any colors. Maybe even convert to sRGB when my out-of-gamut test shows no problems. I continue my editing in this smaller color space. This way I try to fit my image as tight as possible in a color space, maximizing all benefits.

Best,

Hendrik 
[a href=\"index.php?act=findpost&pid=67524\"][{POST_SNAPBACK}][/a]

Hendrik,

I do not think it is necessary to convert the image into ProphotoRGB and then check for out of gamut colors in PS. All you have to do is to check for color channel clipping in the ACR histogram. If there is none, you are OK, otherwise choose a larger color space.

Here is a screen capture of the out of gamut red flower that I published previously. With sRGB there is prominent clipping in the red channel, which is largely eliminated if one goes to ProPhotoRGB:


[attachment=678:attachment]

[attachment=679:attachment]

[Hendrik]

Hendrik,

I do not think it is necessary to convert the image into ProphotoRGB and then check for out of gamut colors in PS. All you have to do is to check for color channel clipping in the ACR histogram. If there is none, you are OK, otherwise choose a larger color space.

Here is a screen capture of the out of gamut red flower that I published previously. With sRGB there is prominent clipping in the red channel, which is largely eliminated if one goes to ProPhotoRGB:
[attachment=678:attachment]

[attachment=679:attachment]
[a href=\"index.php?act=findpost&pid=67841\"][{POST_SNAPBACK}][/a]

Thank you for your suggestion. Unfortunately I use Nikon Capture for my .NEF files. I get the best results with this converter, but it’s not very user friendly (read: really bad) when you want to convert to different color spaces. I hope things will change when Capture NX is released. I can, of course, use ACR for color checking only without the conversion. Thanks!

[Hermie]

Hermie, Dennis and Hendrik,

Still referring to bjanes' red flower in ProPhoto RGB and the question about possible image degradation from conversion to sRGB, the following tests might be interesting though the results are somehow slightly contradictive:

I.) Numerical Difference

File (a.) left in pRGB
Copied file (b.) converted pRGB > sRGB > pRGB,
everything RelCol
/> Create an overlay of both files in Difference blend mode
/> Flatten the layers and update the histogram

On my screen the resulting image looks very dark (not to say largely black).  The average RGB = 1.19 level (deviation 3.12).  This seems to be in line with above Delta E plots.  All in all the numerical difference caused by this conversion pRGB > sRGB seems to be quite low.

Even if it would be higher (e.g. with a more saturated flower), said conversion can be seen as a reduction of color saturation by purpose. I mean, for any reason which shall not be questioned here, ‘we’ want to have this image ‘in’ this smaller gamut. So something has to change, at least as far as oog colors are concerned. Some changes in particular on the color channels a &b simply belong to this conversion.  Accordingly, parts of the Delta E can not really count regarding the loss of details. Or?

Anyway, in this case here there’s only a minor numerical difference. So where is the major loss from conversion ?
II.) Perceivable Difference

Again the idea is to bypass any possible gamut limitations of the monitor, now without relying on the implementation of the Desat-Monitor-Colors function:

File (a.) left in pRGB
Copied file (b.) converted pRGB > sRGB > pRGB

/>  With both files (separately) add a Hue/Sat.-layer and set the saturation slider down to minus50%.  Change this layer to Saturation blend mode, respectively.
/>  Flatten the layers.
/>  Create an overlay of both files in Normal blend mode
/> Toggle the upper layer to watch for perceivable image degradation.

Results are quite interesting.  Yes, there is a some degradation and loss of details (in particularly bottom left).  But, it’s not at all that the whole fine structure would have been wiped out.  The appreciated reader might wish to check and judge this effect.

Somewhere it should be mentioned that this is not the fault of ProPhoto RGB.  There’s a basic input/output mismatch (in this case with sRGB for output) along the whole digital imaging chain, at least for those of us who occasionally capture colorful flowers, etc.
Just two further thoughts:

Finally I tend to accept the second test, at least in the sense of a worst case representation.  On this basis it might be interesting to think again about possible improvements, how to fine-tune the conversion regarding the maintenance of fine details (of course without intending to sacrifice other attributes).  Or, probably more efficient, given that many details are silently still present in sRGB something like an USM + Saturation Mask seems to point in right direction…   

Regarding channel clipping of the histogram (due to RelCol as opposed to exposure) I’d still say that this greatly overemphasizes the problem.  Or, the other way round, the conversion pRGB > sRGB is not so damaging as one might expect.  Bottom line for me is to be careful with any global saturation slider on a pRGB-basis (like in ACR). For example, with some vibrant flowers as part of a landscape, it’s probably better to limit any further increase of saturation e.g. via selections /masks in Photoshop; e.g. to facilitate a deeper blue for the sky.
Sorry for this long post.

Have a nice weekend! Peter

--
[a href=\"index.php?act=findpost&pid=67839\"][{POST_SNAPBACK}][/a]

Very interesting techniques you're showing us here Peter ! You just keep on amazing me  

DeltaE is of course about perceived color differences and shows us more (DeltaE 2000) or less (DeltaE) about perceived image degradation.

Herman