[Openpanorama-info] preliminary comments/suggestions

[Aldo Hoeben]

I'm not sure about the acitivity on this list, as I just joined in.
What follows are a couple of first comments, from reading the example
XML file on the OpenPanorama.org website. I didn't read all
documentation yet, so if I'm making stupid remarks, please say so
and ignore this post ;-)

* new root node
I'ld suggest a new root node that can hold multiple OpenPanorama nodes.
A virtual tour of multiple panoramas COULD BE included in a single
XML file. Using a hotspot or GUI element you can jump to another pano
within the same XML file, OR to another XML file alltogether.
The root node could also include a viewerDescription node

* viewerDescription node
Describes viewer characteristics that are common between all the
OpenPanorama nodes within the root node:
  - initial/default OpenPanorama node
  - common GUI elements (buttons, lists etc as well as Cursor graphics)
  - camera dynamics (such as inertia, sensitivity)
  - splash/load-screens
  - copyright/summary info for the tour (as opposed to single panos)
  - licenses
  - angleType property from OpenPanorama node?

* move the limits and entryPoint node to the body of the OpenPanorama
node
The other nodes within the head represent metadata that is not directly
visible within the panorama.

* rename entryPoint node
defaultView would be a better name for this node:
  - the inclusion of the zoom paramater makes this not a point but a view
  - if you're entering this panorama from a hotspot, a different entry view
    may be specified. The  defaultView should only be used when an
    entry view is not defined/specified.

* combine flatImage and circularImage
new node <panoImage type = "rectangular" fov = 90 pan = "0" tilt = "0">
or <panoImage type = "cylindrical" fov = 360 pan = "0" tilt = "0"> or
<panoImage type = "spherical" fov = 180 pan = "0" tilt = "0">.
Other types of panoImages could be conceivable.
This would also remove the need for a rectangleList as a child to the
flatImage node.

* rename maskImage node
hotspotImage or hotspotIndex would be a better choice. Mask suggest
graphically masking parts of the images (eg through an alpha-channel).

* allow alpha-channeled images
transparentColor only allows for 1 bit transparency, whereas an 8 bit
alpha channel would be better looking. As there are no 32 bit jpeg
formats (AFAIK), a alphaImage node could be usefull as a sibbling to
the image node (or better: an alphaFile parameter could be added to
the image node). The file would be a 8 bit (greyscale) jpeg.

* why require the mimetype for images?
Is this a common XML requirement? If so, I don't like it! You'ld have
the file's actual file format (1), the file format suggested by the filename
or extension (2), the mimetype suggested by the webserver (3) and
the mimetype specified in the file (4), which could all be conflicting!



I think that's enough for now ;-)

'do