Support for saving 16-bit floating-point or 32-bit TIFFs

[Beep6581]

Originally reported on Google Code with ID 2374

With regards to issue 2369 which brings read support for 16-bit, 24-bit and 32-bit floating-point
DNG files, it would be nice to have the ability to save 16-bit floating-point TIFFs
(and 24-bit and 32-bit ones?).

Update 2016-08-09:
The referenced old issue 2369 is new issue #2353

Reported by entertheyoni on 2014-05-08 05:47:04

[Beep6581]

I'm working on this.

Reported by natureh.510 on 2014-05-08 17:44:42

• Status changed: Started
• Labels added: OpSys-All

[Beep6581]

Just curious ..

How many discrete levels can 16bit float handle ?.
If I understand what happens .. it should be 16384 distributed as 1024 levels for each
stop .. this looks equivalent to 14bit int with gamma2.0 encoding .. Am I missing something
?.

Reported by iliasgiarimis on 2014-05-08 18:41:30

[Beep6581]

Ahh sorry .. 5bit exponent - 10 bits mantissa so 32*1024 = 65536

equivalent to 16bit int gamma2.0 encoded ?.

Reported by iliasgiarimis on 2014-05-08 18:55:27

[Beep6581]

I can't answer to your question illias, but it'll save to 32 bit fp, so it's worth the
effort.

Reported by natureh.510 on 2014-05-10 23:22:25

[Beep6581]

One question: following the same thinking than for the HDR DNG patch, can I switch the
internal output image type from IImage16 to IImagefloat, increasing the memory footprint
(the conversion to 16 bit would be done at serialisation time), or should I handle
2 image format through template to use less memory for standard output (8-16 bit, i.e.
98% of cases)?

I've followed the second route so far, but the first one would be simpler to code.
Anyway, if I manage to finish the patch of the second solution, the question would
be pointless.

Reported by natureh.510 on 2014-05-10 23:40:15

[Beep6581]

Hombre, I think, memory footprint doesn't matter at this stage.

Reported by heckflosse@i-weyrich.de on 2014-05-11 00:35:28

[Beep6581]

Do we also care about the LCMS transform speed? It shouldn't be the same from working
with INT_16 and FLT values. I haven't quantified the difference though.

Reported by natureh.510 on 2014-05-11 01:19:00

[Beep6581]

#4, Hombre my question is not about usefulness but to understand the differences.

I think that even the "half float" format will be useful because the data will be linear
without a gamma function needed, so best accuracy and speed maybe .. No idea about
compressibility though .. we have to test how it goes .. 

Then it is the thing about downsampling in linear space which is better .. :) https://code.google.com/p/rawtherapee/issues/detail?id=2286#c1

Reported by iliasgiarimis on 2014-05-11 04:25:45

[Beep6581]

Working in pure float (not mixed with int16 as now) also makes it easier to make a vectorized
version for resizing.

Reported by heckflosse@i-weyrich.de on 2014-05-11 11:19:49