openexr-user
[Top][All Lists]
Advanced

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

[Openexr-user] Questions for more experienced users


From: ben Grossmann
Subject: [Openexr-user] Questions for more experienced users
Date: Sun, 18 Feb 2007 15:53:17 -0800

Hello all!

There is currently a thread on the Cinematographer's Mailing List
discussing the viability of OpenEXR as a capture format, and there
presently is a vaccuum of "informed" debate.  I would very much like
to get some concrete answers or theorys back into that thread as a
means of encouraging camera developers to consider the advantages of
Open EXR.

http://ls.cinematography.net/read/messages?id=124861
In the "cml-2k-444" forum.

I am posting much of the body of a post below where I tried to point
out some of the advantages of Open EXR over the existing formats, and
would love if anyone could either participate in the discussion on
CML, or give me some answers to the following speculation.  I don't
know enough about it to speak with authority.

Thanks so much for your help!

Ben Grossmann
address@hidden

<QUOTE>
Specifically to Open EXR, There are specs in that format (viewable at
openexr.org) to allow for a lot of things that appear very good to me.

The format can contain multiple resolutions of an image.  Ignoring
file size implications for a moment,  it seems to me that the
advantage of having multiple resolutions in the same format, is to
allow them to play back faster on machines that can't handle the full
resolution.    As it stands now in the spec, each file can contain
variations on resolution.  If those resolutions can be pushed to the
player individually, then that solves the "realtime" conundrum.
Machines that need to see it realtime, but can only support it at
half-res, get it that way.  Machines (Probably with fast raids and
good graphics cards) that can support playing it back at full-res, can
do so.  I do NOT know that this is actually the case, so it would be
good to hear from a developer who knows.

The format can support Scanline Images AND Tile-based images.  And it
supports a function to adapt compatibility in case the player doesn't
support one or the other.  This way, you don't have to load an entire
image just to see a specific region at full resolution.  Tile-based
image formats are common in extremely high resolution imagery, like
satallite and Library of Congress Archives.  They allow you to look at
a portion of an 100,000K image without having to load the full
100,000K image into ram, so it seems conceivable to me that you could
have a full aperture image file on disc, but only be pushing the
director's 2.35 image data to the viewer.  Again, this is outlined in
the spec, but I do NOT actually know how it works.

The format maintains a repository of consistent naming conventions for
the auxilliary channels which can be added to as necessary, and they
encourage user to maintain these standards as much as possible rather
than trying to develop their own proprietary channels tags, to
maintain format compatibility.  But they accomodate additional
arbitrary channel identifiers.

The format supports a mind-blowing exposure latitude.  There is a demo
image on the website called "Ocean.exr" that, when viewed in an
appropriate player in float (Like After Effects) will rock your world.
You could never dream to get this range in a 16bit DPX.   And if you
DON'T have this exposure information, or couldn't capture it, then
you're not storing data for it, so the file size is only as big as the
data you're trying to preserve.  Again, someone with more knowledge of
the format can probably clarify this.

I am posting this information to the OpenEXR mailing list to see if
anyone there can answer these questions, and then I'll post back a
digest of the responses.

ben grossmann
vfx supervisor
the syndicate
santa monica, ca

</QUOTE>




reply via email to

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