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
