Slashdot Mirror
Lucas Digital Releases OpenEXR Format
frankie writes "Although George Lucas may have gone over to the dark side, at least some of his staff prefer Freedom and light. ILM has released OpenEXR, a graphics file format and related utilities, under a BSD-style license. Among other things, it supports the same 16 bit format used by Nvidia CG and the Geforce FX. OpenEXR runs on Linux, Jaguar, and Irix; other platforms are likely to work with a little help from the community."
it's www.openexr.com, not 'www.openexr'. Sigh.
The original poster should have given the correct operating system name, MacOS X.
# DO THE MATH! #
Actually, he did, since this is the first time that ILM or any other Lucas Digital company has released source code for free.
It was a group of developers who first floated the idea, but ultimately it was George's call whether or not to do it, and he gave the OK, which is pretty cool, I think.
Before you spend a half-hour downloading any packages, please note that shared libraries aren't supported yet for Mac OS X version 10.2.
Well, to rephrase this, you can build them, but Lucasfilm have't gotten them to link due to undefined symbols and are probably
doing something wrong in the Makefile system.
The test suite will automatically try to link shared libraries if you've built them, so 'make check' will fail. To run the confidence tests, tell configure not to build shared libraries ("./configure --enable-shared=no").
More details are available in the README document.
Reply or e-mail; don't vaguely moderate. Ex-O'Reilly/MIT employee, now a full-time Google employee.
I wish there was some there was some way that I could be outside playing basketball, in the rain, and not get wet.
It's not a show-stopper but tiling really ought to be there. This format doesn't really add much to already existing formats and subtracts something important.
Doesn't it make you feel good to know that our freedoms are protected by politicans, lawyers and journalists.
I believe the parent is Drew Hess - who packaged and maintains the source for OpenEXR.
Hello Drew, and thanks for all the fish.
We submitted an OpenEXR plugin to the Film Gimp team, and I understand it'll show up in the next release.
Also, Idruna Software is working on OpenEXR support for their Photogenics package. It already supports creation of and painting on HDR formats.
16 bit float is just one of the datatypes it supports. The particular format they chose is not limited to Cg or the GeForceFX, it's the most common 16 bit float format out there, even if it isn't an IEEE standard.
The DirectX HLSL is (deliberately) syntacticly identical to Cg, so that's actually good for Cg, rather than killing it off as you suggest. OpenGL2's HLSL has yet to be confirmed, but if (as may be likely) it isn't also just like Cg, Cg will still be able to compile to OpenGL2 - it's just another render target, along with DX8/9, OpenGL 1.3/1.4, and nVidia's own extensions.
HDR info is useful for many many things in both 3D and 2D work (though I'm doubtful about edge detection). Other HDR-supporting formats do exist, including HDRI, TIFF, FLX, and RLA. Even Cineon/DPX supports limited HDR info. Each have their own advantages & disadvantages - OpenEXR is no worse than most, and better than many.
Rendering technique is only one small part of the whole job. If you want to take HDR info from one device/app/system to another, you have to write it into a file, so you need a file format that won't clip all your highlights...
Why would anyone engrave "Elbereth"?
It is VERY different.
.00000006 and 65000 (and also zero).
A 16 bit (unsigned) integer value has a range of 0 to 65535, in 1 unit increments.
A 16 bit floating point (half) value has a range between about
The nice thing about floating point numbers is that you can use the precision that it gives you in the most optimal way for your image whereas with integer values, the precision is spread out evenly over your entire range of values.
In the high range of floating point values (highlights), distances between discrete values will be large. In the low range, they will be small (shadows). Since the eye (and film) is not a linear light sensor (they are close to logarithmic), it makes more sense to deal with pixel values that are floating point instead of integer.
FP numbers to work with when you're doing image manipulation, since scaling up the data-type size (32 bit floating point) leaves you with data where 0.0 (black) and 1.0 (white), for example, have exactly the same meanings, but you now have extra precision for doing intermediate work on the pixel values. If you shift from a 16 bit integer, to 32 bit integer data type, the values of 0 and 1, for example, now have very DIFFERENT meanings, since the value of 'white' for the 32 bit pixel will have to be shifted upwards to take advantage of extra precision.
There are a whole series of advantages, though I'm not sure I've stated them well here. Go to their web site for more information, obviously.
Interesting. Thanks for the informative explanation!
main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
A film scanner like the ones used at VFX houses can produce material with up to 14 bits per channel of color resolution. So can Panoscan's MK1 HDR camera. For reasons outlined in another thread, there are advantages to using FP numbers rather than integers to represent these values.
The CCDs used in these devices are pretty expensive and aren't available in pro-sumer or consumer devices. For now.
Apps like Idruna's Photogenics, Paul Debevec's HDRShop, and Greg Ward's Photophile can produce HDR FP images from scans of photos of the same scene using different exposures. This works with the cheap color scanner that you bought at Fry's or Best Buy.
As for synthetic images, Renderman, Mental Ray use 32-bit FP internally. They can already produce 32-bit TIFF images. We're working on making the OpenEXR display drivers for these apps available with the rest of the OpenEXR software distribution.
Check out Paul Debevec's web site. He seems to have pioneered (correct me if I'm wrong) a lot of image-based rendering techniques. HDR images are an important part of this. He describes how to recover HDR images from photographs, how to create "light probes" (HDR environment maps), and then how to light synthetic scenes with a light probe.
In fact tiles are a complete hinderance to modern programs that want to access arbitrary rectangles of the image and not obey some predefined cutting into tiles. For these programs, "tiles" like in tiff files require reading the entire image into memory before any of it can be returned, completely inverting the entire purpose of tiles. In the software I am writing our tiff reader refuses any tiled tiffs (ie it only accepts files that are one big tile) and we have yet to encounter any tiff that is not just one big tile.
Many modern programs "tile" the image by cutting it into scan lines or groups of scan lines, which you could consider long narrow tiles. But this requires no special support by the file other than storing the pixels in horizontal order.