Re: [Openpanorama-info] Re: preliminary comments/suggestions

[Mathieu VILLEGAS]

Aldo Hoeben wrote:

> 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?
>  
OpenOffice don't open generic XML files. I know that Visual Studio .Net 
can open and edit easily XML files.

>  
>
> > > * 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>
      That's a good idea.

>  
>
> > > * 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.
I'm agree with you.

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

> It could even be usefull to specify a flatImage node in this
> viewerDescription, to
> add a 'tripod-cap' in each pano in the tour.
Hmmmm, I well understand what you want to do. I'ts a good Idea, but we 
have to see if it will not become too complex at the end.
I will see how to add simply such thing in specifications.

>  
>
> > > * 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?
>  
In a node, you have restrictions on the number or order of child node. 
You can't allow something to a child node without allowing it to an 
other one without having a restriction on the node order (it due to the 
diffrent sort of child node listing allowed in XML).

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

The goal of openpanorama is to be able to describe panorama, and be able 
to convert most known panoramas file format to openpanorama file format 
without loss of quality. FlatImage node is usefull for cubic panoramas, 
but it's very usefull for cylindric QTVR panoramas which use many flat 
images to describe it's cylinder. Maybe it can be possible to create a 
Cubic node, and keep flatimage node.
Maybe, being able to use 3D vertex or angles to set the position of the 
flatimage may be a good solution. I will work on it.

>  
>
> > > * 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 ;-)
>  
I'm working to an easy to understant docuement which describe all 
panorama formats, hotspots, etc... I think that I will explain it in 
(with pictures), so it will be easy to understand.
I'm sorry, I don't know what RTFM means.

>  
>
> > > * 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.
>  
   The PNG is a good idea, but not really the good way for Java 
viewers, because I think that most of the JVM's do not support 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)
It's a choice we have to do. For a programmer, having the mime type in 
the file is more easy, but it's possible to use the extension.
For the server, it's not a good idea, because you can open you panorama 
from your hard disc.

> 'do
>
> PS: is there an archive for the list?
http://mail.gnu.org/archive/html/openpanorama-info/

> PPS: how large IS this list? Is there anybody else out there?
There is  approximately 20 persons at this time. It's only the 
beginning, and we still have many work to do.

Regards

Mathieu

> _______________________________________________
> Openpanorama-info mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/openpanorama-info
>
>
>