hugin-devs team mailing list archive

[Yuv <786204@xxxxxxxxxxxxxxxxxx>]

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.


** Patch added: "cpfind.args.patch"
   https://bugs.launchpad.net/hugin/+bug/786204/+attachment/2138511/+files/cpfind.args.patch

** Changed in: hugin
       Status: Invalid => Confirmed

** Changed in: hugin
   Importance: Undecided => Wishlist

** Changed in: hugin
     Assignee: (unassigned) => Yuv (yuv)

-- 
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