cpfind --kall -o does not output PTO file

[Yuv]

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

[tmodes (tmodes)]

That's not a bug, that's a feature. The k-switches are intended for only outputting the keyfiles (no matching, for output the keyfiles to be used with alternate matcher) and therefore ignore the -o switch.
To achieve the wished behaviour use the cache switch. This does exactly what you expect.

[Yuv (yuv)]

Attached is a patch that fixes this "feature" behavior that IMHO is unintuitive, convoluted, user-unfriendly.

why do we need three switches then (k, cache, o), when just two are enough to achieve the same with less strain on user's memory?

why do we need to override the user's instruction when the user clearly specifies -o XXX because the user wants a pto file to be written?

As I user I memorized the -k (keyfiles) and the -o (output) switches. The extra information that I read on the man page ages ago I did not remember because I don't use cpfind that often from the command line.

Can we make this easier for the user please?

1. If I run cpfind with -o, I expect it to do the feature matching and output a pto, or an error why it could not generate a pto.
2. If I run cpfind with a k-option, I expect it to store/cache the keypoints.
3. The cache switch is then redundant. k + o = cache.

The attached patch implements 1+2. I left 3 for backward compatibility.

[tmodes (tmodes)]

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.

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.

Also then "k+o" would not be "cache". The k switch forces the keyfiles to be regenerated even if they exists. 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.

[Yuv (yuv)]

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.