(FYI - ILM considers OpenEXR to be a big failure. They've gotten pretty much zero contributions back from anybody. It's only take take take. It still helps ILM because they're getting most other packages to implement the format so they can make their pipeline more unified, but whether that was more or less effort that open sourcing the package in the first place is subject to debate).
Speak for yourself, it is simply not true that ILM considers OpenEXR to be a failure of any kind. We have received contributions from the open source community. The initial version of OpenEXR didn't support Win32, for example, yet 3 days after we released it, there was a port to Win32 which we later incorporated into the main code base.
Billy Biggs has written a useful collection of OpenEXR tools and made them available as open source.
Cinepaint supports the format and there's at least one other open source project which, last I talked to them, is rewriting its entire image processing pipeline to deal with floating-point pixels, inspired in part by OpenEXR.
Pixar donated code for a new compressor to the project and made it available under our modified BSD-like license.
I will admit that I would have liked to see more VFX houses following Pixar's lead and making contributions, esp. in the form of plugins for various commercial packages, but overall I'm very happy with the support we've gotten from the community in general. Many commercial packages support the format now, or will in their next version, so that's basically a moot point now, anyway.
OpenEXR's success as an open source project isn't judged solely on the number of contributions made, either; it's really all about its acceptance in the industry, and it's doing pretty well in that category. There were several goals in releasing OpenEXR as open source. The main one, from ILM's perspective, was to get support from commercial packages so we didn't have to write and maintain our own plugins. That's already happening, and that alone will save more developer time in the long run than it took to package OpenEXR as an open source project.
Another positive, yet unforseen, outcome that's shaping up is interest in using OpenEXR as an exchange format between post houses. This is something that ILM is currently working on, with valuable input from the community. There was a BOF covering this topic at SIGGRAPH; the initial proposal can be found here. In today's climate of multiple post houses working simultaneously on movie productions, exchanging files and managing color information between houses is a big PITA. There's a lot of excitement about using OpenEXR for this and, in the process, preserving HDR data, which is not possible with DPX (not to the extent that it is with OpenEXR, anyway). Something like this wouldn't have been possible if we hadn't open-sourced OpenEXR.
So, in summary, it's simply not true to say that ILM considers OpenEXR to be a "big failure." We regard it as a pretty big success.
1. Installed Debian i386 unstable in a chroot on my Debian amd64 unstable machine. 2. Installed Cedega in the chroot. 3. Installed the Nvidia 6106 x86-64 drivers and copied the 32-bit OpenGL libs to the i386 chroot. 4. Installed Battlefield 1942, including the Desert Combat and Forgotten Hope mods, using Cedega in the chroot.
It plays great on my Quadro FX 4000, not just vanilla BF1942, but also DC and FH -- pretty impressive considering it's running a 32-bit Windows binary using 32-bit OpenGL drivers using a 64-bit Nvidia driver on a 64-bit kernel. Kudos to Transgaming, Nvidia, and the Debian project.
I'd much rather see a native port of BF1942 to GNU/Linux, though.
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.
You're right, tiling support is missing. We've been able to get away without it because we don't typically work in tiles.
You can load the image in pieces using the FrameBuffer object, but it's scanline-oriented, not tiled. Dunno if apps can get away with that or not.
Does Shake actually load the original file-based image in tiles, or does it simply tile its internal representation of the image and page that out to/from disk?
Sorry, the README.OSX in the distribution is misleading. I didn't mean to say that shared libs are not supported by OS X. I meant to say that the OpenEXR build system can't build them correctly yet. It's my fault, not OS X's, for not having had time to figure out how to build shared libs using autoconf in OS X.
I'm sure somebody will port it to Windows in time. The libraries themselves are pretty vanilla code, so it should be easy to port. We don't really use Windows for effects work here so it hasn't been a priority for us.
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.
Slashdot Mirror
furiousgeorge wrote:
(FYI - ILM considers OpenEXR to be a big failure. They've gotten pretty much zero contributions back from anybody. It's only take take take. It still helps ILM because they're getting most other packages to implement the format so they can make their pipeline more unified, but whether that was more or less effort that open sourcing the package in the first place is subject to debate).
Speak for yourself, it is simply not true that ILM considers OpenEXR to be a failure of any kind. We have received contributions from the open source community. The initial version of OpenEXR didn't support Win32, for example, yet 3 days after we released it, there was a port to Win32 which we later incorporated into the main code base.
Billy Biggs has written a useful collection of OpenEXR tools and made them available as open source.
Cinepaint supports the format and there's at least one other open source project which, last I talked to them, is rewriting its entire image processing pipeline to deal with floating-point pixels, inspired in part by OpenEXR.
Pixar donated code for a new compressor to the project and made it available under our modified BSD-like license.
I will admit that I would have liked to see more VFX houses following Pixar's lead and making contributions, esp. in the form of plugins for various commercial packages, but overall I'm very happy with the support we've gotten from the community in general. Many commercial packages support the format now, or will in their next version, so that's basically a moot point now, anyway.
OpenEXR's success as an open source project isn't judged solely on the number of contributions made, either; it's really all about its acceptance in the industry, and it's doing pretty well in that category. There were several goals in releasing OpenEXR as open source. The main one, from ILM's perspective, was to get support from commercial packages so we didn't have to write and maintain our own plugins. That's already happening, and that alone will save more developer time in the long run than it took to package OpenEXR as an open source project.
Another positive, yet unforseen, outcome that's shaping up is interest in using OpenEXR as an exchange format between post houses. This is something that ILM is currently working on, with valuable input from the community. There was a BOF covering this topic at SIGGRAPH; the initial proposal can be found here. In today's climate of multiple post houses working simultaneously on movie productions, exchanging files and managing color information between houses is a big PITA. There's a lot of excitement about using OpenEXR for this and, in the process, preserving HDR data, which is not possible with DPX (not to the extent that it is with OpenEXR, anyway). Something like this wouldn't have been possible if we hadn't open-sourced OpenEXR.
So, in summary, it's simply not true to say that ILM considers OpenEXR to be a "big failure." We regard it as a pretty big success.
-dwh-
A few days ago I did the following:
1. Installed Debian i386 unstable in a chroot on my Debian amd64 unstable machine.
2. Installed Cedega in the chroot.
3. Installed the Nvidia 6106 x86-64 drivers and copied the 32-bit OpenGL libs to the i386 chroot.
4. Installed Battlefield 1942, including the Desert Combat and Forgotten Hope mods, using Cedega in the chroot.
It plays great on my Quadro FX 4000, not just vanilla BF1942, but also DC and FH -- pretty impressive considering it's running a 32-bit Windows binary using 32-bit OpenGL drivers using a 64-bit Nvidia driver on a 64-bit kernel. Kudos to Transgaming, Nvidia, and the Debian project.
I'd much rather see a native port of BF1942 to GNU/Linux, though.
It was called "EXR" internally until we open-sourced it. Now that it's freely available under a modified BSD license, we call it OpenEXR.
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.
You're right, tiling support is missing. We've been able to get away without it because we don't typically work in tiles.
You can load the image in pieces using the FrameBuffer object, but it's scanline-oriented, not tiled. Dunno if apps can get away with that or not.
Does Shake actually load the original file-based image in tiles, or does it simply tile its internal representation of the image and page that out to/from disk?
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.
Sorry, the README.OSX in the distribution is misleading. I didn't mean to say that shared libs are not supported by OS X. I meant to say that the OpenEXR build system can't build them correctly yet. It's my fault, not OS X's, for not having had time to figure out how to build shared libs using autoconf in OS X.
I'm sure somebody will port it to Windows in time. The libraries themselves are pretty vanilla code, so it should be easy to port. We don't really use Windows for effects work here so it hasn't been a priority for us.
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.
This "event" is so ridiculous, it has prompted me to post to slashdot for the first time ever.
I would have expected something this lame out of a site like AntiOnline, or mtv.com, but slashdot? Please....
Interview somebody interesting next time, and maybe I'll care.
-dwh-