panorama data structure

[Bruno Postle]

On Sun 14-Apr-2002 at 08:53:32 +0300, Martin 'pisi' Paljak wrote:
> 
> For example, afaik PT allows you to have all images made with
> different lens [or am I wrong?] but ptgui allows me to specify only
> once the lens settings and all images will have the same  lens type...

Yes, by default, but you can have separate lens settings and types for
each source image (and you can optimise them separately, though this
makes a bit of a mess).

> Panorama

..or project (see below).

> 	Source pictures (1 to many)
> 		file name
> 		size
> 		crop parameters
> 		lens info

Yep, there is also the special case of the default settings, a
default/dummy image (with id=0 and no filename) that can override any
unset values of other input images (this is the object that you are
modifying in the ptgui lens settings page).

> 	Panorama settings (1)
> 		size
> 		type

Note that so-far this data-type is very similar to the source image
data-type.  There is also the potential for multiple output images that
have their own parameters (the six faces of a cube for example).
Ptstitcher _doesn't_ currently output more than one image (except when
creating vrml - a special case).

> 		stitching algorithm (poly3 etc)
> 		other options that ptstitcher/helper apps can parse
> 		other options that affect the panorama as a whole

A lot of these options in ptgui (like feather-width, sampling-method,
gamma), are lumped together with the general panorama-settings because
that is how ptstitcher currently accepts them.  These attributes might
be better attached to the default-input-image since Helmut _could_
someday make them variable for each input image.

> 	Controlpoints (1 to many)
> 		image1
> 			coordinates
> 		image2 (is it possible to have one point on 3 images?)
> 			coordinates

It's not possible at the moment to have more than two input images in a
control-point set.  Panorama-tools script files are limited because x
and y are used for the left image and X and Y are used for the right
image - There is no reason in principle why a control point couldn't
exist in three images, and actually this could be useful if an optimizer
was ever written to handle it (I think the whole xyXY thing is a yuk
historical design decision).

> 		CP type

..as xml this might look this this:

  <control>
    <point id="0" error="0.452937" type="horizontal">
      <image id="5" x="883" y="720" />
      <image id="6" x="363" y="704" />
    </point>
      ...
  </control>

(note, the error-value is just informational feedback from the optimizer
and there is space for future extra input-images)

> Who knows panorama internals, please help to define a nice structure
> for the panorama info file. who knows xml good can help out by
> creating the dtd as we evolve with the data structure ? [I can
> volunteer]

Basically the existing script file format is horrible, the language is
very unexpressive and some stuff is tacked-on (like the optimizer
instructions which are not associated with the input images that they
are optimizing).  The ptgui files are simply pt script files with extra
project info stored in comment-blocks.

It might be a good idea to keep the gui-tool well away from ptsticher
and ptoptimizer.  If we can describe a project as rational xml, then a
separate tool could act as a 'driver';  ie. take the xml, generate
suitable pt script files, run the helper tools and deal with the
results.

-- 
Bruno