Does “remove the clamping when reading floating point image data” refer to reading a floating point image that was saved to disk by some other image processing software such as GIMP-2.9?
Does “scaling the channels” mean normalizing the channel data to fit within the display range 0.0f to 1.0f?
What does “clipped HL” mean?
Let’s say someone opens with RawTherapee a floating point image that’s in an RGB color space that’s not one of RT’s “Working Profiles” color spaces. What’s the first thing that happens with the current RawTherapee code. Is the image immediately converted to one of RT’s Working Profiles? Or maybe to CIELAB?
Does “remove the clamping when reading floating point image data” refer to reading a floating point image that was saved to disk by some other image processing software such as GIMP-2.9?
Yes
Does “scaling the channels” mean normalizing the channel data to fit within the display range 0.0f to 1.0f?
Yes
What does “clipped HL” mean?
Clipped highlights
Is the image immediately converted to one of RT’s Working Profiles? Or maybe to CIELAB?
Actually, for 32 bits floats images, the data is scaled to 0.0-1.0 based on the detected min/max values, then converted to the embedded profile.
Hmm, in that case instead of normalizing the data, I’d recommend just clamping it and letting people know it will be clamped to the channel range 0.0-1.0. That way the user can (is forced to) make their own decisions about how to deal with out-of-display-range channel values before they bring the image into RawTherapee.
As you already noted, simply normalizing the channel values can do funny things to the colors. I think it would be easier to tell users “for now, until the processing pipe line is unclamped, channel values are clamped on import”, than to explain to users why all of a sudden the image colors are all different than they were before opening the image with RawTherapee.
I agree with Elle about not normalizing the data based on the min/max values.
Have a look at this file, which obviously lacks highlights
First the raw in rt:
Now the same image saved to float tiff, loaded and normalized to [0;1] based on min/max values.
Edit: as (technically) expected the normalizing stretches the histogram in this case. But I don’t think that’s a user’s expection.
Edit: Here’s a screenshot of the same tif without normalizing based on min/max values.
When using the dev version of RawTherapee (updated yesterday, I think) via the RT-GIMP plugin, is there a way to tell RawTherapee to send a 32f instead of a 16i image?
Hi @Morgan_Hardwood and thanks! That particular edit didn’t work. But replacing all references in the RT code to “tiffBits =8” and “tiffBits = 16” to “tiffBits = 32”, did the trick. Of course this wouldn’t be suitable for general usage, but for my purposes it works just fine. So I’m guessing the “single place” (if there is one) that would require changing to provide 32f output via the GIMP plugin is in one of these files:
I also looked at the actual GIMP-RT plug-in code, but nothing looked promising. Though that doesn’t mean much as I don’t find the plug-in code very easy to read, and I didn’t look very hard to see if the plug-in code could control the bit depth of the returned file.
One thing that will need to be done as part of unclamping 32-bit floating point throughput and output is making sure all the ICC profile transforms and also the output ICC profiles support unbounded floating point conversions.
Not all ICC profile TRCs fully support unbounded floating point conversions, and some don’t even partially support unbounded floating point conversions:
Point curves don’t support unbounded floating point conversions. Everything is clipped to the display range.
True gamma TRCs (other than gamma=1.0) allow for unbounded positive channel values, but clip shadow channel values to 0.0. Which means “out of gamut” colors are clipped to zero in the shadows, which in turn means the potential for data loss, and what’s left of the original out of gamut data has undergone LCH Hue and Chroma changes.
Linear gamma (gamma = 1.0) ICC profiles do fully support unbounded floating point conversions, but of course only if the TRC is actually a gamma curve instead of a point curve.
The sRGB, Rec.709, and LAB L TRCs do support fully unbounded floating point conversions but only if these curves are encoded using a parametric curve, which means using a V4 profile, and of course requires not asking LCMS to output a point TRC.
I’m assuming any other Type 4 parametric curve that has a small "linear portion in the shadows also will fully support unbounded floating point profile conversions (and maybe also Type 5? and 6? see the LCMS API documentation table of parametric curve types). But the “point curve” equivalents of these parametric equations don’t support unbounded ICC profile conversions.
Looking at RawTherapee-supplied output profiles, the only ones that support unbounded floating point conversions are ACES.icc (linear gamma TRC) and I’m guessing the two DCI-P3 profiles, which seem to have nonlinear true gamma curve TRCs, and so support channel values > 1.0 but not channel values < 0.0.
All of the remaining RawTherapee output profiles have point curves, including the linear gamma version of sRGB and the linear gamma version of LargeRGB, and so don’t support unbounded floating point profile conversions. Instead RGB values are clipped.
There are some other problems with RawTherapee ICC profiles: Most of them aren’t completely well-behaved, and most of them have slightly wrong red, green, blue, and V2 white point tags:
“Rec2020.icm” is a copy of the ArgyllCMS (public domain) Rec2020.icm. All the ArgyllCMS ICC profiles are well-behaved.
The second well-behaved profile (“RT_Medium_gsRGB.icc”) brings up a problem that affects most of the RawTherapee output profiles, which is that the white point, red, green, and blue XYZ tags deviate from what you’d get if you made the profiles exactly according to the various color space specs, and also don’t match the ArgyllCMS equivalent profiles (when there is one), and also don’t match existing old proprietary versions, for those profiles for which I could find such profiles.
According to the profile description “RT_Medium_gsRGB.icc” is supposed to be a variant of the AdobeRGB1998 profile, except with the sRGB TRC. But the profile XYZ tags aren’t correct. Here are the white, red, green, and blue tags from the RawTherapee profile, compared to the same tags from the ArgyllCMS “ClayRGB.icm” profile (the ClayRGB.icm profile exactly matches the AdobeRGB1998 specs):
TagSignature>wtpt
RT XYZNumber X=“0.95016479” Y=“1.00000000” Z=“1.08842468”
AR XYZNumber X=“0.95045471” Y=“1.00000000” Z=“1.08905029”
TagSignature>rXYZ
RT XYZNumber X=“0.60961914” Y=“0.31103516” Z=“0.01947021”
AR XYZNumber X=“0.60974121” Y=“0.31111145” Z=“0.01947021”
TagSignature>bXYZ
RT XYZNumber X=“0.14916992” Y=“0.06320190” Z=“0.74453735”
AR XYZNumber X=“0.14918518” Y=“0.06321716” Z=“0.74456787”
TagSignature>gXYZ
RT XYZNumber X=“0.20541382” Y=“0.62576294” Z=“0.06089783”
AR XYZNumber X=“0.20527649” Y=“0.62567139” Z=“0.06086731”
Similar problems obtain for many of the other RawTherapee output profiles, including the sRGB profile. The problems have a couple of different sources:
Using the wrong values for D65 and D50
Not correcting for hexadecimal rounding during the profile-making process.
Using the LCMS built-in sRGB profile-making function (“cmsCreate_sRGBProfile()”).
For details see these articles:
Will the Real sRGB Profile Please Stand Up?
From sRGB color space to sRGB profile: how to calculate the ICC sRGB profile primaries from the sRGB color space specifications
Survey of Free and Open Source ICC RGB Working Space Profiles
Are Your Working Space Profiles Well Behaved?
In Quest of Well Behaved Working Spaces
Elle Stone’s Well-Behaved ICC Profiles and Code
I think it’s important that free/libre software have properly made ICC profiles, and from what I can tell, an awful lot of profile suppliers for free/libre software don’t actually provide completely correct profiles.
If someone says “well, our profiles are close enough”, that’s a statement that just leaves me confused - why not be “exactly right” instead of “sort of right”, when there’s no particular cost associated with using the right parameters to make the profiles?
If someone wants to say “well, we prefer using this other value for D65 and/or for D50”, then that’s fine, but the resulting profile shouldn’t be passed around as a profile for the intended color space, as color space specifications include not just the primaries, but also the white point values.
My profile-making code is GPL’ed and so anyone can borrow and modify any or all of it to incorporate into their own projects, and of course if anyone finds errors, please let me know! The most important parts of my profile-making code are the “spec-based” white points and the back-calculated matrices for profiles that otherwise wouldn’t be well-behaved. To calculate these matrices I use one of the ArgyllCMS source code files modified separately for each profile, plus a spreadsheet to calculate these matrices. ArgyllCMS has code for correcting for hexadecimal rounding, to make well-behaved profiles. LCMS doesn’t have such code.
I’m a satisfied customer of your profiles. I use the Rec2020-g18 for working, and the sRGB-srgbtrc for JPEG output. Those, and my calibrated camera and display profiles and my color appears consistent among all my home monitors. Need to find time to bring my colorimeter to work…
Are you sure about those numbers? To me they look an awful lot like the wrong ones I recently fixed in darktable: D50 adapted primaries with a D65 white point!
Bruce Lindbloom’s equations are correct. At least all the equations on his website that I’ve used produce results consistent with ArgyllCMS profiles and xicclu output, and are consistent with equations found elsewhere. I haven’t put every single equation Lindbloom provides in a spreadsheet, but I’ve done this with enough of them that I’m very confident in Lindbloom’s equations.
Lindbloom’s posted unadapted primaries are correct, except possibly his WideGamut primaries, which don’t agree with old Adobe WideGamut ICC profiles and don’t agree with Pascale’s primaries (http://www.babelcolor.com/index_htm_files/A%20review%20of%20RGB%20color%20spaces.pdf). If there are any WideGamut color space specs I haven’t been able to locate them. As an aside, WideGamut was made by Adobe as a wide gamut editing color space, but Adobe very quickly switched over to ProPhotoRGB as their recommended wide gamut color space.
Lindbloom doesn’t use the correct values for D65 and D50 when calculating adapted primaries:
Lindbloom’s posted white point values for D65 are not taken from actual color space specs such as sRGB, AdobeRGB, and etc. AFAICT from looking at profiles and reading specs, all “D65” color space specs use the same D65 xy values: x=0.3127, y=0.3290. For some reason Lindbloom uses ASTM values for D65: x=0.312726615, y=0.329023130.
Likewise with D50 values. To correctly make an ICC profile you have to use the D50 values given in the ICC profile specs: x=0.345702915, y=0.358538597 (converted from XYZ). But again for some reasons Lindbloom uses ASTM values: x=0.345669187
y=0.358496180
One might say, well, the D65 color space spec’s white point xy values are just rounded ASTM values, but that doesn’t matter. The specs are the specs, and if someone wants to produce a “by the specs” D50-adapted ICC profile from a D65 color space such as sRGB and AdobeRGB, they need to use the color space spec’s D65 values and the ICC spec’s D50 values. See the “Selected D50 and D65 profile white point xyY values” table here for more variations in D50/D65 white points, including LCMS “6504” versions of D65:
I’m not sure which numbers are “those numbers” - do you mean the numbers highlighted in red?
Here are comparison ICC profile XYZ values for ArgyllCMS ClayRGB (“ar”), Darktable AdobeRGB-compatible (“dt”), my own version of ClayRGB (“es”), and RawTherapee’s MediumRGB (“rt”), with Lindbloom’s adapted RGB XYZ values thrown in for good measure:
White Point
ar X="0.95045471" Y="1.00000000" Z="1.08905029"
es X="0.95045471" Y="1.00000000" Z="1.08905029"
dt X="0.96420288" Y="1.00000000" Z="0.82490540"
rt X="0.95016479" Y="1.00000000" Z="1.08842468"
Red
ar X="0.60974121" Y="0.31111145" Z="0.01947021"
es X="0.60974121" Y="0.31111145" Z="0.01947021"
dt X="0.60974121" Y="0.31111145" Z="0.01947021"
rt X="0.60961914" Y="0.31103516" Z="0.01947021"
Lindbloom: 0.6097559 0.3111242 0.0194811
Green:
ar X="0.20527649" Y="0.62567139" Z="0.06086731"
es X="0.20527649" Y="0.62567139" Z="0.06086731"
dt X="0.20527649" Y="0.62567139" Z="0.06086731"
rt X="0.20541382" Y="0.62576294" Z="0.06089783"
Lindbloom: 0.2052401 0.6256560 0.0608902
Blue
ar X="0.14918518" Y="0.06321716" Z="0.74456787"
es X="0.14918518" Y="0.06321716" Z="0.74456787"
dt X="0.14918518" Y="0.06321716" Z="0.74456787"
rt X="0.14916992" Y="0.06320190" Z="0.74453735"
Lindbloom: 0.1492240 0.0632197 0.7448387
Notice the darktable Red, Green, and Blue values match values from ArgyllCMS and my own “ClayRGB” profile. But the darktable White Point tag is clearly D50 instead of D65. This is because darktable supplies “V2 according to V4” spec V2 profiles. ArgyllCMS supplies “true V2 according V2” spec profiles.
I used to supply “V2 according to V4” spec V2 profiles, but was asked by some people who work with VFX stuff to please supply true V2 profiles. This must sound confusing, but it’s covered in my “Survey of Free and Open Source ICC RGB Working Space Profiles” linked to in my last post, and also in my “Elle Stone’s Well-Behaved ICC Profiles and Code”, also linked to in my last post.
Please note that RT values are sufficiently close to what I’m saying are the actual correct values, that in practice no-one will see differences between the same image adjustments made using different versions of “the same” profile, unless they are making relatively large editing adjustments.
But as RawTherapee does need to use different TRCs to accomodate an unclamped processing and output pipeline, it seems like a good time to also change the primaries, if that’s what the RT devs decide to do. Which is why I went to the trouble of posting the above information here.
As an aside, switching to V4 profiles with their parametric curves for the sRGB, Rec709, LAB L and etc TRCs, in order to accomodate unclamped ICC profile conversions using these TRCs, does mean switching to the V4 specs, which means the white point tag in V4 profiles needs to be the D50 white point, not the D65 white point, and the D65 source white point information needs to go in the “chad” tag.
I mean all of them. I am not talking about minute details in the 15th decimal place but the obvious differences.
As I understand it the primaries have to match the white point given? And the latter has to be D50 for ICC profiles? So shouldn’t it be wrong to have D50 adapted primaries and a D65 wtpt tag?
I must admit that I am a little confused. Because those profiles are what I asked you to review a week or so ago and you said they were good to go.
Edit: It seems the dt profiles are broken as they don’t contain a chad tag?
Well, now I’m confused. What do you mean by “all of them” and “obvious differences”?
Your AdobeRGB profile has RGB XYZ values that exactly match the Adobe specs, the original AdobeRGB proprietary profile RGB XYZ values (from an example profile that I have), and the ArgyllCMS and my own RGB XYZ values. So there is no obvious difference here, but instead an exact match.
All the profiles for which I give the white point and RGB XYZ values in my last post have a tag that says they are V2 profiles. But the darktable profile doesn’t use the same white point tag values as ArgyllCMS and my own profiles. Here are some relevant considerations:
The original V2 specs didn’t say anything at all about how to encode the source color space white point. So many/most profile vendors put that information in the white point tag. At that time there wasn’t any “chad” tag. That’s a V4 thing.
For some reason the ICC decided to rewrite history and publish a revised V2 standard that did things differently, producing what I refer to as a “V2 according to V4 specs” profile.
But older V2 CMM software doesn’t understand the “chad” tag. These CMMs look at the white point tag, which is where the old V2 profiles did put the source white point information. Which is exactly why I switched my profile-making code to produce what I’ve called “true V2” ICC profiles (along with V4 profiles) - some of the people who use my profiles really do need “true V2” ICC profiles to use with software that uses an older V2 CMM.
In a V4 CMM, functionally it doesn’t matter what’s in the white point tag, that tag is just ignored, though the technically correct values are D50 values, not D65 values, even for profiles made from D65 color spaces. V4 CMMs use the chad tag to store and retrieve the source white point information.
In a “V2 according to V4” CMM, if there is such a thing, the white point tag would probably be ignored, and the chad tag would be used. Or maybe such a CMM would look in both places if it really intended to be used with older V2 profiles. But I don’t really know - if you have such software you’d have to do some experimenting to see what it does.
I admit this is confusing. Don’t blame me. Blame the ICC. Some of the changes from V2 to V4 were bitterly contested. How to handle absolute colorimetric intent is one such bitterly contested item. The old V2 CMMs use the information in the white point tag for absolute colorimetric conversion intent, and they allow absolute colorimetric intent even for destination “display” profiles, which a V4 workflow doesn’t allow unless special programming is added, and then for a V4 profile the “chad” tag is used, not the white point tag. It makes no sense to me at all that a V4 CMM isn’t backwards-compatible with the original V2 specs.
Well, the latest revised “V2” specs provided by color.org do include the “chad” tag. I didn’t read closely enough to see if it’s a required tag, though it is for V4 profiles. I’d advise either using D65 in the white point tag, or else adding a chad tag, depending on the needs of various darktable users.
Here’s the page to download the current V4 and latest V2 specs: ICC Specifications
Notice older V2 specs have to be requested via email. They are no longer posted to the color.org website. Also notice that older V2 CMMs do use the information in the white point tag to determine the source white point. So there is a serious conflict here between the latest color.org V2 profile specs and profile-making recommendations and what older V2 CMMs actually do.
So you have to make your own choice, to provide “V2 according to V4” profiles with the source white point information in the chad tag, or “V4 profiles” again with the source white point information in the chad tag, or “true V2” profiles for which the source white point information is available in the white point tag.
Oh, I owe you an apology! When I looked at your profiles did I even mention the white point at all? I think I didn’t. And I didn’t look to see if there was a “chad” tag. My focus was on getting from the EXR file the correct chomaticities for the profile that GIMP was making when the darktable plug-in was used to open raw files, so all I paid attention to was the RGB XYZ values. What the white point tag “should” read and whether there “should” be a chad tag depends on who uses your profiles for what purposes with what software, and also on how closely you want to follow the latest “revised” V2 ICC specs.
Actually, why does darktable supply V2 profiles? For that matter, why does RawTherapee provide V2 profiles? From a practical point of view, what “should” be done with the white point and chad tags for V2 profiles depends on who’s using these profiles with what software for what purposes.
If you are using V2 software that expects to find the source white point in the white point tag, then it’s very wrong to not put the source white point in the white point tag.
The older V2 ICC specs made no provision for “where to put the source white point”. So by consensus, people put that information in the white point tag. There wasn’t a chad tag, so the information couldn’t go there.
The V4 specs say the white point tag should always be D50, which is simply a repeat of the information in the illuminant tag, so functionally speaking doesn’t accomplish anything at all. The V4 specs put the source white point information in a chad tag.
The latest ICC revision of the V2 specs - which seems to be an attempt to “shoehorn” V4 specs backwards into a V2 workflow, or maybe it’s an attempt to break functionality of V2 workflows because that’s exactly what it does - also says “use a chad tag”. This latest revision isn’t being used by software that still uses the older V2 specs, which is the case for ArgyllCMS and also, I’ve been told, for some fairly important print-oriented software.
ArgyllCMS supplies true V2 ICC profiles. The ArgyllCMS profiles don’t contain a chad tag. Are they broken?
What about all the other V2 ICC profiles that have been produced over the years before the V4 specs were released? Are they all broken? They weren’t broken before the ICC “revised” the V2 specs. And they aren’t broken now for people using V2-based software that expects to find the source white point information in the white point tag.
If someone wants to use the ArgyllCMS command line utilities to access absolute colorimetric intent information, they need true V2 ICC profiles. Putting the source white point information in the “chad” tag doesn’t work. It needs to go in the white point tag. Unless maybe ArgyllCMS has added code to handle the chad tag in V2 profiles. At some point there such code was added but it didn’t seem to work very well, and I don’t know if it’s still there because I stopped making and using “V2 according to V4 spec” profiles. If I get really motivated one of these days I’ll make some “V2 according to V4” profiles and see if the latest ArgyllCMS can read the chad tags.
The same is true for at least some important print-oriented software, or so I’ve been told - for full functionality including absolute colorimetric intent conversions, the white point tag needs to hold the source white point information. ArgyllCMS and older V2 “print-oriented” software are the reason I now supply “true V2” and “V4” versions of my profiles, and no longer supply “V2 according to V4” versions of my profiles.
The functional problem with the dt profiles (that led me to report a problem with the ICC profiles constructed from the EXR files exported to GIMP) was with the RGB XYZ tags, and that’s what I looked at. I only glanced at the other profile tags. I didn’t for example verify that every header tag was exactly right or that the TRC tags had exactly right point values. I did notice and should have mentioned the missing “source white point” information, for which I apologize.
If the reason darktable and RawTherapee supply V2 profiles is for embedding in images posted to the web, for browsers that don’t read V4 profiles, either type of V2 profile will work just fine, and unless the browser supports absolute colorimetric intent and the user is actually using color management and also has chosen to use absolute colorimetric intent to view the images (which would be weird), it doesn’t make any difference at all whether the source white point information is present or missing.
But you are right, the darktable D65 profiles should have either a D65 white point tag or a “chad” tag, depending on whether you want the profiles to meet the latest V2 specs, or whether you want the profiles to be useable in software that expects the source white point information to be in the white point tag.
I just pushed a new branch unbounded-processing with the goal of not clipping in the intermediate stages of the pipeline (and allowing to not clip at all if you save as float tiff). It seems to work, except for the following:
it always clips at 0. This makes the code simpler, and I can’t think of any drawback. But this doesn’t mean much… so if someone gives a good use-case for allowing negative values, I’m definitely interested;
CIECAM02 must be turned off. If you turn it on, the output will be clipped. (That part of the code is simply too much for me to handle);
As @Elle wrote above, the default output profiles will clip (specifically, they will cause lcms to work in “bounded” mode); a simple workaround is to set a custom output gamma (e.g. “linear_g1.0”) in the “color management” tool;
I had to mess up a little bit with some SSE2-only code paths; there might be some slight performance degradation but I’m confident that someone more competent can fix this;
there are probably many other bugs that I just haven’t discovered yet.
A little demo (forgive the slow speed, my machine is not exactly cutting-edge):
I just put in out-of-bound display coloration (cyan for < 0.0, magenta for > 1.0) in rawproc, and I was surprised to see how many operations drove tones < 0.0. It’s probably not as egregious to clip to 0.0 as it is to 1.0, but it does give you pause to think; now, I tend to not set a black point in scaling, and wait until the other editing is done, see where it puts the data.
As I have mentioned (Unbounded Floating Point Pipelines - #25 by snibgo ) , negative values can arise from “innocent” operations such as resizing and sharpening. Sometimes, clipping these is acceptable but sometimes it isn’t. We might prefer a more “filmic” treatment that doesn’t lose data.
Hence, please consider this a vote for preventing clipping negative values, where feasible.
EDIT to add: if some stage in the RT pipeline really can’t deal with negative values, developers might consider alternatives to simple clipping. For example, apply a curve that pushes negative values to positive, and (to maintain relative values) make some positive values more positive.
