hdrmerge fails due to differing image sizes

[zachmckracken]

I get this message (and another telling me to post it here) while stitching an HDR panorama:

hugin_hdrmerge -m khan -i 4 -s 30.000000 -o _MG_7820-_MG_7855_stack_hdr_0000.exr _MG_7820-_MG_7855_hdr_0000.exr _MG_7820-_MG_7855_hdr_0001.exr _MG_7820-_MG_7855_hdr_0002.exr
caught exception: Input images must have the same dimensions
make: *** [_MG_7820-_MG_7855_stack_hdr_0000.exr] aborted

There are two stacks with 3 images each. I get the individual TIFFs, I can build 3 panoramas for the different exposures, but merging the first stack fails because the first of the three TIFFs from the first stack (and in consequence the EXRs) is just slightly wider than the others, for no apparent reason.
I tried to make a series of these panoramas in batch mode, and some failed this way, others worked. I can't seem to find out what makes the difference.

I could post the project, but the files have 13 MB combined, so I'd better ask before uploading.
I'm on Linux, using version 2010.0.0-12.6

[amidee (amidee)]

Same here. I have a perfectly aligned, 20 image (10 per exposure) panorama. All images perfectly aligned, 2,9 maximum and 0,8 mean error.
Lower exposure is slightly larger (with black fill, too) on the right. Everything is perfectly still from one exposure to the other except for a single object in top right corner which moves inexplicably, despite me anchoring it perfectly with 30 points manually.
This is rather annoying. Error is same as above when using khan;
Using avarage slow I get this error:

Error: Input images need to be of the same size
ContractViolation:
Precondition violation!
BasicImage::upperLeft(): image must have non-zero size.
(../src/foreign/vigra/vigra/basicimage.hxx:877)

caught exception:
Precondition violation!
BasicImage::upperLeft(): image must have non-zero size.
(../src/foreign/vigra/vigra/basicimage.hxx:877)

gnumake: *** [hdr2_stack_hdr_0004.exr] Abort trap

Using simple average, I finally get a final image. And this is the amazing result:

http://img820.imageshack.us/img820/5790/schermata20100907a23344.png

Black parts are BLACK like in black 100%. the rest is a poorly made and ghosted hdr.

I'm on Mac, version is 2010.1.0.38ed0587798b. Yea I know it's a nightly but I don't think that's the problem.

M.

[rew (r-e-wolff)]

Zach, Amidee, PLEASE upload the images somewhere so that we can try to reproduce it on a developer's machine.

If all else fails, Email me the images. You might have to split things because your mail system doesn't handle large files. But I can handle up to 100Mb just fine.

[rew (r-e-wolff)]

see also bug #678936

[tmodes (tmodes)]

This bug has nothing to do with enblend. The bug is in hdr_merge. Nobody has mentioned enblend. So setting to invalid in enblend.

[tmodes (tmodes)]

The bug seems to be in hdr_merge.
Does the exr format support the offset tag?
If not, this could explain the observed behaviour.
If yes, then we need to check if the tag is correctly read and written.

Could you try to stitch the hdr images with non-cropped images (on Stitcher tab, goto Nona options and deselect "use cropped images" or similiar)?

[atenrok (atenrok)]

I've got one of these as well. http://img715.imageshack.us/img715/1925/windowshot2010121323222.png
see what was supposed to come out and what did.

[Yuv (yuv)]

can any of the reporter please upload a PTO file (without the images) causing the error? Once you upload, change also the status of the bug to New again, to make us aware of the change.

[Launchpad Janitor (janitor)]

[Expired for Hugin because there has been no activity for 60 days.]

[Sami Boukortt (sboukortt)]

I encounter this problem with the attached .pto file with Nona set to the default of “Save cropped images” and the HDR merge mode set to “Average slow” or “De-ghosting (Khan)”. Unchecking the Nona cropping option makes “Average slow” and “De-ghosting (Khan)” work properly, and “Average” always works.

[tmodes (tmodes)]

Trying to fix in repository. Avg_slow and Khan should now also work with cropped images.