← Back to team overview

hugin-devs team mailing list archive

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