CDO@ibm-b.rutherford.ac.UK ("C D Osland 0235 44-6565", CDO at UKACRL) (03/21/91)
It is interesting to see that others ARE using CGM for the production
of videos.
I am dismayed to see people proposing formats like
320x200 for a library of video pictures. In analogue form PAL is
768 wide by 576 high and I believe NTSC must be 648 by 486 high.
These 'pixels' are square. In digital form (CCIR 601, 4:2:2 component
formar) the number of lines is preserved in both codings but the number
of samples along a line made the same (at 720) so that NTSC digital
'pixels' are 1:1.111 aspect ratio (portrait) and PAL 'pixels' ar
1:0.9375 aspect ratio (landscape).
Thus even current video standards are way above 320 by 200.
High definition TV is now pushing the number of lines into the
1100 to 1300 region and the change in the aspect ratio from 4:3
(both PAL and NTSC) to 16:9 accentuates the need for agreement on
a format for storing pictures that explicitly (and internally)
specifies the aspect ratio and addressing range. The CGM
does this, and so any shape pictures (square, 4:3, 16:9, 3:2 from
cine material) can be correctly rendered without externally
provided information.
As someone else pointed out, the CGM structure also provides for the
storage of picture sequences; this was an explicit part of the
scope of the project. To quote from the standard:
"The CGM provides a file format suitable for the storage
and retrieval of picture description information....
The main reasons for producing a standard computer graphics
metafile are:
a) to allow picture information to be stored in an organized way..
b) to facilitate transfer of picture information between
graphical devices
c) to enable picture information to be transferred between graphical
devices
d) to enable picture information to be transferred between different
graphics installations
CGM has never been 'just for GKS-like primitives';
a scanner can produce a CGM as its image file just as a plotter can
take a CGM as its input file. CGM does have the GKS primitives, for
use in situations in which the generator wishes to store the picture
in that form.
Incidentally, the CGM is explicitly designed so that random access
to frames is possible, without scanner earlier frames. That is not
true for many of the compressed formats being mentioned. This also
means that frames can even be played backwards! Try doing that with
a forward-compressed sequence!
Enough for now - I'll wait for the AAA
Chris Osland