Slashdot Mirror

This is great, a similar thing happened with Open EXR which is an image file format for high end film production. ILM open sourced it and it was quickly picked up by other studios, which lead to the software companies implementing it.

It seems like it's a good route for the VFX companies to take. Open source tools that are useful, then they get implemented in the main software packages which reduces your costs of maintaining plugins and a lot of custom code.

Would someone who understands these issues please explain how this standard is similar and different to OpenEXR?

http://www.openexr.com/

http://en.wikipedia.org/wiki/OpenEXR

Is OpenEXR more computationally expensive? (In other words, would the Microsoft format allow for longer battery life and shorter time interval between taking pictures?)

Actually, are there any cameras available that can capture to OpenEXR? If not, perhaps that's a clue.

Do you know if he had anything to do with the development of the OpenEXR format?

EXR is a very specialized format used mostly in "film" (ie movie production.)

Huh? OpenEXR isn't particularly "specialized" (in fact it's pretty flexible) and it's what you want to be using if you're doing HDR photos.

[If it's currently used mostly in film production, that's more likely due to history and the fact that they're incredibly picky about image quality.]

...do you guys realise that an open source project received an Academy Award this year? I find it weird that it hasn't been reported much in the geek news outlets.

But you don't have to compress the full dynamic range just part of it (if you want that sort of pictures) or use "smart" compression that preserves contrast between objects in the image while extending the visible dynamic range (see http://www.cs.huji.ac.il/~danix/hdr/results.html). Also, having the "same" image with different exposures allows you to render an image that has as little under and/or over exposure as possible (see http://www.openexr.com/samples.html).

Not to mention color depth: 24 bit color is clearly inadequate for many uses, and formats like OpenEXR (one of the current best HDR image formats; it uses 48 bits per pixel, in the form of 3 16-bit "half floats") are gaining popularity. For some uses RGB isn't sufficient either, and you want samples at many more wavelengths.

As very many have already pointed out, that was indeed a crap article. I don't want to spend any time quoting it and going "WTF?!", but I *do* want to link to OpenEXR, which is a file format for managing HDR images. It typically uses 16-bit floating point numbers per pixel, which seems to give a decent brightness range. It's cool to watch the same image rendered using different levels of "virtual exposure". It's by Industrial Light and Magic, which some of you might have heard of. I have, of course, no affiliation with either, just wanted to link to something relevant.

1. Scan the film to individual images, preferably at 32 bits per color, Kodak's Cineon format will handle this or ILM's OpenEXR format (it's open source too).
2. Load frames onto harddisk
3. Edit each frame gamma, color corection, and dust-busting that's 24 frames per second, that's a lot of frames for a 30 minutes of film.
convert to a color-dept for encoding, then encoding/
4 do the menues
5 burn the DvD
in short a lot of work take a look at Cinepaint for the frame editing software.

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 of us from Frantic Films Software wrote up summary of SIGGRAPH 2004 for CgChannel this past Thursday. It touches on many of the same topics in a slightly different light -- although not at all on open source in the industry.

I understand that open source is a hard sell for VFX companies. Most specifically while at SIGGRAPH I heard Steve Sullivan from ILM speak (at a discussion panel) about how even though they have had many users of OpenEXR and wide community adoption of the technology they have had very few people from other VFX companies contribute back to its future development. Steve said that ILM pretty much had to write version 2.0 of OpenEXR by themselves. Thus in effect they have had the problem of many people free riding on their large effort.

Thus for us, while we do plan on releasing smaller tools open source (similar to some of my past open source projects: ExoEngine and Exocortex.DSP), ILM's experience with a large costly open source endeavor scares me away from trying this with a larger project -- at least for the time being.

-ben

I found this series to be a pretty big let down. I guess I was expecting too much, but I was hoping the author would go down the list of where digital doesn't live up to film as a call to action for camera makers and consumers. But no, the series for the most part just talks about existing digital camera features like autofocus and zoom lenses. Oh well.

I want to see some serious discussion about things like color gamut. The gamut of film (especially slide film) is much better than that of digital cameras. Is anyone working to improve the situation for digicams? There's a interesting looking article at extreme tech that talks about gamuts here.

Basically current sRGB devices don't cover the full range of colors which the human visual system can percieve (nor does film, but film comes closer than digital). Think of deep violet for instance. You simply can't get those hues on a monitor, and so today's digital cameras just don't record those colors. However, it is likely that some day we will have monitors and hardcopy ouptut devices that perform as well as the human visual system. So ideally the pictures I take today would have the full range of color information, even if they're forced to display only a subset of those colors on current display devices. That way, in the future when "uberdisplays" are available, my pictures from 2000 will still look nice, and not washed out and cheesy like color photographs from the 60's do today.

If you widen the gamut of CCDs, you'll probably want to add a few bits to each color channel as well -- use 12 bit color instead of 8 bit for instance.

And as long as you're adding bits, the other thing it seems like digital cameras could possibly offer some day is point-and-click high dynamic range (HDR) images, say in EXR format. Couldn't one build CDD sensors with automatic gain control (ISO) on a per-pixel basis, and then assemble the results into a HDR image? Currently the way to make HDR images is by taking several photos of the same scene and carefully merging them together, but that's pretty cumbersome.

With HDR images, you have much more flexibility to adjust the exposure and reveal detail in the shadows after taking the image.

What other cool things could digital cameras offer that would take us beyond simply replacing film cameras?

Yes, grain is a side effect of the mechanism. However, it's still important that it be preserved. I'm not talking about recording the value of every single grain on the negative; that'd be ridiculous. Rather, I'm talking about preserving the same amount of grain one would see in an 8x10" print.

When it comes to those "extra bits", you're missing the point. Color accuracy is only part of it. The negative carries more image data than is seen in the print. Those extra bits are for holding that data.

For an example, just look at this page on the OpenEXR website.

Basically, while on the print a certain area might appear to be totally white or totally black, on the negative there's more image information in that area. If you're trying to do a true archive, you'd want to preserve that information, at which point you need an image format that can store overrange data. Although .png can store 16 bits per channel, none of that is overrange, so it can't be used for this purpose. You'd have to go with Cineon or a floating-point format.

Also, if you think 16 bits per channel is overkill, then I guess everyone at those Hollywood VFX studios just doesn't know as much about the subject as you. ILM developed OpenEXR, a 16-bit floating-point per channel, high dynamic range image format. Just think of the time they'd have saved if they had only known that 16 bits was overkill. Or think of the effort Rythm & Hues could've saved by not starting Film Gimp, which eventually became CinePaint. And what about Digital Domain? If they knew as much as you, then their in-house compositing program Nuke wouldn't internally represent image data with floating-point numbers. The evil Kodak would never have developed Cineon and convinced so many studios to use it and virtually every compositing and 3D rendering program to support it.

In all fairness, Cineon only uses 10 bits per channel, but the data is logarithmic rather than linear. To linearize a Cineon image without having to throw out any data would take about 14 bits per channel.

Yes, grain is a side effect of the mechanism. However, it's still important that it be preserved. I'm not talking about recording the value of every single grain on the negative; that'd be ridiculous. Rather, I'm talking about preserving the same amount of grain one would see in an 8x10" print.

When it comes to those "extra bits", you're missing the point. Color accuracy is only part of it. The negative carries more image data than is seen in the print. Those extra bits are for holding that data.

For an example, just look at this page on the OpenEXR website.

Basically, while on the print a certain area might appear to be totally white or totally black, on the negative there's more image information in that area. If you're trying to do a true archive, you'd want to preserve that information, at which point you need an image format that can store overrange data. Although .png can store 16 bits per channel, none of that is overrange, so it can't be used for this purpose. You'd have to go with Cineon or a floating-point format.

Also, if you think 16 bits per channel is overkill, then I guess everyone at those Hollywood VFX studios just doesn't know as much about the subject as you. ILM developed OpenEXR, a 16-bit floating-point per channel, high dynamic range image format. Just think of the time they'd have saved if they had only known that 16 bits was overkill. Or think of the effort Rythm & Hues could've saved by not starting Film Gimp, which eventually became CinePaint. And what about Digital Domain? If they knew as much as you, then their in-house compositing program Nuke wouldn't internally represent image data with floating-point numbers. The evil Kodak would never have developed Cineon and convinced so many studios to use it and virtually every compositing and 3D rendering program to support it.

In all fairness, Cineon only uses 10 bits per channel, but the data is logarithmic rather than linear. To linearize a Cineon image without having to throw out any data would take about 14 bits per channel.

Other disc formats offer higher resolutions for applications such as professional photography and color prepress operations.

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.

OpenEXR

it's www.openexr.com, not 'www.openexr'. Sigh.

The link should be www.openexr.com althought .org and .net work too.. ...