openexr-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Openexr-user] Questions for more experienced users


From: Florian Kainz
Subject: Re: [Openexr-user] Questions for more experienced users
Date: Thu, 22 Feb 2007 14:52:02 -0800
User-agent: Mozilla Thunderbird 1.0 (X11/20041207)

ben Grossmann wrote:
> I have a few questions that maybe you would know about the "real-time"
> aspect of reading and writing Open EXRs.
>
> Writing:
> You mention that the encoders are too slow to run in real-time on
> "affordable hardware".
> Does this mean that they could run in real time in "not-so-affordable
> hardware?"  After all, cameras themselves are "not-so-affordable
> hardware", and there are manufacturers making specific hardware to
> write image data to different formats, so maybe it's not unreasonable
> that we could do this.

I don't know if it would be possible to build a hardware PIZ compressor.
More complicated algorithms have been implemented in hardware, so guess
the answer is "yes."

However, as I mentioned in my original mail, lossless compression may
not be particularly useful for a real-time system, which must maintain a
fixed frame rate.  With lossless compression the size of the compressed
data changes, and sufficiently random-looking images would not compress
at all.  In order to avoid choking on those worst-case images, a recording
system would have support the same data rate as what you'd need for
uncompressed images.  If you can already handle that data rate, then you
might as well record uncompressed images and avoid spending money for the
compression hardware.

If you were recording to a hard disk or similar medium, then compression
would save space, but this wouldn't be the case for a tape drive running
at constant speed.  The tape would have to run fast enough to handle the
worst-case data rate; images that compress well would simply leave some
of the tape's storage capacity unused.

> Reading:
> I lack the knowledge of the format to understand if this is possible.
> Since you can store multiple resolutions "Rip/Mip maps" of an image,
> is it possible to read those lower resolutions without pulling and
> loading all the other data in the file?  If that was the case, then
> conceivably you could have real-time playback with the maximum
> resolution your hardware can support.

Yes, you can read the lower resolutions without loading the rest of the file.

A mip-mapped OpenEXR file is 33% larger than a single-resolution file,
and the data rate required for real-time recording increases correspondingly.
(Some file formats, for example JPEG2000, use a clever compression method
that allows you to extract a lower or higher resolution image depending on
how much of the file you read.  Such a multi-resolution file is no larger
than an equivalent single-resolution file.  Explicitly storing the lower-
resolution levels makes OpenEXR files larger, but the multi-resolution capability becomdes independent of the compression method, and image
writers have full control over the content of the lower-resolution images.
The writer may have specific requirements for filtering, subsampling and
treatment of edges.

> Other Advantages:
> In addition to the dynamic color range and luts, I think that a day
> will soon come where the other metadata for camera transforms, lens
> info, chip profiles, scene/take info, etc. could be written into the
> image capture, or syncronized with it at a slightly later time, so
> that it is all accessible throughtout the pipeline without tracking
> several different types of data for each image.
>
> I know it seems unweildy now, but having all this information part of
> the same basic file is certainly a natural evolution for the future of
> the format.  I'm wondering how far away it really is....Particularly
> given ILM's proposal for color management, we need formats that can
> store this basic input/output profile information.

One of the tasks of the Academy of Motion Picture Arts and Sciences'
Image Interchange Framework committee is to figure out how to store,
use and exchange the kind of metadata you mentioned above.  The recently
released Color Transformation Language is a first step in this direction.
(See http://www.oscars.org/council/ctl.html)




reply via email to

[Prev in Thread] Current Thread [Next in Thread]