Why don't raw converters offer rendering intents at export?

[NAwlins_Contrarian]

It appears to me--please tell me if you think I'm wrong--that neither Adobe Lightroom nor DxO Optics Pro offers a choice of rendering intents when exporting an edited raw file as a JPEG or TIFF, even though they offer a choice of color spaces. Why?!

It appears to be widely accepted that many digital cameras' raw files contain colors outside the gamut of sRGB and even Adobe RGB. If I edit a raw file and export my edits as a JPEG or TIFF, the raw converter lets me choose the color space. But if the edited raw file's actually-used gamut exceeds the chosen color space's gamut, presumably the export process has to use some sort of rendering intent to compress or truncate or some combination of the two to fit the edited raw file's colors into the chosen gamut. How come the user cannot choose the rendering intent for this process?

If I go into many programs and take a TIFF or JPEG in one color space and convert it to another color space ('convert to profile'), I get to choose the rendering intent to be used for that process, and try different ones to see which looks best. Even the freeware GIMP lets me do that. Not having that sort of control when exporting the edits to a raw file seems like an odd omission.

I realize that often a workaround would be to export into a 16-bit TIFF in ProPhoto RGB, then convert that that TIFF to the ultimate desired profile with a program that lets you choose--and experiment with--rendering intents. But that extra step is a kluge and a discredit to the design of the raw conversion software.

Am I missing something?

Thanks!

[Jack Hogan]

See here.

[MHMG]

Raw converters are outputting to idealized RGB working colorspaces, i.e. sRGB, aRGB, ProPhotoRGB. These standardized RGB working color spaces use matrix profiles where only relative colorimetric rendering is necessary to define the precise color properties of the chosen RGB working space. Any perceptual rendering tag would have to remain true to the the relcol tag tone and color curve or it would no longer represent the intended image editing environment of the chosen RGB working space. In other words, a perceptual tag would introduce further image edits within the chosen working space not performed by the user, hence it's redundant and unnecessary.  Pure white RGB 255,255,255 maps to LAB 100,0,0 and Pure RGB black maps to LAB 0,0,0 in all of these working RGB colorspaces Perceptual rendering intent then comes into practical use when outputting to from the chosen source working space profile to the chosen destination profile (i.e., your chosen printer/media profile).

cheers,
Mark
http://www.aardenburg

[Jack Hogan]

Where does pure green map to?

[Jim Kasson]

Raw converters are outputting to idealized RGB working colorspaces, i.e. sRGB, aRGB, ProPhotoRGB. These standardized RGB working color spaces use matrix profiles where only relative colorimetric rendering is necessary to define the precise color properties of the chosen RGB working space. Any perceptual rendering tag would have to remain true to the the relcol tag tone and color curve or it would no longer represent the intended image editing environment of the chosen RGB working space. In other words, a perceptual tag would introduce further image edits within the chosen working space not performed by the user, hence it's redundant and unnecessary.  Pure white RGB 255,255,255 maps to LAB 100,0,0 and Pure RGB black maps to LAB 0,0,0 in all of these working RGB colorspaces Perceptual rendering intent then comes into practical use when outputting to from the chosen source working space profile to the chosen destination profile (i.e., your chosen printer/media profile).

You are right that there is inadequate information in the currently used matrix profiles to perform perceptual rendering.

I don't agree with you that performing such rendering is either redundant or unnecessary. When you do color space conversions, you have to decide what to do with colors that are out of gamut in the destination space, and I think that more choices that just clipping them to the destination gamut envelop would be A Good Thing.

However, I am not much of a fan of the way that Perceptual Mode is currently implemented, either. I think that image-aware and neighborhood methods would be big improvements. However, in view of the fact that we're not currently doing things we knew how to do 25 years ago, I don't hold out much hope.

Jim

[Jim Kasson]

Where does pure green map to?

I'll answer for gamut clipping in general, not necessarily for relative colorimetric. Pick a wavelength for spectral green. In general, that's outside the destination gamut (there are few source gamuts that it's inside, too). Trace a line back from that color to the gray axis in the color space of your choice (probably Lab). Changing luminance is optional. Where the line hits the envelope of the destination gamut is your new color. Note that doing this in Lab will cause hue shifts for some colors.

But I suspect you knew that.

Jim

[BobShaw]

I realize that often a workaround would be to export into a 16-bit TIFF in ProPhoto RGB, then convert that that TIFF to the ultimate desired profile with a program that lets you choose--and experiment with--rendering intents. But that extra step is a kluge and a discredit to the design of the raw conversion software.
Thanks!

Exporting in ProPhotoRGB is to me not a workaround. if you are serious it is just what you do. Then use ProPhotoRGB as the working space in Photoshop and export a ProPhotoRGB TIFF for the printer. If you have to convert something then only do it once at the printer.

[NAwlins_Contrarian]

Thanks everyone for the replies. After considerable additional reading and watching, I think it's becoming clearer. So it seems:

* Color working spaces do not (with minor / emerging exceptions--maybe a new V4 profile for sRGB?!) contain in their profile files (the .icc or .icm) the information with which to convert from one to another except with relative colorimetric rendering intent. Andrew Rodney discusses this at about 0:37:05 of his video at http://digitaldog.net/files/PhotoshopColorSettings.mp4.

* Jack Hogan's Adobe forum link (https://forums.adobe.com/thread/1083949) was quite informative, contains some other helpful links, and basically confirms that Adobe products (well, I assume Lightroom and Photoshop, not sure what color management facilities Elements has) use relative colorimetric rendering intent to map edited raw data into the chosen color space when exporting to a TIFF or JPEG.

* And because very, very few if any colors that our typical cameras can capture are outside of ProPhoto RGB, a safe option from either Lightroom or Optics Pro is to export the edited raw data to a 16-bit TIFF in ProPhoto RGB, and then convert that TIFF to the desired ultimate color space / profile with software that lets you choose the rendering intent at least where the destination profile actually gives you options, i.e., typically printer+paper profiles but typically not working space profiles.

But all of that, even if correct, doesn't resolve the issue, and this thread appears to contain at least one error above: "Raw converters are outputting to idealized RGB working colorspaces, i.e. sRGB, aRGB, ProPhotoRGB." Not necessarily! In fact, maybe not even desirably. Both Lightroom and Optics Pro are (or at least appear to be) perfectly willing to let you export edited raw data into a TIFF or JPEG in a printer profile color space instead of a working color space. I have actually done this more than once with Optics Pro. Attached is a screen capture of Lightroom set to do it. In such circumstances, I ought to be able to choose the rendering intent. Why would I want to? Usually because I edit my photos on a computer that is not conveniently connected to a Canon Pro-100 on which I sometimes print them. Why can't I just export from Lightroom or Optics Pro a ready-to-print JPEG, and then e-mail or otherwise transmit it to another computer, which shares a network with the Pro-100?

And on a broader level / to expand the inquiry: why don't the IEC (for sRGB), Adobe (for Adobe RGB 1998), the ICC or Kodak(!) (I think, for ProPhoto RGB), etc. create bigger and better profile files that contain the information to allow us to use perceptual and/or other rendering intents? It seems that even (especially?) when converting among working space profiles, we might well want to / ought to get the choice of whether to truncate out-of-gamut color or compress all colors from the wider gamut to fit into the smaller one, as an aesthetic choice specific to the photo we're processing. I think Jim was saying that above, and it certainly strikes me as true (although I'm quite the novice with this stuff).

Again, many thanks!

[Simon Garrett]

But all of that, even if correct, doesn't resolve the issue, and this thread appears to contain at least one error above: "Raw converters are outputting to idealized RGB working colorspaces, i.e. sRGB, aRGB, ProPhotoRGB." Not necessarily! In fact, maybe not even desirably. Both Lightroom and Optics Pro are (or at least appear to be) perfectly willing to let you export edited raw data into a TIFF or JPEG in a printer profile color space instead of a working color space. I have actually done this more than once with Optics Pro.

Why would you want to do that?  I mean: export to a tiff or jpeg in a printer profile (or other device-specific profile). 

I know of one very old-fashioned print lab that requires images to be sent to them converted to their own Fuji Frontier printer profiles, but this is a Dickensian lab that if you ask for a paper invoice probably sends it written with a quill pen.  Sooner or later they'll probably make it into the 21st Century.  For labs like that I export temporary copies (converted to their colour space) to send them, and then delete those copies.

Under normal circumstances, I can't think of any reason to convert to a device-specific profile except during the print process or while outputting to that device.  To do so is simply to commit an image to a specific device (and narrowing one's options), rather than leaving it in a more general form. 

I wonder if I'm missing something here, or if that's the purpose you have in mind.

[GWGill]

You are right that there is inadequate information in the currently used matrix profiles to perform perceptual rendering.

All that is needed is the source and destination gamuts, something that is obtainable from a matrix conversion to/from CIE space + the device space gamut of the image to be converted.

It's true that a matrix cannot encode a pre-canned gamut mapping, but pre-canned mappings are limited in their usefulness anyway, particularly when it comes to input referred imagery.

[fdisilvestro]

One comment about DxO Optics Pro. This converter works internally in Adobe RGB, so you do not gain anything by exporting Tiffs in ProPhotoRGB.

[Jim Kasson]

One comment about DxO Optics Pro. This converter works internally in Adobe RGB, so you do not gain anything by exporting Tiffs in ProPhotoRGB.

Well, you might, depending on the limits internally applied. All colors can be represented in any monitor-modelled RGB color space if you allow negative values. When I'm working with RGB color spaces I not only routinely allow negative values for internal calculations, but values greater than one, which is my chosen nominal full scale.

Jim

[Jim Kasson]

All that is needed is the source and destination gamuts, something that is obtainable from a matrix conversion to/from CIE space + the device space gamut of the image to be converted.

It's true that a matrix cannot encode a pre-canned gamut mapping, but pre-canned mappings are limited in their usefulness anyway, particularly when it comes to input referred imagery.

This is correct. It's not fair to blame the ICC for not having more gamut mapping choices. In addition, the application mediating the mapping has information not available at the time the profile is generated: the range and distribution of colors in the image.

Jim

[MHMG]

...I don't agree with you that performing such rendering is either redundant or unnecessary. When you do color space conversions, you have to decide what to do with colors that are out of gamut in the destination space, and I think that more choices that just clipping them to the destination gamut envelop would be A Good Thing.

Jim

Hi Jim, Ok, I did misspeak a bit. I do realize that a perceptual rendering option for working RGB colorspaces would indeed be of some value, i.e., in the situation where one is converting from a bigger gamut working space to smaller working space, say for example, converting a ProphotoRGB tagged image file to sRGB for the web.  However, I still maintain it's redundant in the context of the OP's initial question about its use with a raw converter.  When you open a raw file, the software is doing a lot of "secret sauce" translation of the raw data to post its initial "default" rendering of the image to the display. Not just demosaicing, lots of perceptual tone mapping as well. There is no fully standardized tone and color mapping algorithm for this stage of the raw conversion process, AFAIK. So, each raw convertor's proprietary mapping during this initial default conversion step is to my mind essentially analogous to a "perceptual rendering" intent. In LR, One can also further "flavor" the initial rendering step by using DCP profiles. I can choose "adobe standard" or switch to my Nikon's camera flat, vivid, neutral, etc. recipe, or even build a custom DCP profile with other software. Yet even the custom DCP profile doesn't magically fix camera exposure or clipping point values  nor does it free the user from having to make numerous additional edits like tone and color balance.  Because there's no standardized way for raw convertors to perform this first default rendering step, the user is thus presented with merely a starting point whereupon many color and tone values must be further altered, e.g. color balance, highlight and shadow response, whitepoint and blackpoint levels, clarity, saturation, etc. etc. I find with my cameras, I rarely accept the outcome of any raw convertor's default settings, not even the camera manufacturer's raw convertor default. The beauty (and agony ) of working with RAW files is that they usually need lots of manual intervention by the user before the file gets exported to the desired working color space as tiff or jpeg.  Hence, raw convertors would not really benefit from yet one more perceptual rendering checkbox, and IMHO, are thus redundant in any raw conversion process.

all the best
Mark
http://www.aadenburg-imaging.com

[Jim Kasson]

Hi Jim, Ok, I did misspeak a bit. I do realize that a perceptual rendering option for working RGB colorspaces would indeed be of some value, i.e., in the situation where one is converting from a bigger gamut working space to smaller working space, say for example, converting a ProphotoRGB tagged image file to sRGB for the web.  However, I still maintain it's redundant in the context of the OP's initial question about its use with a raw converter.  When you open a raw file, the software is doing a lot of "secret sauce" translation of the raw data to post its initial "default" rendering of the image to the display. Not just demosaicing, lots of perceptual tone mapping as well. There is no fully standardized tone and color mapping algorithm for this stage of the raw conversion process, AFAIK. So, each raw convertor's proprietary mapping during this initial default conversion step is to my mind essentially analogous to a "perceptual rendering" intent. In LR, One can also further "flavor" the initial rendering step by using DCP profiles. I can choose "adobe standard" or switch to my Nikon's camera flat, vivid, neutral, etc. recipe, or even build a custom DCP profile with other software. Yet even the custom DCP profile doesn't magically fix camera exposure or clipping point values  nor does it free the user from having to make numerous additional edits like tone and color balance.  Because there's no standardized way for raw convertors to perform this first default rendering step, the user is thus presented with merely a starting point whereupon many color and tone values must be further altered, e.g. color balance, highlight and shadow response, whitepoint and blackpoint levels, clarity, saturation, etc. etc. I find with my cameras, I rarely accept the outcome of any raw convertor's default settings, not even the camera manufacturer's raw convertor default. The beauty (and agony ) of working with RAW files is that they usually need lots of manual intervention by the user before the file gets exported to the desired working color space as tiff or jpeg.  Hence, raw convertors would not really benefit from yet one more perceptual rendering checkbox, and IMHO, are thus redundant in any raw conversion process.

Thanks, Mark. I think we're pretty much on the same page here. I was thinking of a multi-use situation. Say you have developed an image with the intent to print it on your Epson 4900, and now you want to post it on your website. At this point, you have two choices. You can make a copy of the image and edit it manually so that it falls within the sRGB gamut, or you can export it and let your developer/editor do a one-size-fits-all conversion. I'm just arguing for more sizes in the second case.

I edit with printing in mind. I don't want to go to the trouble of manually tweaking copies of images to make them look good on the web.

And then there's the matter of keeping track of the copies. I once did a set of image copies mapped into the GRACoL 2006 gamut (but in PPRGB, not in CMYK) for a book. I kept getting them confused with the base images when people wanted a print.

Jim

[NAwlins_Contrarian]

Two points / issues / questions:

One comment about DxO Optics Pro. This converter works internally in Adobe RGB, so you do not gain anything by exporting Tiffs in ProPhotoRGB.

Although I have seen that claim before, I have also seen the claim that internally Optics Pro works in a large LAB space, which seems more logical for what otherwise seems to be a fairly sophisticated piece of software. Can anyone supply evidence on this point?

(I agree that if both (1) a program internally uses Adobe RGB and (2) (on the point Jim makes) it limits its internal use to the values to 0-65535 or 0-255, then in those circumstances outputting in ProPhoto RGB achieves nothing (and indeed is arguably counter-productive).

Why would you want to do that?  I mean: export to a tiff or jpeg in a printer profile (or other device-specific profile).

Because when I don't need to perform editing past what Optics Pro or Lightroom can do, my 'master' is the original raw file plus the recorded set of editing instructions that each program keeps (Optics Pro in a readily-findable sidecar). There is no need or purpose to outputting that as a TIFF or whatever. I go straight from the master to the final output version in Optics Pro or Lightroom. There should be no reason (other than the one I've raised here) why I can't generate the to-be-printed version right in Optics Pro or Lightroom, exported in the final output device color space / profile, and then send it to the Pro-100, or to Costco, or whatever.

[Jim Kasson]

Because when I don't need to perform editing past what Optics Pro or Lightroom can do, my 'master' is the original raw file plus the recorded set of editing instructions that each program keeps (Optics Pro in a readily-findable sidecar). There is no need or purpose to outputting that as a TIFF or whatever. I go straight from the master to the final output version in Optics Pro or Lightroom. There should be no reason (other than the one I've raised here) why I can't generate the to-be-printed version right in Optics Pro or Lightroom, exported in the final output device color space / profile, and then send it to the Pro-100, or to Costco, or whatever.

There are two possible models to make this work.

1) Send the PPRGB file to the printer, and let them do the gamut mapping on printing. Optionally, specify the rendering intent.

Advantage: convenience. Disadvantage: loss of control.

2) Get the printer profile from the printer. With an combination of color space conversions and manual edits, map your image to the gamut of the printer. Send the gamut mapped file, in PPRGB, to the printer. Specify relative colorimetric as the rendering intent. They won't be doing any gamu mapping, because you've already done it.

Advantage: control. Disadvantage: inconvenience.

Until Lr gets better at offering more RGB gamut mapping choices, a workaround is batch conversions in Ps:

http://blog.kasson.com/the-last-word/a-book-report-hard-copy-proofing/

You'll need the printer profile for this.

Jim

[NAwlins_Contrarian]

Upon further review

I've seen multiple statements or at least suggestions (which I repeated above) that the standard color working spaces and/or the files we use to work with them (.icc and/or .icm) do not contain the information that would be necessary to convert into them with perceptual rendering intent. That may be literally true. However--in my somewhat limited understanding--I cannot see, as a matter of mathematics, how you can have enough information to convert from one color space / profile to another with relative colorimetric rendering intent but not with perceptual rendering intent. If I can calculate from a point outside of a color space (maybe or maybe not in some other color space, depending on whether it's raw data) to the most similar point on the surface of the color space (basically what relative colorimetric rendering intent does), then it seems that by definition I can also calculate from a point outside of the color space to a similar point inside the volume of the color space (basically what perceptual rendering intent does).

I think that more choices that just clipping them to the destination gamut envelop would be A Good Thing. However, I am not much of a fan of the way that Perceptual Mode is currently implemented, either. I think that image-aware and neighborhood methods would be big improvements.

Indeed. There seems to be an incorrect notion that there is a perceptual rendering. That the ICC or somebody may define one process for doing it does not mean there there are no others that would work similarly. The bigger / more obvious question is how much you leave colors nearer the center unchanged or nearly so and then scale the outer colors more radically, versus scale them all linearly or with some exponential equation. There's no reason we can't, and shouldn't have perceptual rendering or something like it with user-adjustable choices on these issues.

Moreover, in some cases we probably want a combination of (1) truncating smaller quantities of / less important colors that are farther outside the destination space and (2) scaling larger quantities of / more important colors that are less far outside of the destination space.

So what does that leave me thinking?

sRGB, aRGB, ProPhotoRGB. These standardized RGB working color spaces use matrix profiles where only relative colorimetric rendering is necessary to define the precise color properties of the chosen RGB working space.

If what's meant is that the space's properties are defined by its exterior contours--to which out-of-gamut colors would be mapped with relative colorimetric rendering intent--then I agree. However, if part of what's meant is that profiles with sufficient information to allow relative colorimetric rendering during conversion do not have enough information to allow a reasonably-sophisticated program to use some sort of perceptual rendering during conversion, I do not see how, as a matter of mathematics, that can be true.

You are right that there is inadequate information in the currently used matrix profiles to perform perceptual rendering.

That may be literally true, but one would not expect--or I think even want--profiles to contain such information, but the information that they do contain should suffice to allow reasonably-sophisticated software to make a perceptual rendering, especially with some input from the user on the details of how to make the compression.

[MHMG]

...Although I have seen that claim before, I have also seen the claim that internally Optics Pro works in a large LAB space, which seems more logical for what otherwise seems to be a fairly sophisticated piece of software. Can anyone supply evidence on this point?

I don't have the latest version of DXO, only the older version DXO9 which the company recently released (for a limited time?) as a "freebie". It's cool software, and I generally like its output although not for all RAW file formats. Irridient Developer beats it in certain circumstances (e.g. fuji Xtrans RAW files).   I have no idea what colorspace math is going on under the hood, but I have not found any option to export the edited RAW file to ProPhotoRGB. The final conversion is sRGB or aRGB choice only, AFAIK. Hence, as a practical matter aRGB is the biggest colorspace one seems to be able to invoke in DXO9. I will probably upgrade to DX11 for the more recently added DNG support, but until then, I can't say whether DXO11 (latest version?) now fixes the aRGB working colorspace constraint.

Mark
http://www.aardenburg-imaging.com

[fdisilvestro]

Well, you might, depending on the limits internally applied. All colors can be represented in any monitor-modelled RGB color space if you allow negative values. When I'm working with RGB color spaces I not only routinely allow negative values for internal calculations, but values greater than one, which is my chosen nominal full scale.

Jim

I agree with your statement but that is not what DxO does. The output values are limited to Adobe RGB and while you can technically use PropotoRGB, you will just be using a subset of the possible encoding values

Although I have seen that claim before, I have also seen the claim that internally Optics Pro works in a large LAB space, which seems more logical for what otherwise seems to be a fairly sophisticated piece of software. Can anyone supply evidence on this point?

(I agree that if both (1) a program internally uses Adobe RGB and (2) (on the point Jim makes) it limits its internal use to the values to 0-65535 or 0-255, then in those circumstances outputting in ProPhoto RGB achieves nothing (and indeed is arguably counter-productive).

You may want to look at this thread:
http://forum.luminous-landscape.com/index.php?topic=71979

And some test I made:

http://forum.luminous-landscape.com/index.php?topic=54284.0