This won't help on the documentation front, but for your question about how channels are handled...
This is setup in initializeChannelRules() <https://github.com/openexr/openexr/blob/master/OpenEXR/IlmImf/ImfDwaCompressor.cpp#L3120>. That logic is basically saying: - If the channel name is A, use a lossless RLE compression on it - If the channel name is {Y, BY, RY}, and the data is {FLOAT, HALF}, lossy compress the channel - If the channel name is {R, G, B}, and the data is {FLOAT, HALF}, lossy compress the channels. - If we have R, G, and B channels, convert to a color difference format prior to quantization. Otherwise, deal with the channels independently as-is. - Otherwise, use a lossless compression on the data So channels named {y, u, U, v, V} should not be lossy compressed. The rule set that Jonathan is referring to is in initializeLegacyChannelRules() <https://github.com/openexr/openexr/blob/master/OpenEXR/IlmImf/ImfDwaCompressor.cpp#L3149>, and are slightly different from what 2.2 does by default. Most of this is hold-over from the time before multi-part files allowed more control over compression on different channel sets. Karl On Mon, Mar 28, 2016 at 1:56 PM, Richard Hadsell <hads...@blueskystudios.com > wrote: > There has been discussion on the [nuke-prerelease] e-mail list about DWAA > and DWAB compression with OpenExr 2.2. I checked the OpenExr Technical > Introduction, but was disappointed to see that it has not been updated > since November 2013. Is there any chance that someone is working on an > update? > > It is not difficult to use DWAA and DWAB compressions, which are available > in the compression header. That is not the problem. The questions that I > would like to see answered pertain more to lossy vs. lossless compression. > The [nuke-prerelease] discussion included interesting information like this: > > On Thu, Mar 17, 2016 at 1:03 PM, Jonathan Egstad < > jonathan.egs...@dreamworks.com> wrote: > ... > > 3. Does the lossyness cause issues with data aov's, motion vectors, uv, > position, normals, etc...? > > Yup - it will destroy data AOVs like normals, positions, etc. I believe > the codec recognizes typical color-channel names like 'r/R/red/RED', etc > and only lossy compresses those. Channels it doesn't recognize will get > lossless compressed with I believe ZIP - alpha for example is lossless > compressed. > One gotcha is I think it traps 'Y/y, u/U, v/V' as valid color channels and > lossy-compresses those, which is a problem for xyz and uv channels... > This is how our internal codec works so you might want to check that the > one in the official OpenEXR2.2+ release has these behaviors. > ... > (end quote) > > It would be great to see a list of those special channel names. Are they > the only channels that are compressed with DWAA/DWAB? What compression > would be applied to the other channels? Does this behavior apply to all > lossy compressions? > > I hope to see answers to these questions in an updated Technical Intro > (eventually). > > -- > Dick Hadsell 203-992-6320 Fax: 203-992-6001 > Reply-to: hads...@blueskystudios.com > Blue Sky Studios http://www.blueskystudios.com > 1 American Lane, Greenwich, CT 06831-2560 > > > _______________________________________________ > Openexr-devel mailing list > Openexr-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/openexr-devel > >
_______________________________________________ Openexr-devel mailing list Openexr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/openexr-devel
