On January 2, 2011 01:38:46 pm kfj wrote: > the C parser used by hugin would probably throw a fit
you'll be surprised to know that Hugin took a hand-crafted pto file with s/a/w
parameters without any problem, and ran the optimization as if they were not
there. So from that perspective, we can add them and then add support to them
in the relevant tools.
> #-hugin cpWeight s0 a0 w100
>
> AFAIK this is established practice for introducing additional
> ('noncritical') values into the pto without breaking compatibility
> with other pto-using programs.
Really? what other pto-using programs? and what compatibility?
I tried feeding a simple PTO file straight out of Hugin to PToptimizer, with
whom the specs are supposedly 'shared'.
It chokes... already on the p line, so compatibility is broken anyway.
Even after removing the E/R/S parameters from the p line, it chokes again on
the Eev in the i line.
And: what you call 'established practice' is just a confusing hack. Let's do
things right.
A. PUT THE HISTORY OF THE PTO FORMAT TO REST
It was once derived from the original panotools syntax specified by Helmut
Dersch. In that sense it shares some DNA and a common ancestor with the
syntax of other PT based tools. But they have all evolved in different
directions and it can be safely assumed that:
1. the PTO format is specified by the Hugin project and for Hugin.
2. it has evolved to fit the growing needs of Hugin (e.g. adding photometric
variables, translation variables, etc.)
3. we are on our own and can keep it growing and try to steer the growth
toward a sensible solution
B. SPECIFYING THE NEW NEEDS
1. there is a case/request to activate/deactivate CPs
2. there is a case to weight CPs
3. there is a case to discern the source of CPs (human or computer generated)
C. EXTENDED SPECIFICATION OF THE PTO FORMAT TO MATCH THESE NEEDS
New variables on the 'c' lines:
- s: source (0=unknown, 1=human, 2=cpfind, etc.)
- a: active (0=yes, 1=no)
- w: weight (0 to 100)
Note that the these params are optionals and they have sensible default for
backward compatibility if a parser is properly coded, maybe with the exception
of weight - should it be in a range from 1 to 100 to avoid that all CPs have
weight of 0?
If there are no objections I will updated the specs both in Hugin and in
Libpano to make developers aware of things to come.
Ideally
http://hugin.hg.sourceforge.net/hgweb/hugin/hugin/file/default/doc/nona.txt
http://panotools.svn.sourceforge.net/viewvc/panotools/trunk/libpano/doc/stitch.txt
http://panotools.svn.sourceforge.net/viewvc/panotools/trunk/libpano/doc/Optimize.txt
should share a single, synchronized and coordinated spec.
D. PARSING A PTO FILE (or a PT dialect script)
I don't know how many parsers there are out there that do parse pto files. I
hope for them that they are designed as robustly as your Python parser or
Hugin's own parser. A good parser should be able to ignore noise such as
extra parameters that it does not need; or have a 'strict' syntax option to
throw warnings with a switch to disable those warnings. Feature request for
Panotools.
https://bugs.launchpad.net/panotools/+bug/696673
I don't know if Bruno's Perl tools are affected?
E. MAKING SENSE OF THE NEW PARAMETERS
It may or may not make sense for different tools to implement the new
parameters. Once they are specified and the parsers are robust enough, there
is no hurry. You can start playing around with these parameters in your
Python scripts; I can add the facility into the Hugin GUI to discern which
points are manually entered by the user; and so on. Eventually they will make
sense in the big scheme of things.
Yuv
signature.asc
Description: This is a digitally signed message part.
