[ptx] error compiling hugin on x86_64 (fedora fc4)

Hal V. Engel hvengel at astound.net
Sat Feb 11 22:45:47 GMT 2006


On Saturday 11 February 2006 01:57 pm, Pablo d'Angelo wrote:
snip
> >
> > Error during stitching
> >
> >    Precondition violation!
> >    RemappingPanoImage::remapimage(): image sizes not consistent
> >    (../../src/include/PT/RemappedPanoImage.h:398)
>
> I'll take a look at that.
>
> I have modified some code and added additional size checks. This error
> might happen if the image size in the .pto file differs from the actual
> image size.
>

The original images were processed by UFRAW using VNG interpolation and I have 
since reprocessed these images using a newer version of UFRAW that supports 
AHD interpolation which might make them a slightly different size.  I looked 
at the pto file and the image size was 2012x3038 and newer versions of UFRAW 
are creating images that are 2014x3039 (both AHD and VNG) from the same RAW 
files.  I hand modified the pto file and I am stitching now with both CPU 
cores at 100%.

I had just stitched this same set of (AHD) images with the same pto file with 
Hugin 0.5 so this appears to be a result of the added error checks.  Perhaps 
this should be checked when the pto file is opened to make sure that the 
image sizes in the pto file match the images rather than at stitch time.  

Just finished stitching.  Hugin 0.5 would take about 11:40 minutes to stitch 
this and 0.6 took about 6:15 minutes using two CPU cores on the same 
hardware.   I should add that the latest versions of enblend (2.4 and 2.5) 
are way faster than previous versions.  Enblend 2.3 would take longer to 
blend this stitch than it took a single threaded nona to do the stitch.   The 
new enblend will blend this in about 1:45 minutes so the over all performance 
impact of the Hugin/enblend updates on a two CPU machine are to reduce 
stitch/blend time by about 70%.  I like it.  It should be even more dramatic 
on a 4 or 8 way machine.

Hal


More information about the ptx mailing list