Colored patches regression in Verdandi

258 views
Skip to first unread message

Kevin Mehall

unread,
Jul 12, 2024, 9:54:25 PM7/12/24
to hugin and other free panoramic software

I'm occasionally seeing bad results from Verdandi in which parts of the panorama are discolored:

This looks similar to an issue previously reported and fixed in 2019: https://groups.google.com/g/hugin-ptx/c/mpnWNfJZ4b8/m/LMFVNMdbBQAJ

In testing, I found that 2023.0.0 and mercurial tip are affected, while 2022.0.0 results are good.

Weirdly, it seems that the nona output is nondeterministic for the same images and PTO file. The nona output itself looks fine, and the artifacts are introduced by verdandi. The severity and coloring of these artifacts varies between different sets of remapped images from running nona multiple times, but does not seem to change between different runs of verdandi on the same remapped TIFs.

There are only a few commits touching verdandi between 2022.0.0 and 2023.0.0, but 8556:17d25b5ae116 stands out. It re-adds a call to Multigrid that had been commented out with the note "this results in artefacts, maybe there is still a small error in other lines" in a 2019 change that I think was the bugfix from the thread linked above.  I tested commenting out that line again and the results look better.

I don't understand the algorithm enough to know how this helps, what other problem it might be working around, or what the proper fix would be, but I'm hoping someone can take another look at it.

Here are two sets of remapped images that exhibit the problem:
https://test-bucket.stscn.net/pano/verdandi-color-bug/1_remapped.zip
https://test-bucket.stscn.net/pano/verdandi-color-bug/2_remapped.zip

Run verdandi --wrap --seam=blend --compression=LZW -o out.tif -- part*.tif.

Let me know if I can help with more details, testing, or anything else.


Thanks,

Kevin

Kevin Mehall

unread,
Jul 12, 2024, 9:57:47 PM7/12/24
to hugin and other free panoramic software
Image was removed from the post, trying again:
image.png

T. Modes

unread,
Aug 1, 2024, 9:29:48 AM8/1/24
to hugin and other free panoramic software
Hi Kevin,

I had no time in the last weeks. Will look into it.
But such big images makes it not easy to debug it.

Thomas

T. Modes

unread,
Aug 3, 2024, 3:46:39 AM8/3/24
to hugin and other free panoramic software
Hi Kevin,

should be fixed now in repository. At least your 2 panorama blend now without discolored patches again.

Thomas

Kevin Mehall

unread,
Aug 9, 2024, 9:06:14 PM8/9/24
to hugin and other free panoramic software
Thanks! This indeed fixes it for the two I sent, but another panorama from the same drone is still affected and made slightly worse by this change:


2023.0.0:
case3-2023.png

hg tip (8715:e73862b75341):
case3-hg.png

The workaround patch removing the second `Multigrid` call does help, though:
case3-workaround.png

-- Kevin

T. Modes

unread,
Aug 10, 2024, 12:29:23 PM8/10/24
to hugin and other free panoramic software
Hi Kevin

kevin....@gmail.com schrieb am Samstag, 10. August 2024 um 03:06:14 UTC+2:
Thanks! This indeed fixes it for the two I sent, but another panorama from the same drone is still affected and made slightly worse by this change:

what have you for workflow/camera that that happens so often ;-) Very strange. In my panos this did not happen.

I would prefer small reproduction cases. Verdandi blend always 2 images at one time. So no need for the full set. Normally 2 files should be sufficient to reproduce the issue (So blend image 1 and 2, save the results. Then blend this image with the next one until the artefact appears.). So instead of downloading each time nearly 1 GB, maybe less than 100 MB would be sufficient. (The same would also speed up the uploading.)

Removing the second multigrid call would only hide/mask/decrease the issue, but about long or short another case would appear with similar artefacts.
I tried to fix the remaining issue in changeset b11fef488e70.

Thomas

Kevin Mehall

unread,
Aug 14, 2024, 1:44:53 PM8/14/24
to hugin and other free panoramic software
Thanks! Confirmed it works on all 3 cases where I've seen this.

> what have you for workflow/camera that that happens so often ;-) Very strange. In my panos this did not happen.

All of these are from a DJI Mavic 3 drone. We've processed dozens of panos from this drone and only seen artifacts in a few. Lots more panoramas from other drone models with no problems. I'm assuming it was something with the specific geometry of the photos' orientation and overlap, which is highly repeatable using the drone gimbal but still varies between panoramas a tiny bit to make it somewhat rare.

> I would prefer small reproduction cases. Verdandi blend always 2 images at one time. So no need for the full set.

Good to know. If issues come up again, I'll minimize the cases for you.

> Removing the second multigrid call would only hide/mask/decrease the issue, but about long or short another case would appear with similar artefacts.

Yeah, I assumed it was more of a temporary workaround than a proper fix based on your comment in the 2022.0 version of the code. Glad to have a better fix now.

Thanks again,
Kevin

Cristian Marchi

unread,
Oct 19, 2024, 6:01:06 AM10/19/24
to hugin and other free panoramic software

I'm writing on this thread because I'm seeing, maybe, the same problem. I'm using Hugin compiled from hg repository. When using Verdandi with "blend" seam I'm getting results like this in many panorama:
Schermata del 2024-10-19 11-53-01.pngSchermata del 2024-10-19 11-52-22.png

If I use "hard" seam the output panorama is generally fine.
I've tried to change dimensions of the output panorama, or move images in the "Photos" tab: the colored patches are always there with small changes in color or position.

T. Modes

unread,
Oct 20, 2024, 3:40:40 AM10/20/24
to hugin and other free panoramic software
cri....@gmail.com schrieb am Samstag, 19. Oktober 2024 um 12:01:06 UTC+2:

I'm writing on this thread because I'm seeing, maybe, the same problem. I'm using Hugin compiled from hg repository. When using Verdandi with "blend" seam I'm getting results like this in many panorama:

As I have already written, I don't see the issue in my panoramas. And I hoped the latest patch fixes some of the remaining issues - which was the case for Kevins panos.
But looking alone at the results does not help further. So without a reproducible example I can't do anything. Ideally a pto file and 2-3 images, if you can reproduce it with this smaller set.

Thomas

Cristian Marchi

unread,
Oct 20, 2024, 7:43:15 AM10/20/24
to hugin and other free panoramic software
Can you please test with the pto and a couple of images in this zip?

I get black/white patch in the final panorama for the top image both in Ubuntu with Hugin compiled from hg and in Hugin 2024 beta1 under win11

Thanks

T. Modes

unread,
Oct 21, 2024, 1:11:10 PM10/21/24
to hugin and other free panoramic software
cri....@gmail.com schrieb am Sonntag, 20. Oktober 2024 um 13:43:15 UTC+2:
Can you please test with the pto and a couple of images in this zip?

I get black/white patch in the final panorama for the top image both in Ubuntu with Hugin compiled from hg and in Hugin 2024 beta1 under win11

I can reproduce the issue. Thanks for providing a small/minimal test case.
It should now be fixed in repository.

Thomas

Cristian Marchi

unread,
Oct 23, 2024, 8:02:03 AM10/23/24
to hugin and other free panoramic software
Thanks Thomas, tested on a couple of pano and working fine!

Kevin Mehall

unread,
Jun 24, 2025, 2:57:26 PMJun 24
to hugin and other free panoramic software
I encountered another instance of this still happening with latest hg tip 8819:280e83b57064.

Image

Minimal set of remapped images can be found here: http://test-bucket.stscn.net/pano/2025-06-24.zip

The green color appears when blending part0027 into a partially-merged panorama:

verdandi --wrap --seam=blend --compression=LZW partial.tif part0027.tif -o partial+27.tif

Blending images 26 and 27 alone also produces artifacts in the same area, but of different colors (black and orange):

verdandi --wrap --seam=blend --compression=LZW part0026.tif part0027.tif -o out-26-27.tif

It may be be related to the fact that  part0026 and part0027 are nearly redundant images. These are from a DJI M4E with significant vignetting, but Hugin normally does a good job ignoring the image corners.

Thanks,
Kevin

T. Modes

unread,
Jul 19, 2025, 9:52:12 AMJul 19
to hugin and other free panoramic software
Hi Kevin,

kevin....@gmail.com schrieb am Dienstag, 24. Juni 2025 um 20:57:26 UTC+2:
I encountered another instance of this still happening with latest hg tip 8819:280e83b57064.

Should be fixed in repository now. Both examples should be blended now okay. Hopefully it does not break other one.

Thomas 
Reply all
Reply to author
Forward
0 new messages