Re: Technical Introduction update ?

+1 .. there is nothing that the client code really has to do. It's purely
based off the channel names.

-Piotr


On 28 March 2016 at 15:05, Karl Rasche <[email protected]> wrote:

> 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]>
>> 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]> 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]> 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]
>>>> Blue Sky Studios                http://www.blueskystudios.com
>>>> 1 American Lane, Greenwich, CT 06831-2560
>>>>
>>>>
>>>> _______________________________________________
>>>> Openexr-devel mailing list
>>>> [email protected]
>>>> https://lists.nongnu.org/mailman/listinfo/openexr-devel
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Openexr-devel mailing list
>>> [email protected]
>>> https://lists.nongnu.org/mailman/listinfo/openexr-devel
>>>
>>>
>>
> _______________________________________________
> Openexr-devel mailing list
> [email protected]
> https://lists.nongnu.org/mailman/listinfo/openexr-devel
>
>

_______________________________________________
Openexr-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/openexr-devel