Feature request: save as floating-point

Software RawTherapee
102

RT has the wonderful CIECAM02 code, and I don’t have any clue what kind of input it requires, except that the range of colors over which it works well is apparently a fairly small color gamut, maybe even smaller than the color gamut over which LAB works fairly well. And I’m pretty sure a whole lot of RT ops aren’t designed to work with channel data outside the range 0.0f to 1.0f.

It might be faster internally to do matrix-to-matrix conversions where possible, saving the use of ICC profile transforms for places where such is really required such as input/output. GIMP and darktable do this already, even (especially) for conversions to LAB/LCH.

103

This is already the case for RT too.

1 Like
104

I just verify my “old” profiles. In 2012 (or 2013) I elaborated them with LCMS, but the code which was between comment /* */ - I think in simpleprocess.cc or ?? has disapeared , or I don’t found it.

I compared with 2 profiles from Elle that must be the same or very near
for Elle profile : LargeRGB-elle-v2-rec709.icc and sRGB-elle-v2-g10.icc

for my profiles : RT_Large_gBT709.icm and RT_SRGB_g10.icm
I make 2 test - 1) compareason with TIFF files 2) compareason with “ICC profiles inspector” and inspect all tags

For 1) no differences or very very small (with Photoshop layers differences in 16 bits)
For 2) no major differences, only very small for example : wp 0.95045 1.0 1.08905 for Elle and 0.95016 1.0 1.08842 for me, which has no or smail incidence. For the rest, same TRC, quasi same XYZ…

The only big differences for others profiles, is that Elle used also v4.

Jacques

1 Like
105

So, in summary, RT_ profiles are correct, similar to those of @Elle with small differences related to the choice of white point.
By cons Elle has other profiles, including V4

Note: if you use “Output gamma” you can generate with all the working profiles, the Output profile of your choice in terms of gamma

Then, I think we can used Elle profiles :slight_smile:

Jacques

106

I have compile the Elle code, made some small changes, to call profiles “RT_xxxx_yyyy.icc” instead of xxx_elle_yyyy, but keep Copyright,

What we do ?

jacques

107

Ask @Elle if she’s fine with that and include the profiles?
BTW, note that from my experiments the “V2” profiles work just fine as far as the “unbounded mode” is concerned. I have no idea of the benefits/trade-offs of V4 vs V2, but I had the impression (maybe wrong?) that V4 profiles are not so widely supported as V2…

108

The copyright for my code is separate from the copyright that I used for the “already made” profiles in the github “profiles” folder. This is to allow software devs to:

  • Either include my profiles “unchanged” without having to compile the code, in which case the copyright in my already-made profiles should remain unchanged.

  • Or else use and also modify the code as desired in accord with the code copyright, to make new profiles to suit, in which case also change the copyright in the new profiles to suit.

If RT uses my code - modified or otherwise - to make its own profiles, I don’t see any reason to attribute the resulting profiles to “Elle Stone”. Though if the resulting profiles are identical to the “already made” profiles that are in my “profiles” folder, feel free to keep my copyright in the resulting profiles if you like.

That’s a lot of words. Profiles are funny things, more like resources than code. The copyright in the actual profiles are intended to allow people to modify my “already made” profiles any way they want, as long as the resulting modified profile isn’t attributed to me, but instead the person who made the modification should be listed in the copyright of the modified profile.

As destination profiles during an ICC profile transform from source to destination:

  • V2 and also V4 ICC profiles with a true linear gamma=1.0 TRC (not a point TRC) work in unbounded mode.

  • V2 and also V4 ICC profiles with a true gamma=X TRC, where X is greater than one, clip any resulting channel values that would be less than zero, but don’t clip resulting channel values that are greater than 1.0f.

  • V2 ICC profiles with the lab, sRGB, Rec709, etc TRC clip any channel value that would be <0 or >1. V4 versions of these profiles that use a parametric curve instead of points, can be used in unbounded mode with no clipping. This is because the linear portion in the shadows allows unambiguous extrapolation of channel values < 0.

If the RT code is just taking the primaries from a user-supplied profile, then of course it doesn’t matter if the user-supplied profile is V2 or V4.

V4 profiles are still not as widely supported as V2 profiles, despite the ICC’s best efforts. That’s why my profile-making code makes both V2 and V4 versions of all the profiles. Especially in print-oriented applications V2 profiles have some advantages, or so I’ve been told. ArgyllCMS doesn’t yet work with V2 profiles.

FWIW, my code makes “true” V2 profiles, not “V2 profiles made according to V4 specs”, in response to a request made by a person who uses both V2 and V4 profiles and wanted “real” V2 profiles - otherwise V2-based applications can’t determine the source white point for absolute colorimetric conversions.

1 Like
109

@Elle
Thank you for your response :slight_smile:

As, I only modified the name(s) of profiles, I think better to keep your name in “Copyright” it is your work , thank you for this good job :slight_smile:

@agriggio @Morgan_Hardwood
Now, there are 37 profiles - do we keep them all, or only a few, and if so, which ones?

Other question for me, I am not a computer scientist ! how to do next to update “Dev” ?

jacques

110

@jdc where can I find them?

Said the guy who wrote, among others, the CIECAM02 module :slight_smile:

git rm unwanted_old_files.icc
git add new_files.icc
git commit -a

But let’s first open an issue with the 37 profiles, so we can test before committing.

111

True that!

112

I had bad experience with exotic profiles and photolabs. Since they (at least those few I was cooperating with) accept only sRGB and AdobeRGB files, color management was off or the whole photolab refused to work. First case resulted in dull, low saturation and contrast images with yellow skin, second case in a phonecall: “Hi Jacek, your photos jammed our Noritsu once again”.

So my question is: will the new super-duper color profiles comply with all the standards, supported by low end, cheap print services, as well as high-end photolabs? Or are they just for exporting into 3rd party software?

113

@cuniek you can still use your own output profiles, as usual. in your specific case, I’d try to convince your photo lab to send you their printer profile so you can soft-proof…

114

I have their color profiles, I softproof. Everything prints fine when I export to sRGB (I learned that wide gamut is not an option for printing). Still they got random crashes with my files (saved into sRGB). Once I sent them 800 files and poor guy had to open them in Photoshop, and resave, otherwise the printer/lab refused to print them. I tried to nail the problem but I failed (and so the owner of photolab, he said that he never saw anything like that. Filesize was ok, 24bit sRGB, jpeg, all applications open them without any warnings, still random crashes). I was using RT_sRGB in case You ask.

115

what makes you think it was the profile?

116

Well, here is what I know:

-When I sent them a tiff file exported into RT_Large_g10, the file was printed allright, but looked exactly the same as when I opened the file without color management. Later it turned out that they support sRGB and AdobeRGB only. So that was my mistake.

-Their Noritsu randomly refuse to print jpeg files saved into RT_sRGB (owner said this was not file specific, few were printed, and then crash. They started printing from last unprinted file - worked fine until anothe crash, and so on). Prints had spot on color and contrast (I was softproofing).

-I saved tiff files into RT_sRGB, opened in Affinity Photo (it shows that the color profile is IEC61966-2.1 sRGB, and does not modify it) and saved into sRGB jpeg. The same behaviour. The only thing inherited from RT is the color profile.

-I saved into RT_sRGB, than Affinity Photo tiff (without colorspace modyfication), and resaved files in RT into RT_sRGB once again - the same problems.

I haven’t had time or strength to experiment more. Maybe this summer.

117

thanks for the info. you could also try setting the profile from outside RT completely (eg in GIMP) and see if it still crashes… whenever you have time of course

118

Hmm, the only thing odd about the current RT sRGB profile that I can see, is the 4096-point TRC.

I was going to say that my V2 point curve profiles use 1024 points. But I double-checked to verify after I saw your post, and in fact even though I intended that my profile-making code copy the 1024-point curves from some included “sample V2” profiles in the code folder, somehow that isn’t happening. Instead my V2 profiles have 4096-point curves just like RT profiles.

By the oddest coincidence I got a private email today (just now in fact) specifically asking about those V2 point curves. When it rains, it pours :slight_smile: . Anyway, I will do my best to fix my code so that the V2 profiles with point curves actually do use the intended 1024-point curves and not 4096-point curves.

Which of course doesn’t guarantee that problems with the printing of your images will be solved by using 1024-point curves. But I’m very grateful to you and also to the person who emailed me about the V2 point curves, for having taken the time to point out this fairly serious problem (well, I think it’s a serious problem) in my V2 profiles.

My apologies! for failing to double-check something so basic as “Are those V2 point curves really 1024-point instead of 4096-point curves”.

119

@Elle, just for my education, why is having 4096 points a problem? is this violating the standard?

120

@agriggio
Alberto

By default it is LCMS that fixe this value

#define MAX_NODES_IN_CURVE 4097 in cmsgamma.c

jacques

121

Well, for my V2 profiles I wanted the profiles to functionally match ArgyllCMS V2 profiles that have TRCs that require point curves, which have 1024 points, as do most other older “real V2” sRGB ICC profiles. So my decision to use 1024 points (which now I know doesn’t actually happen with my current profile-making code) wasn’t based on “there are standards” but rather on matching existing “real V2” (as opposed to “V2 according to V4 standards”) profiles.

As far as standards go, there are standards for color spaces, such as the sRGB color space. Then there are V2 and V4 ICC specs for making ICC profiles from the color space specs. I don’t recall if the original V2 specs made any such specification as “this many points”, and I don’t recall any such specification in the V4 specs, but in both cases I think it’s not likely that there is such a restriction embedded in the ICC specs.

Regarding the LCMS point profiles with “more points”, didn’t Marti make that change in response to a discussion with the RT devs? The problem was the accuracy with which LCMS makes conversions between V2 point curves. My recollection is that ArgyllCMS (and perhaps other CMMs besides LCMS) interpolates between the points, whereas LCMS quantizes. For example see this thread:

https://sourceforge.net/p/lcms/mailman/message/31673858/

Also see this somewhat related thread, where the problems (especially evident for channel values near zero) with V4 matrix-to-matrix transforms fortunately were subsequently fixed in LCMS (click on “View entire thread” to view the entire thread):

https://sourceforge.net/p/lcms/mailman/message/32821597/

Another way that the RT sRGB “V2” profile differs from older and ArgylCMS sRGB V2 profiles is in the presence of “unicode” tags. For example, here’s a tag from ArygyllCMS “sRGB.icm” profile (note the MacScript tag isn’t in all of ArgyllCMS profiles):

<textDescriptionType>
  <TagSignature>desc</TagSignature>
  <ASCII><![CDATA[sRGB IEC61966-2.1 (Equivalent to www.srgb.com 1998 HP profile)]]></ASCII>
  <MacScript ScriptCode="0000">735247422049454336313936362D322E3120284571756976616C656E7420746F207777772E737267622E636F6D20313939382048502070726F66696C652900</MacScript>
</textDescriptionType>

And here’s the equivalent tag from RT sRGB profile:

<textDescriptionType>
  <TagSignature>desc</TagSignature>
  <ASCII><![CDATA[RT_sRGB gamma sRGB(IEC61966 equivalent)]]></ASCII>
  <Unicode><![CDATA[RT_sRGB gamma sRGB(IEC61966 equivalent)]]></Unicode>
</textDescriptionType>

And from my own V2 sRGB profile (like RT’s profile and unlike ArgyllCMS profiles), there is the Unicode line:

<textDescriptionType>
  <TagSignature>desc</TagSignature>
  <ASCII><![CDATA[sRGB-elle-V2-srgbtrc.icc]]></ASCII>
  <Unicode><![CDATA[sRGB-elle-V2-srgbtrc.icc]]></Unicode>
</textDescriptionType>
  </Tags>

So perhaps the printing place @cuniek uses somehow has V2 software in the pipeline, feeding stuff to the printer, that might stumble over the unicode parts of the RT profile?

But seriously this is just a guessing game as to what causes the Frontier printer to have issues with RT jpegs - what we really need is an example output jpeg from PhotoShop, that was output using the version and the specific color management settings that are used in the establishment with the Frontier printer.

If the Frontier printer only takes sRGB input, I’m curious why the processing pipeline even looks at any embedded ICC profile, as it could just assume the input is sRGB input. Though this would result in truly awful results for non-sRGB files sent to the lab. And if there really is a profile conversion going on from the embedded ICC profile to some other destination ICC profile, why doesn’t the Frontier printer fail on every single jpeg with the RT profile embedded?

Personally I don’t use V2 profiles when doing ICC profile conversions using LCMS or when image editing using LCMS as the CMM. Instead, I make profile conversions using the equivalent V4 profile. If I want a V2 profile in a final output file - such as uploading an sRGB image to the web - then I assign the equivalent V2 profile to the already converted image file, using exiftool, which I’m already using to add copyright and such, so it’s not really an extra step. But obviously my “workaround” is limited to standard matrix RGB output spaces.