Verdandi segfault with 2022.0.0

[Kevin Mehall]

After upgrading Hugin from 2021.0.0 to 2022.0.0, I am seeing verdandi segfault when stitching 360x180° drone panoramas. One of the affected image sets is linked below. It stitches correctly when downgrading to 2021.0.0, and reproducibly fails with 2022.0.0 and latest from hg. I am testing on Linux (NixOS), and both Hugin versions are built against the same version of vigra (git snapshot at 093d57d15) and other dependencies.

Steps to reproduce:

```
curl -O https://test-bucket.stscn.net/pano/hugin-crash/1/project.pto
curl -O https://test-bucket.stscn.net/pano/hugin-crash/1/photos.zip
unzip photos.zip
nona -v -z LZW -r ldr -m TIFF_m -o part project.pto
verdandi --wrap --seam=blend --compression=LZW -o equirectangular.tif -- part0000.tif part0001.tif part0002.tif part0003.tif part0004.tif part0005.tif part0006.tif part0007.tif part0008.tif part0009.tif part0010.tif part0011.tif part0012.tif part0013.tif part0014.tif part0015.tif part0016.tif part0017.tif part0018.tif part0019.tif part0020.tif part0021.tif part0022.tif part0023.tif part0024.tif part0025.tif part0026.tif part0027.tif part0028.tif part0029.tif part0030.tif part0031.tif part0032.tif part0033.tif part0034.tif
```

Results in:

```
Loaded part0000.tif
Loaded part0001.tif
Loaded part0002.tif
Loaded part0003.tif
Loaded part0004.tif
Segmentation fault (core dumped)
```

Stack trace of the crash on hg commit 8608:d0a5f7c6b7ef:

```
Thread 1 "verdandi" received signal SIGSEGV, Segmentation fault.
0x0000000000435364 in vigra::fastSeededRegionGrowing<vigra::ConstBasicImageIterator<unsigned char, unsigned char**>, vigra::StandardConstValueAccessor<unsigned char>, vigra::BasicImageIterator<unsigned char, unsigned char**>, vigra::StandardValueAccessor<unsigned char>, vigra::ArrayOfRegionStatistics<vigra::SeedRgDirectValueFunctor<unsigned char>, int>, vigra::FourNeighborhood::NeighborCode> (srcul=...,
    srclr=..., destul=..., stats=..., srgType=vigra::CompleteGrow, max_cost=255, bucket_count=256, ad=..., as=...)
    at /nix/store/3qbk1bgvp7zl5amrcpk2s3a3r3sd7fz9-vigra-unstable-2022-01-11/include/vigra/seededregiongrowing.hxx:856
856                                std::max((std::ptrdiff_t)stats[label].cost(as(isx, c.diff())), cost);
(gdb) bt
#0  0x0000000000435364 in vigra::fastSeededRegionGrowing<vigra::ConstBasicImageIterator<unsigned char, unsigned char**>, vigra::StandardConstValueAccessor<unsigned char>, vigra::BasicImageIterator<unsigned char, unsigned char**>, vigra::StandardValueAccessor<unsigned char>, vigra::ArrayOfRegionStatistics<vigra::SeedRgDirectValueFunctor<unsigned char>, int>, vigra::FourNeighborhood::NeighborCode> (srcul=...,
    srclr=..., destul=..., stats=..., srgType=vigra::CompleteGrow, max_cost=255, bucket_count=256, ad=..., as=...)
    at /nix/store/3qbk1bgvp7zl5amrcpk2s3a3r3sd7fz9-vigra-unstable-2022-01-11/include/vigra/seededregiongrowing.hxx:856
#1  0x00000000005335ac in vigra::fastSeededRegionGrowing<vigra::ConstBasicImageIterator<unsigned char, unsigned char**>, vigra::StandardConstValueAccessor<unsigned char>, vigra::BasicImageIterator<unsigned char, unsigned char**>, vigra::StandardValueAccessor<unsigned char>, vigra::ArrayOfRegionStatistics<vigra::SeedRgDirectValueFunctor<unsigned char>, int>, vigra::FourNeighborhood::NeighborCode> (
    bucket_count=256, max_cost=255, n=..., srgType=vigra::CompleteGrow, stats=..., dest={...}, src=...)
    at /nix/store/3qbk1bgvp7zl5amrcpk2s3a3r3sd7fz9-vigra-unstable-2022-01-11/include/vigra/seededregiongrowing.hxx:921
#2  vigra_ext::MergeImages<vigra::BasicImage<vigra::RGBValue<unsigned char, 0u, 1u, 2u>, std::allocator<vigra::RGBValue<unsigned char, 0u, 1u, 2u> > >, vigra::BasicImage<unsigned char, std::allocator<unsigned char> > > (offset=..., hardSeam=false, wrap=true, mask2=..., image2=..., mask1=..., image1=...) at /home/kevin/hugin/hugin-hg/src/hugin_base/vigra_ext/StitchWatershed.h:244
#3  LoadAndMergeImages<vigra::BasicImage<vigra::RGBValue<unsigned char, 0u, 1u, 2u>, std::allocator<vigra::RGBValue<unsigned char, 0u, 1u, 2u> > > > (imageInfos=std::vector of length 35, capacity 35 = {...},
    filename="equirectangular.tif", compression="LZW", wrap=wrap@entry=true, hardSeam=hardSeam@entry=false, useBigTiff=useBigTiff@entry=false) at /home/kevin/hugin/hugin-hg/src/tools/verdandi.cpp:167
#4  0x000000000041a889 in main (argc=<optimized out>, argv=<optimized out>) at /home/kevin/hugin/hugin-hg/src/tools/verdandi.cpp:497
```

hg bisect says

```
The first bad revision is:
changeset:   8395:12c7cb72f052
parent:      8392:01623862382e
user:        tmodes
date:        Sat Jan 15 18:41:16 2022 +0100
summary:     verdandi: Blend images when they are only touching and not overlapping
```

Let me know if there's anything else I can do to help troubleshoot, and thanks for Hugin!

-- Kevin

[T. Modes]

kevin....@gmail.com schrieb am Dienstag, 23. Mai 2023 um 22:08:39 UTC+2:

After upgrading Hugin from 2021.0.0 to 2022.0.0, I am seeing verdandi segfault when stitching 360x180° drone panoramas. One of the affected image sets is linked below. It stitches correctly when downgrading to 2021.0.0, and reproducibly fails with 2022.0.0 and latest from hg.

Thanks for the detailed bug report and reproducer. It should be now fixed in repository.

 

unzip photos.zip
nona -v -z LZW -r ldr -m TIFF_m -o part project.pto
verdandi --wrap --seam=blend --compression=LZW -o equirectangular.tif -- part0000.tif part0001.tif part0002.tif part0003.tif part0004.tif part0005.tif part0006.tif part0007.tif part0008.tif part0009.tif part0010.tif part0011.tif part0012.tif part0013.tif part0014.tif part0015.tif part0016.tif part0017.tif part0018.tif part0019.tif part0020.tif part0021.tif part0022.tif part0023.tif part0024.tif part0025.tif part0026.tif part0027.tif part0028.tif part0029.tif part0030.tif part0031.tif part0032.tif part0033.tif part0034.tif
```

The main issue here is that you are supplying the images in a random order (already in the pto file).

But verdandi's blend algorithm works best when working on neighbouring images starting from an anchor. But when using a random order greater gradients can occurs.

Imaging 3 images in a row: from left to right image 1/image 2/image 3. The best result is achieved when first blend image 1 and image 2 and then blending the result with image 3.

Now imaging a random order e.g. first image 1 and image 3, both images will be only copied into the results because they don't overlap (and don't touch). When now blending image 2 in between it has to change to match to image 1 *and* image 3. This creates greater restriction on the blending and therefore can create a bigger gradient.

When stitching from the GUI or hugin_executor they take care of this and supply the images in a sensible order to verdandi.

By using the command line utilities in combination with the random order in the pto file you are bypassing this restriction.

It would also help when you would generate the pto file with ordered images instead of the random order. Then you would also have a sensible order for blending.

Thomas

[Kevin Mehall]

Thanks for the quick fix! It works great.

And thanks also for the advice on the image ordering. I hadn't noticed that pto_gen is no longer sorting the input images, and so I've updated my script to sort them itself. It actually simplifies things that way for scripting, because the input image ordering matches the image numbers passed to `pto_var`.

-- Kevin

[T. Modes]

kevin....@gmail.com schrieb am Mittwoch, 31. Mai 2023 um 02:13:56 UTC+2:

And thanks also for the advice on the image ordering. I hadn't noticed that pto_gen is no longer sorting the input images, and so I've updated my script to sort them itself.

 there should be no need to sort them by itself. Simply add the switch --sort to the pto_gen command and let pto_gen sort the images.

There are use cases where a special order is important. So I made the sorting optional. (Because otherwise it is not possible to enforce an order.)

Sorry for the noise.

Thomas