That looks odd. I'll need to refer back to the code to see how this could come to be ...
On 28 March 2016 at 16:17, Deke Kincaid <dekekinc...@gmail.com> wrote: > They must be implementing something incorrectly then. Below is a > truncated exrheader on a file out of Nuke with the "interleave" knob set to > "channels" which means each layer is put into a separate part.. > > file testMultiPartChannelsdwaa.exr: > > file format version: 2, flags 0x1000 > > part 0: > channels (type chlist): > x, 16-bit floating-point, sampling 1 1 > y, 16-bit floating-point, sampling 1 1 > z, 16-bit floating-point, sampling 1 1 > chunkCount (type int): 34 > compression (type compression): dwa, small scanline blocks > dataWindow (type box2i): (0 240) - (2047 1315) > displayWindow (type box2i): (0 0) - (2047 1555) > dwaCompressionLevel (type float): 45 > lineOrder (type lineOrder): increasing y > name (type string): "N.left" > nuke/full_layer_names (type int): 0 > nuke/node_hash (type string): "368b9d1b87a4b787" > nuke/version (type string): "9.0v8" > pixelAspectRatio (type float): 1 > screenWindowCenter (type v2f): (0 0) > screenWindowWidth (type float): 1 > type (type string): "scanlineimage" > version (type int): 1 > view (type string): "left" > > part 1: > channels (type chlist): > x, 16-bit floating-point, sampling 1 1 > y, 16-bit floating-point, sampling 1 1 > z, 16-bit floating-point, sampling 1 1 > chunkCount (type int): 34 > compression (type compression): dwa, small scanline blocks > dataWindow (type box2i): (0 240) - (2047 1315) > displayWindow (type box2i): (0 0) - (2047 1555) > dwaCompressionLevel (type float): 45 > lineOrder (type lineOrder): increasing y > name (type string): "P.left" > pixelAspectRatio (type float): 1 > screenWindowCenter (type v2f): (0 0) > screenWindowWidth (type float): 1 > type (type string): "scanlineimage" > version (type int): 1 > view (type string): "left" > > part 2: > channels (type chlist): > Z, 16-bit floating-point, sampling 1 1 > chunkCount (type int): 34 > compression (type compression): dwa, small scanline blocks > dataWindow (type box2i): (0 240) - (2047 1315) > displayWindow (type box2i): (0 0) - (2047 1555) > dwaCompressionLevel (type float): 45 > lineOrder (type lineOrder): increasing y > name (type string): "depth.left" > pixelAspectRatio (type float): 1 > screenWindowCenter (type v2f): (0 0) > screenWindowWidth (type float): 1 > type (type string): "scanlineimage" > version (type int): 1 > view (type string): "left" > > part 3: > channels (type chlist): > u, 16-bit floating-point, sampling 1 1 > v, 16-bit floating-point, sampling 1 1 > chunkCount (type int): 34 > compression (type compression): dwa, small scanline blocks > dataWindow (type box2i): (0 240) - (2047 1315) > displayWindow (type box2i): (0 0) - (2047 1555) > dwaCompressionLevel (type float): 45 > lineOrder (type lineOrder): increasing y > name (type string): "motion.left" > pixelAspectRatio (type float): 1 > screenWindowCenter (type v2f): (0 0) > screenWindowWidth (type float): 1 > type (type string): "scanlineimage" > version (type int): 1 > view (type string): "left" > > part 4: > channels (type chlist): > A, 16-bit floating-point, sampling 1 1 > B, 16-bit floating-point, sampling 1 1 > G, 16-bit floating-point, sampling 1 1 > R, 16-bit floating-point, sampling 1 1 > chunkCount (type int): 34 > compression (type compression): dwa, small scanline blocks > dataWindow (type box2i): (0 240) - (2047 1315) > displayWindow (type box2i): (0 0) - (2047 1555) > dwaCompressionLevel (type float): 45 > lineOrder (type lineOrder): increasing y > name (type string): "rgba.left" > pixelAspectRatio (type float): 1 > screenWindowCenter (type v2f): (0 0) > screenWindowWidth (type float): 1 > type (type string): "scanlineimage" > version (type int): 1 > view (type string): "left" > > > > On Mon, Mar 28, 2016 at 3:16 PM, Piotr Stanczyk <piotr.stanc...@gmail.com> > wrote: > >> +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 <karlras...@gmail.com> 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 <dekekinc...@gmail.com> 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 <karlras...@gmail.com> >>>> 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 < >>>>> 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 >>>>> >>>>> >>>> >>> _______________________________________________ >>> 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 > >
_______________________________________________ Openexr-devel mailing list Openexr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/openexr-devel
