Save as 16 float tiff error

Hi guys. I have a problem saving as tif 16 float. When I open file from rawtherapee in some other software like GIMP the file is 16bit float but it looks that some information are lost. In original image a have a sky that is over burn. If I lower the exposure, I can see clouds. If I do the same operation with file saved by RawTherapee I will never see clouds. It looks like the data are converted to integers first and than again to float.
I’m using rawtherapy-cli but using inferface it is the same. The simplest command that I’m using is:
rawtherapee-cli.exe -o “16f_e.tif” -a -t -b16f -Y -c “in.tif”
If I add some profile it is the same.
16f_e.tif (7.3 MB) in.tif (7.0 MB)

Perhaps you will have to give more details, and add some more explanations.

First question: why do you convert from a 16 bit floating point tiff to another 16bit floating point tiff?

Post caught my eye, because 16-bit float is not a universal thing in software. Image libraries like OpenEXR support it, but they had to write their own data type library for it, as the programming languages don’t support it natively.

Reviewing the rawpedia page on command line options and the command line you provided, I don’t think ‘-b16f’ will do what you’re hoping, as the -f switch is defined “Use the custom fast-export processing pipeline.” I didn’t see any command line option that allowed saving to a float format.

Sadly RawPedia seems to be outdated there. If you call rawtherapee-cli -? you will see several options not documented:

  -b<8|16|16f|32>  Specify bit depth per channel.
                   8   = 8-bit integer.  Applies to JPEG, PNG and TIFF. Default for JPEG and PNG.
                   16  = 16-bit integer. Applies to TIFF and PNG. Default for TIFF.
                   16f = 16-bit float.   Applies to TIFF.
                   32  = 32-bit float.   Applies to TIFF.

My question was about converting a floating point tiff to another floating point tiff, and maybe it’s there where the problem is, although I can’t see any reason to do that.

1 Like

Normally I apply some profile. This command line is a simple example to show the bug. Theoretically if I pass 16f tif to RawTherapee and save it, it should be identical. Like a standard piepe. cat aa.txt > a.txt I whould recevie the same file. With rawtherapee is not true. I pass 16f tiff and gets something like 8-bit integer that is pretending to be 16f

Can you try with this one disabled?

grafik

1 Like

It doesn’t change anything

Thanks for testing. Internally RT works in 32 bit single precision float and most of the time the values are in [0.0;65535.0[ range.

That’s the reason why I personally never use 16bit floats:

Precision limitations on integer values

    Integers between 0 and 2048 can be exactly represented (and also between −2048 and 0)
    Integers between 2048 and 4096 round to a multiple of 2 (even number)
    Integers between 4096 and 8192 round to a multiple of 4
    Integers between 8192 and 16384 round to a multiple of 8
    Integers between 16384 and 32768 round to a multiple of 16
    Integers between 32768 and 65519 round to a multiple of 32[9]
    Integers above 65519 are rounded to "infinity" if using round-to-even, or above 65535 if using round-to-zero, or above 65504 if using round-to-infinity.
1 Like

Yes, I’ve read all of the OpenEXR prose about the space-saving of 16-bit float and still providing the precision of float, but that doesn’t add up when comparing to 16-bit integer; you’re using bits to encode information structure, at the expense of actual information…

1 Like

Yes, that’s all bullshit.

In raw processing we start with non-negative integer values. Let’s say this values are in 16-bit range [0;65535].

Encoding them using 16-bit floats means:

  1. we have only 15 bits to encode them (because of the sign bit we do not need)
  2. still 15 bits left, but max value is lower than 65535
  3. the precision in higher values (>= 2048) is much reduced, while the precision in lower values (< 2048) stays the same (at least, if we do no calcuations on the data and just convert from unsigned int 16 to float16)
1 Like

Nice to know that 16-bit float is not a best idea, but still I don’t have a solution to my problem. I have 16-bit float HDR input image. I open it with raw therapy, save it and I get something that is not HDR image anymore. Please take a look at images that I uploaded with first post. I’m not talking about screen shots, I’m talking about tifs.
To be honest, for me the ideal would be to open exr and save exr.

One more thing. I’ve tried to save as 16-bit int, 16-bit float, 32-bit float and non of them looks to be working. As I said in first post, if I open them with gimp, I can make exposure correction only to original image. I can not correct exposure of any image saved by RawTherapee

Which version of gimp?

I have never come accross such a claim, can you please provide a reference? Any prose I saw was selling it as suitable, certainly not equivalent. It would be the same as saying 32-bit float provides space saving while guaranteeing the precision of 64-bit double float…

@heckflosse Let’s please keep the language civil, or some good engineers might take personal offense for the effort they’re putting into developing various useful technologies.

Yes, half-float (or FP16) does not provide the same precision as regular 32-bit float (well duh). But that doesn’t mean it’s not a suitable encoding format. If Greg Ward found it provides a balanced trade-off and is practical for HDR content storage, I tend to believe him. Heck, the GPU industry even thinks it’s good enough for processing.

The point is, because of Weber-Fechner law (or Barten’s sensitivity model if you want to be even more precise), and the photon shot noise, you don’t need the same small quantization step at higher intensities, so it’s not a big deal to skip some integer values at the top of the range. In a way, the quantization per f-stop is constant, so this is a nice format for imagery.

You can think of half-float as another form of visually lossless compression - it’s not truly lossless, but still better than any log or gamma scheme.

GIMP version 2.10.18

Guys, this discussion is very interesting but it does not help so solve my problem. I can save as 32-bit float and I hope we all agree that it has highest precision.
I repeat. I have at the begging 16 float OpenExr image. As rawTherapee does not import it, I convert it to 16 float TIFF. This tif is a real HDR image. I can correct exposure and see thing that previously were totally white. Than export this image from rawTherapee (without applying any modification, just open and save). The image is loosing some data. If I reopen exported image exposure correction is not working correctly anymore. Data are lost. And it does not matter if I export 16-bit int, 16-bit float or 32-bit float.

The data is already lost on import.

they are not lost on import. In rawTherapee I can correct exposure so they are not lost

If I set this
grafik
for in.tif the data is not lost

Huh. :confused: I opened in.tif in RT dev, applied “Neutral” and reduced exposure: still pure white, no sky.