Dealing with some images which contain no keypoints

[Merlijn B.W. Wajer]

Hi,

I'm looking on some advice on stitching together a set of images where a
few images might have no key points, but where I do know their position
(without reason).

I previously described my setup in a mail to this list titled "Field of
view, crop and canvas size" (see [1] for a part of that mail). I have
since adopted pto_template and cpfind --prealigned in my pipeline.

In my project, we shoot a total of 16 photos in a 4x4 grid, numbered as
follows:

01 02 03 04
08 07 06 05
09 10 11 12
16 15 14 13

The stitching process is headless / automated and there is no room for
human interaction. To prevent bad stitches, I have written code that
calls and parses 'checkpto foo.pto --print-output-info' to ensure the
min/mean/max error are within acceptable thresholds and all the images
are connected. The code also checks the exit status of checkpto (it has
to be zero).

Occasionally some photos (say one or two photos in the 13 - 16 range)
contain almost no useful content / features for control points. In this
case, the checks will usually trip up because unconnected images are
found. Assuming that I can write some code that the detects if this is
the case for a set of images, I was wondering what my options would be
with Hugin.

From my perspective, ideally I could still produce an image with these
16 shots included/stitched and accept that there will be visible seams -
given that there is not useful content this likely would not matter that
much.

Not including the images without content in the stitching process is an
alternative option, but I am hoping to not have to do that - in the odd
chance that some of the images do contain some useful content.

Which brings me to my two questions:

1. Is there a way to naively define an offset for an image with respect
to another image when there are no control points? I suppose I could
write an estimated TrX and TrY in the 'image lines' portion of the pto -
but without any control points, I suspect the images will still be seen
as 'not connected'. Should I insert some synthetic (but hopefully semi
accurate) control points? Will that work, or will those get discarded by
say cpclean?

2. Is there a way to use the existing command line tooling to 'remove'
or 'disable' an image in a project file? (Disabled in my book would mean
that checkpto would ignore it and it also wouldn't be included in the
final result)

With (2) I could temporarily disable some images and run checkpto and
confirm that the other images are all properly linked and (1) would
allow me to then place the remaining images with a known offset (again,
accepting that they'd be slightly misplaced/offset).

If I do end up programatically inserting some 'mostly accurate' points
in the .pto files, is there anything that I need to keep in mind when it
comes to optimising the .pto file? Like, should I tell autooptimiser to
not optimise for the synthetically inserted images?

Please see this link for an example of what the 4x4 grid looks like [2]
(this is not a stitched image, just some scaled down images pasted in a
grid with a black boundary separating them).

Finally, thank you very much for hugin and panotools.

Thanks in advance for any insight/help,
Regards,
Merlijn


[1] A few quick details: the images are made at a high magnification and
high resolution (151PM). The stitching is part of an effort to digitise
microfiche cards and the stitching is a fully automated process - so
people aren't supposed to say launch Hugin and fix some problem(s). The
output images are about ~1.3 gigapixel grayscale images.

[2]
https://archive.org/download/micro_IA40386401_0002/micro_IA40386401_0002_itemimage.png

[T. Modes]

mer...@archive.org schrieb am Freitag, 11. April 2025 um 12:59:45 UTC+2:

Which brings me to my two questions:

1. Is there a way to naively define an offset for an image with respect
to another image when there are no control points? I suppose I could
write an estimated TrX and TrY in the 'image lines' portion of the pto -
but without any control points, I suspect the images will still be seen
as 'not connected'. Should I insert some synthetic (but hopefully semi
accurate) control points? Will that work, or will those get discarded by
say cpclean? 

Hugin has already the geocpset tool https://wiki.panotools.org/Geocpset to set some kind of dummy control points to keep these featureless images in connection to its surrounding images during optimisation.

It needs some rough positions of the images. This should be possible in your use case with the 4x4 grid. See also https://wiki.panotools.org/Hugin_Panorama_Workflow for another example.

But don't run cpclean afterwards. (First run cpclean and then geocpset, not vice versa.)

Thomas

[Merlijn B.W. Wajer]

Hi Thomas,

Thank you for the quick response - I have replied inline.

On 11/04/2025 16:13, 'T. Modes' via hugin and other free panoramic

This was exactly what I was looking for, thank you!

It took me a bit of time to integrate this in my workflow, but now that
I got it working I am quite happy with it. I ended up using pto_template
with cpfind --prealigned, falling back geocpset if I was sure the
template was good enough (sometimes I stitch items in batches that go
through more or less the exact same motions, and the first item having
enough control points makes me confident enough that the rest will have
gone through similar motions, so I can use the first item as template).

One thing that I did run into with the above approach was that geocpset
wouldn't set points for an image if it is already linked to any image -
even if there are multiple image groups. Say there are two groups:
[0,1,2,3,4,5,6,7,8,9,11] and [12,13,14,15] - then geocpset doesn't link
the two groups.

All of that makes sense from geocpset's point of view, but I wanted
geocpset to supplement the regular control points. So to work around
this I ended up writing some custom code that removes control points of
all images in groups (except for the latest group), and then run
geocpset. This way images that are connected by regular control points
are untouched, but the images that have no control points that connect
them to main group get synthetic control points set. (And of course this
approach is only used if regular cpfind runs into trouble)

(I went with the pto_template approach because I couldn't easily figure
out how to map the pto_var set formula options to the 'real world'
movements (in millimeter) that my XY stage makes.)

Thanks again,
Regards,
Merlijn

[T. Modes]

Hi,

mer...@archive.org schrieb am Sonntag, 13. April 2025 um 23:22:33 UTC+2:

One thing that I did run into with the above approach was that geocpset
wouldn't set points for an image if it is already linked to any image -
even if there are multiple image groups. Say there are two groups:
[0,1,2,3,4,5,6,7,8,9,11] and [12,13,14,15] - then geocpset doesn't link
the two groups.

I think in this case the switch --each-overlap should help.

If not, please provide the pto file so I could check it.

Thomas