Re: Technical Introduction update ?

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