-
Notifications
You must be signed in to change notification settings - Fork 15
Home
The names in the format v3 files are now stored in base64 to help compatibility with existing softwares like RV or Nuke.
The file format is now in version 3. The files are standard EXR deep images with the R,G,B,A,Z. The extra Id channel is still the index in the name table.
In an OpenEXR/Id file, each pixel is a list of RGBAZ values per object. Each object has an id (uint32) which is an index in a table of strings. OpenEXR/Id uses the deep slice of OpenEXR 2.0 to store such lists.
To reconstruct an image, the plug-in builds an automata with all the user regular expressions using RE2. The plug-in matches every object names against the automata. Then, for every pixel, the plug-in accumulates the samples of the matching ids.
The EXR/Id file format is now in version 3. (EXRIdVersion = 3)
The EXR/Id file is an EXR 2.0 file using deep slices.
The EXR header must contain the following attributes :
- "EXRIdVersion" (optional) integer, if present must be 2 or 3
- "EXRIdNames" string, in version 2 : the string array (C strings concatenated with their ending \0) of the object names compressed using zlib deflate.
- "EXRIdNames" string, in version 3 : a string composed of the names concatenated with a return carriage character "\n", compressed using zlib deflate and then encoded in base64.
The deep part is composed of :
- A mandatory alpha half deep slice ("A")
- Optional deep slices ("R", "G", "B", etc..). If R,G or B is not present, the plug-in generates only masks.
- A mandatory Z deep slice ("Z")
- A mandatory uint32 id deep slice ("Id")
- Optional AOVs color slices (like "Specular.R", "Specular.G", "Specular.B") for futur use. They are not used right now by the OpenFX plug-in, but the idea is to propose to merge an AOV list directly from the plug-in.
Each pixel contains a deep fragment per object. The "Id" slice stores the object id in the string array stored in the EXRIdNames attribute.
Help is welcome here :)
Propose a patch for OpenEXR (see Compatibility with OpenEXR).- Make the OpenFX plug-in directly merge the AOVs.
Make a native Nuke reader plug-in to behave like other Nuke readers.- Support the "%04d" frame tag style. Only # are supported right now in the OFX plug-in.
- Modify the openexrid::Builder interface to add a weight to the samples. The progressive/adaptive sample values need to be normalized at the end of the render.
- Add compression schemes to the openexrid::Builder interface. It could be "minimal coverage" or "max objects per pixels" or both. The samples that can't be created in their own Id in the pixel would be averaged in a remaining Id, something like Id=0, Name="".
And for the craziest : study if it is possible to make a Nuke deep reader and keep the OpenEXR/Id raw data in the Nuke's data flow.
It's up to the renderer to craft the string to assign at each Id. For exemple, Guerilla Render crafts a Maya style full path without the ending shape, like "root|parent|transform".
Thanks to the regexp, the user will be able to isolate any level of hierarchy :
- "$root"
- "$root|parent"
- "$root|parent|child"
The deep node OpenEXR/Id has been successfully tested on :
- Nuke 9,10,10.5 windows & linux
OpenEXR/Id in OFX has been successfully tested on :
- Nuke 7 windows
- Nuke 8 windows & linux
- Nuke 10 windows & linux
- Nuke 10.5 windows & linux
- Nuke 11.0 windows & linux
- Nuke 11.1 windows & linux
- Natron windows & linux
- Fusion Studio 8 windows
Let us know if you run it on other platforms.
OpenEXR/Id files are not directly readable through the OpenEXR::RgbaInputFile interface. The OpenEXR library thinks OpenEXR/Id files are deep images and fails to composite them.
OpenEXR/Id 2 files are now fully compatible with software able to read deep openexr images.