Initial revision

1 files changed, 200 insertions, 0 deletions

diff --git a/Demo/sgi/video/cmif-film.ms b/Demo/sgi/video/cmif-film.ms
new file mode 100755
index 0000000..aa114d9
--- /dev/null
+++ b/Demo/sgi/video/cmif-film.ms
@@ -0,0 +1,200 @@
+.de PP
+.LP
+..
+.de pT
+.IP \fB\\$1\fP
+..
+.TL
+CMIF video file format
+.AU
+Jack Jansen
+(Version of 27-Feb-92)
+.SH
+Introduction
+.PP
+The CMIF video format was invented to allow various applications
+to exchange video data. The format consists of
+a header containing global information (like data format)
+followed by a sequence of frames, each consisting of a header
+followed by the actual frame data.
+All information except pixel data is
+encoded in ASCII. Pixel data is \fIalways\fP encoded in Silicon Graphics
+order, which means that the first pixel in the frame is the lower left
+pixel on the screen.
+.PP
+All ASCII data except the first line of the file
+is in python format. This means that
+outer parentheses can be ommitted, and parentheses around a tuple with
+one element can also be omitted. So, the lines
+.IP
+.ft C
+.nf
+('grey',(4))
+('grey',4)
+'grey',4
+.LP
+have the same meaning. 
+To ease parsing in C programs, however, it is advised that there are
+no parenteses around single items, and that there are parentheses around
+lists. So, the second format above is preferred.
+.PP
+The current version is version 3, but this document will also explain
+shortly what the previous formats looked like.
+.SH
+Header.
+.PP
+The header consists of three lines. The first line identifies the file
+as a CMIF video file, and gives the version number.
+It looks as follows:
+.IP
+.ft C
+CMIF video 3.0
+.LP
+All programs expect the layout to be exactly like this, so no
+extra spaces, etc. should be added.
+.PP
+The second line specifies the data format. Its format is a python
+tuple with two members. The first member is a string giving the format
+type and the second is a tuple containing type-specific information.
+The following formats are currently understood:
+.pT rgb
+The video data is 24 bit RGB packed into 32 bit words. 
+R is the least significant byte, then G and then B. The top byte is
+unused.
+.IP
+There is no type-specific information, so the complete data format
+line is
+.IP
+.ft C
+('rgb',())
+.pT grey
+The video data is greyscale, at most 8 bits. Data is packed into
+8 bit bytes (in the low-order bits). The extra information is the
+number of significant bits, so an example data format line is
+.IP
+.ft C
+('grey',(6))
+.pT yiq
+The video data is in YIQ format. This is a format that has one luminance
+component, Y, and two chrominance components, I and Q. The luminance and
+chrominance components are encoded in \fItwo\fP pixel arrays: first an
+array of 8-bit luminance values followed by a array of 16 bit chrominance
+values. See the section on chrominance coding for details.
+.IP
+The type specific part contains the number of bits for Y, I and Q,
+the chrominance packfactor and the colormap offset. So, a sample format
+information line of
+.IP
+.ft C
+('yiq',(5,3,3,2,1024))
+.IP
+means that the pictures have 5 bit Y values (in the luminance array),
+3 bits of I and Q each (in the chrominance array), chrominance data
+is packed for 2x2 pixels, and the first colormap index used is 1024.
+.pT hls
+The video data is in HLS format. L is the luminance component, H and S
+are the chrominance components. The data format and type specific information
+are the same as for the yiq format.
+.pT hsv
+The video data is in HSV format. V is the luminance component, H and S
+are the chrominance components. Again, data format and type specific
+information are the same as for the yiq format.
+.pT rgb8
+The video data is in 8 bit dithered rgb format. This is the format
+used internally by the Indigo. bit 0-2 are green, bit 3-4 are blue and
+bit 5-7 are red. Because rgb8 is treated more-or-less like yiq format
+internally the type-specific information is the same, with zeroes for
+the (unused) chrominance sizes:
+.IP
+.ft C
+('rgb8',(8,0,0,0,0))
+.PP
+The third header line contains width and height of the video image,
+in pixels, and the pack factor of the picture. For compatability, RGB
+images must have a pack factor of 0 (zero), and non-RGB images must
+have a pack factor of at least 1.
+The packfactor is the amount of compression done on the original video
+signal to obtain pictures. In other words, if only one out of three pixels
+and lines is stored (so every 9 original pixels have one pixel in the
+data) the packfactor is three. Width and height are the size of the
+\fIoriginal\fP picture.
+Viewers are expected to enlarge the picture so it is shown in the
+original size. RGB videos cannot be packed.
+So, a size line like
+.IP
+.ft C
+200,200,2
+.LP
+means that this was a 200x200 picture that is stored as 100x100 pixels.
+.SH
+Frame header
+.PP
+Each frame is preceded by a single header line. This line contains timing information
+and optional size information. The time information is mandatory, and
+contains the time this frame should be displayed, in milliseconds since
+the start of the film. Frames should be stored in chronological order.
+.PP
+An optional second number is interpreted as the size of the luminance
+data in bytes. Currently this number, if present, should always be the
+same as \fCwidth*height/(packfactor*packfactor)\fP (times 4 for RGB
+data), but this might change if we come up with variable-length encoding
+for frame data.
+.PP
+An optional third number is the size of the chrominance data
+in bytes. If present, the number should be equal to
+.ft C
+luminance_size2*/(chrompack*chrompack).
+.SH
+Frame data
+.PP
+For RGB films, the frame data is an array of 32 bit pixels containing
+RGB data in the lower 24 bits. For greyscale films, the frame data
+is an array of 8 bit pixels. For split luminance/chrominance films the
+data consists of two parts: first an array of 8 bit luminance values
+followed by an  array of 16 bit chrominance values.
+.PP
+For all data formats, the data is stored left-to-right, bottom-to-top.
+.SH
+Chrominance coding
+.PP
+Since the human eye is apparently more sensitive to luminance changes
+than to chrominance changes we support a coding where we split the luminance
+and chrominance components of the video image. The main point of this
+is that it allows us to transmit chrominance data in a coarser granularity
+than luminance data, for instance one chrominance pixel for every
+2x2 luminance pixels. According to the theory this should result in an
+acceptable picture while reducing the data by a fair amount.
+.PP
+The coding of split chrominance/luminance data is a bit tricky, to
+make maximum use of the graphics hardware on the Personal Iris. Therefore,
+there are the following constraints on the number of bits used:
+.IP -
+No more than 8 luminance bits,
+.IP -
+No more than 11 bits total,
+.IP -
+The luminance bits are in the low-end of the data word, and are stored
+as 8 bit bytes,
+.IP -
+The two sets of chrominance bits are stored in 16 bit words, correctly
+aligned,
+.IP -
+The color map offset is added to the chrominance data. The offset should
+be at most 4096-256-2**(total number of bits). To reduce interference with
+other applications the offset should be at least 1024.
+.LP
+So, as an example, an HLS video with 5 bits L, 4 bits H, 2 bits S and an
+offset of 1024 will look as follows in-core and in-file:
+.IP
+.nf
+.ft C
+	  31         15    11 10 9 8  5 4   0
+         +-----------------------------------+
+incore   +               0+ 1+  S +  H +   L +
+         +-----------------------------------+
+                                  +----------+
+L-array                           +  0 +   L +
+                                  +----------+
+                     +-----------------------+
+C-array              +   0+ 1+  S +  H +   0 +
+                     +-----------------------+