Quantcast

high bit depth tiff issues

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

high bit depth tiff issues

Casey Connor
Hello -- I've been posting around trying to help get to the bottom of
various problems with tiff formats in higher bit depths -- perhaps you
saw my posts on gimp-user-list. I'm told that the .tif format is a bit
of a mess, but in case it's useful, I thought I'd post here (apologies
for the pseudo-cross-posting -- not sure where to go for this -- if I
should stop here and just file a bug report, let me know):

Here is a .zip file of various .tif files, most of which don't open
properly for me in GIMP (linux or windows):
http://caseyconnor.org/pub/image/smallexample2.zip 
<http://caseyconnor.org/pub/image/smallexample2.zip>

Some of these can be "recovered" by opening them (they open as
all-white) and then changing to an integer precision. Some can't. All of
them open properly in Luminance HDR, which seems bullet-proof for
high-bit-depth tifs. Everything else (gwenview, hugin, darktable, etc)
seems to have various issues with this or that format.

Files in the zip:

original.tif -- 16bit integer -- original image exported from Canon
Digital Photo Professional
original2.tif -- a copy of original.tif
aligned000?.tif - the result of "align_image_stack --gpu -C -a aligned
original*.tif
aligned_then_gmic.tif -- the result of gmic -median_files aligned\*.tif
-o aligned_then_gmic.tif
hugin_output.tif -- the result from hugin of running a simple
rectilinear stitch on aligned_then_gmic.tif
aligned_then_gmic.pto -- the pto used with hugin to do that
other_example.tif -- another strangely-behaving .tif file in case it's
useful

I can come up with workarounds on this stuff, I was just hoping that
these various tools could possibly be brought in line with each other --
seems like they should be friends. :-)

My test setup: Kubuntu 16.10, otto-kesselgulasch gimp 2944dbd688. (Also
happens with pixls.us gimps. Happens on linux and windows.) G'MIC 2.0.0.
pre-release #013117. align_image_stack version 2016.3.0.85fedd083c55

Thanks!

-c


_______________________________________________
gimp-developer-list mailing list
List address:    [hidden email]
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: high bit depth tiff issues

Casey Connor
Just a follow-up in case anyone is interested: apparently one issue is
that G'MIC outputs 32bit float tiffs in the range 0-65536, which might
explain why they are all-white (and sometimes there are some black
pixels). (This according to folks on the g'mic forum. As to why
sometimes changing to integer precision fixes it and sometimes it
doesn't, I have no guess. But I thought I'd mention this in case it
helps further the cause.

The pixls.us CCE AppImages seem to open more of the example files
without apparent issue. Not sure if there is code there that could be
leveraged?

-c


_______________________________________________
gimp-developer-list mailing list
List address:    [hidden email]
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: high bit depth tiff issues

Casey Connor
In reply to this post by Casey Connor
...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


_______________________________________________
gimp-developer-list mailing list
List address:    [hidden email]
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: high bit depth tiff issues

Michael Natterer
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

_______________________________________________
gimp-developer-list mailing list
List address:    [hidden email]
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: high bit depth tiff issues

Casey Connor
> 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

_______________________________________________
gimp-developer-list mailing list
List address:    [hidden email]
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list
Loading...