Aha! That certainly fixes the write out. Thanks!

It seems though that nuke is still unable to re-read the file back in.
After creating the read node it also adds a whole mess of incorrect channel
names to the rgbaz layer.


-Mark


On Wed, Dec 4, 2013 at 6:27 PM, Deke Kincaid <[email protected]> wrote:

> Hi Mark
>
> There is a setting in the write node's exr settings called "Standard layer
> name format".  This will write the data in the method your asking for.  I
> believe we added this preference roughly around Nuke 6.3.
>
> -deke
>
>
> On Wednesday, December 4, 2013, Mark Boorer wrote:
>
>> Hello,
>>
>> Just had a quick question with regards to channel names in multiview
>> (stereo) exr's.
>>
>> According to the documentation here:
>> http://www.openexr.com/MultiViewOpenEXR.pdf
>>
>> The view name must be the ultimate layer name, that is, the penultimate
>>> period-delimited component in
>>> each channel name. In other words, the view name is followed by a period
>>> and a final channel name in the
>>> format *layer.view.channel* or *view.channel*.
>>>
>>
>> But it appears as though nuke writes its layers and channels in*
>> view.layer.channel* order.
>>
>> Is there a reason for this behaviour?
>>
>> This means that interoperability between applications where multiple
>> channels / layers exist is problematic.
>>
>> Below is a script that will write out the layer "rgbaz" with both left
>> and right views, exhibiting the problem.
>> Nuke is unable to read the written file back in.
>>
>> Here is some relevant output from the exrheader application:
>>
>> channels (type chlist):
>>     rgbaz.a, 16-bit floating-point, sampling 1 1
>>     rgbaz.b, 16-bit floating-point, sampling 1 1
>>     rgbaz.g, 16-bit floating-point, sampling 1 1
>>     rgbaz.r, 16-bit floating-point, sampling 1 1
>>     right.rgbaz.a, 16-bit floating-point, sampling 1 1
>>     right.rgbaz.b, 16-bit floating-point, sampling 1 1
>>     right.rgbaz.g, 16-bit floating-point, sampling 1 1
>>     right.rgbaz.r, 16-bit floating-point, sampling 1 1
>> multiView (type stringvector):
>>     "left"
>>     "right"
>>
>> Cheers,
>> Mark
>>
>> NB: The script below was written in the Nuke 8 beta, but will open in
>> most Nuke versions.
>> The problem was reproducible as far back as I tested, (nuke 6.2v3)
>>
>> #! /opt/nuke8.0v1b48/libnuke-8.0.v1b48.so -nx
>> version 8.0 v1b48
>> define_window_layout_xml {<?xml version="1.0" encoding="UTF-8"?>
>> <layout version="1.0">
>>     <window x="42" y="48" w="1680" h="1024" screen="0">
>>         <splitter orientation="1">
>>             <split size="1062"/>
>>             <splitter orientation="1">
>>                 <split size="40"/>
>>                 <dock id="" hideTitles="1" activePageId="Toolbar.1">
>>                     <page id="Toolbar.1"/>
>>                 </dock>
>>                 <split size="1018"/>
>>                 <splitter orientation="2">
>>                     <split size="585"/>
>>                     <dock id="" activePageId="Viewer.1">
>>                         <page id="Viewer.1"/>
>>                     </dock>
>>                     <split size="412"/>
>>                     <dock id="" activePageId="DAG.1">
>>                         <page id="DAG.1"/>
>>                         <page id="Curve Editor.1"/>
>>                         <page id="DopeSheet.1"/>
>>                     </dock>
>>                 </splitter>
>>             </splitter>
>>             <split size="614"/>
>>             <dock id="" activePageId="Properties.1">
>>                 <page id="Properties.1"/>
>>             </dock>
>>         </splitter>
>>     </window>
>> </layout>
>> }
>> Root {
>>  inputs 0
>>  name /tmp/nuke8_channelbug.nk
>>  format "2048 1556 0 0 2048 1556 1 2K_Super_35(full-ap)"
>>  proxy_type scale
>>  proxy_format "1024 778 0 0 1024 778 1 1K_Super_35(full-ap)"
>>  views "left #ff0000
>> right #00ff00"
>> }
>> add_layer {rgbaz rgbaz.r rgbaz.g rgbaz.b rgbaz.a rgbaz.z}
>> Constant {
>>  inputs 0
>>  channels rgbaz
>>  color {1 0 0 0}
>>  format "1920 1080 0 0 1920 1080 1 HD"
>>  name Constant2
>>  xpos -178
>>  ypos -211
>> }
>> Text {
>>  output rgbaz
>>  message RIGHT
>>  font /usr/share/fonts/liberation/LiberationMono-Regular.ttf
>>  size 400
>>  yjustify center
>>  box {512 389 1784 1167}
>>  translate {-60 -210}
>>  center {1024 778}
>>  color {0 1 0 0}
>>  name Text2
>>  xpos -178
>>  ypos -129
>> }
>> Remove {
>>  channels rgba
>>  name Remove2
>>  xpos -178
>>  ypos -93
>> }
>> Constant {
>>  inputs 0
>>  channels rgbaz
>>  color {0 0 1 0}
>>  format "1920 1080 0 0 1920 1080 1 HD"
>>  name Constant1
>>  xpos -285
>>  ypos -213
>> }
>> Text {
>>  output rgbaz
>>  message LEFT
>>  font /usr/share/fonts/liberation/LiberationMono-Regular.ttf
>>  size 400
>>  yjustify center
>>  box {512 389 1536 1167}
>>  translate {-60 -210}
>>  center {1024 778}
>>  color {0 1 0 0}
>>  name Text1
>>  xpos -285
>>  ypos -129
>> }
>> Remove {
>>  channels rgba
>>  name Remove1
>>  xpos -285
>>  ypos -95
>> }
>> JoinViews {
>>  inputs 2
>>  name JoinViews1
>>  xpos -236
>>  ypos -54
>>  viewassoc "left\nright"
>> }
>> Write {
>>  channels all
>>  file /tmp/test.exr
>>  file_type exr
>>  version 7
>>  name Write1
>>  xpos -236
>>  ypos -30
>> }
>> Viewer {
>>  frame 1
>>  channels rgbaz
>>  input_process false
>>  name Viewer1
>>  xpos -235
>>  ypos 44
>> }
>>
>>
>
> --
> --
> Deke Kincaid
> Creative Specialist
> The Foundry
> Skype: dekekincaid
> Tel: (310) 399 4555 - Mobile: (310) 883 4313
> Web: www.thefoundry.co.uk
> Email: [email protected]
>
>
> _______________________________________________
> Nuke-users mailing list
> [email protected], http://forums.thefoundry.co.uk/
> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
>
_______________________________________________
Nuke-users mailing list
[email protected], http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users

Reply via email to