hugin-devs team mailing list archive
-
hugin-devs team
-
Mailing list archive
-
Message #01951
Re: [Bug 786204] Re: cpfind --kall -o does not output PTO file
On May 22, 2011 11:40:09 AM tmodes wrote:
> Sorry, but your patch introduces an user unfriendly behaviour: When
> starting without -o switch it runs the whole cp finding and matching
> (which can be time consuming) and at the end *no* output is written.
how is this different from starting with --kall -o and at the end *no* pto
file is written? are you sure this is new behavior introduced and not
consequence of the initial convoluted behavior, coupled with my quick and
superficial hacking?
> Also when starting with e.g. "-k 0 -k 1" instead of -kall this will not
> produce the wanted behaviour (it will only find the matches between
> image 0 and 1 and ignore all other image pairs, or in the worst case it
> will crash), please have a better look into the code before starting
> hacking.
thanks for the feedback. the reason why i dumped this as a patch in the
tracker is because i am aware of my limitations. i am not familiar with the
code and at this moment i do not have time to look better into it. i spent 15
minutes to find what i was looking for, change it, build and make a simple and
insufficient test. then i "saved" my work in a way that it can be picked up
at a later stage, by myself or by anybody else. it is saved in this tracker
ticket, with a qualification of "wishlist". It will probably take a few
minutes to somebody familiar with the code to get the behavior right. It will
probably take me a couple of hours that I do not have. Especially since
within a few months I will have forgotten the details and the code will be
equally impenetrable to me as it is now. From my perspective, I rather focus
on the python scripting access to detection matching and hack around on a
python script replacement for the strategy logic.
> Also then "k+o" would not be "cache". The k switch forces the keyfiles
> to be regenerated even if they exists.
IIRC when I was using cpfind and there were keyfiles, even if I had the --kall
switch enabled I read on the screen that the existing keyfile was used. But
you know better, you coded this. How about making a smart decision if the
keyfile needs to be re-generated or not, rather than blindly re-generating it?
or is the cache option blindly re-using it, even if the image may have
changed, or the fov/projection input may have changed?
> This does not happen with cache
> switch. So there is a right to live for both, even if you personally
> does not need one of them.
I am still of the opinion that all situations can be handled with two
switches. Using a third one is overly complicated.
--
You received this bug notification because you are a member of Hugin
Developers, which is subscribed to Hugin.
https://bugs.launchpad.net/bugs/786204
Title:
cpfind --kall -o does not output PTO file
Status in Hugin - Panorama Tools GUI:
Confirmed
Bug description:
when entering the command cpfind --kall -o out.pto in.pto I would expect
a) all .key files for the input images to be stored on disk
b) out.pto to be equally stored on disk
indeed the first part happens, but the second not and I must repeat
the command cpfind -o out.pto in.pto to obtain the expected result
References