RSS/Atom feed Twitter
Site is read-only, email is disabled
  1. Chat
  2. Useful links
  3. Polls

Featured content

high bit depth tiff issues

This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

3 of 3 messages available
Toggle history

Please log in to manage your subscriptions.
high bit depth tiff issues Casey Connor 28 Apr 06:07
  high bit depth tiff issues Michael Natterer 28 Apr 07:55
   high bit depth tiff issues Casey Connor 28 Apr 16:49
Casey Connor
2017-04-28 06:07:27 UTC (over 7 years ago)

high bit depth tiff issues

...and a final follow-up, just so people don't need to spend any time on this: changing the range with g'mic makes the files work properly in GIMP:

gmic 16bit_input.tif -/ 65535 -o 32bit_float_output.tif

(that scales the output to the [0,1] range.)

So that seems like the logical way to handle this, unless gimp wanted to handle large ranges automatically or something. (Apparently the CCE edition is already doing that to some extent.)

-c

Michael Natterer
2017-04-28 07:55:06 UTC (over 7 years ago)

high bit depth tiff issues

On Thu, 2017-04-27 at 23:07 -0700, Casey Connor wrote:

...and a final follow-up, just so people don't need to spend any time on 
this: changing the range with g'mic makes the files work properly in GIMP:

gmic 16bit_input.tif -/ 65535 -o 32bit_float_output.tif

(that scales the output to the [0,1] range.)

So that seems like the logical way to handle this, unless gimp wanted to 
handle large ranges automatically or something. (Apparently the CCE  edition is already doing that to some extent.)

Hi Casey,

thanks for investigating this issue. GIMP should load all these files just fine. I think support for 16/32 bit float TIFF was added without checking what range the values would have.

GIMP completely ignores TIFFTAG_{MAX,MIN}SAMPLEVALUE, and according to the spec they should default to

2**(BitsPerSample) - 1

which is just the scaling factor of 65535 you encountered.

However not for 32 bit files, but judging from your command line above I assume you meant 16 bit, or both gmic and gimp are broken, who knows :)

Can you please file a bug and attach the sample files?

The fix should be trivial, but I need some files to test.

Regards, Mitch

Casey Connor
2017-04-28 16:49:44 UTC (over 7 years ago)

high bit depth tiff issues

However not for 32 bit files, but judging from your command line above I assume you meant 16 bit, or both gmic and gimp are broken, who knows :)

Yeah, my g'mic example had a semantic mistake, sorry: it should have read something like:

gmic 32bit_float_input_with_range_to_65535.tif -/ 65535 -o 32bit_float_output.tif

...meaning, GIMP opens the 16bit integer stuff fine, it's the float format with an unexpected range that gives it trouble. There is a normalize operator ("-n 0,1") for g'mic, but as the g'mic developer points out, that could mess with the dynamic range, so using the divisor (-/) you can scale it appropriately. (E.g. -/ 255 if the original ranged over an 8bit scale.)

Can you please file a bug and attach the sample files?

Will do! Thanks!

-c