Although RT works in floating-point, it can’t save to TIFF as floating-point. Is that correct? Are there plans to add this? It would seem a simple addition (though I could be wrong).
I’m not so concerned by the greater precision from floating-point (though that would be nice), but with out-of-gamut results. Then I could do my own processing after RT to deal with OOG.
(My apologies if this is a FAQ. I couldn’t see it anywhere.)
@snibgo Welcome to the forum! You are right that RT doesn’t currently export floating point (http://rawtherapee.com/blog/features). PhotoFlow does if you are interested.
As an aside, I don’t know if you can recall that you helped me in the IM forums several years ago. I have learned a lot since then. It is a pleasure to welcome you here 
.
Sounds like a good shout to me, assuming you could import the tif into Gimp (and so benefit from the greater accuracy).
@snibgo Have you made this request on their github or searched for an equivalent? I think that the RT devs prefer it that way. See: GitHub - Beep6581/RawTherapee: A powerful cross-platform raw photo processing program, maybe Support for saving 16-bit floating-point or 32-bit TIFFs · Issue #2357 · Beep6581/RawTherapee · GitHub?
@afre - you beat me to it That issue 2357 seems to be the closest issue for requesting 32f output. I thought there was another, but I couldn’t find it.
I think that a lot of RT users would rejoice the day it happens! Just waiting for that gallant hero to appear. Or maybe a lowly squire might rise to the occasion… to be continued.
As far as I know, floating-point TIFFs created with PhotoFlow are loaded without troubles into GIMP 2.9.x, so the same should be for RT’s 32f TIFFs once available…
Thanks for the welcome. I’ve submitted a git issue: Save as floating-point TIFF · Issue #4190 · Beep6581/RawTherapee · GitHub
Yes, Gimp (v2.9.3) and ImageMagick (HDRI) can read and write 32-bit/channel floating-point TIFFs.
I’m think of the case where I take a load of photos, process one in RawTherapee, and apply the same processing to the batch of photos while I get a coffee. I want the computer to tell me which photos had problems (eg out-of-gamut), and how it has tried to fix them (eg with highlight and shadow curves). In general I want to prevent clipping, not fix it after it has occurred.
Hi, I just pushed an experimental RT branch tiff32float that lets you save 32-bit floating-point TIFFs. Please note that:
I knew nothing about the TIFF format before tonight;
I still know almost nothing about the TIFF format;
I had to change quite a few things in RT, and I might have broken something;
So, this needs to be tested extensively!
That said, I was able to create a 32-bit float TIFF that can be opened successfully both in RT and GIMP. But I did not test all the possible combinations (in particular I did not try custom output profiles), so take all this with care. Use at your own risk. It might destroy your computer or worse. You have been warned
So for the adventurous W64 user, you will find
RawTherapee_tiff32float_5.3-212-g912f9f43_WinVista_64.zip
at https://drive.google.com/open?id=0B2q9OrgyDEfPS2FpdDAtMVI1RG8
Thanks for the quick turnaround. I’ve downloaded and installed.
The good news is: I used RT to read a NEF file (from a Nikon D800), ramped up the “exposure compensation” to the max, turned off “Highlight reconstruction”, turned down "Highlight compression, so virtually all pixels were out of gamut, and saved.
Gimp and ImageMagick can read it. It is 32-bit/channel floating point.
Now the bad news: the maximum value in the image is 1.0 (on a “in-gamut” scale of 0.0 to 1.0).
Do I need to flip another switch in RawTherapee so it will write OOG pixels to the file?
Thanks for testing! I’ll need to take a closer look to see where clipping happens…
Is it appropriate to add to the feature request, that importing it as floating point would also be useful, and very likely related? Or should I open a separate issue?
opening 32-bit float tiffs is already supported
The options to not clip outside of 0.0-1.0 is what I like about PhotoFlow. If this becomes a feature in RT and RT no longer has the slowdowns described here, I would be using RT more often 
.
@afre I’m not sure what slowdowns you are referring to exactly, but startup times have improved significantly as of late.
regarding clipping, unfortunately that happens deep down in the pipeline, so it’s not something fixable in 5 minutes I’m afraid 
Yes, the load time has improved significantly. Still too slow for my comfort but that is my system’s and my own problem. Also when working with multiple windows, it takes 10s+ for inactive ones to become active. In any case, if I use RT, I will use an earlier version.
No worries about the clipping “issue”. I agree that we would have to make some fundamental changes for that to be practical. Just felt like 
ing. That is all.
I just updated and compiled RawTherapee from git, the “dev” branch. Some nice changes, including 32-bit floating point tiff output - Awesome! Thanks!
Though on exporting a 32-bit floating point tiff, (which did open with no problem in GIMP-2.9), apparently “something” went wrong - the CPU was churning away, and this was printed in the terminal:
(rawtherapee:24167): GLib-GObject-WARNING **: instance of invalid non-instantiatable type 'gchararray'
(rawtherapee:24167): GLib-GObject-CRITICAL **: g_signal_handlers_destroy: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
Segmentation fault
Hmm, no, sorry, that terminal output was from earlier running the version of RT installed from Gentoo portage, sorry! too many terminals open at once! But the “CPU churning” did stop as soon as I closed RT.
Can not reproduce using latest dev code.