Luminous Landscape Forum
Raw & Post Processing, Printing => Digital Image Processing => Topic started by: Hendrik on June 06, 2006, 07:58:26 am
-
I’m always trying to educate myself (reading Dan’s LAB-book, reading PS and color management books and threads). The purpose: maximize the quality of my images within the practical boundaries. I have the time to fine-tune every image I make.
In the past I used Adobe RGB as my working color space, now I use ProPhoto RGB as my working color space. One of the reasons is LL’s ‘Understanding ProPhoto RGB’ article.
Since I mostly shoot portraits, ProPhoto RGB has not always benefits, since all colors captured fits often in a smaller color space. I want to use a workflow that combines the benefits of a large color space (not throwing colors away) with the benefits of a smaller color space (finer control over color and tone, because the data points are packed closer together).
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
-
In the past I used Adobe RGB as my working color space, now I use ProPhoto RGB as my working color space. One of the reasons is LL’s ‘Understanding ProPhoto RGB’ article.
There is a problem with PS and ProPhotoRGB, as discussed here in this thread (http://luminous-landscape.com/forum/index.php?showtopic=10883&hl): As I understand it, PS is not able to do a perceptual rendering with ProPhotoRGB, since it's a matrix based profile. It does relative colormetric instead. Your intention is, to compress or map the OOG colors smoothly into your destination color space, that's what a perceptive rendering intent is supposed to do. RelCol on the other hand means, that OOG colors are simply clipped, so at a first sight, there's no use in ProPhotoRGB, since all the extra color is clipped. In the above linked thread, there's a procedere from Peter Lange to get the tonalities to the smaller gamut. I am still evaluating on this. Another method is, to reduce the saturation locally with a saturation mask, using the gamut warning feature in PS.
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.
This is no problem: Open your image with the ProPhotoRGB profile and do a soft proof: Go to View>Proof Setup>Custom... and set your destination color space, eg. AdobeRGB. Then activate Proof Colors and Gamut Warning, and you'll see all the OOG colors as grey.
-
There is a problem with PS and ProPhotoRGB, as discussed here in this thread (http://luminous-landscape.com/forum/index.php?showtopic=10883&hl): As I understand it, PS is not able to do a perceptual rendering with ProPhotoRGB, since it's a matrix based profile. It does relative colormetric instead. ...
Thank you for the interesting thread; it seems another aspect to keep in mind (will it ever end? )
More and more photographers use ProPhoto RGB as there standard working space, regardless the contents of the image (that includes me). Articles like ‘Understanding ProPhoto RGB (http://www.luminous-landscape.com/tutorials/prophoto-rgb.shtml) with subtitle ‘Preferred Working Space for Digital Photographers’ suggests such a way of thinking.
I think it’s better to use the color space that fits your image best, whether it’s ProPhoto RGB, Adobe RGB or sRGB. Maybe I overlook something, that’s why I put it here for evaluation.
Thanks.
-
There is a problem with PS and ProPhotoRGB, as discussed here in this thread (http://luminous-landscape.com/forum/index.php?showtopic=10883&hl): As I understand it, PS is not able to do a perceptual rendering with ProPhotoRGB, since it's a matrix based profile. It does relative colormetric instead. Your intention is, to compress or map the OOG colors smoothly into your destination color space, that's what a perceptive rendering intent is supposed to do. RelCol on the other hand means, that OOG colors are simply clipped, so at a first sight, there's no use in ProPhotoRGB, since all the extra color is clipped.
[a href=\"index.php?act=findpost&pid=67527\"][{POST_SNAPBACK}][/a]
This is true if, and only if, the profile to which you are converting is also a matrix profile (which is one of the reasons I think it's daft to go from ProPhoto to an intermediate working space). If you go direct from ProPhoto to print space, you have complete use of all the rendering intents, but more importantly, you have complete use of all the data you captured.
-
This is true if, and only if, the profile to which you are converting is also a matrix profile
Thanks for the correction and clarification. I knew it couldn't be the whole story... I was just looking at a picture of yellow flower, converted via ACR to PrpPhotoRGB, which was completely out of gamut in sRGB. At least the gamut warning showed this:
(http://minolta.eazypix.de/forum/oog.jpg)
So, if the OOG color would be clipped via conversion from ProPhotoRGB to sRGB, the whole flower should become a plain yellow spot.
But how do I know, which proiles are matrix based, and thus are problematic? And when I choose RelCol with the above picture, the flower is rendered fine. Why? Alle the yellow colors are OOG, and thus should be clipped. Is the gamut warning not working correctly?
-
But how do I know, which proiles are matrix based,
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=67559\")
File size is an indication, something like 1KB is matrix.
Most working spaces are matrix based. There's one lut based working space afaik (PhotoGamut RGB).
Use a free utility like ICC Profile Inspector to explore more details of profiles:
[a href=\"http://www.color.org/profileinspector.html]http://www.color.org/profileinspector.html[/url]
Herman
-
File size is an indication, something like 1KB is matrix.
Aha, thanks. This is correct for all my RGB profiles.
So the above mentioned problem is valid for all RGB-to-RGB conversions, right? That would explain, why there's litteraly no difference in converting a picture perceptive or RelCol from ProPhotoRGB to any RGB, while the differncies are pretty obvious converting to a CMYK profile.
But again, I don't understand, why OOG colors are not clipped going from ProPhotoRGB to sRGB, if the true RI is supposed to be RelCol - whatever RI you might choose.
-
...
But again, I don't understand, why OOG colors are not clipped going from ProPhotoRGB to sRGB, if the true RI is supposed to be RelCol - whatever RI you might choose.
[a href=\"index.php?act=findpost&pid=67570\"][{POST_SNAPBACK}][/a]
Yes they are clipped. I can see clipping (loosing detail) when I soft proof a highly saturated ProPhoto RGB image to sRGB.
You can see/test it yourself when you use the flower image from bjanes from the thread Dennis quoted.
-
I hope you don’t mind bringing this thread back on-topic, since I need more input for my own reassurance.
I think Andrew Rodney answered my question, although it’s quoted from another thread: “A working space is a container for holding you image data and it has a fixed gamut. You can shoot a gray card in RAW and encode that data into two working spaces of differing gamuts. It might fully fit within sRGB and it will of course fit in ProPhoto with a heck of a lot of additional gamut around this data. So looking at the scene gamut before even deciding what working space to use for encoding is useful. If you can fit this gray into sRGB, using ProPhoto buys you nothing.’
ProPhoto RGB has no advantages if the color gamut of your image fits in another smaller color space. Therefore I think it’s wise to check for OOG colors and adjust your working color space accordingly.
Put into practice:
No OOG colors in sRGB, then sRGB is the preferred working color space.
No OOG colors in Adobe RGB, but OOG colors in sRGB, use Adobe RGB.
No OOG colors in ProPhoto RGB, but OOG colors in Adobe RGB, use ProPhoto RGB.
Considerations:
- There are no disadvantages when using smaller color spaces (if there are no OOG colors), but is there an advantage? A wider gamut gives you a wider range of color, but it doesn't give you more colors. The size of the working space's gamut determines the spacing of all possible values of each channel. The same number of colors is simply stretched over a larger color range. This means using a smaller color space gives you finer control over the color.
- High-bit editing gives you 32768 levels per color channel, but your tools use 256 possible values. Maybe (banding) artifacts are reduced, but your color control while editing is not any better. …or is it? This brings me to …
- Does using ProPhoto RGB have any real disadvantages when you work with small gamut 48-bit images. For example, I remember something that perceptual rendering (to the printer profile) attempts to compress the gamut of the source space into the gamut of the target space. Does that mean there is also a change in saturation when the image's gamut fits easily into the target space and there are no OOG colors?
I hope some can give more insight in this matter. I lack the knowledge to fully understand all possible consequences, but I’m tempted to leave ProPhoto RGB as my standard working space and use the space that fits my image.
Thanks!
Hendrik
-
Yes they are clipped. I can see clipping (loosing detail) when I soft proof a highly saturated ProPhoto RGB image to sRGB.
You can see/test it yourself when you use the flower image from bjanes from the thread Dennis quoted.
Is that so ??
Somehow a key question.
Once again I’ve opened the nice flower (http://luminous-landscape.com/forum/index.php?act=Attach&type=post&id=577) from bjanes' earlier post (http://luminous-landscape.com/forum/index.php?showtopic=10883&view=findpost&p=65945) (in ProPhoto RGB), changed to 16 bit/ch. Then, I visited the main Color Settings tab in Photoshop, advanced settings, in order to reduce the saturation of monitor colors by 50%. This is to get this whole story within the limited capabilities of my humble monitor (tested in advance via a Granger Rainbow).
Now, after installing a SoftProof to sRGB, I’m toggling it via Ctrl + Y.
That way, I do NOT see any loss of details...(even at some hundred % magnification).
The only conclusion I have, is that all visible & relevant details survive the conversion to sRGB. Though channel clipping occurs, former out-of-sRGB colors seem to find enough 'room' on the surface of sRGB to be still distinguishable - in particular considering that merged colors do not necessarily have to be located next to each other in the image.
I’d be pleased if we could sort this out here.
Peter
--
-
> The only conclusion I have, is that all visible & relevant details survive the conversion to sRGB. Though channel clipping occurs, former out-of-sRGB colors seem to find enough 'room' on the surface of sRGB to be still distinguishable - in particular considering that merged colors do not necessarily have to be located next to each other in the image.
> I’d be pleased if we could sort this out here.
Peter,
I thought I found a clue when I examined the bjanes image in ColorThink. ColorThink includes a very nifty feature to visualize the mapping/clipping of OOG colors
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?
Herman
-
I remember something that perceptual rendering (to the printer profile) attempts to compress the gamut of the source space into the gamut of the target space. Does that mean there is also a change in saturation when the image's gamut fits easily into the target space and there are no OOG colors?
[a href=\"index.php?act=findpost&pid=67609\"][{POST_SNAPBACK}][/a]
It doesn't work like that. The conversion (from working to output space) is a two-stage process where the source colours (and not gamut) first get converted into the connection space and then from there to output. So the gamut of each is independent. You can verify this by creating an sRGB image filled with say 255,0,0 and using Photoshop's Info box to readout Proof Color. Now use Convert Profile to convert it to ProPhoto RGB. The image RGB values will change, but the Proof Color will be the same.
-
My understanding of this is that the rendering intent is designed to handle out of gamut colours in different ways depending on the choice of rendering intent. Most of the technical discussion of rendering intent focuses on how the rendering intent handles the relationship between out of gamut colours and in-gamut colours. This relationship is not that simple according to Fraser et. al. in "Real World Color Management". When faced with OOG colours, Perceptual rendering intent will move the OOG colours into gamut at the same time that it shifts many of the ingamut colours so that overall colour RELATIONSHIPS are preserved (on the principle that human perception is more sensitive to the relationship between colours rather than to their absolute hues). In so doing, it will shift some colours that are in gamut, and it will also desaturate some colours. Fraser et. al. go on to say that the visible differences between these rendering intents is quite subtle. I have not seen discussion of the impact on colour saturation from changing rendering intent for images that have no OOG colours, but the information that is available would tend to suggest you should see extremely little - if any - saturation impact, say moving between Relative Colorimetric and Perceptual because there are no OOG adjustments to be made that would impact other colours in the image.
-
Fraser et. al. go on to say that the visible differences between these rendering intents is quite subtle. I have not seen discussion of the impact on colour saturation from changing rendering intent for images that have no OOG colours, but the information that is available would tend to suggest you should see extremely little - if any - saturation impact, say moving between Relative Colorimetric and Perceptual because there are no OOG adjustments to be made that would impact other colours in the image.
[a href=\"index.php?act=findpost&pid=67662\"][{POST_SNAPBACK}][/a]
The process isn't adaptive, that is it doesn't know/care whether all colours are in the output gamut or not. It just remaps everything according to fixed tables. (This after the input colours have been converted to the connection space.) The difference between colorimetric and perceptual depends entirely on the perceptual tables themselves. Some could be designed for more compression at the output gamut boundary, others could spread the shifts more evenly throughout the space. The only way to know is to soft-proof or print.
-
Lets assume that soft proofing on a calibrated monitor has some predictive value. Maybe it’s not a good assumption, but what purpose does it have if we didn’t.
I see clearly a loss of detail when I soft proof, maybe even some very slight banding. I attached a screen capture. It’s more apparent on my screen when I toggle between the two versions.
Soft proof settings: RelCol, ‘black point compensation’ checked.
@Peter, if I do the same as you did (50% desaturation of monitor colors and 16bit/channel), I still see the same, maybe even better noticeable.
@MarkDS, the differences between Perceptual rendering and RelCol isn’t valid here, my (newly) understanding is that it doesn’t matter with conversions between matrix profiles. Whatever you select, you only can use Colorimetric rendering.
Btw, anyone of the experts a comment on my topic?
-
Btw, anyone of the experts a comment on my topic?
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=67688\")
I'm no expert, but I think the answer to your original post is that it will work fine (provided ProPhoto is in 16-bits) ... but maybe it doesn't really matter that much. While I can think of colours from the original outside of Adobe RGB that I've managed to transfer intact to print it has been pretty rare. The downsides of larger spaces are of course that any adjustments you do will be coarser (sometimes too coarse) and you can't actually see what you're doing. You may want to read the following:
[a href=\"http://www.jeremydaalder.com/singleArticle.php?articleID=6]http://www.jeremydaalder.com/singleArticle.php?articleID=6[/url]
Note that in the above, the gamut of the current K3 inkset is larger that for the 2100 so this point no longer applies.
Personally, I'm coming to the opinion that it's better to just settle on a mid-sized space and concentrate more on differentiation of in-gamut colours (al la Dan's book) than maximizing the gamut itself. It will depend a lot on your subject matter. If you're starting from RAW you can always go back for the colours you've missed if you find some use for them in the future.
-
@ Stephan
Thank you for the link (http://www.jeremydaalder.com/singleArticle.php?articleID=6). This is in essence exactly what I was thinking, though must better written. It answers all my questions. More and more I became uncomfortable using ProPhoto RGB as my standard color space, all I needed was a confirmation to change my way of working.
-
I'm no expert, but I think the answer to your original post is that it will work fine (provided ProPhoto is in 16-bits) ... but maybe it doesn't really matter that much. While I can think of colours from the original outside of Adobe RGB that I've managed to transfer intact to print it has been pretty rare. The downsides of larger spaces are of course that any adjustments you do will be coarser (sometimes too coarse) and you can't actually see what you're doing. You may want to read the following:
http://www.jeremydaalder.com/singleArticle.php?articleID=6 (http://www.jeremydaalder.com/singleArticle.php?articleID=6)
Note that in the above, the gamut of the current K3 inkset is larger that for the 2100 so this point no longer applies.
Personally, I'm coming to the opinion that it's better to just settle on a mid-sized space and concentrate more on differentiation of in-gamut colours (al la Dan's book) than maximizing the gamut itself. It will depend a lot on your subject matter. If you're starting from RAW you can always go back for the colours you've missed if you find some use for them in the future.
[a href=\"index.php?act=findpost&pid=67693\"][{POST_SNAPBACK}][/a]
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.
-
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]
I work exclusively in 16-bit but find fine tuning of images somewhat difficult in ProPhoto, or even Beta RGB which is a better match for my scanned originals. Personally, I think the benefits of ProPhoto are largely overstated. Further that it's possible to get too hung up in absolute gamut size (and Dmax) and lose sight of what you're trying to achieve but this is a different argument!
As I tried to say above, for output it doesn't matter which working space you're using (assuming the same image colours) so use whatever *you* feel comfortable with.
-
That way, I do NOT see any loss of details...(even at some hundred % magnification).
The only conclusion I have, is that all visible & relevant details survive the conversion to sRGB. Though channel clipping occurs, former out-of-sRGB colors seem to find enough 'room' on the surface of sRGB to be still distinguishable - in particular considering that merged colors do not necessarily have to be located next to each other in the image.
Maybe this due to the fact, that the image was converted to 8bit, which is a nonsense with a large gamut. A raw image would make a far better starting point. With my own experiences, I definately can see a difference:
Raw image converted to ProPhotoRGB at 16bit with an exposure compensation to bring the histogram off the right end. Compared to a straight 8bit sRGB conversion and set the "Reduce Monitor Saturation" to -30%, there are differencies. Using desaturation and gamut warning, it is possible to get those fine tonalities into 8bit sRGB.
-
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.
-
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.
-
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.
-
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.
-
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] (http://index.php?act=findpost&pid=67716\")
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.
-
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.
-
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.
-
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
--
-
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,
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.
(http://www.xs4all.nl/~teeuwen/ct212_samples.jpg)
(http://www.xs4all.nl/~teeuwen/ct212_abs.jpg)
(http://www.xs4all.nl/~teeuwen/ct212_rel.jpg)
Herman
-
...
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]
-
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
--
-
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.
(http://www.xs4all.nl/~teeuwen/deltaE.jpg)
Herman
-
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
-
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.
-
Hermie, Dennis and Hendrik,
Still referring to bjanes' red flower (http://luminous-landscape.com/forum/index.php?act=Attach&type=post&id=577) 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
--
-
> 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 (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
-
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,
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, Dennis and Hendrik,
Still referring to bjanes' red flower (http://luminous-landscape.com/forum/index.php?act=Attach&type=post&id=577) 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
-
Very interesting techniques you're showing us here Peter ! You just keep on amazing me
Hermie,
Thanks! I’m doing my best to sort this out "once and for all" .
Trust you’ve already discovered that I’m still trying to clarify some further aspects; about the Desaturate-Monitor-Colors feature and what it really does under the hood (see here (http://www.adobeforums.com/cgi-bin/webx/.3bc08ba1/1)).
Peter
--
-
Clipping in ACR vs. OOG.
If I have an L=50, A=OOG or B=OOG, ACR isn't going to show clipping at L=100/rgb=255.