Re: [Openpanorama-info] preliminary comments/suggestions

[Mathieu VILLEGAS]

Hello,

> 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 ;-)
>  
Most of the documents are simple though on the project. The xml example 
is the more interresting document.

> * 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
>  
I'm agree with this point. I'm trying to find the best way to have such 
system.
I've start working on a XML specification for a GUI, but it's not in the 
web site at this time, because there is many work to do on it.

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

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

> * 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.
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.
We have work on a little scripting language which can be easily used in 
a panorama... We will put our first though about it very soon.

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

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

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

> * 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!
>
>  
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). The viewer don't know what it is, it 
just know that it's vrml. It give the file to it's vrml viewer (If it 
find one) and just ask for a refresh of th image surface if necessary. 
With such system it's possible to include any type of  media in the 
panorama, and all openpanorama viewers will be able to open it (if the 
viewer don't find a plugin or player for the mime type, it do not open 
it, but can open all other images). An editor will be able to edit this 
panorama and cnahge it even if one of the image format can't be displayed...

> I think that's enough for now ;-)
>
> 'do
>  

Regards

Mathieu Villegaz