[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