Pages: 1 [2]   Go Down

Author Topic: Why don't raw converters offer rendering intents at export?  (Read 7449 times)

Jim Kasson

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 2370
    • The Last Word
Re: Why don't raw converters offer rendering intents at export?
« Reply #20 on: April 23, 2017, 03:46:47 pm »

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

NAwlins_Contrarian

  • Full Member
  • ***
  • Offline Offline
  • Posts: 225
Re: Why don't raw converters offer rendering intents at export?
« Reply #21 on: April 23, 2017, 06:58:46 pm »

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),
Quote
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:
Quote
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:
Quote
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!)
« Last Edit: April 23, 2017, 07:07:37 pm by NAwlins_Contrarian »
Logged

fdisilvestro

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 1852
    • Frank Disilvestro
Re: Why don't raw converters offer rendering intents at export?
« Reply #22 on: April 23, 2017, 08:11:20 pm »

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

GWGill

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 608
  • Author of ArgyllCMS & ArgyllPRO ColorMeter
    • ArgyllCMS
Re: Why don't raw converters offer rendering intents at export?
« Reply #23 on: April 23, 2017, 08:33:29 pm »

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.

Logged

MHMG

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 1285
Re: Why don't raw converters offer rendering intents at export?
« Reply #24 on: April 23, 2017, 09:34:16 pm »


...* 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.
Logged

fdisilvestro

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 1852
    • Frank Disilvestro
Re: Why don't raw converters offer rendering intents at export?
« Reply #25 on: April 23, 2017, 09:54:15 pm »

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.

MHMG

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 1285
Re: Why don't raw converters offer rendering intents at export?
« Reply #26 on: April 23, 2017, 11:04:02 pm »

.... 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.
« Last Edit: April 23, 2017, 11:25:18 pm by MHMG »
Logged

Jim Kasson

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 2370
    • The Last Word
Re: Why don't raw converters offer rendering intents at export?
« Reply #27 on: April 23, 2017, 11:40:08 pm »

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

BradFunkhouser

  • Jr. Member
  • **
  • Offline Offline
  • Posts: 52
Re: Why don't raw converters offer rendering intents at export?
« Reply #28 on: April 24, 2017, 11:02:39 am »

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.
Logged
Pages: 1 [2]   Go Up