hugin generating corrupted EXR.

[esby]

I have been toying around since a while with Hugin svn build, it works more or less, still I have encountered weird assembling from hugin when creating panoramas in HDR, using the EXR option.

The main problem is that the EXR created get a black band in the middle of it, resulting in corrupted panorama like this one:
http://esby.free.fr/perso/images/A.jpg

A 7zip archive containing all the images to make the panorama I have been trying to assemble is here:
http://esby.free.fr/perso/images/report.7z

24 jpeg files, with low quality jpeg showing the problem here...)
Constituting a 360° panorama.

I don't know if it is really a bug or not, but I was not able to fix by toying with the settings.
I used low resolution (including jpeg) to save time and bandwidth while trying to report the possible bug.

The version of Hugin I used was 0.7.0.3051 (windows).

esby

[esby (esby)]

The file A.jpg was added: None

[esby (esby)]

Logged In: YES
user_id=879770
Originator: YES

The attached A.jpg is the bugged resulting panorama after basic tone mapping.

[Bruno Postle (brunopostle)]

Logged In: YES
user_id=35360
Originator: NO

Has this been blended with enblend? as I'm not sure if hugin uses enblend when you pick EXR output.

I see this with a current snapshot using nona JPEG, PNG and TIFF output but not with TIFF_m, hence you won't see this bug if you are blending with enblend. Basically the internal seaming nona uses when creating a single output file appears to be broken.

How to reproduce: save a hugin project, open it up and change n"TIFF_m c:NONE" to n"TIFF c:NONE", then try and stitch it with `nona -o junk project.pto`.

[esby (esby)]

Logged In: YES
user_id=879770
Originator: YES

I did some further testing:

If I remove all images except P1020527.*, P1020528.* and P1020529.* (the ones that appears black in the profile)
(I am using TIF files in my project, the sample use JPEG files..)
Adjust the field of view and save the EXR.
The file created is just 'black' and unmappable by mapping application (picturenaut and qtpsfgui fails at mapping the file here.)

I don't know if what brunopostle said is related or not, I have noticed non mappable EXR a few times, usually resulting from 3 images with different exposure. On other times, all went fine, the EXR created in similar conditions could be mapped normally. So I am a bit puzzled here.

esby

[Bruno Postle (brunopostle)]

Logged In: YES
user_id=35360
Originator: NO

I'm marking this as a duplicate of bug 1850361 as the description is the same.

The other bug I found needs to be a separate bug report.

[sf-robot (sf-robot-users)]

Logged In: YES
user_id=1312539
Originator: NO

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

[atenrok (atenrok)]

this is what I'm getting when trying to generate HDR panorama out of 6 .tiff images (see screenshot). http://img718.imageshack.us/img718/4981/screenshot2010121313240.png

From left to right HDR tiff, HDR exr and blended tif. Note the black stripe on the bottom of hdr images and complete LDR image. I have other examples where an image comes out with ~1/6 black rectangle in the upper-right corner, and another HDR image which comes totally black with a white bar across. Worth noting, that out of set of 6 panoramas I'm working on right now, 3 HDR files came out as expected, the other three are corrupt.

Please let me know how else I can help with data on bug.

[atenrok (atenrok)]

sorry, seems like image was cropped at imageshak. See here http://img190.imageshack.us/img190/4981/screenshot2010121313240.png

[Yuv (yuv)]

Hi Oleksandr

thank you for the information. This bug report was closed long ago as a duplicate of bug 678694 (when it was still sf-1850361).

You can add to the information on bug 678694. Please report there what versions of Hugin and Enblend are on your system.

Thank you for the report
Yuv