While EXRs have been used by VFX houses internally for years, the adoption of delivering EXRs for final DI in my experience has been relatively new (meaning the past couple of years). For VFX vendors delivering OpenEXR, what compression types are supported under the ACES container?
I thought I had read somewhere that only three compression types were allowed as the ACES container is a subset of OpenEXR:
NO_COMPRESSION (file is not compressed)
PIZ_COMPRESSION (lossless)
B44A_COMPRESSION (lossy)
A common form of compression used with Nuke and VFX facilities is ZIP (1 scanline). Some DI houses support this and others don’t.
Any concerns with delivering ACES2065 material as EXR with this type of compression?
I am curious about this as well, not only about ZIP1 compression (which is definitely the global standard for most VFX houses from my experience), but especially in regards to the EXR2.2 DWA compression schemes.
From my understanding, EXR’s written with anything else but uncompressed, PIZ and B44 are not necessarily ACES-compliant, but will still ‘work’ and store the required information as long as they are 16-bit half float (not 32bit(?!)). I am wondering if those restrictions were imposed to guarantee realtime-playback, but then, on the other hand, PIZ does not really fit in… but those are just assumptions, and I would like to second Mike’s question and extend it to include DWAA compression as well.
The SMPTE ST 2065-4 spec “ACES Image Container File Layout” currently requires uncompressed files. Also, there are other restrictions such as only 16-bit float and only certain channel layouts (RGB, RGBA, and stereo RGB/RGBA).
These limitations do make sense for use-cases that involve archiving or real-time playback.
Obviously for VFX use-cases, you will often need more layers and may want to use compression. You can certainly put ACES2065-1 color values in an OpenEXR container for these purposes. They would not be ACES2065-4 compliant (and they should not have the acesImageContainerFlag attribute set). That may be fine for many use-cases (e.g. exchanging files between VFX facilities during production) but not fine for others (e.g. final deliverable of a movie for the archive).
At some point, perhaps the 2065-4 spec will be augmented to allow compression or other channel layouts. (Although my understanding is that it is quite a lot of work to document compression algorithms in sufficient detail to include them in SMPTE standards.)
Regarding allowing other channels for VFX, one thing that I think would be useful would be a naming convention to help identify which channels are color passes and which are data/AOVs (obviously only the color passes should be color managed).
It is a somehow annoying one because it precludes storage of absolute luminance / illuminance light values in an ACES Image Container. It means that you will have to normalise your data and store the normalisation factor somewhere (likely the container metadata) if you want to follow the specification. This is a problem for high dynamic range imagery where you can get very very high values from any type of light sources.
Here are a few numbers I measured recently for reference:
CFL lightbulbs as high as [90001, 65158, 33179] for ±100 Lux
Sun disc at [1.7e13, 1.7e13, 1.6e13] for ±51000 Lux
I agree that it may be useful to have access to absolute luminance (or radiance) values for objects in a scene. However, those would not be valid ACES values. SMPTE 2065-1 requires that ACES values be normalized: “ACES is scaled such that a perfect reflecting diffuser under a particular illuminant produce ACES values of 1.0”
This is in line with the convention stated in ILM’s “Technical Introduction to OpenEXR” which states: “The convention employed by OpenEXR is to determine a middle gray object, and assign it the photographic 18% gray value, or 0.18 in the floating point scheme.”
I agree with you that the normalization factor could be stored in the header. I seem to recall that there actually was an OpenEXR attribute for that purpose but can’t seem to find reference to it at the moment.
I don’t have access to SMPTE 2065-1 but I didn’t remember seeing a mention in the Technical Bulletins that absolute exposure values are forbidden or illegal.
That being said after re-reading the 5.3.3 Absolute exposure values section in TB-2014-004 one should infer it:
ACES exposure values are relative: they are specified in reference to the values that would be captured from a perfect reflecting diffuser. When absolute exposure values are desired […], an external measuring device such as a light meter can be used to determine the absolute luminance of a neutral reflector in the scene. […]
The information thus determined can be carried, either as metadata associated with the image, or in the image itself. […]
I would maybe argue that making an emphasis in TB-2014-004 that absolute exposure values are illegal in the container might be worth it, especially with VFX vendors and Games vendors diving into the absolute light values realm. @aforsythe, @sdyer what do you think guys?
