Telling cpfind where to look.
Rogier Wolff
I'm making test-shots with my home-made gigapan unit.
I have to clean up the control points manually because cpfind
sometimes finds matches that are not there, but also because it
sometimes doesn't find matches that ARE there.
Because I know the shooting order of my pano, I know which images
overlap with which others.
Just like multiblend now allows you to specify the seamlines in an
external program, I would like to be able to load the
list-of-images-to-try-to-match into cpfind. Simple ones it should be
able to do all by itself.
- All pairs
- 0-1, 1-2, 2-3, 3-4 ... (n-1 - n).
But apparently the "multirow" option that is already available does
not do a really good (enough) job.
So, how about we allow cpfind to read a list of potential matches?
The advantage is that we separate the "what matches to try" from the
control point finding. This means that in the future for example,
after an initial layout optmization, we might find overlaps where
there are no controlpoints. So then the hugin gui might be able to
fire off a second cpfind run that runs on the found-to-be-overlapping
images....
Or maybe this is already implemented and I should just go and RTFM?
Roger.
--
** R.E....@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.
kfj
On 14 Feb., 15:12, Rogier Wolff <rew-googlegro...@BitWizard.nl> wrote:
> Hi,
> list-of-images-to-try-to-match into cpfind. Simple ones it should be
> able to do all by itself.
> - All pairs
> - 0-1, 1-2, 2-3, 3-4 ... (n-1 - n).
>
> But apparently the "multirow" option that is already available does
> not do a really good (enough) job.
>
> So, how about we allow cpfind to read a list of potential matches?
to have a matching-strategy script. What you can do until someone
implements matching strategies in cpfind is this: Initially have a go
at all the images to just create and cache keyfiles. Once you have the
keyfiles, matching two images (by calling cpfind with just two images
per go) is really fast, so you can have a script doing the matching
strategy for you. If you do it that way, you don't need any new syntax
in cpfind and you have all the added flexibility you gain from having
an individual cpfind call per pair.
Stuff like that is really done best in a glue layer between hugin and
it's slave programs. That way noone has to touch code which needs
compiling and experiments are made easy. I have tried to popularize
the technique, but found little interest. My approach to a glue layer
for cpg's is this:
http://bazaar.launchpad.net/~kfj/+junk/script/view/head:/main/cpg_glue.py
Kay
Bruno Postle
>On 14 Feb., 15:12, Rogier Wolff <rew-googlegro...@BitWizard.nl> wrote:
>> I would like to be able to load the
>> list-of-images-to-try-to-match into cpfind. Simple ones it should be
>> able to do all by itself.
>> - All pairs
>> - 0-1, 1-2, 2-3, 3-4 ... (n-1 - n).
>>
>> But apparently the "multirow" option that is already available does
>> not do a really good (enough) job.
>>
>> So, how about we allow cpfind to read a list of potential matches?
>
>I'm all for it! Command line syntax is one thing, but another would be
>to have a matching-strategy script. What you can do until someone
>implements matching strategies in cpfind is this: Initially have a go
>at all the images to just create and cache keyfiles. Once you have the
>keyfiles, matching two images (by calling cpfind with just two images
>per go) is really fast
All this is ready to go, but on the command-line:
cpfind can create cache files, has various modes like --linearmatch
that help you align just a selection of photos. Use pto_gen to
specify which photos belong to each batch. ptomerge can join these
project fragments together. ptosort and ptosplit can help divide up
project files for further processing.
These tools and lots of others exist _specifically_ for the kind of
experimentation in better matching strategies that can later be
incorporated into the tools used by the Hugin GUI.
--
Bruno
Naked Robot
i.e. if i pre-align an image, will it help cpfind or not?
this, i think, is what is really missing.
Carlos Eduardo G. Carvalho (Cartola)
Cheers,
Carlos E G Carvalho (Cartola)
http://cartola.org/360
Is there any way to specify specific overlapped areas for cpfind to look?
i.e. if i pre-align an image, will it help cpfind or not?
this, i think, is what is really missing.
--
You received this message because you are subscribed to the Google Groups "Hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugi...@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx+...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
kfj
On 15 Feb., 10:24, Naked Robot <360cit...@gmail.com> wrote:
> Is there any way to specify specific overlapped areas for cpfind to look?
>
> i.e. if i pre-align an image, will it help cpfind or not?
bits (may they be overlapping because you manually prealigned the
images or because the optimizer did it for you), warps them to a
common geometry, calculates CPs and recalculates what the coordinates
of the CPs would have been in the original images.
Kay
Bruno Postle
cpfind actually does this overlap detection as the last step of the
--multirow option, it just isn't available separately.
It should be straightforward to make it a separate option (look for
'overlap' in src/hugin_cpfind/cpfind/PanoDetector.cpp).
There is also the 'ptofill' tool in Panotools::Script which already
does this: http://search.cpan.org/dist/Panotools-Script/bin/ptofill
Unfortunately ptofill was written to use the generatekeys/autopano
pair, and was never updated to use cpfind as a backend, this is
very fixable but I'm not doing it right now.
--
Bruno