Save as 16 float tiff error

[floessie (Flössie)]

Confirmed.

[heckflosse (Ingo Weyrich)]

[gaaned92]

Yes no profile (pass through) does not clip. But using the embedded input profile (sRGB IEC61966-2.1) clips the highlight though it should not.

If I use no profile and I use woorking profile sRGB with TRC, I obtain the same as embedded.
So IN.tif could be coded in a linear space (as it should ) with a gamma TRC profile embedded.

[heckflosse (Ingo Weyrich)]

@gaaned92

But using the embedded input profile (sRGB IEC61966-2.1) clips the highlight though it should not.

Afaik nothing we can do here. RT uses lcms2 with TYPE_RGB_FLOAT for that transform. If the input profile does not match the input, we will get wrong results.

[ggbutcher (Glenn Butcher)]

@kmilos

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…

Yeah, that was a bit off-the-cuff. In terms of encoding precision, I think it’s more appropriate to consider 16-bit float against 16-bit integer. For internal processing of single images the well-supported 32-bit float works just fine. With the volumes of data involved with video, that consideration changes: https://www.openexr.com/about.html

I incorporated half float in my hack software to accommodate low-memory 32-bit architectures. I used Christian Rau’s half library. the code to conditionally incorporate multiple data types was a PITA to maintain, and if I ever had SSE aspirations I don’t know how I’d handle that. For my next version I’m going to abandon support for it.

[bartek_zgo (Bartosz)]

Sorry but I still don’t understand. [heckflosse] has obtained the sky. So in file in.tif there is sky as I said. So what is wrong after saving the file? What I’m doing wrong?

[heckflosse (Ingo Weyrich)]

@bartek_zgo

What I’m doing wrong?

On in.tif use a profile (pp3) where No input profile is set.

Edit: Clip out-of-gamut colors should also be disabled, as mentioned above…

tiff16f.pp3 (12.4 KB)

[gaaned92]

@heckflosse

Afaik nothing we can do here. RT uses lcms2 with TYPE_RGB_FLOAT for that transform. If the input profile does not match the input, we will get wrong results.

It is the same in GIMP. if I don’t convert to internal sRGB it doesn’t clip. If I convert to internal sRGB it clips.

@bartek_zgo There is a clipping due to the input color space conversion. with no profile, there is no conversion so no clipping.
How you generated the in.tif file?

[heckflosse (Ingo Weyrich)]

@gaaned92

But it seems to works in GIMP and there is no clipping.

Do we know, whether GIMP uses the embedded profile for float tiffs or just ignores it?

[gaaned92]

See above: it is the same in GIMP.
Why LCMS2 is clipping? I thought it was used in unbounded mode.
https://ninedegreesbelow.com/photography/lcms2-unbounded-mode.html

Perhaps sRGB cannot work in unbounded mode?

[heckflosse (Ingo Weyrich)]

So you mean, GIMP ignores the embedded profile?

[gaaned92]

No it is like in RT. when loading a file, you can either bypass the input prfile (no profile in RT) or convert to internal sRGB(embedded in RT).
And result is the same as in RT.

[heckflosse (Ingo Weyrich)]

@gaaned92

And result is the same as in RT.

Well, then I do not understand the issue

[gaaned92]

@heckflosse

Well, then I do not understand the issue

when you do not apply the embedded profile (in RT or GIMP) there is no clipping .
When you apply the embedded sRGB IEC profile to go in other space (WS in RT or internal sRGB in GIMP) there is a clipping.

It seems not to be a RT or a GIMP issue, but that sRGB cannot work in unbounded mode.
At least that is that I understand about unbounded profiles.

[ggbutcher (Glenn Butcher)]

@gaaned92

It seems not to be a RT or a GIMP issue, but that sRGB cannot work in unbounded mode.
At least that is that I understand about unbounded profiles.

LittleCMS will do unbounded transforms if 1) the input and output profiles are V4, and 2) the image data format is floating point. At least that’s what I can gather from:

CIC18_UnboundedCMM.pdf

[heckflosse (Ingo Weyrich)]

My conclusions:

1. don’t assign an input profile on a float tiff

2. If an input profile is assigned to a float tiff
   2.1) either ignore it
   2.2) or, if it is a v4 profile (unbounded), use it

3. change the issue title, as the misbehaviour is not caused by saving the tif in RT, but by applying a misbehaving input profile to a float tiff when loading the file in RT or GIMP

[paulmiller]

The problem is the source profile.

If you use a icc V4 sRGB profile (which uses parametric curves to define the EOTF, rather than the LUT based ones in the V2 profile which is currently on in.tif), then lcms will do conversions in unbounded mode and -5 stops of exposure compensation will recover blue sky in RawTherapee. The saved TIFF file will not have values clipped at 100% either (provided you turn ‘clip out of gamut colours’ off).

[kmilos]

@ggbutcher

I think it’s more appropriate to consider 16-bit float against 16-bit integer.

Therein lies the rub. It’s apples and oranges.

For a single raw shot the 16-bit integer storage might have a slight numerical advantage (perceptual quality difference is debatable because of said photon shot noise and non-linear eye response), but good luck trying to encode more than 16 stops of dynamic range without any loss

[gaaned92]

@heckflosse, excuse me, I would rephrase your conclusions following @paulmiller post :

1. assign a V4 profile to float tiff files and preferably a linear V4 profile
2. If an input profile is assigned to a float tiff
   2.1) if it is a V2 profile either ignore it using “no profile” (the colour will be out) or reassign a V4 profile with “custom”.
   2.2) if it is a v4 profile (unbounded) use it using “embedded profile”.

This could be documented in rawpedia.

Bug in RT : it seems that there is no linear output profiles bundled in RT even those that have to be linear ( ACES profiles ).

Demonstration:

[paulmiller]

My post oversimplifies the situation.

Not all V4 ICC profiles will work in unbounded mode. Not all ICC engines will work in unbounded mode.

Most ICC rendering intents (Relative Colorimetric, Perceptual, Saturation) are output referred - they encode colours relative to a ‘media white’ value. You can’t have a colour lighter than media white. Absolute Colorimetric rendering intent can be used for scene referred data, but usually the maximum luminance value is restricted to 1.0 (which makes it not very useful if your scene has specular reflections or light sources in it). Unbounded mode relaxes this restriction.

ICC V4.3 supports unbounded mode transforms but only as an optional extension under limited circumstances (I don’t think I have seen any ICC profiles in the wild which use the necessary D2Bx tags, and even if you have one, support for this particular corner of the ICC spec is patchy across different CMMs - probably because there are no profiles…).

LittleCMS’s unbounded mode is an extension of the ICC standard, which makes unbounded mode available on a wider range of profiles. Think of an ICC profile as a toolkit of different processing steps (parametric curves, matrices, 1D and nD LUTs…), rather than a single thing. If all the steps involved in a transform are compatible with unbounded mode, then lcms will use unbounded mode otherwise, your values will get clipped.

So, you can get unbounded mode working but you are likely to run into compatibility problems if you use the resulting files with software or profiles that do not support unbounded mode. If it fits your particular workflow, thats fine - but I would be wary of distributing (or archiving) content encoded this way.