This content has been marked as final. Show 17 replies
An interesting post, but upon reading the ICC White Paper 26, which is referenced in the link you posted, I'm not sure you are using the profile correctly. If you look at A1-3 in the annex, you will see that the original image is in sRGB and the first step is to assign the v4 sRGB profile to the sRGB image and one goes from there.
In A4 the task is to start with an image originally rendered to a print referred state, and the first step is to assign an appropriate v4 color space or printer profile. If you are starting out with a ProPhotoRGB image, you would have to assign a v4 ProPhotoRGB profile and go from there. Normally, the ProPhoto source would not be print referred.
In the additional example in A4, starting with an image in aRGB, the image was converted to sRGB with colorimetric rendering (with clipping) and then the v4 sRGB profile is assigned. It would seem that the optimal work flow would be to assign the ProPhotoRGB image to a v4 ProPhoto space and then go from there.
Hopefully Eric Chan or some other expert will correct and clarify any mistakes we have made in our posts.
By the way, your histograms are from cached data as indicated by the yellow triangle at the top right of the images, and it would be better to use the entire data by clicking on the triangle.
Oh, I'm pretty sure I'm using that profile incorrectly. I dread reading white papers.
Just tinkering around as I always do with this stuff and noticed this odd little quirk with the histograms. Didn't know the triangle in the histogram meant cached data. Geez! This stuff is just getting way too complicated. I thought I was viewing a live representation of the data. I've been using PS 7 and just started getting into CS2. Like I said I'm playing with scissors here.
How do you get the histogram in CS2 to give a live update and no caching when the Convert To Profile dialog box is open and when editing? Is there some preference I'm missing?
Anyway I clicked on the triangle just now and all it did was shift the histogram maybe a smidgeon toward the left on all of the conversions posted. The No BPC version did slightly clip the red channel but not as bad as converting to the old sRGB2.1. Thought I'ld mention the conversions are being performed on a final rendered 16bit ProPhoto tiff out of ACR 3.7.
The reason I posted this is I keep reading about folk's concern about their ProPhoto images clipping in the histogram when converting to standard sRGB2.1 while the preview remains unaffected and thought this would be interesting if not helpful. With this new v4 sRGB the exact opposite ocurrs. The histogram is fine but the preview slightly shifts in hue and luminosity using the perceptual intent, but then I am using this profile incorrectly.
When did making a picture turn into brain surgery?
There is no Pro Photo RGB spec, but its profile is similar to ROMM RGB which is standardized in ISO 22028-2.
The ROMM RGB reference medium is similar to the ICC v4 perceptual reference medium (PRM), which is a reflection print.
The bottom line is, good Pro Photo RGB images are more or less print-referred to the ICC PRM.
A primary design goal in developing the v4 sRGB profile was conversion from the PRM to sRGB with minimal clipping.
Then would first converting from ProPhoto RGB included in ACR to ROMM RGB ICC v4 then to sRGB ICC v4 using perceptual intent be a better alternative?
I guess I should just try it out.
Another thought, the ProPhoto RGB version included in ACR 3.7 uses the old spec I'm assuming, correct? Any updated version of ACR like 4.5 and 5 included with CS4 use the ICC v4 ProPhoto?
Thanks, Jack for the ROMM RGB info. I wasn't aware that this version existed.
Just tried it using both assigning and converting combinations with the whole gamut of intent and BPC options. No difference.
I even tweaked the shadows of that image prior to assigning and converting so no channels clipped to 0 and got the same results.
I guess I'll stick to the old way of converting from ACR ProPhoto to sRGB2.1.
The ICC v4 route might work with other images but it just looks like a hair nest of workflow options to deal with.
Assigning ROMM RGB to the ProPhoto image and converting to sRGB2.1 using relative intent and turning off BPC gave better results retaining the original iridescent hue of the duck's head at the expense of a flatter and lighter looking image overall which was reflected in the final histogram. See cropped sample below:
>There is no Pro Photo RGB spec, but its profile is similar to ROMM RGB which is standardized in ISO 22028-2.
>The ROMM RGB reference medium is similar to the ICC v4 perceptual reference medium (PRM), which is a reflection print.
>The bottom line is, good Pro Photo RGB images are more or less print-referred to the ICC PRM.
>A primary design goal in developing the v4 sRGB profile was conversion from the PRM to sRGB with minimal clipping.
Thanks, Jack. This information is very useful.
The ICC White Paper 26 describes the tone mapping for a reflection print but does not go much into the color gamut of the PRM. The wire frame plots show that the color gamut is larger than sRGB, but how does it compare to the ROMM RGB gamut? Would there be clipping if one uses the PRM with ROMM RGB?
The differentiation of Scene Referred vs. Output Referred spaces is a bit confusing. As Karl Lang discusses in his excellent white paper, output referred images are tone mapped to the lower dynamic range of a photographic print. ProPhotoRGB is output referred, but ACR uses ProPhotoRGB primaries with linear tone mapping for scene referred images. Other than a gamma of 1, what is the difference?
mmh, just caught this..."good Pro Photo RGB images"...how can you tell?
I don't know how anyone would know whether ACR's ProPhotoRGB would be scene or output referred when it's all histogram driven which is how I based my edits according to how I remembered the scene. What type of referring are these edits based on? How would a profile know? Are they going by the histogram data in the final edited image?
Is the dynamic range (excluding gamut) of ProPhoto RGB much wider than all the versions of sRGB profiles both ICC v2 and v4?
Is this why the histograms clip the data using Relative Intent w/BPC converting to both?
What's in the new ROMM RGB that allows turning off BPC when converting to any version of sRGB that makes the image slightly lighter as shown in the posted sample? Is it just mapping 1.8 gamma based data of ROMM RGB to the 2.2 gamma of sRGB that causes this?
BTW only assigning the new ROMM RGB and converting to sRGB with BPC off affects previews this way. Turning off BPC converting from ACR ProPhoto to any version of sRGB has no affect.
Something else I forgot to mention with regards to concerns of histograms clipping converting to sRGB is how it will affect prints destined to minilabs whose hue/sat/luminance seems to be pretty close to sRGB.
It's puzzling even my minilab prints look decent with severely clipped endpoints converting to sRGB. How does anyone trust a histogram as it relates to the preview in all of this? I know it's just a guide but I would expect a little bit better precision as it relates to dynamic range.
I'll try to respond to a few items above.
The digital values in a Pro Photo RGB file should generally be the same as for a ROMM RGB file. The exception is that all possible Pro Photo RGB values are "legal" but not all ROMM RGB values are "legal." ISO 22028-2 restricts the legal ROMM values to those with PCS LAB values between 0 and 100 L* and -128 to +128 a* and b*.
There is no enforcement if you use the illegal values in a ROMM file but as some of these values do not represent possible colors this is not advisable. I think it is good practice to try to stay mostly inside the ICC v4 PRM gamut with Pro Photo/ROMM images. You can check this using the gamut warning profile on the ICC site.
If you have a Pro Photo RGB image you should just assign the ROMM profile to it. Converting to ROMM RGB should not change anything in the ideal sense but there is the possibility to introduce rounding errors and mismatch black points.
The main difference between the Pro Photo RGB profile and the ROMM RGB profile is the former includes black scaling to zero (as is common with v2 color space and display profiles) and the latter does not (as is required with v4 profiles).
In the duck picture, the reason for the difference is the ROMM profile black is at L*=3 so this is where the lowest blacks land when converting MRC to v2 sRGB (which has the sRGB blacks scaled to L*=0). In this case leaving BPC off is analogous to turning on "Simulate Black Ink" in Photoshop Proof Setup.
All the ACR color space choices are v2 profiles with black scaling. If you want a v4 profile embedded you have to assign it (if you have a corresponding v4 profile) or convert to it.
Both the sRGB and PRM gamuts fit within the ROMM RGB legal encoding range, but if you use a v2 profile with black scaling you should always turn on BPC when combining with a v4 profile. Otherwise the v4 profile will think the v2 profile represents a device with an infinite dynamic range. When BPC is on the Color Engine scales the black point of the source profile to the black point of the destination profile.
The sRGB gamut extends outside the PRM gamut in some places, and the PRM gamut extends outside the sRGB gamut in other places. If you convert using a colorimetric intent in either direction some of the gamut will be clipped. The purpose of the sRGB v4 perceptual transforms is to minimize clipping in both directions.
I can't do this justice here but basically scene-referred images are encodings of the scene colors and output-referred images are encodings of the picture colors on some medium for which the picture colors have been optimized. You can make a scene-referred image by setting the ACR sliders (except the white balance sliders) to zero and the curves tab to linear. You make an output-referred image when you adjust the sliders to non-zero values to make a nice picture as viewed on some medium. For example you might adjust the sliders differently to get the best results printing colorimetrically on glossy photo paper vs. on plain office paper.
Often an important part of the transform to output-referred includes a midtone contrast and saturation boost. While there will likely be some highlight and may be some shadow compression, it is misleading to think of this transform only as a compression to some output medium dynamic range. In some cases the output medium dynamic range is larger than that of the scene.
Usually the transform to output-referred is more complicated than a simple gamma function.
Regardless of the image state (scene-referred or output-referred) the sRGB, Adobe RGB, or Pro Photo RGB nonlinearities will be applied to create the image data that you open into Photoshop.
We are working in the ICC to prepare more information for posting on this topic.
>The sRGB gamut extends outside the PRM gamut in some places, and the PRM gamut extends outside the sRGB gamut in other places. If you convert using a colorimetric intent in either direction some of the gamut will be clipped. The purpose of the sRGB v4 perceptual transforms is to minimize clipping in both directions.
Yes, I went back and looked at the ICC white paper 26. In some areas, the sRGB gamut does extend beyond the PRM space. Since sRGB is criticized as being too limited, I don't know if the PRM space is really that good if you are using a really wide gamut printer such as the new Epson ink jets. Better stick with ProPhotoRGB and take care of out of gamut colors yourself.
Thanks for clarifying, Jack.
I guess I'll do as Bill suggests and stick with ProPhotoRGB previews and ignore the histograms converting to regular sRGB or my minilab's profile. Soft Proof first of course using Relative Intent and BPC on and edit for gamut clipping.
Thanks to all for the input on this subject.
>I don't know how anyone would know whether ACR's ProPhotoRGB would be scene or output referred when it's all histogram driven which is how I based my edits according to how I remembered the scene. What type of referring are these edits based on? How would a profile know? Are they going by the histogram data in the final edited image?
I should have clarified that I was referring to the internal working space that ACR uses. Since photo receptors are linear devices, their output is scene referred by definition. If you render into ProPhotoRGB from ACR, then you get an print referred image with a gamma of 1.8
>Is the dynamic range (excluding gamut) of ProPhoto RGB much wider than all the versions of sRGB profiles both ICC v2 and v4?
As far as I know, if bit depth and gamma are held constant, then all RGB working spaces using a gamma curve have the same DR. With linear encoding such as in raw files, the DR is limited by the bit depth: a bit depth of 12 yields 12 f/stops of potential DR. However, the practical DR is limited by noise and posterization in the shadows. If you use a gamma curve (power function), you need fewer levels in the shadows. Log encodings are even better. Since the slope of a power curve is infinite at a luminance of zero, many spaces such as sRGB and L*a*b use a linear ramp for low luminances. This link gives some details.
Holy crap, Bill. How'ld you find that worm hole archive on gamma? It's amazing the amount of folks that actually study the heck out of this subject.
With all this complexity just with luminance mapping going on under the digital hood I wonder where the standard is in all this?
Thanks for the link. I'm going to see if I can warp, I mean wrap my brain around this.
The light bulb went on for me with the 6 bit linear vs gamma diagram on that linked page. Now I understand what ACR's default settings are meant to do...prevent the user from having to edit linear (dark) sensor data to look as the human eye perceives a scene.
Which curve would you want to edit to add definition to shadow detail with the least amount of shadow noise? The linear or 2.2 gamma curve?
I've tried coming up with my own custom contrast curve to correct for the dark linear sensor data and preview in Raw Developer, another third party raw converter, but it was shear torture. I can't imagine doing this with math could be any easier or controllable.
So I take it this is sort of what's happening assigning/converting with these different profiles with all their added intent and BPC settings and what it does to the previews and/or histogram except it's all being done under the hood in an already gamma encoded color space.