[hugin-ptx] Re: Verdandi segfault with 2022.0.0

2023-05-31 Thread 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

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/4949395a-3606-4e45-a076-da756334b867n%40googlegroups.com.

[hugin-ptx] Re: Verdandi segfault with 2022.0.0

2023-05-30 Thread 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
On Wednesday, May 24, 2023 at 11:40:13 AM UTC-6 T. Modes wrote:

> 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 -- 
> part.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
>
>

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/c9d9a682-4901-482a-bff9-2341a9cdd7fan%40googlegroups.com.

[hugin-ptx] Re: Verdandi segfault with 2022.0.0

2023-05-24 Thread 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 -- 
part.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

-- 
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
--- 
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/104a8e48-3966-4406-afdb-7d8e461353cbn%40googlegroups.com.