Hugin 2022.0 Black blotches on final stitches

[Robert Mahar]

( OK, well 2022.0.0.a0962865f932 )

I often get black regions in final stitches.   For smaller projects, not often.   As I approach 80 - 200 images, a lot more often.   Usually just one or two tiles, retrying after "juggling the handle"  will often given a different black area.   A lot of "futzing" and maybe they all go away and I get a clean output.   I have read all the home remedy and animal sacrifice suggestions.   But how do I actually identify the issue, with the hope of fixing it?

The suggestion I have seen work is "re-arrange the images" - however with my recent projects that's not really a practical solutions.   Here is an example of the final stitch:

And here is the neighborhood of overlapping images:

Its as if image 52 just fell off the edge of the table.   The logs look unremarkable.   I get all of the intermediate images generated by nona including the one for 52.   This tends to happen for my chip photos, which have a regular right to left, top to bottom shooting pattern, so naturally, the overlap would be following that.   And as others have reported, just "messing" with the images "fixes" the problem.  Or not.   I've even gotten to the point of writing a "randomize image order" function to take a PTO and reassign the image numbers throughout.   And often this fixes the issue.  Or not.

-- Bob

[Greg 'groggy' Lehey]

On Saturday, 11 November 2023 at 22:08:34 -0800, Robert Mahar wrote:
> ( OK, well 2022.0.0.a0962865f932 )
>
> I often get black regions in final stitches. For smaller projects, not
> often.

"Me too". This seems to be happening more frequently. Until recently
I was using the 2018 version, then 2022, and with 2022 things became
worse.

I'm still investigating, and so far I don't have any further
information, but at least I wanted to say that you're not alone.
Hopefully I'll come up with more information.

Greg
--
Sent from my desktop computer.
Finger groo...@gmail.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed. If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA.php

[David W. Jones]

On November 12, 2023 5:10:35 PM HST, Greg 'groggy' Lehey <groo...@gmail.com> wrote:
> On Saturday, 11 November 2023 at 22:08:34 -0800, Robert Mahar wrote:
> > ( OK, well 2022.0.0.a0962865f932 )
> >
> > I often get black regions in final stitches. For smaller projects, not
> > often.
>
> "Me too". This seems to be happening more frequently. Until recently
> I was using the 2018 version, then 2022, and with 2022 things became
> worse.
>
> I'm still investigating, and so far I don't have any further
> information, but at least I wanted to say that you're not alone.
> Hopefully I'll come up with more information.
>
> Greg

I use 2022. I've rarely gotten it. It only seems to happen when I'm messing around with complex masks, or it turns out that alignment is really off.

--
David W. Jones
gnome...@gmail.com
exploring the landscape of god
http://dancingtreefrog.com

Sent from my Android device with F/LOSS K-9 Mail.

[Luís Henrique Camargo Quiroz]

   Hi!

   One idea: if you can, try cropping (by use of exclusion masks) and diminishing/changing  the superposition among adjacent images. At least where you saw problems.

   In a few days I'll be able to use Hugin again, I needed to put my panoramas on hold because of other activities. But it was really a while without such kind of blotches in my last panos.

  all the best,

   Luís Henrique

--
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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/1E39918C-62B7-412E-BECB-9404A8950B07%40gmail.com.

--

--
Luis Henrique Camargo Quiroz
http://luishcq.br.tripod.com - http://www.christusrex.org/www2/cantgreg
http://panoramaslh.net/

[Bruno Postle]

The black shadows are an enblend bug, they don't appear if you use the built-in Hugin blender (which is not as sophisticated as enblend, but is more stable) - Bruno

[Robert Mahar]

Yeah, thats whats forcing me to stick with enblend and "jiggle the handle" till the black tiles go away.  This 240 tile project gives 1 - 4 black areas every stitch if the images are in order ( right to left / top to bottom ).   I was going to dig into this, but I've always had issues building enblend from source owing to vigra, but I guess I need to figure that out to look under the hood.   FWIW I do see this issue when there is a regular overlap in the shooting pattern as there is in this project.  Unfortunately the tool I'm working on as a substitute for cpfind needs the order of the images to be preserved at the moment - once thats fixed somehow then I can permute the image order and sidestep this.

[Robert Mahar]

I'll stop posting after this one, but trying several different approaches.   The one that "worked" is reversing the order of the images and using --pre-assemble.   No complaints, and it ran to completion.   Given the exact same input images, the difference in blotchy-ness in the "good" portions of the various runs is curious :

Other methods like using using --fine-mask --primary-seam-generator=nearest-feature-transform and reversing the order gave me:

and then randomizing the input and using --pre-assemble --fine-mask --primary-seam-generator=nearest-feature-transform made it go nuts:

What s highly organized disaster.   Anyway, I'll stop being a pest with this stuff.

-- Bob

On Tuesday, November 14, 2023 at 3:00:56 PM UTC-5 Robert Mahar wrote:

Yeah, thats whats forcing me to stick with enblend and "jiggle the handle" till the black tiles go away.  This 240 tile project gives 1 - 4 black areas every stitch if the images are in order ( right to left / top to bottom ).   I was going to dig into this, but I've always had issues building enblend from source owing to vigra, but I guess I need to figure that out to look under the hood.   FWIW I do see this issue when there is a regular overlap in the shooting pattern as there is in this project.  Unfortunately the tool I'm working on as a substitute for cpfind needs the order of the images to be preserved at the moment - once thats fixed somehow then I can permute the image order and sidestep this.

[Saleh Saeed]

Hi,

The black part is the blend mask. Looks like the mask is created successfully but there is no texture from image/tiles to map onto it. I am not sure if this really is a geometric or photometric problem? Can you check that you get correct geometric alignment of all images/tiles (no image/tile is skipped and perfectly mapped at its respective location) before you move to photometric correction - Saleh

--

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+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/dd79c9af-7494-4bf2-b07b-beb3257a9f6en%40googlegroups.com.

[Merlijn B.W. Wajer]

Hi Robert,

On 14/11/2023 21:00, Robert Mahar wrote:
> Yeah, thats whats forcing me to stick with enblend and "jiggle the
> handle" till the black tiles go away.  This 240 tile project gives 1 - 4
> black areas every stitch if the images are in order ( right to left /
> top to bottom ).   I was going to dig into this, but I've always had
> issues building enblend from source owing to vigra, but I guess I need
> to figure that out to look under the hood.   FWIW I do see this issue
> when there is a regular overlap in the shooting pattern as there is in
> this project.  Unfortunately the tool I'm working on as a substitute for
> cpfind needs the order of the images to be preserved at the moment -
> once thats fixed somehow then I can permute the image order and sidestep
> this.

I am not sure how helpful my suggestions here are going to be, but from
my experience over the past month (doing the same but for photos
microfiche), I can maybe suggest a few things for this:

1. For blending, give multiblend [1] at try if you haven't already. I've
had some problems with enblend producing some odd artifacts at time. I
am not confident enough to say it was really an enblend problem (and not
my project variables / control points at the time), but I appreciate the
speed and reproducibility of multiblend.

2. For control point finding, you said you use a custom one. I also
ended up writing my custom control pointer (ORB based) finder and I was
having problems with visible seams until I realized my control points
weren't actually fitted properly with RANSAC - I wasn't accounting for
rotation in between my images (I expected there to be none). I'm not
saying the problems you're having are because you use a custom control
point finder, but it might be worth ruling that out by just using cpfind
with --multirow

2b. Related to control point finding, I don't know what is the reason
for not using cpfind, but if the reason is performance, then this might
help. If you make a template and apply it using pto_template, you can
use cpfind --prealigned and have cpfind 'do the right thing', so it
won't do excessive matching that you might be trying to avoid. At least,
I've understood this should do the trick at being more efficient.
(Please let me know if you figure this out (it's probably not too hard,
but I didn't try yet)

3. Maybe just open the project file in Hugin and see if the control
points are really all correct/align for the individual images.

Regards,
Merlijn

[1] https://horman.net/multiblend/

> On Monday, November 13, 2023 at 10:21:02 AM UTC-5 bruno...@gmail.com wrote:
>
> The black shadows are an enblend bug, they don't appear if you use
> the built-in Hugin blender (which is not as sophisticated as
> enblend, but is more stable) - Bruno
>

> --
> A list of frequently asked questions is available at:

> http://wiki.panotools.org/Hugin_FAQ <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+...@googlegroups.com

> <mailto:hugin-ptx+...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/hugin-ptx/430b6057-4fb3-4f29-acb3-9cb3030a1713n%40googlegroups.com <https://groups.google.com/d/msgid/hugin-ptx/430b6057-4fb3-4f29-acb3-9cb3030a1713n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Claudio Rocha]

When I've run into this issue in the past, the only solution I've found is to re-arrange the order of the images, or to eliminate images that have too many redundant control points (or completely overlap other images)

[David W. Jones]

I hit this recently. Running clean control points again in Hugin fixed it.

I tried the Hugin built-in blender; instead of a smooth blend, it produced areas of little square tiles (each a solid color) instead. So I went back to enblend.

I also think alignment might be sensitive to the presence of unnecessary images. Say one in the middle somewhere that is completely covered by other images.

I'm also starting to wonder about the Hugin PTO Generator option (select images, right click, open with Hugin PTO Generator). Opening the resulting PTO file in Hugin and making a panorama (using either my usual step-by-step process, or using the Assistant) from it sometimes just produces panoramas with weird curves, misaligned frames, etc. If I close the PTO, start a new project in Hugin, drag-and-drop the same images into Hugin, then make my panorama either way - it comes out fine.

Just thoughts and ideas.

-- 
David W. Jones
gnome...@gmail.com
wandering the landscape of god
http://dancingtreefrog.com
My password is the last 8 digits of π.