Luminous Landscape Forum
Raw & Post Processing, Printing => Colour Management => Topic started by: NAwlins_Contrarian on April 22, 2017, 12:44:28 am
-
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!
-
See here (https://forums.adobe.com/thread/1083949).
-
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
-
Where does pure green map to?
-
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
-
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
-
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.
-
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 (http://digitaldog.net/files/PhotoshopColorSettings.mp4).
* Jack Hogan's Adobe forum link (https://forums.adobe.com/thread/1083949 (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!
-
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.
-
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.
-
One comment about DxO Optics Pro. This converter works internally in Adobe RGB, so you do not gain anything by exporting Tiffs in ProPhotoRGB.
-
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
-
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
-
...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
-
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
-
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.
-
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
-
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.
-
...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
-
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 (http://forum.luminous-landscape.com/index.php?topic=71979)
And some test I made:
http://forum.luminous-landscape.com/index.php?topic=54284.0 (http://forum.luminous-landscape.com/index.php?topic=54284.0)
-
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).
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?
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.
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.
Now that positions have been clarified, I don't think there is serious disagreement with what you are saying.
By way of illustration, consider, if you will, a vintage patent by a color scientist whose brilliance has not received as much respect at it deserves :)
https://www.google.com/patents/US5450216
This illustrates several points, some of which made by you above:
1) All you need to produce the gamut-mapped image colorimetric color space B is a) an image in a colorimetric color space A, b) a definition of color space A, c) the color matching functions of space A and space B, and a definition of the destination color space, which is B. Note that the CMFs for both color spaces have to be the same, otherwise all bets are off.
2) The mapping can change chromaticity and luminance of in-gamut as well as out of gamut colors.
3) The mapping can depend on the specific colors in the image. Different images can have their colors mapped differently, even between the same spaces.
4) Even within a single image, colors can be mapped differently depending on the colors around them.
At no time was an in-band definition of intent required. That could come from a check box in the application, or from a group of sliders.
Are images gamut mapped this way today? Not to my knowledge.
Jim
-
Thanks again for some good information and food for thought!
* Two of the cited threads contain what is reported as a quote from "Andy" at DxO, regarding Optics Pro 8 (4.5 years ago), DxO Optics Pro uses Adobe RGB as its internal working color space.
Assuming that was correct--which I don't consider a safe assumption because I have personally received incorrect or at least incomplete responses from DxO before--then I would have been disappointed with that in Optics Pro 8. If Optics Pro 11 has such a limitation, that is inexcusable. It certainly warrants a follow-up with DxO.
* Another cited thread contains information on a test that the poster made 6 years ago, apparently with Optics Pro 7. That is very interesting, but it contains one claim that is at least, by a test I made just now, not correct for Optics Pro 11:
If your input file is jpeg or tiff, DOP works only with sRGB. If you open a file in AdobeRGB it will "assign" (not "convert to") sRGB.
Just now I took a TIFF in Adobe RGB (that had been created from a raw file), opened it in Optics Pro, exported it, and opened both the original Adobe RGB TIFF and the export from the Adobe RGB TIFF in another program. If Optics Pro had assigned (not converted to) sRGB to the Adobe RGB TIFF on opening, the two would have substantially-different color. In fact they both had to my eyes identical color. So my initial conclusion from my limited test is that (1) DxO has in some respects changed the way Optics Pro manages color between version 7 and version 11 and/or (2) the original post is at least in some respects incorrect.
* What Optics Pro will output:
I don't have the latest version of DXO, only the older version DXO9.... I have not found any option to export the edited RAW file to ProPhotoRGB. The final conversion is sRGB or aRGB choice only, AFAIK.
At least for Optics Pro 11 (I used OP 9, but don't recall the details on this), that is not quite correct. As the screen captures attached / below show, the Export to disk options for "ICC profile" are "Original", "sRGB", "AdobeRGB", and "Custom". I assume original means 'in whatever color space the camera tagged the raw file' or 'whatever DxO received it in, we won't assign or convert'. But more importantly, under Custom you just navigate to the .icc or .icm file for whatever you want to use. I had downloaded ProPhoto RGB from the ICC website (they call it ROMM), installed it, and created a new Export option for a 16-bit TIFF in ProPhoto RGB.
* As for Jim and the patent: I might have to try to read that in more detail later. Jim, I know you're an ace on this stuff. On the other hand, no doubt you've heard this before, maybe even set to music, "There's no BM like IBM / There's no BM I know!" (Just joking with you!)
-
Thanks again for some good information and food for thought!
* Another cited thread contains information on a test that the poster made 6 years ago, apparently with Optics Pro 7. That is very interesting, but it contains one claim that is at least, by a test I made just now, not correct for Optics Pro 11:Just now I took a TIFF in Adobe RGB (that had been created from a raw file), opened it in Optics Pro, exported it, and opened both the original Adobe RGB TIFF and the export from the Adobe RGB TIFF in another program. If Optics Pro had assigned (not converted to) sRGB to the Adobe RGB TIFF on opening, the two would have substantially-different color. In fact they both had to my eyes identical color. So my initial conclusion from my limited test is that (1) DxO has in some respects changed the way Optics Pro manages color between version 7 and version 11 and/or (2) the original post is at least in some respects incorrect.
That is correct, they added color management for Tiffs/Jpeg in version 8 but did not change the internal color space as far as I know.
* What Optics Pro will output:At least for Optics Pro 11 (I used OP 9, but don't recall the details on this), that is not quite correct. As the screen captures attached / below show, the Export to disk options for "ICC profile" are "Original", "sRGB", "AdobeRGB", and "Custom". I assume original means 'in whatever color space the camera tagged the raw file' or 'whatever DxO received it in, we won't assign or convert'. But more importantly, under Custom you just navigate to the .icc or .icm file for whatever you want to use. I had downloaded ProPhoto RGB from the ICC website (they call it ROMM), installed it, and created a new Export option for a 16-bit TIFF in ProPhoto RGB.
Yes, that is also correct and has been always there, at least from version 6
-
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.
There are a whole lot of misconceptions embodied in this view. Two that have been encouraged by the ICC "pre-canned" conversion within device profile approach are that gamut mapping is somehow a property of the device profile, and that it is possible to do fully featured (i.e. perceptual etc.) gamut mapping while mixing and matching pre-canned device profile conversions.
In fact it is not at all natural to shoehorn gamut mapping into device profiles, and noticeable compromises result. The natural place that gamut mapping should be computed is when linking two (colorimetric) device profiles to create a device to device transform, either explicitly (i.e. when creating a device link profile), or implicitly when invoking a conversion in a CMM. The ICC profile format was created in a different computing age, when there were a lot less CPU cycles available to users, and so the ICC tried to cram as much functionality into pre-computed tables as possible. Trying to split a gamut mapping into two pieces that are independent of each is (in general) an attempt to defy logic. You simply cannot do this when a gamut mapping intent requires the knowledge of both gamuts. For a sub-set of intents you can - colorimetric and saturation. For perceptual intents (where perceptual is defined as an intent that doesn't expand the source gamut out to the destination, but only compresses out of gamut colors), it is simply logically impossible if the source gamut is unknown to the destination profile or visa-versa. So when you invoke "perceptual" in most ICC contexts, what results is a complete fudge.
More nuanced gamut mapping intents (i.e. say a mild saturation enhancing transform) similarly require simultaneous knowledge of the source and destination gamuts to implement properly.
[ If a device profile is built with the intention of linking with a specific other device profile, it is possible to overcome this problem, but device links are a better approach. ]
But if you take a step back, the whole notion of gamut mappings based on the gamuts of the color spaces used to encode images has a set of assumptions and limitations built into it. The basic assumption is that the color space gamut is a good representation of the images gamut. This typically only true for output referred imagery. What I mean by that is that this works when the imagery has already been tweaked, gamut mapped and clipped to occupy a device space that has a limited, real world gamut, such as that of a display or printer (or standardized representations of real world spaces such as sRGB, AdobeRGB, Fogra etc.) As soon as you start dealing with input referred images (such as those captured in RAW), and/or encoded in large gamut colorspaces (i.e. ProPhotoRGB, L*a*b*, XYZ, scRGB etc.), this assumption doesn't apply. To do gamut mapping in this situation, you need to look at the gamut of the image, not the colorspace it is encoded in.
-
...* What Optics Pro will output:At least for Optics Pro 11 (I used OP 9, but don't recall the details on this), that is not quite correct. As the screen captures attached / below show, the Export to disk options for "ICC profile" are "Original", "sRGB", "AdobeRGB", and "Custom". I assume original means 'in whatever color space the camera tagged the raw file' or 'whatever DxO received it in, we won't assign or convert'. But more importantly, under Custom you just navigate to the .icc or .icm file for whatever you want to use. I had downloaded ProPhoto RGB from the ICC website (they call it ROMM), installed it, and created a new Export option for a 16-bit TIFF in ProPhoto RGB.
Ah yes, you just jogged my memory. I attempted "custom" ICC profile route in DXO9 with no success a while back, and I admit I perhaps gave up too soon because I couldn't make it work easily. However, this all begs the question, "why doesn't DXO just simplify matters and gives us a native proPhotoRGB output without all the gymnastics?" Surely, the DXO team knows the competition like Adobe ACR, LR, Phase One Capture 1, Irridient Developer, etc. etc. don't make the user jump through hoops to get ProPhotoRGB tagged output.
-
However, this all begs the question, "why doesn't DXO just simplify matters and gives us a native proPhotoRGB output without all the gymnastics?" Surely, the DXO team knows the competition like Adobe ACR, LR, Phase One Capture 1, Irridient Developer, etc. etc. don't make the user jump through hoops to get ProPhotoRGB tagged output.
Because you don't gain anything. DxO limits the gamut to Adobe RGB which means you just lose encoding values in your destination file if you choose ProphotoRGB.
The "superiority" of Prophoto RGB as editing color space is not something universally accepted.
-
.... DxO limits the gamut to Adobe RGB which means you just lose encoding values in your destination file if you choose ProphotoRGB.
The "superiority" of Prophoto RGB as editing color space is not something universally accepted.
If DXO is limiting raw conversion to aRGB at the initial RAW data conversion stage compared to raw convertors like ACR which processes natively in Melissa RGB (very close to ProPhotoRGB in colorspace metrics), then DXO is immediately limiting your camera sensor output because most camera sensors can record colors with larger native color gamut than aRGB colorspace, as BTW, so did many traditional color films. As for the superiority of ProPhoto RGB, many images don't need the extra color gamut volume capacity compared to sRGB or aRGB, but some do. The highly regarded Joe Holmes's Ektaspace profile is a good example of a working space profile designed for scanning Kodak Ektachrome transparency films which is not as wide gamut as ProphotoRGB but is indeed definitely bigger than aRGB. So, if I understand this discussion correctly, I could use the Ektaspace profile as a "custom" export colorspace in DXO, but it would be irrelevant because DXO has apparently already constrained it's RAW file editing colorspace to aRGB according to some folks participating in this thread. That's a drawback for DXO, IMHO, not a positive selling "feature" compared to ACR/LR and other RAW editors that do the raw conversion heavy lifting in colorspaces larger than aRGB.
-
If DXO is limiting raw conversion to aRGB at the initial RAW data conversion stage compared to raw convertors like ACR which processes natively in Melissa RGB (very close to ProPhotoRGB in colorspace metrics), then DXO is immediately limiting your camera sensor output because most camera sensors can record colors with larger native color gamut than aRGB colorspace, as BTW, so did many traditional color films.
I believe Lr internal encoding is a linear color space with the PPRGB primaries and white point, while Melissa RGB (PPRGB primaries and WP, sRGB nonlinearity) is used to display the histograms and other readouts.
Jim
-
There are a whole lot of misconceptions embodied in this view. Two that have been encouraged by the ICC "pre-canned" conversion within device profile approach are that gamut mapping is somehow a property of the device profile, and that it is possible to do fully featured (i.e. perceptual etc.) gamut mapping while mixing and matching pre-canned device profile conversions.
In fact it is not at all natural to shoehorn gamut mapping into device profiles, and noticeable compromises result. The natural place that gamut mapping should be computed is when linking two (colorimetric) device profiles to create a device to device transform, either explicitly (i.e. when creating a device link profile), or implicitly when invoking a conversion in a CMM. The ICC profile format was created in a different computing age, when there were a lot less CPU cycles available to users, and so the ICC tried to cram as much functionality into pre-computed tables as possible. Trying to split a gamut mapping into two pieces that are independent of each is (in general) an attempt to defy logic. You simply cannot do this when a gamut mapping intent requires the knowledge of both gamuts. For a sub-set of intents you can - colorimetric and saturation. For perceptual intents (where perceptual is defined as an intent that doesn't expand the source gamut out to the destination, but only compresses out of gamut colors), it is simply logically impossible if the source gamut is unknown to the destination profile or visa-versa. So when you invoke "perceptual" in most ICC contexts, what results is a complete fudge.
More nuanced gamut mapping intents (i.e. say a mild saturation enhancing transform) similarly require simultaneous knowledge of the source and destination gamuts to implement properly.
[ If a device profile is built with the intention of linking with a specific other device profile, it is possible to overcome this problem, but device links are a better approach. ]
But if you take a step back, the whole notion of gamut mappings based on the gamuts of the color spaces used to encode images has a set of assumptions and limitations built into it. The basic assumption is that the color space gamut is a good representation of the images gamut. This typically only true for output referred imagery. What I mean by that is that this works when the imagery has already been tweaked, gamut mapped and clipped to occupy a device space that has a limited, real world gamut, such as that of a display or printer (or standardized representations of real world spaces such as sRGB, AdobeRGB, Fogra etc.) As soon as you start dealing with input referred images (such as those captured in RAW), and/or encoded in large gamut colorspaces (i.e. ProPhotoRGB, L*a*b*, XYZ, scRGB etc.), this assumption doesn't apply. To do gamut mapping in this situation, you need to look at the gamut of the image, not the colorspace it is encoded in.
Thanks for the detailed explanation. Using the image specific perceptual gamut mapping features of ArgyllCMS (tiffgamut, collink -g, colprof -g, etc.) definitely helped me work through the misconceptions I'd previously held regarding perceptual rendering intents.