Deke - All the channel rule setup should happen automagically; there isn't anything for Nuke to setup.
That said, if your channels are all named RGB going into the write node, they'll all be handled the same by the compressor. Karl On Monday, March 28, 2016, Deke Kincaid <[email protected]> wrote: > Thanks for the info Karl. Currently Nuke doesn't follow these rules and > when you pick DWAA and just compresses all channels the same instead of > selectively based on channel names. So we are having to write some hackery > to work around it at the moment. > > I'll put this into my feature request/bug to the Foundry. > > On Mon, Mar 28, 2016 at 2:15 PM, Karl Rasche <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: > >> >> 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 < >> [email protected] >> <javascript:_e(%7B%7D,'cvml','[email protected]');>> 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 < >>> [email protected] >>> <javascript:_e(%7B%7D,'cvml','[email protected]');>> 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: [email protected] >>> <javascript:_e(%7B%7D,'cvml','[email protected]');> >>> Blue Sky Studios http://www.blueskystudios.com >>> 1 American Lane, Greenwich, CT 06831-2560 >>> >>> >>> _______________________________________________ >>> Openexr-devel mailing list >>> [email protected] >>> <javascript:_e(%7B%7D,'cvml','[email protected]');> >>> https://lists.nongnu.org/mailman/listinfo/openexr-devel >>> >>> >> >> _______________________________________________ >> Openexr-devel mailing list >> [email protected] >> <javascript:_e(%7B%7D,'cvml','[email protected]');> >> https://lists.nongnu.org/mailman/listinfo/openexr-devel >> >> >
_______________________________________________ Openexr-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/openexr-devel
