From: rasure@sherman.eece.unm.edu (John Rasure)
Newsgroups: comp.soft-sys.khoros
Subject: Re: Khoros 2.0 viff structure
Date: 15 Aug 92 03:47:45 GMT


In "Khoros 2.0 viff structure", Geir Atle Storhaug writes:
+ This is a follow up to something John Rasure wrote back on Wed Jun 3 1992
+ In "Re: Sequences under Khoros 2.0 ? and RGB-mult...", he writes:
+ 
+ .... stuff deleted
+ > The num_of_images in the viff of 1.0 is not supported.   Khoros 2.0 has
+ > a much better viff structure.  Because of the interest in it, I will
+ > put an ftpable copy of it on pprg in a week or so.  I want to make a few
+ > more changes to support geometry (for scientific viz and rendering) and
+ > then I will put it out for review.
+ .... stuff deleted
+ 
+ Where can I find the file describing the viff structure in Khoros 2.0?

I just made a design modification to support geometry, and don't want to
be embarrassed by it before a few people have a chance to look at it.

So, if in a week or so, if you ask me again where it is, I will tell you
where to ftp if from.

+ 
+ The main items on my wishlist are:
+ 
+  - The viff structure should be able to store multiband sequences where
+    the bands have different sizes and pixeltypes.

Oooops.  That won't be available, that is the different sizes part.  We
have a general solution for this via a VIFF 2.0 extension that will come
available after the release of Khoros 2.0.  And that is that we allow
for an arbitray data structure instead of pixel vectors.

+ 
+  - I don't think it is possible to create a set of headers which suites
+    everyone. Therefore I think it should be easy to include additional
+    information in the headers. We need tools (e.g. designers, editors,
+    browsers, libraries) to make it easy to create and maintain these
+    headers. It is important that it is possible to store additional
+    information in:

This is true, and we address this in two ways.  First we will support
"add your own tags" for bringing allong application specific information.

Second, we have an abstract data type implemented via a data services layer.
This is the layer that you will use, not direct access to VIFF.  This implies
that you can choose your own complete data representation and put it
under the data services layer.

+     a) The file header: Used for information common to all bands and all
+        pictures in a file (e.g. date and place of recording etc.).
+     b) The band headers: Used for information specific for this band,
+        but common to all pictures in the file (e.g. camera and lens type
+        used for this band).

Hmmm, sounds like you want to support band grouping, much in the same way
geometry people use hierachy for geometry primitives.

+     c) The picture headers: Used for information specific for this
+        picture, but common to all bands in this picture (e.g. GPS/Navstar
+        position, speed, heading etc. when this picture was recorded).
+     d) In headers which stores information for ONE band on ONE picture (e.g.
+        information about video gain and offset).
+ 
+  - An (optional) automatic history recording in the viff headers. The idea
+    is that an image should remember its origin and all operations which has
+    been performed on the image.
+ 
+  ____     ___   Geir Atle Storhaug
+ / ____/\ (__    storhaug@ndre.no
+ \___//  \___)   Phone: +47 6 807658 (office)     +47 6 838987 (home)
End of message from Geir Atle Storhaug