DPX format status

As some of you know, I have been working for the past couple of months 
to support the SMPTE DPX format, which is used uncompressed motion 
film images.  Sometimes these are used for "digital intermediates", 
which are used to as the master for the final film print (film -> DPX 
image -> film) and other times they are used to master DVDs. 
Information on typical equipment which produces these images may be 
found at "http://www.grassvalley.com/products/film/spirit_4k/" or 
"http://www.filmlight.ltd.uk/northlight.html".

Progress has gone well.  The work is just about completed.  The latest 
GraphicsMagick 1.2 snapshot quite possibly supports more of the 
specification than any other available software.

Since the image data is uncompressed, and uses 10, 12, or 16 bits per 
sample, the images can be quite large.  Typical file sizes range from 
12MB to 131MB.  Most other image formats (except for perhaps TIFF) 
that GraphicsMagick deals with are compressed so more time is spent 
decompressing than reading the file data.  With DPX, the physical I/O 
rate to disk is the limiting factor.  Images are always growing 
larger.  Typical working image size has been 2K pixels across, but now 
4K images are starting to be used, and some equipment can produce 6K 
images.  Experts say that a 4K image is sufficient to capture all the 
detail a 35mm negative can produce.

GraphicsMagick uses memory-mapped access when reading files. In the 
case of DPX, reading is also "zero copy" access since the data is not 
double-buffered while reading.  When a file is read for the first 
time, the data rate may be only 6M pixels/second (or 1.2M 
pixels/second if the file is on a network) but it may read at 20M 
pixels/second thereafter.  Unfortunately, when processing thousands of 
files, it is more typical for each image to be read one time.  Some 
efficient and portable means needs to be found to cause the data to be 
read into memory as quickly as possible while allowing the 
GraphicsMagick read operation to turn it into useful pixels.  In other 
words, the data should be available in RAM shortly before 
GraphicsMagick accesses it so that the CPU is always busy.  The system 
should discard the data as soon as possible when it is no longer 
needed so the RAM can be used for the next image.

Bob
======================================
Bob Friesenhahn
[email protected], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click