[Openicc] ProPhoto, ICCv4, was: meta data in test chart

[Chris Murphy]

I'm changing the subject, this isn't at all about metadata or test charts. Make it easier for some people to filter my esoteric detour.



On Jan 27, 2011, at 1:24 AM, Graeme Gill wrote:
> 
> Ahh, that explains it. They aren't actually ever rendering to ProPhoto, it's
> just being used as a working space. They need to manually tune their
> image to their chosen (real) output/printer space (presumably using trial and
> error, or print preview), and then using colorimetric to avoid any
> automatic (wrong) gamut mapping.

They do render into ProPhoto, trying to mimic the in-camera rendering to JPEG, because customers have asked that the initial rendering they see on-screen look like the JPEG. I find this to be a silly request, but whatever. So there is an initial rendering into ProPhoto, and you can export it as a ProPhoto RGB TIFF, and you can print it and it prints fine. But looks like in-camera JPEG.

If you use the Lightroom workflow, then yes it is a manual rendering to make the image look good (on-screen). There is no soft proofing in Lightroom. No gamut restriction. The main restriction that makes the rendering process output-referred and allows the workflows to work as well as they do, is the preview on a typical display forces the user to render the image to a smaller dynamic range. And then going to print is not such a big leap. Both display and print are output-referred image states. For now.

Again the differences between RelCol+BPC and Perceptual are pretty minimal in this workflow. I see hundreds of prints per semester, and I've kinda given up on the differences, it's so subtle. I consider this the artist's preference and I just don't get involved except in one case: there are certain images with very fine saturated detail where the perceptual intent will help hold together that detail in print, whereas it will more easily posterize with RelCol. So in those cases, there's usually a clear favoring for the perceptual intent.


>> This is a rather common workflow these days as it's a pretty popular product. So I'm a
>> little mystified how these dull and/or bad prints are occurring when converting from
>> ProPhoto RGB to print space.
> 
> That's what happens if you store an image as ProPhoto, and then gamut
> map to your output space, on the assumption that the image has actually
> been rendered into ProPhoto. Having it rendered to some printer space,
> but stored in ProPhoto breaks conventional perceptual rendering workflows.

I'm not understanding the distinction you're making. Here is an example workflow:

1. Take a Raw image in Lightroom or Camera Raw, render it on-screen to user satisfaction.
2. Export (from Lightroom) as ProPhoto RGB TIFF, Adobe RGB (1998) TIFF, sRGB TIFF. (You can do something similar from within Adobe Camera Raw as well).

So at this point you have three image files based on a single Raw image and rendering. Clearly one of those is an image stored in ProPhoto.

3. Print all three images, using either perceptual and relative colorimetric.

You will get six prints, and all of them, while not identical, are virtually identical. The differences between them are very subtle. Any non-subtle differences will invariably be captured materials that are very highly saturated which are getting clipped when converting/exporting the the sRGB or Adobe RGB TIFFs. Things like blue or indigo flowers, certain kinds of synthetic highly chromatic materials, etc. And in those cases, 8 in 10 photographers report that the ProPhoto version retained the proper hue/saturation. And about 2 in 10 prefer either the sRGB or Adobe RGB version, saying it retained the proper hue/saturation of such objects of interest.

So the point of the exercise for students is that these issues are rather minor issues, and not to get hung up on sRGB vs ProPhoto RGB, when a 1/2 stop exposure difference is a f'n HUGE difference in comparison to color space angels dancing on head pins. It's a demonstration for them to not get neurotic about it. And also, if they have some odd problem with some colors, try rendering into a different intermediate space before printing, or use a different rendering intent than they normally use.

ANYWAY, the big elephant in the room here is that we don't have good perceptual mappings from ProPhoto RGB to the display, let alone to print. And a v4 +PRMG ProPhoto RGB, with v4 + PRGM display profiles would get us much better perceptual mapping from ProPhoto to display. And further it would make a sensible default rendering intent in almost all instances, regardless of the source space (if all sources were v4 + PRMG based). The source profile is really the key, the output device profile being PRMG based is useful too but really it's the source spaces that need it.

Now I'm happy to entertain the argument that we should do even better than this and totally bypass ICC v4 altogether. At this point it appears to be only slightly better off than road kill, when it comes to having a pulse. But I think conceptually, within the framework of what the ICC profile format was established to be at the time v4 was imagined, it's not a bad idea. I'd rather have seen all of this effort put into an open source CMM rather than force every single profile vendor on the planet have to learn how to implement the PRMG mapping in their products. We are NO WHERE when it comes to that.

Chris Murphy