[Openpanorama-info] Re: preliminary comments/suggestions

[Aldo Hoeben]

Sorry for starting wat could have been a discussion, and then going on a
holiday...

> >What follows are a couple of first comments, from reading the example
> >XML file on the OpenPanorama.org website.

> Most of the documents are simple though on the project. The xml example
> is the more interresting document.

Too bad the XML file isn't in a format that encourages comments. Is there a
nice way to open/edit generic XML files in OpenOffice and keep the changes?

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

> I'm agree with this point. I'm trying to find the best way to have such
> system.

By the way, would it be legal XML to do something like:

<openPanoramaTour>
  <viewerDescription><!-- dynamics, custom toolbar and reference to initial
pano here //--></viewerDescription>
  <openPanorama src="singlePano.xml"></openPanorama>
  <openPanorama><!-- 'inline' panorama node with all the bells and whistles
//--></openPanorama>
</openPanoramaTour>

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

> Why not. In my mind, most of those parameters was in the XML file which
> describe viewer parameters (the GUI).

Ah, but it is much more than just a GUI. GUI elements CAN be part of it, but
GUI elements should also be attacheable to single panoramas in a tour. Eg
when you have different floors in a realestate tour, you want different maps
for different panos. The toolbar would probably be the same for each pano.
As would camera-dynamics etc, so it would be sort-off logical to have the
common GUI elements and the common viewer characteristics bound together
in the viewerDescription node.

Come to think of it... The viewerDescriptionNode could be a sort of sticky
openPanorama node. It can have most of the openPanorama node's tags, but
its tags are overridden automatically if they are specified in the current
panorama.
It could even be usefull to specify a flatImage node in this
viewerDescription, to
add a 'tripod-cap' in each pano in the tour.

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

> Here there is a problem with XML Specifications. Entrypoint and limits
> can be set only one time in a panorama.
> But in the body, it's not possible to allow more than one <flatImage>,
> for example, and only one <limits> without having to list all node in a
> specific order... If someone know a way to do that, his help is welcome.

Ok, so I'm new to XML... but I really don't understand this limitation. Why
would <flatImage> and <limits> be bound together?

> >* rename entryPoint node
> >defaultView would be a better name for this node:

> I was thinking that the default view have to be used when the panorama
> is not open from an other panorama hotspot. When it's from a hotspot,
> the north angle is used to keep the same direction of the view. I think
> that if the designer want to specify a specific point of view when it
> comes from a specific hotspot, he can use the srcipting language to do
> exactely what he want.

Ok, then what's the current entryPoint node for?
By the way, I like the way the direction is kept between two panos, but
what if the author didn't specify the orientation of each panorama (eg
didn't
have GPS). If he/she also didn't specify an entryView going from one pano
to another (hotspot), then the defaultView (now entryPoint) would be used.

I think scripting should be kept to a minimum.

> >* 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.
> >
> >
> I understand what you want, but I think it's not really the best
> solution. You need the rectangle child for diffrent reasons:
>     - you can have more than one face per image

So you need to define images seperately from faces that use them.
Is it possible to do something like the VRML statement USE in
XML? In VRML you could define eg an image once, and USE it
from there.

>     - the position of the image can't be set with only a pan tilt and
> fov angle in many cases (need roll and other things)

Ok, so you need
<panoImage type = "rectangular" fov = "90" pan = "0" tilt = "0" roll="0"
fall="0" twist="0">
Where roll, fall and twist are optional. Fall and twist are my own terms for
the image
falling over (rotating on it's horizontal axis) or twisting (rotating on
it's vertical axis).
Perhaps there are better terms.

>     - using pan til and fov floating point approximation angles may
> create bad stitching between faces  in a cube, for example, and can
> create bad lines betweentwo faces. (I hope what i've try to explain is
> clear).

Ok, point somewhat taken. I still favor my solution. Letting the author
specify
4 vertices will only lead to non-planar rectangles etc. Lots of hassle.

The way of specifying the rectangular image using pan, tilt and roll is akin
to
the way Panotools lets you work with extracted images.

BTW, I'ld suggest a fourth panoImage type: cubic
cubic would be a shortcut for 6 rectangular images. It would take one image,
which
combines 6 faces in a specific order (eg front, right, back, left, bottom,
top in a horizontal
strip). In its implementation, this type could add some safeguards against
seams.

Inserts within a panorama are less prone to show seams, as they either
include part of the
panorama, or they have some sort of transparency to hide the seam.

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

> For me it was a mask, because it can be used as mask image too to
> display mouse over images for example... but why not..

Ah, could you explain how your mouse over images work? You have a grayscale
hotspot
index image (which can have 256 - 1 hotspots defined), but only one mouse
over image...
Do you have a demo somewhere?

...or you could just tell me to RTFM if you've explained it there ;-)

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

> For this part I was thinking that creating an openpanorama image file
> format (ex: a zipped file with xml informatios in and an image and a
> mask image ) may be a good idea. I think that the alpha channel must be
> in the image (with our own file format, or a format which natively got
> it like PNG)

I vote for PNG. We don't really want to create more fileformats. Just didn't
think of PNG.

> >* why require the mimetype for images?
> >Is this a common XML requirement? If so, I don't like it!

> Because, if it can be an image,it can any other thing. Maybe, it can be
> a 3D object, a movie, or any other media. For example, the object to
> display may be a 3D object (vrml).

Ok, but why not depend on the mimetype the server is giving? Or on the
file's extension, or on the contents of the file (ok, point taken on the
contents
of the file, that would be a hassle)

'do

PS: is there an archive for the list?
PPS: how large IS this list? Is there anybody else out there?