GMIC images render all-white from hugin?

[clepsydrae]

I'm trying to make a pano from images that I ran through gmic -median_files, but the resulting pano is always all white.

Here is an example.pto if anyone has a second to check it -- the .zip is about 591 MB -- I can make a smaller one if that would be more useful: http://caseyconnor.org/pub/image/huginexample.zip

That uses just two images and stitches them together; the result (in the .zip file) is output_from_hugin.tif, which opens as all-white for me.

Gimp 2.9.5 in linux has some trouble opening high-precision images, but I can usually work around it. In any case, these results seem truly white: they open as white in linux gimp, windows gimp, photoshop (CS2), etc., so I don't think it's just a viewing issue?

Is there some file format issue happening? Or have I messed up my .pto somehow?

I can see the images fine in the fast preview window -- everything looks great. There is no exposure adjustment happening (that I'm aware of). I'm doing an "exposure corrected, low dynamic range" pano output. File format choice for output doesn't seem to matter. Remapper is nona (with cropping enabled, but i don't think it made a difference turning it off?), blender is default enblend.

GMIC outputs 32bit float images (examples included in .zip), so I assume that's related? If I do similar panos in hugin with 16bit-integer tiffs (before any GMIC work) it all works fine.

I tried to read everything applicable and search around -- sorry if this is an old question.

Thanks!
-c

-------------------------------

Kubuntu 16.10
Gimp 2.9.5 pixls.us AppImage commit 224722
GMIC Version 2.0.0 (pre-release #013117)

Operating System: Linux 4.8.0-46-generic x86_64
Architecture: 64 bit
Free memory: 3711400 kiB

Hugin
Version: 2016.3.0.044ebb48818c
Path to resources: /usr/share/hugin/xrc/
Path to data: /usr/share/hugin/data/
Hugins camera and lens database: /home/casey/.hugindata/camlens.db
Multi-threading using C++11 std::thread and OpenMP

Libraries
wxWidgets: wxWidgets 3.0.2
wxWidgets Library (wxGTK port)
Version 3.0.2 (Unicode: wchar_t, debug level: 1),
Runtime version of toolkit used is 2.24.
Compile-time GTK+ version is 2.24.30.

libpano13: 2.9.19
Boost: 1.61.0
Exiv2: 0.25
SQLite3: 3.14.1
Vigra: 1.11.0
LittleCMS2: 2.7

[Gnome Nomad]

Hmm - do your output images work in HDR tools like Luminance HDR?

--
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
---
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/4766cde5-15b1-47c2-a93f-2cadb64c4fc2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

David W. Jones
gnome...@gmail.com
authenticity, honesty, community
http://dancingtreefrog.com

[clepsydrae]

Why, yes, they do! I've never used it before, but I just ran it, opened the result image ("Open HDR image"), and it shows right up.

Does that point towards a viewing issue, then? Or something being written wrong out of hugin?

Thanks!
-c

[David W. Jones]

I just tried to read your output_from_TIF using the image viewer, it
reported being unable to read RGB data. That image viewer handles my
16-bit-per-channel TIFF images without problems, so I suspect the viewer
doesn't like 32-bit float. Same result trying to read your source TIFFs,
too. So I suspect a problem with the viewer, possibly in a library.

I opened it in GIMP 2.8.18 and it reported "Unsupported layout, no RGBA
loader". I think that's because GIMP doesn't support 16-bits per
channel, let alone 32-bit floating point.

Nothing appeared in the app window when I tried opening it in
RawTherapee. RT supports 16-bit-per-channel with no problems. Again, I
suspect the 32-bit float.

I can't explain Adobe Photoshop's problem unless it's due to using a
12-year-old version. Maybe it didn't support 32-bit floating point back
then. CS2 dates back to 2005, according to Wikipedia, and the current
version is CC 2017.0.1.

You might consider using Luminance HDR to convert from 32-bit-floating
point to JPG. Here's a link to what I got from Luminance:

http://clanjones.org/graphs/example-luminance-conversion.jpg (30.2MB)

Let me know when you grab it. I'll delete it afterwards.

For what it's worth, Luminance HDR reported an unsupported sample format
when I tried to open one of your source images, so I don't know if that
means there's something weird about your source images or what.

Really nice shot, though - I like the feathery water contrasted with the
sharp detail of the rock face. The Luminance operator I used (Reinhard
'05) also boosted color saturation, bringing out the green growing on
the rocks.

--
David W. Jones
gnome...@gmail.com

wandering the landscape of god
http://dancingtreefrog.com

[clepsydrae]

I just tried to read your output_from_TIF using the image viewer, it
reported being unable to read RGB data. That image viewer handles my
16-bit-per-channel TIFF images without problems, so I suspect the viewer
doesn't like 32-bit float. Same result trying to read your source TIFFs,
too. So I suspect a problem with the viewer, possibly in a library.

Yeah... I guess I should take it up with the GIMP crew. G'MIC authors mention how odd it is that 32bit float is not well supported in viewers and editors, given that the standard is apparently long-established. It just seemed odd that I can open the 32bit-float source images in GIMP, hugin can open the same source images, but the 32bit float written result from hugin doesn't work in GIMP (or anything else I can find except Luminance HDR). That made me wonder if Hugin was making a mistake.

I opened it in GIMP 2.8.18 and it reported "Unsupported layout, no RGBA
loader". I think that's because GIMP doesn't support 16-bits per
channel, let alone 32-bit floating point.

Yeah, GIMP 2.9.5 adds 32bit float support (and 64bit float in windows). Even so, 32bit float images from G'MIC don't work quite right: I have to open the file and then change precision to an integer format to see it properly (and IIRC I have to also remove the alpha channel to avoid issues.) So, there are bugs still. I brought it up a couple times on the GIMP mailing list without success (others could not reproduce) but I'll try again.

You might consider using Luminance HDR to convert from 32-bit-floating
point to JPG. Here's a link to what I got from Luminance:

That's kind, thanks -- I can actually just use G'MIC in 16-bit integer mode, so I make something that works. But I appreciate the assist. :-)

Really nice shot, though - I like the feathery water contrasted with the
sharp detail of the rock face.

Thanks! -- you should see it when the 57 other images that comprise that panorama are included. :-) Those were just two frames at random from the overall pano. :-)

[T. Modes]

Am Mittwoch, 26. April 2017 04:45:58 UTC+2 schrieb clepsydrae:

I'm trying to make a pano from images that I ran through gmic -median_files, but the resulting pano is always all white.

Here is an example.pto if anyone has a second to check it -- the .zip is about 591 MB -- I can make a smaller one if that would be more useful:

A smaller set would be easier for testing.

Thomas

[clepsydrae]

Here is a new set: http://caseyconnor.org/pub/image/smallexample2.zip

The output of hugin is "hugin_output.tif".

When creating these examples, it became clear that there are bugs everywhere surrounding high-bit-depth tiff's (meaning, not in hugin, but every viewer, editor, processor I used...) The only program that seems to open everything as expected is Luminance HDR.

Files in the zip:

original.tif -- the original image exported from Canon Digital Photo Professional
original2.tif -- a copy of original.tif used for processing
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 of running a simple rectilinear stitch on aligned_then_gmic.tif
aligned_then_gmic.pto -- the pto used to do that
other_example.tif -- another strangely-behaving .tif file in case it's useful (hugin can't open this one, maybe? But Luminance HDR can.)

...none of the processed .tif files open properly in GIMP, but some of them can be recovered by changing to an integer format. hugin_output.tif can not be reecovered (though again, Luminance HDR opens it fine, and so does hugin).

Thanks for any time you have to check it out. I'm on the gimp user list asking questions about this as well.

-c

[T. Modes]

Am Donnerstag, 27. April 2017 19:18:50 UTC+2 schrieb clepsydrae:

original.tif -- the original image exported from Canon Digital Photo Professional
original2.tif -- a copy of original.tif used for processing
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 of running a simple rectilinear stitch on aligned_then_gmic.tif
aligned_then_gmic.pto -- the pto used to do that
other_example.tif -- another strangely-behaving .tif file in case it's useful (hugin can't open this one, maybe? But Luminance HDR can.)

...none of the processed .tif files open properly in GIMP, but some of them can be recovered by changing to an integer format. hugin_output.tif can not be reecovered (though again, Luminance HDR opens it fine, and so does hugin).

I think the format GMIC write is at least unusual. It write float values, but does not adapt the range. The 16 bit integer format goes from 0..65536 for red, green and blue. GMIC write the float values also in this range, but normally the TIFF image are linear when using float (and cover therefore another range). That's the main reason of the problem.
Hugin writes the images in the same range as in the input (but is using another sub format, so this confuses some viewers more).

So I think you should use the integer format or ask GMIC to rescale the float values. So this is no bug in Hugin.

Thomas

[clepsydrae]

Thank you for looking at it! -- I'll pass this to the G'MIC developer. -c

[clepsydrae]

Just a follow-up, in case anyone finds the thread:

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

...will change the range to [0,1] and make the image work in GIMP, work better in hugin, etc.

( -/ 255 for 8bit images, of course. )

[David W. Jones]

On 04/26/2017 02:30 PM, clepsydrae wrote:

> I just tried to read your output_from_TIF using the image viewer, it
> reported being unable to read RGB data. That image viewer handles my
> 16-bit-per-channel TIFF images without problems, so I suspect the
> viewer
> doesn't like 32-bit float. Same result trying to read your source
> TIFFs,
> too. So I suspect a problem with the viewer, possibly in a library.
>
> Yeah... I guess I should take it up with the GIMP crew. G'MIC authors
> mention how odd it is that 32bit float is not well supported in viewers
> and editors, given that the standard is apparently long-established. It
> just seemed odd that I can open the 32bit-float source images in GIMP,
> hugin can open the same source images, but the 32bit float written
> result from hugin doesn't work in GIMP (or anything else I can find
> except Luminance HDR). That made me wonder if Hugin was making a mistake.

Sounds more likely the problem lies in GIMP. I'm not sure that floating
point is much use for images, I prefer 16-bit per channel for RGB
(48-bit color). I can see adding a 16-bit alpha channel. But whatever
people need.

> I opened it in GIMP 2.8.18 and it reported "Unsupported layout, no RGBA
> loader". I think that's because GIMP doesn't support 16-bits per
> channel, let alone 32-bit floating point.
>
> Yeah, GIMP 2.9.5 adds 32bit float support (and 64bit float in windows).
> Even so, 32bit float images from G'MIC don't work quite right: I have to
> open the file and then change precision to an integer format to see it
> properly (and IIRC I have to also remove the alpha channel to avoid
> issues.) So, there are bugs still. I brought it up a couple times on the
> GIMP mailing list without success (others could not reproduce) but I'll
> try again.

Ah. I think the best way see the original image in Luminance HDR is to
change the gamma to Linear. Works decently on my laptop display, but
that has an extended-range display. I wonder what a 32-bit/64-bit float
image would look like on an HDR display?

> You might consider using Luminance HDR to convert from 32-bit-floating
> point to JPG. Here's a link to what I got from Luminance:
>
> That's kind, thanks -- I can actually just use G'MIC in 16-bit integer
> mode, so I make something that works. But I appreciate the assist. :-)

Like I said, it's a nice image all by itself.

> Really nice shot, though - I like the feathery water contrasted with
> the
> sharp detail of the rock face.
>
> Thanks! -- you should see it when the 57 other images that comprise that
> panorama are included. :-) Those were just two frames at random from the
> overall pano. :-)

Looking forward to seeing a small version of the result. :)

[clepsydrae]

Oops, correction:

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

...in the above example "16bit_input.tif" is actually 32bit-float, in the range [0,65535]

To convert to 16bit integer:

gmic 32bit_float_range_65535.tif -o 16bit_integer_output.tif,ushort

-c