Providing order of images in Hugin assistant

[Venkat]

Hello All,

We are trying to use the hugin assistant in code to stitch a panoramic image. We were wondering is there command line parameter to force the order of images. Currently the assistant figures out  by trying different combination in some cases its taking around a minute or two for a set of 11 or 12 images. Since we know the order to be stitched wonder is there a way to force the assistant to use the designated order as opposed to trying all the permutations.  Any pointers would be really appreciated.

Thanks in advance

Venkat

[T. Modes]

Please post only once. No need for duplicate posts.

Venkat schrieb am Montag, 25. März 2024 um 17:11:16 UTC+1:

Since we know the order to be stitched wonder is there a way to force the assistant to use the designated order as opposed to trying all the permutations.  Any pointers would be really appreciated.

The default assistant is using cpfind --multirow. This should prevent a check of all permutation and only test a sensible count if image pairs. (It falls back to all image pairs only if there are unconnected image pairs.)

Otherwise you would assign rough image positions and then run cpfind --prealigned. But this would require some more adjustment to the assistant.

Thomas

[Venkat]

Cool thanks for the note. I will see if we could tweak the assistant to handle cpfind --prealigned. If you have the information handy, it would be helpful as well. 

Sorry about multiple post. When I did the first post it didn't show up immediately and had to post again. Later realized both are posted.

[PanoSeek]

I do something similar with my pano script for my Drone shots. - templates.    Probably not the ideal case for you, but may be useful.

https://github.com/RookieITSec/HuginPanoScript

[Venkatramani Sankarlingam]

Ok, interesting, let me explore further on those set of parameters.

--
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
---
You received this message because you are subscribed to a topic in the Google Groups "hugin and other free panoramic software" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/hugin-ptx/HbPrWtleIXw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to hugin-ptx+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/95e07615-7c6b-4f02-868e-c6cea8cb842fn%40googlegroups.com.

[Greg 'groggy' Lehey]

On Monday, 25 March 2024 at 8:55:19 -0700, Venkat wrote:
>
> We are trying to use the hugin assistant in code to stitch a
> panoramic image. We were wondering is there command line parameter
> to force the order of images.

I don't understand the question. If you're using the "command line",
simply name the images in the order that you want. To make any sense,
you'd need the --linearmatch option. Or am I missing something?

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

[Greg 'groggy' Lehey]

On Monday, 25 March 2024 at 11:19:52 -0700, Venkat wrote:
>
> Cool thanks for the note. I will see if we could tweak the assistant to
> handle cpfind --prealigned. If you have the information handy, it would be
> helpful as well.

Again, I may be misunderstanding, but I'm not sure that --prealigned
would help here. From the --help (for some reason this isn't
mentioned in the man page):

--prealigned Match only overlapping images,
requires a rough aligned panorama

I haven't used it, but it seems that this is a second step, and I
think you're looking for the first.

[Venkatramani Sankarlingam]

Thanks for the additional clarification. We are doing the following steps

1. pto_gen -o output.pto *.jpg --sort 

 2. hugin_executor --assistant output.pto 

 3. hugin_executor --stitching --prefix=prefix output.pto

And the images are numerically numbered starting from 0. And #2 and #3 can be potentially combined into one step. The above approach ends up trying all permutations.We also tried to provide the individual images during #1 and ended up with the same result.

From reading the code https://github.com/ndevenish/Hugin/blob/master/src/hugin1/executor/hugin_executor.cpp looks like there isn't much option to provide "use the predefined order of images''. Probably we may have to break it down into individual steps to control the order better .

 

--
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
---
You received this message because you are subscribed to a topic in the Google Groups "hugin and other free panoramic software" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/hugin-ptx/HbPrWtleIXw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to hugin-ptx+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/ZgIEOnHA1njWIiR7%40hydra.lemis.com.

[T. Modes]

Venkat schrieb am Dienstag, 26. März 2024 um 07:48:18 UTC+1:

From reading the code https://github.com/ndevenish/Hugin/blob/master/src/hugin1/executor/hugin_executor.cpp looks like there isn't much option to provide "use the predefined order of images''.

This is not the official repository. And it is totally out of date.

Hopefully you are using a current version and not this very old one from the mentioned repo.

When the assistant checks all image pairs there is a wrong setting in the preferences.

Goto the menu File>Preferences, on tab control points detectors select reset to default.

Then check the default control point setting, it should be cpfind and it should contain the --multirow switch in the settings.

Thomas

[Venkatramani Sankarlingam]

Thanks for the note, we will look into it. 

Yeah we are using the official repo. 

--
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
---
You received this message because you are subscribed to a topic in the Google Groups "hugin and other free panoramic software" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/hugin-ptx/HbPrWtleIXw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to hugin-ptx+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/cb459f3b-226d-46da-89be-4b832e9475can%40googlegroups.com.

[Greg 'groggy' Lehey]

[Rearranged for clarity]

Original post:

On Monday, 25 March 2024 at 8:55:19 -0700, Venkat wrote:
>
> We are trying to use the hugin assistant in code to stitch a panoramic
> image. We were wondering is there command line parameter to force the order

> of images. Currently the assistant figures out by trying different
> combination in some cases its taking around a minute or two for a set of 11

> or 12 images. Since we know the order to be stitched wonder is there a way

> to force the assistant to use the designated order as opposed to trying all
> the permutations. Any pointers would be really appreciated.

Current messages:

On Monday, 25 March 2024 at 23:48:02 -0700, Venkatramani Sankarlingam wrote:
> On Mon, Mar 25, 2024 at 4:09 PM Greg 'groggy' Lehey <groo...@gmail.com>
> wrote:
>
>> On Monday, 25 March 2024 at 11:19:52 -0700, Venkat wrote:
>>>
>>> Cool thanks for the note. I will see if we could tweak the
>>> assistant to handle cpfind --prealigned. If you have the
>>> information handy, it would be helpful as well.
>>
>> Again, I may be misunderstanding, but I'm not sure that --prealigned
>> would help here. From the --help (for some reason this isn't
>> mentioned in the man page):
>>
>> --prealigned Match only overlapping images,
>> requires a rough aligned panorama
>>
>> I haven't used it, but it seems that this is a second step, and I
>> think you're looking for the first.
>

> Thanks for the additional clarification. We are doing the following steps
> 1. pto_gen -o output.pto *.jpg --sort

OK, this is clearly not what you want. You're selecting your files
sorted by name (*.jpg), when in fact you want to specify your own
order.

> 2. hugin_executor --assistant output.pto
> 3. hugin_executor --stitching --prefix=prefix output.pto
>
> And the images are numerically numbered starting from 0. And #2 and #3 can
> be potentially combined into one step. The above approach ends up trying
> all permutations.We also tried to provide the individual images during #1
> and ended up with the same result.

You don't say how you "provide the individual images". If you specify
the names in the order you want, you're half way there. But you're
using the undocumented --sort option, which imposes the same sort
order. What happens if you do something like this?

pto_gen -o output.pto 4.jpg 6.jpg 8.jpg 1.jpg 2.jpg 3.jpg 7.jpg 9.jpg 5.jpg 10.jpg 11.jpg

That's an example of out-of-order processing; substitute your own.
And note the lack of the --sort option.

I'd be interested, though, in why your processing takes so long. Is
this a very slow machine, or are the images very large?

On Tuesday, 26 March 2024 at 9:30:13 -0700, Thomas Modes wrote:
>
> When the assistant checks all image pairs there is a wrong setting
> in the preferences. Goto the menu File>Preferences, on tab control
> points detectors select reset to default.

Wouldn't it be a good idea to check what the current setting is first?
But I can't find how to do that in the GUI, and I can't find a "reset
to default" button, just "Load Defaults". This is Hugin
2023.0.0.d88dc56ded0e. But the information is all in the ~/.hugin
file. Here an example entry that probably matches what Thomas is
saying:

Description=Hugin's CPFind
Program=cpfind
Arguments=--multirow -o %o %s
ProgramMatcher=
ArgumentsMatcher=
Option=1

POLA warning: this has changed at some point relatively recently. In
my ~/.hugin I have:

Description=Hugin's CPFind
Program=cpfind
Arguments=-o %o %s
ProgramMatcher=
ArgumentsMatcher=
Option=1
[AutoPano/AutoPano_1]
Type=1
Description=Cpfind (multirow/stacked)
Program=cpfind
Arguments=-o %o --multirow %s
ProgramMatcher=
ArgumentsMatcher=
ProgramStack=align_image_stack
ArgumentsStack=-f %v -v -p %o %i

That corresponds to two entries on the GUI preferences screen, Hugin's
CPFind and Cpfind (multirow/stacked). So the old Hugin's CPFind no
longer exists, and has been replaced by the contents of Cpfind
(multirow/stacked). Others might also be interested in this change.

It's not clear, though, that this is what you want. --multirow only
makes sense when you have, well, multiple rows. If your images are
all in the same plane, --linearmatch is probably what you're looking
for. I don't know how to set it from the GUI, but you can edit the
.cpfind file. Be sure to keep a backup in case something goes wrong.

> Then check the default control point setting, it should be cpfind
> and it should contain the --multirow switch in the settings.

Thomas: OK, where do I check this? How do I change it?

[T. Modes]

Hi Greg,

Groogle schrieb am Mittwoch, 27. März 2024 um 02:03:34 UTC+1:

Wouldn't it be a good idea to check what the current setting is first?
But I can't find how to do that in the GUI, and I can't find a "reset
to default" button, just "Load Defaults".

I meant this button. I did not check the English string, I looked only on the localized version.

 

This is Hugin
2023.0.0.d88dc56ded0e. But the information is all in the ~/.hugin
file. Here an example entry that probably matches what Thomas is
saying:

That corresponds to two entries on the GUI preferences screen, Hugin's
CPFind and Cpfind (multirow/stacked).

So you did change these settings in the past! The default setting has 6 entries.

It's not clear, though, that this is what you want. --multirow only
makes sense when you have, well, multiple rows.

That is a misunderstanding. The multirow algorithm works also fine for single row panoramas.

The help page for cpfind states under --multirow:

> This is an optimized matching strategy for single and multi-row panorama:

 

> Then check the default control point setting, it should be cpfind
> and it should contain the --multirow switch in the settings.

Thomas: OK, where do I check this? How do I change it?

I though the "edit" button directly beside the list is obviously enough.

<sarcasm on> Mhh, maybe I should rename the button to "show the setting and let me change them to my personal preferences"</sarcasm off>

Thomas

[Venkat]

Thanks for taking a stab at this.

 

You don't say how you "provide the individual images". If you specify
the names in the order you want, you're half way there. But you're
using the undocumented --sort option, which imposes the same sort
order. What happens if you do something like this?

pto_gen -o output.pto 4.jpg 6.jpg 8.jpg 1.jpg 2.jpg 3.jpg 7.jpg 9.jpg 5.jpg 10.jpg 11.jpg

   [ Venkat ]

   The above option ( ex - pto_gen -o output.pto 1.jpg 2.jpg 3.jpg 4.jpg 5.jpg ) still resulted in 

   multiple combinations to find best matching pair.

 

That's an example of out-of-order processing; substitute your own.
And note the lack of the --sort option.

I'd be interested, though, in why your processing takes so long. Is
this a very slow machine, or are the images very large?

   [ Venkat ] 

   Average size of image - 1.56 mb, resolution - 4000 x 1600 RAM - 20 GB. It was

  running on Windows Subsytem For Linux ( Ubuntu 22.04 ). May be WSL is causing 

slowness.

[Greg 'groggy' Lehey]

On Wednesday, 27 March 2024 at 13:44:34 -0700, Venkat wrote:
> Thanks for taking a stab at this.
>
>> You don't say how you "provide the individual images". If you
>> specify the names in the order you want, you're half way there. But
>> you're using the undocumented --sort option, which imposes the same
>> sort order. What happens if you do something like this?
>>
>> pto_gen -o output.pto 4.jpg 6.jpg 8.jpg 1.jpg 2.jpg 3.jpg 7.jpg 9.jpg 5.jpg
>> 10.jpg 11.jpg
>

> The above option ( ex - pto_gen -o output.pto 1.jpg 2.jpg 3.jpg
> 4.jpg 5.jpg ) still resulted in multiple combinations to find best
> matching pair.

Yes, but there's a subtle difference: as I said,

>> That's an example of out-of-order processing; substitute your own.
>> And note the lack of the --sort option.

Your example showed the file names in alphabetical order. My
understanding was that this isn't what you wanted. And you missed
this important part:

>> If your images are all in the same plane, --linearmatch is probably
>> what you're looking for.

Without --linearmatch, the sequence isn't important. Still, all of
this may be overkill:

>> I'd be interested, though, in why your processing takes so long. Is
>> this a very slow machine, or are the images very large?
>

> Average size of image - 1.56 mb, resolution - 4000 x 1600 RAM - 20
> GB.

Nothing unusual in that. I regularly stitch much larger images.

> It was running on Windows Subsytem For Linux ( Ubuntu 22.04 ). May
> be WSL is causing slowness.

That would be my guess. If you're running under Linux, why not use
the Linux version of Hugin? I'm sure it gets much more developer
attention. And then I guess you wouldn't need to do anything special
to get your images processed in a timely fashion.

If you do this, it would be good to hear from you whether it improves
performance.

[Venkat]

>>>>Your example showed the file names in alphabetical order. My
>>>>understanding was that this isn't what you wanted. 

We were providing alphabetical order so that even when we pass --sort we would

end getting the right order (assuming sort does ascending). But you are right if the

user knows the order then no need for "--sort" or having sorted order file names.

>>>> And you missed this important part:
>>>> If your images are all in the same plane, --linearmatch is probably
>>>> what you're looking for.

Our entry point is calling "pto_gen" and "hugin_executor" with different parameter 

and going with  the default assumptions.

So when hugin_executor gets called with --assistant it calls 

"cpfind" with some defaults. This results in trying all matches ( regardless of sort or not  

during the "pto_gen" step). 

Probably that's where we need make "hugin_executor" to make it pass 

cpfind with a --linearmatch. To have that granular control I guess we need to pass

hugin_executor with a "user_defined" assistant file to have fine control of 

variosu parameters to various modules.  

>>>> That would be my guess. If you're running under Linux, why not use
>>>>   the Linux version of Hugin? I'm sure it gets much more developer
>>>>   attention. And then I guess you wouldn't need to do anything special
>>>>   to get your images processed in a timely fashion.

Yeah, having a dedicated linux box would be ideal. Since we had a windows laptop 

we just enabled the linux subsytem on windows and tried the linux modules to see

as a prototype.

>>>> If you do this, it would be good to hear from you whether it improves
>>>> performance.

Sure, I will have to try it as docker image. I will keep this thread posted when I have

the result.

[Greg 'groggy' Lehey]

On Thursday, 28 March 2024 at 18:09:38 -0700, Venkat wrote:
>>>>> Your example showed the file names in alphabetical order. My
>>>>> understanding was that this isn't what you wanted.

> We were providing alphabetical order so that even when we pass
> --sort we would end getting the right order (assuming sort does
> ascending). But you are right if the user knows the order then no
> need for "--sort" or having sorted order file names.

Somewhere round here I'm getting the feeling that we're
misunderstanding each other. Anyway:

>>>>> That would be my guess. If you're running under Linux, why not
>>>>> use the Linux version of Hugin? I'm sure it gets much more
>>>>> developer attention. And then I guess you wouldn't need to do
>>>>> anything special to get your images processed in a timely
>>>>> fashion.
>
> Yeah, having a dedicated linux box would be ideal. Since we had a
> windows laptop we just enabled the linux subsytem on windows and
> tried the linux modules to see as a prototype.

Clearly this is another misunderstanding. I thought you were running
Microsoft on top of Linux, in other words the other way round.

Still, you can get Hugin for Microsoft. Why not install that and see
how it works?

[Venkat]

>>>> Still, you can get Hugin for Microsoft. Why not install that and see
>>>> how it works?

Yeah, we tried that option as well. hugin_executor --assistant ./output.pto was taking roughly 

around a minute.  Also, eventually our goal is to run on Linux box and had to try WSL as a quick way.

[T. Modes]

Venkat schrieb am Freitag, 29. März 2024 um 02:09:38 UTC+1:

So when hugin_executor gets called with --assistant it calls 

"cpfind" with some defaults. This results in trying all matches ( regardless of sort or not  

during the "pto_gen" step). 

Either you have not set the multirow switch for the default cp generator or something else is going wrong.

But have been said already and I have the feeling we are going in circles.

The best would be you provide a link to one image set and the log of commands. Then we can try ourself and compare with your output.

[Venkat]

Let me take a another stab at this. 

Recapping  the original steps:  

1. pto_gen -o output.pto 1.jpg 2.jpg 3.jpg 4.jpg 5.jpg 6.jpg 7.jpg 8.jpg 9.jpg 10.jpg 11.jpg 12.jpg
2. hugin_executor --assistant ./output.pto
3. hugin_executor --stitching --prefix=prefix ./output.pto

Problems:

1) Attached Default.txt which captures the log output of the above steps.  From Line 112 to Line 143 we could see the match is made

among the combinations of the images ex: image 0.jpg  (its actually 1.jpg but zero indexed internally ) with all other images, likewise other images

are matched as well. Ideally I want the match to be restricted to the sequence provided in the command line ie. 1 <> 2, 2<> 3 so on and so forth till 11 <> 12. 

Probable fix :

During Step2 run the cpfind with a --linearmatch. In order to do that I had to use a user-defined-assistant fileas below. 

hugin_executor --assistant  --user-defined-assistant=C:/Users/svrvs/Downloads/Feb24/general.assistant  ./gen.pto

Attached gen.log,  general.assistant ( in this I don't think checkpto, cpclean are really needed but that's a experiment for another day ). 

This seem to take in the image as is per command line passed in step1.

2) Initially step2 was around a minute.  step3 probably around 10 - 15 seconds.  With the cpfind --linearmatch as in problem#1 

the time was cut down to 23 seconds during step2, step3 not a drastic change.

Btw, the images have restrictions to share

[Venkat]

Minor clarification

>> Probable fix :

>> During Step2 run the cpfind with a --linearmatch. In order to do that I had to use a user-defined-assistant fileas below. 

>> hugin_executor --assistant  --user-defined-assistant=C:/Users/svrvs/Downloads/Feb24/general.assistant  ./gen.pto

>>  Attached gen.log,  general.assistant ( in this I don't think checkpto, cpclean are really needed but that's a experiment for another day ). 

>>  This seem to take in the image as is per command line passed in step1.

During Step1, I used gen.pto as the filename to generate.

[T. Modes]

Venkat schrieb am Samstag, 30. März 2024 um 07:06:32 UTC+1:

Problems:

1) Attached Default.txt which captures the log output of the above steps.  From Line 112 to Line 143 we could see the match is made

among the combinations of the images ex: image 0.jpg  (its actually 1.jpg but zero indexed internally ) with all other images, likewise other images

are matched as well.

No, it does not check all combinations.

e.g. image 0 is matched with image 1, 2, 3, 7, 8, 9, 10, 11; but not with images 4-6.

These matches are done because you have a lot of overlap between the images (see that most of the matches are done under the caption --- Find matches for overlapping images ---).

You see this also in the output of enblend: warning: some images are redundant and will not be blended.

So if speed is your main concern, reduce the number of images, because you have a lot of overlap and redundant images.

[Venkat]

>> No, it does not check all combinations.

>> e.g. image 0 is matched with image 1, 2, 3, 7, 8, 9, 10, 11; but not with images 4-6.

>> These matches are done because you have a lot of overlap between the images (see that most of the matches are done under the caption --- Find matches >> for overlapping images ---).

>> You see this also in the output of enblend: warning: some images are redundant and will not be blended.

>> So if speed is your main concern, reduce the number of images, because you have a lot of overlap and redundant images.

I will look into this. Thanks team for the insights.