Feature request: save as floating-point

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

1 Like

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 :wink:.

@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 :frowning:

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 :wink: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.

@Elle please be aware though that 32-bit float tiffs are still clamped to 0-1; changing that is desirable and hopefully it will be done at some point, but it requires some major refactoring of the internals…

I’m posting this just in case it’s relevant. Just now running RawTherapee compiled yesterday from the “dev” branch, this message was printed to the terminal screen:

$ rawtherapee
blockdenom vanishes
blockdenom vanishes

Regarding the “churning” that I mentioned, yesterday while using RawTherapee, after making some adjustments to a raw file and then exporting as a floating point tif, then making some additional adjustments and exporting again under a new file name, and etc for maybe 5 or 6 iterations, my computer froze. After several minutes the computer was still frozen - even the task bar cpu and ram displays were frozen - shutting down individual windows wasn’t possible. So I used the physical “shutdown” button on my computer to shut the computer down.

Since then I’ve avoided doing more than two iterations of “make changes and then export” because at the second export, things start to slow down on my computer - changing windows is slow, etc. I have no idea whether/if/how RT itself might be the problem as coincidence is not necessarily linked by causality. Anyway, when I recompile RT I’ll use “debug”.

@Elle does it happen only if you export as a float tiff?

I experienced the same issue when testing something involving saving images to all formats, including 32-bit TIFF. RT ate up all RAM and my swap was almost at 100%. I managed to kill RT from the TTY.

@heckflosse told me that “blockdenom vanishes” means that raw auto CA correction was not able to detect correction parameters.

Thanks! - sometimes I wish terminal output were a little less cryptic. I guess this means the image in question didn’t exhibit any signs of chromatic aberration that might need correction? Or maybe it means that it seemed like one part of the image needed one set of parameters and another part needed another set of parameters?

@agriggio - I haven’t yet tried exporting at other bit depths. But given what @Morgan_Hardwood reports, maybe the type of exported image isn’t relevant.

My computer has 32GB RAM and 16GB swap, and when my computer froze the taskbar “RAM” monitor did indicate a fair amount of RAM was in use, but it didn’t look anywhere near 100%.

I just pulled the latest RT code and recompiled using “debug”. Next time I start RT I’ll keep a watch on the RAM usage. When starting RawTherapee, are there any command line switches that maybe I should use to get better terminal output, something like using “–verbose” when starting GIMP?

hi,

maybe I am misunderstanding what he wrote, but I still think this is relevant…

These blockdenom vanishes are from Emil’s original code and no one ever changed them.
I agree that we should improve that.

Anyway, it means, that raw auto ca correction failed and the image is not ca corrected.

Edit: the blockdenom vanishes also is in darktable version of raw ca correction :wink:

Well I did also export 32-bit fp, so my point was that it does seem like this format was the trigger. When I export only 16-bit TIFF, which I usually do, there are no problems.