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 [EMAIL PROTECTED] <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> _______________________________________________ Openexr-user mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/openexr-user
