Thank you :)

What is the CCE edition of GIMP?

Elle Stone's "Color Corrected Edition":

http://ninedegreesbelow.com/photography/patched-gimp-compared-to-default-gimp.html

...specifically I tested the latest at pixls.us/files:

 https://pixls.us/files/gimp-cce-2.9.5-20170405.glibc2.15-x86_64.AppImage

Thanks for looking in to it!

(In reply to gnome_bugzilla from comment #0)

> The CCE
> edition of GIMP seems to open them properly, but I didn't check if it's
> actually scaling to the appropriate range or if it's just normalizing to
> min/max.
> 
> Attached files include:
> 
> original.tif -- 16bit integer -- opens fine in GIMP; from Canon Digital
> Photo Professional
> 
> original_16bit_int.tif -- a 16bit integer tif
> gmic_output_32bit_float.tif -- g'mic's 32bit float output -- opens white in
> GIMP
> gmic_output_scaled.tif -- also 32bit float, but scaled to [0,1] with g'mic
> -- opens fine in GIMP

Actually, in my local copy of CCE the file "gmic_output_32bit_float.tif" opens as "white" - all the RGB values are considerably >1.0. Auto-stretching restores the colors. The file also opens as white in Krita 3.12. Did G'MIC generate this file?

My mistake! -- CCE opens the same as regular gimp. Sorry for the confusion -- I was tracking a lot of behaviors across many apps and forums and example files. :-)

Yes -- G'MIC generated that file. It writes 32bit floats in the [0,65535] range.

After looking at the files, and the code, I'm pretty sure that G'MIC
is simply writing broken TIFF files.

Assuming that a "default" range of float (16, 32 of 64) bits is "normally"
0.0..1.0, G'MIC should really scale things to that range, or alternatively
set 

TIFFTAG_SMIN,MAXSAMPLEVALUE

(*not* TIFFTAG_MIN,MAXSAMPLEVALUE, which is not supposed to
 modify data interpretation at all).

At least if I'm reading the spec correctly:

https://www.itu.int/itudoc/itu-t/com16/tiff-fx/docs/tiff6.pdf

Pages 81 and 82.

To avoid the monster of TIFF setting permutations rearing its heads at us, it would be nice if g'mic could write processed 8bpc/16bpc integer files out as normalized 0.0-1.0 floating point in TIFF rather than what currently seems to be the case and annotate it with additional meta-data that different programs reading TIFF are bound to interpret differently.

I could not agree more. we should probably do nothing in GIMP.

Thanks guys -- I don't think g'mic is interested to normalize to 0,1 -- per discussion here: https://discuss.pixls.us/t/high-bit-depth-tiff-compatability-issues/3725/12

He makes the point that floating point data may have physical interpretation, such as the number of photons measured by a sensor, and that scaling to [0,1] seems an unnecessary limitation.

I'm chatting with him about it, and he has added a preliminary commit for adding the metadata described above. I'll let you know how it turns out.

And yeah, it's obviously not the end of the world if GIMP doesn't want to interpret the metadata, since there's already an easy way to have g'mic scale to 0,1.

That said, it does seem logical that GIMP should read that metadata and use it, if it's present, no? Otherwise, you're enforcing an arbitrary convention on the floating point range?

I don't believe that TIFFTAG_SMIN,MAXSAMPLEVALUE should affect the interpretation of the image data at all. I interpret the spec so that this is an alternative to TIFFTAG_MIN,MAXSAMPLEVALUE for sample formats != SHORT. Note that the data type for TIFFTAG_MIN,MAXSAMPLEVALUE is specified as SHORT, where TIFFTAG_SMIN,MAXSAMPLEVALUE inherits its type from the sample format.

The Comment says that "The presence of these fields makes it possible for readers to assume that data samples are bound to the range [SMinSampleValue,
SMaxSampleValue]".

It would be wrong to scale the image data in a way that SMinSampleValue gets mapped to 0 and SMaxSampleValue to 1.0.

It also would be wrong to use SMaxSampleValue as a place to store the "normal white value", this would invalidate the assumption described in the comment.

If there is no other way to store a "default white sample value" I don't see what gimp can do here. Having sample values in the range from 0.0 to 65535.0 might totally be reasonable for a hdr image, even when its default white sample value is 1.0.

Having 1.0 as the "default white sample value" seems to be the commonly accepted default interpretation. Yeah, if the tiff contains photon counts this will be interpreted wrongly by gimp, but then the user has to make sure that the sample values get mapped accordingly (hopefully this can be done by levels tool & friends).

@Simon -- I saw the same thing; there are a few places in the spec that led me to think otherwise re: the semantics of those tags, but at best it's vague, and the g'mic developer isn't setting them to the range anyway, he's setting them (in a preliminary commit) to (min, max), so they wouldn't work for this purpose anyway.

So it sounds from both the g'mic and gimp sides that things are already working as they should be, and users can just adjust the output of g'mic manually. Thanks for looking at it.

Ok, lets close this for now.

Please feel free to reopen if there are new interpretations or insights into the tiff specification.

Thanks for your input.