diff options
Diffstat (limited to 'Demo/sgi/video/cmif-film.ms')
| -rwxr-xr-x | Demo/sgi/video/cmif-film.ms | 200 |
1 files changed, 0 insertions, 200 deletions
diff --git a/Demo/sgi/video/cmif-film.ms b/Demo/sgi/video/cmif-film.ms deleted file mode 100755 index aa114d9..0000000 --- a/Demo/sgi/video/cmif-film.ms +++ /dev/null @@ -1,200 +0,0 @@ -.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 + - +-----------------------+ |