On 2011-01-17 3:43 PM, Thomas Sharpless wrote:
Yes it needs to allow optimization. But an error if both
old(current) and new method is used together. A variable is used if
it is either defined as non zero or set to be optimized.
On Sun, Jan 16, 2011 at 11:30 PM, dmg <email@example.com>
I vote to define a new flag.
it would minimize potential bugs. The default (zero) would be
Do you think it should be a new optimizer ('v' line) flag?
That would seem logical, since this is really an optimization
option. However there is no new optimizable variable to go
along with it.
Currently only variables in i lines can be optimized.
Parameters defining a lens:
Old = projection format, Field of View, abc distortion (f, v, a,
b, & c)
New = projection format, Focal length, sensor size, abc?
What about we add a new line/class to define a lens, an l line.
and the i line/class that define an image can use a l=0 (lens = lens
This should help to get the lens data into a database.
Although, adding a new type of line would likely cause most
optimizers and stitchers to through an error and quit.
Input image information does not belong in the p line. I don't
think we need to change the way we define the Field of View of the
result. I would also like an easy way of using the output results
and putting them back in as input.
Adding another var to the 'p' line might be nice, just because
that line is not already overloaded with vars. That would
disallow mixing polynomial modes in projects using multiple
lenses, but I wonder if anyone would care? Indeed, I think
that might be the best policy...
An image could be defined using the old(current) method or the new
lens based method. If the image was generated to a specific FoV
then the old method would be used. If the input image is from a
camera then the new lens based method would be used.
I'd really like to enable this option only for projects
involving lens-based images. But I don't know if libpano has
a sufficiently high-level view to determine that.