A Workflow with Beta RGB

[Robert Ardill]

I was going to return to the subject of using ProPhoto as the working space in Photoshop and the effect that this can have on a Perceptual mapping to a much smaller destination space, but I see that Graeme Gill has taken up the baton, so I'll happily leave it in his most capable hands!

So, instead I wanted to talk a little about the workflow - raw to destination - and the dangers of introducing clipping and out-of-gamut colors.

If we are working entirely within Lightroom, then there isn't much of a problem because before output we will, presumably, have the good sense to soft-proof and adjust the exposure so that it doesn't clip colors in the destination space (going back to Jim's point about the RGB gamuts going to a point at white and black).  ProPhoto, having a wider gamut than the destination will be able to accommodate colors which will be out of gamut in the destination space, simply because of the exposure.

However, if our workflow includes Photoshop then I think we need to be more careful.  We could have a nicely ETTR image in Lightroom, beautifully exposed so that the histogram sits snugly between 0 and 255 (or nearly) and everything is fine.  If we then bring it into Photoshop and convert it to, say, Beta RGB, we will most likely be clipping colors at the highlight end (easy to see by doing a soft-proof first).  If we drop the image brightness before doing the conversion then the colors will remain in gamut.  However doing that damages the image ... and to get the colors back in gamut needs a severe brightness adjustment.  Not quite so bad in 16-bit, but very bad in 8-bit.

The same can happen at the dark end.

So, this would indicate to me that if we intend our destination to be in a smaller space than ProPhoto (which we almost inevitably do), then we should open the image from Lightroom to Photoshop in a working space that is not too much bigger than the destination (which currently means opening into ProPhoto and then converting to the smaller working space unless the smaller space is sRGB or Adobe RGB), and we should make sure that the image exposure is adjusted to that space before opening it into Photoshop.

This is also a good reason to use a raw Smart Object in Photoshop. Open into Photoshop and convert to Beta RGB (no need to be careful in Lightroom).  Go into the Smart Object and soft-proof to the print destination and adjust the exposure, contrast etc (and saturation of individual colors if necessary) to bring the image (more or less) into gamut for the destination.  Then convert to the destination and print. (I'm leaving out editing steps in Photoshop ... and of course these could result in destination OOG colors: these can be fixed by going back into the Smart Object, or from within Photoshop itself, or by letting the CMM do its job).

Robert

[fdisilvestro]

By definition, L*a*b* encompass all visible colors. Perhaps you actually mean that L*a*b* with a* and b* restricted to the range -128 to +128 can't represent all visible colors ?

Yes, you are absolutely right. It is not L*a*b per se but the way it is implemented with integer numbers restricted to the -128 to 128 (or 127) range

[fdisilvestro]

We could have a nicely ETTR image in Lightroom, beautifully exposed so that the histogram sits snugly between 0 and 255 (or nearly) and everything is fine.  If we then bring it into Photoshop and convert it to, say, Beta RGB, we will most likely be clipping colors at the highlight end (easy to see by doing a soft-proof first).  If we drop the image brightness before doing the conversion then the colors will remain in gamut.  However doing that damages the image ... and to get the colors back in gamut needs a severe brightness adjustment.  Not quite so bad in 16-bit, but very bad in 8-bit.

No, do not use brightness to solve OOG colors issues.

ETTR has a meaning only for a scene referred image, once you are ready to go to photoshop it should not play any role.

Do not rely on the histogram alone. The attached files (extending the point made by Jim Kasson) show the case of two different images whose RGB histogram span from 0 to 255 in all channels. The first is three gradients that go from neutral gray (127,127,127) to the extreme of every channel (255,0,0);(0,255,0) and (0,0,255).

The second image is just a gradient from black to white and again the histogram span from 0 to 255 in all channels. The missing piece of information in histograms is that it does not show if those values occur simultaneously as in the black to white gradient or at different locations.

The third image shows a gamut warning converting the first image from ProphotoRGB to sRGB (it is in softproof mode, so it shill shows the histogram in Prophoto RGB). Do you think that adjusting image brightness will be of any value? Not at all, using exposure or brightness to solve a blown out channels is the wrong approach. It only works if the issue is luminosity and not saturation (look at the luminosity histogram, there is nothing to adjust with brightness)

The last image shows how the histogram looks if we converted to sRGB without doing any other adjustments. Huge spikes in each channels (all channels blown out) and yet the luminosity well below the extremes.

If your issues are with OOG colors, then you have to work with saturation, vibrance, mask, etc. but not with the brightness or exposure

The same can happen at the dark end.

So, this would indicate to me that if we intend our destination to be in a smaller space than ProPhoto (which we almost inevitably do), then we should open the image from Lightroom to Photoshop in a working space that is not too much bigger than the destination (which currently means opening into ProPhoto and then converting to the smaller working space unless the smaller space is sRGB or Adobe RGB), and we should make sure that the image exposure is adjusted to that space before opening it into Photoshop.

The fact that a color space is smaller in volume than another does not mean that all the colors in the smaller space are contained in the bigger space. Color spaces do not behave like a matryoshka where the bigger contains the smaller. This is especially true with output (printer/paper) profiles. Do you know that AdobeRGB has colors outside of ProPhoto RGB? If you perform an absolute colorimetric conversion between them this actually happens, if you perform a relative colorimetric conversion then AdobeRGB is fully contained in Prophoto. What plays a role here is the white point (D50 vs D65)

This is also a good reason to use a raw Smart Object in Photoshop. Open into Photoshop and convert to Beta RGB (no need to be careful in Lightroom).  Go into the Smart Object and soft-proof to the print destination and adjust the exposure, contrast etc (and saturation of individual colors if necessary) to bring the image (more or less) into gamut for the destination.  Then convert to the destination and print. (I'm leaving out editing steps in Photoshop ... and of course these could result in destination OOG colors: these can be fixed by going back into the Smart Object, or from within Photoshop itself, or by letting the CMM do its job).

Robert

Using a smart object is a good recommendation, convert to Beta RGB might work for some images, not for others.

[Robert Ardill]

No, do not use brightness to solve OOG colors issues.

ETTR has a meaning only for a scene referred image, once you are ready to go to photoshop it should not play any role.

Do not rely on the histogram alone.

If your issues are with OOG colors, then you have to work with saturation, vibrance, mask, etc. but not with the brightness or exposure

Hi Francisco,

I didn't say that adjusting brightness etc., would fix all out of gamut problems ... only those caused at the light and dark ends due to the fact that ProPhoto extends further into these areas than most other color spaces. Of course the clipping could also be fixed by desaturating or changing the hue.

You can see this here:



So clipping due to too much tightness at the highlights is likely to cause OOG in the bright yellows, whereas at the dark end if will be dark blues and dark green.  Of course the clipping may not be too bad ... and the CMM might do a perfectly acceptable job ... but then again it might not.

Mentioning ETTR was a bit of a red herring since exactly the same problem can be caused just with the Lightroom tonal sliders. And we can quite safely use ETTR, but we may need to back off the white and black levels a bit if the destination space is narrower (or missing) at either end.

Needless to say, ProPhoto is well capable of holding colors that are outside the gamut of most destination spaces, and adjusting the luminosity of the image will have little or no effect with these colors.

[/quote]

Do you know that AdobeRGB has colors outside of ProPhoto RGB? If you perform an absolute colorimetric conversion between them this actually happens, if you perform a relative colorimetric conversion then AdobeRGB is fully contained in Prophoto. What plays a role here is the white point (D50 vs D65)

No, I must say that it is news to me that AdobeRGB has colors outside of ProPhoto.  Are you sure you aren't mistaken?  

All conversions from one working space to another are relative colorimetric, so I don't see how an absolute colorimetric conversion could change the gamut (it does change the white point, but that won't affect the gamut ... but as this will cause a shift in the colors I suppose it's possible that some of these might end up outside the ProPhoto space.

Using a smart object is a good recommendation, convert to Beta RGB might work for some images, not for others.

Yes, well of course it's all image-dependent, but in general Beta RGB is large enough to contain most destination spaces (I know that some printer profiles stretch it a bit, but I'm not sure that the extra little bit of printer gamut would be noticeable, if we ever used it).  If things change and printers or other output devices end up with larger gamuts then of course we would need a larger working space.

Robert

[fdisilvestro]

No, I must say that it is news to me that AdobeRGB has colors outside of ProPhoto.  Are you sure you aren't mistaken?  

All conversions from one working space to another are relative colorimetric, so I don't see how an absolute colorimetric conversion could change the gamut (it does change the white point, but that won't affect the gamut ... but as this will cause a shift in the colors I suppose it's possible that some of these might end up outside the ProPhoto space.

Hi Robert,

This is something of little or no practical value. Usually you have to perform chromatic adaptation to go from a color space to another with a different white point. However, if you don't and plot both AdobeRGB and ProPhotoRGB with their original white points, there is a small area in the blues of AdobeRGB that is outside of the ProphotoRGB space. It is more a curiosity than something of real value (it would cause shifts in color an non neutral tones)

[GWGill]

However, if you don't and plot both AdobeRGB and ProPhotoRGB with their original white points, there is a small area in the blues of AdobeRGB that is outside of the ProphotoRGB space.

The same applies to sRGB - some of it is out of gamut in absolute terms compared to ProPhoto. This is only of significance for some methods of soft proofing, since it's more normal to calibrate a display to suit the white point of what's being proofed.

[Robert Ardill]

The same applies to sRGB - some of it is out of gamut in absolute terms compared to ProPhoto. This is only of significance for some methods of soft proofing, since it's more normal to calibrate a display to suit the white point of what's being proofed.

So this could cause a problem with Photoshop soft-proofing where the wtpt tag value is changed?  Is there some way of finding out if there is clipping in the AtoB direction?

Robert

[fdisilvestro]

Hi

Performing the chromatic adaptation before converting spaces is a criteria shared by many and it is actually a criteria implemented in the color management engine. For instance, if you use the Adobe ACE color engine in Photoshop (recommended), you will not see any issues converting from sRGB or AdobeRGB to ProphotoRGB using Absolute colorimetric rendering intent, so it must be performing chromatic adaptation.

However if you choose Microsoft ICM as the engine, then it is apparent that the chromatic adaptation is not performed as shown in the attached files.
The image is a test created by Bruce Lindbloom with all possible RGB values and no embedded profile. So I loaded it into PS, assigned sRGB and tried softproofing to ProphotoRGB with gamut warning on.

The first image shows an OOG area when using Absolute colorimetric RI, while the other image does not show any issue using relatice colorimetric RI (Yes, this is going from sRGB to ProPhotoRGB)

[GWGill]

Performing the chromatic adaptation before converting spaces is a criteria shared by many and it is actually a criteria implemented in the color management engine. For instance, if you use the Adobe ACE color engine in Photoshop (recommended), you will not see any issues converting from sRGB or AdobeRGB to ProphotoRGB using Absolute colorimetric rendering intent, so it must be performing chromatic adaptation.

It will depend on the intent chosen, as well as the details of the display ICC profiles. For instance, ICCV4 changed the display profile spec. to disable the normal absolute colorimetric rendering mode. Some V2 ICC profiles are also formulated in a similar fashion. A CMM now has to go out of it's way and use the 'chad' tag to restore absolute rendering when using V4 profiles.

[Robert Ardill]

The first image shows an OOG area when using Absolute colorimetric RI, while the other image does not show any issue using relatice colorimetric RI.

Thanks Frank,

That answers my question regarding the potential AtoB2 clipping. Convert to the destination and then soft-proof back to the working-space using the Absolute RI. (Bearing in mind the possible CA and icc v2/v4 issues etc

Thanks!

Robert

[Robert Ardill]

I've been doing some Perceptual mapping tests, using different profiles and techniques, which may be of interest.

The three methods I've used are:

• Normal conversion from the ProPhoto image to the print destination
  
• 'Smart Conversion' with ArgyllCMS: this creates an image gamut, a link profile from the image to the destination and it then converts the image. This is a new technique for me and I am not using it optimally.
  
• The 2-step conversion I've proposed (Relative to BetaRGB followed by Perceptual to destination)
  

Here are the results:

1. Normal conversion from the ProPhoto image to the print destination



The stripes are caused by a mask. The darker stripes are the original image and the lighter ones are after the Perceptual conversion.

2. 'Smart Conversion' using ArgylCMS (the image is shown as for 1. with the same mask)



3. 2-Step conversion (again, the image is shown as for 1. with the same mask)


The profile used was a Permajet Oyster profile made using an i1Pro2.

As you can see, 2 and 3 give good results whereas there is substantial lightening with 1.  What is not very apparent with the small sRGB image is that with 1 there is also a loss of contrast.

The 1-Step Photoshop conversion works quite well with some profiles, but not with others.  So far, the 2-step approach has been very good. I don't have enough experience with the Argyll 'Smart Conversion' to be sure, but in the 3 tests I've done so far it looks very good, with some problems in a fourth test with an Epson Enhanced Matte profile. The Enhanced Matte test was with a poor profile, and the paper has a small gamut and bad DMax - it could be that some tuning of the Argyll parameters is needed to get an optimal conversion (the problem was in a dark shadow area).

I do have a number of preliminary conclusions, but for now my main one is that it is worth trying different techniques if the straightforward Photoshop Perceptual conversion changes the image unacceptably.

Robert

[digitaldog]

I do have a number of preliminary conclusions, but for now my main one is that it is worth trying different techniques if the straightforward Photoshop Perceptual conversion changes the image unacceptably.

Interesting test, thanks. Couple thoughts. First, if you soft proof using just the Photoshop method AND you have the original prior to conversion on-screen at the same time, presumably you would see that the image gets a bit lighter. The question would be, could you build a very quick and simple adjustment layer to 'correct' for this based on viewing the 'before' image? This would be simpler and faster in Lightroom using a Proof Copy. And you'd have your output specific tweak in that VC.

2nd, what do you see between the two tests you did on a print?

[Robert Ardill]

Interesting test, thanks. Couple thoughts. First, if you soft proof using just the Photoshop method AND you have the original prior to conversion on-screen at the same time, presumably you would see that the image gets a bit lighter. The question would be, could you build a very quick and simple adjustment layer to 'correct' for this based on viewing the 'before' image? This would be simpler and faster in Lightroom using a Proof Copy. And you'd have your output specific tweak in that VC.

2nd, what do you see between the two tests you did on a print?

Yes, sure, of course it would be possible to adjust the soft-proofed image before the conversion to 'align' it towards the original (perhaps with a curve to darken and add more contrast, and a clarity-type adjustment for local contrast).

I've only checked on my monitor ... it really would be necessary to print for any final conclusions (time-consuming unfortunately!).

Robert

[fdisilvestro]

it is worth trying different techniques if the straightforward Photoshop Perceptual conversion changes the image unacceptably.

Robert

Couldn't agree more with that statement! thanks for sharing the test.

I also think that if you are converting to an output (print) color space, the conclusions have to be made looking at the prints, not at the monitor. Could it be that the increased brightness is due to compensation for the paper white?

Regards

[Robert Ardill]

Couldn't agree more with that statement! thanks for sharing the test.

Could it be that the increased brightness is due to compensation for the paper white?

No - the images are converted, not soft-proofed. BPC was on in all cases.

Robert

[digitaldog]

No - the images are converted, not soft-proofed. BPC was on in all cases.

I believe Francisco still raises a valid point even with converted images: converted for the paper in mind.

[Robert Ardill]

I believe Francisco still raises a valid point even with converted images: converted for the paper in mind.

Yes, definitely as far as needing to print for the final evaluation. 

As for a possible explanation for the extra lightness in the 1-step ProPhoto to destination conversion ... on reflection, it is possible that the i1Profiler profile attempts to compensate for the paper color by brightening the image in a perceptual conversion (it doesn't do it in a relative conversion). I've checked an i1Profiler profile for an Ilford Gloss paper and it doesn't do it for this paper ... but this needs further investigation.  As you say, Francisco could be onto something.

I'm away for 10 days, but I'll see if I can get to the bottom of what's happening on my return (or perhaps someone else could check it out).

Robert

[Guillermo Luijk]

However, if our workflow includes Photoshop then I think we need to be more careful.  We could have a nicely ETTR image in Lightroom, beautifully exposed so that the histogram sits snugly between 0 and 255 (or nearly) and everything is fine.  If we then bring it into Photoshop and convert it to, say, Beta RGB, we will most likely be clipping colors at the highlight end (easy to see by doing a soft-proof first).  If we drop the image brightness before doing the conversion then the colors will remain in gamut.  However doing that damages the image ... and to get the colors back in gamut needs a severe brightness adjustment.  Not quite so bad in 16-bit, but very bad in 8-bit.

Hi Robert, just to add to the thread Photoshop is not a 16-bit tool but it's 15-bit. So forget about 65536 encoding levels, it's half of that.

Genuine 16-bit TIFF file:


Just open and save in Photoshop:


TADAAAA!!!

Even with that I never experienced posterization problems when using ProPhoto RGB on 16-bit files in Photoshop. It's always the 8-bit conversión to build the output JPEG that could display posterization (typ. areas with uniform colours and good SNR such as skies).

Regards