Hi Andrew, With regards the "purple" bug, this was found and fixed at the Foundry a couple of weeks ago. It was due to the OCIODisplay node writing to a wrong channel. This will appear in a future Nuke release, but if you or somebody at your facility can rebuild the Nuke nodes, we can post a code patch to you.
I'm not in the office now until the end of next week, but if Mr Pearson is reading this perhaps he can send you the patch? Sean, I'll make sure you guys get the patch as well. Regards, Peter. On Thu, Jul 5, 2012 at 10:42 PM, <[email protected]> wrote: > ** > Its understandable for other software packages to be accounted for and > even though i've been talking about 1D unweighted viewer only transforms I > understand the issues with any other scenario. > > As far as only the Red and Blue of sub layers being affected, Sean the > script is below however it seems best to change the OCIO layer selection > from 'all' to 'RGB' to keep everything else viewed as linear and unaffected > but the view lut. > > Cheers > > Andrew > > > > -------------------------------------------------------- > > set cut_paste_input [stack 0] > version 6.3 v8 > push $cut_paste_input > Ramp { > p1 {100 1224} > name Ramp1 > selected true > xpos 1051 > ypos -294 > postage_stamp true > } > add_layer {reflect reflect.red reflect.green reflect.blue} > Shuffle { > out reflect > name Shuffle3 > label "rgb > \[knob out] to\ntest SubChannels" > selected true > xpos 1051 > ypos -206 > } > OCIODisplay { > view {{2} None sRGB rec709} > name OCIODisplay1 > selected true > xpos 1051 > ypos -129 > } > set N53e8350 [stack 0] > Dot { > name Dot2 > selected true > xpos 1203 > ypos -125 > } > Shuffle { > in reflect > alpha black > name Shuffle2 > label "\[knob in] > rgb" > selected true > xpos 1169 > ypos -95 > } > Text { > message Reflect > font /usr/share/fonts/truetype/ttf-bitstream-vera/Vera.ttf > xjustify center > yjustify center > box {1566 12 1910 142} > center {1024 778} > name Text6 > label Reflect > selected true > xpos 1169 > ypos -57 > } > Crop { > box {1365.333333 0 2048 1556} > name Crop3 > selected true > xpos 1169 > ypos -19 > } > push 0 > push $N53e8350 > Dot { > name Dot3 > selected true > xpos 982 > ypos -125 > } > Text { > message RGB > font /usr/share/fonts/truetype/ttf-bitstream-vera/Vera.ttf > yjustify center > box {324 12 668 142} > center {1024 778} > name Text1 > label RGB > selected true > xpos 948 > ypos -54 > } > Crop { > box {0 0 682.6666667 1556} > name Crop1 > selected true > xpos 948 > ypos -16 > } > push $N53e8350 > Shuffle { > in alpha > alpha black > name Shuffle1 > label "\[knob in] > rgb" > selected true > xpos 1051 > ypos -93 > } > Text { > message Alpha > font /usr/share/fonts/truetype/ttf-bitstream-vera/Vera.ttf > xjustify center > yjustify center > box {858 12 1202 142} > center {1024 778} > name Text5 > label Alpha > selected true > xpos 1051 > ypos -55 > } > Crop { > box {682.6666667 0 1365.333333 1556} > name Crop2 > selected true > xpos 1051 > ypos -17 > } > Merge2 { > inputs 3+1 > name Merge1 > selected true > xpos 1051 > ypos 53 > } > > > > –––––––– > > MIRADA > Purveyors of Handmade Storytelling, > Since 2010 > > 4235 Redwood Avenue > Los Angeles, CA 90066+1 424 216 7470mirada.com > > Please consider the environment before printing this email. > > This communication is confidential and may contain legally privileged > information related to Mirada. If you are not the named recipient, please > contact us immediately and delete this message and attachments. You must not > copy, use or disclose this communication, or any attachments or information > in it, without our prior consent. All opinions, conclusions and other > information expressed in this message not of an official nature shall not be > deemed as given or endorsed by Mirada unless otherwise indicated by an > authorized representative independent of this message. > > > On 07/05/2012 02:15 PM, Howard Jones wrote: > > Small correction > > When viewing the reflection layer in the OCIO Display I do see a shift > through this node or the standard colourspace node however downstream > through the shuffles I see no shift. But again no purple > > Howard > > ------------------------------ > *From:* Howard Jones <[email protected]> <[email protected]> > *To:* Nuke user discussion > <[email protected]><[email protected]> > *Sent:* Thursday, 5 July 2012, 22:09 > *Subject:* Re: [Nuke-users] 6.3v8 OCIO display lut > > Only RGB channels from the RGBA layer are affected - the alpha is not > and this has been the case for several years now in Nuke. > This is the correct and desired behaviour, though admittedly seems strange > at first. > > Any other embedded layers in an exr file are (or should be) treated as > linear and no conversion is applied. > > > Testing your script though I am not seeing the purple you are seeing. > RGB is changed but Alpha and reflection are identical. > Nuke 6.3v8 -MacOSX Lion > > Howard > > ------------------------------ > *From:* "[email protected]" <[email protected]> > <[email protected]><[email protected]> > *To:* [email protected] > *Sent:* Thursday, 5 July 2012, 21:45 > *Subject:* Re: [Nuke-users] 6.3v8 OCIO display lut > > I understand that the alpha has the purpose of defining transparency > values however it should be treated like any other channel/layer in the > software. Especially as the view transform is applied to all layers (when > using 'all') some of which are meant for color some not such as diffuse vs > velocity yet they're both just channels as far a Nuke is concerned. > > I guess it just seems pretty strange/undesirable to me to have a value of > 0.5 in the RGB and 0.5 in the Alpha appear a different shade to each other > in the viewer. > > I'm also seeing a bug where the viewer lut is applying to only the Red and > Blue channels of my other layers. Making all the other layers in my renders > appear purple. I have tested this on multiple files, multiple machines and > multiple scripts with the same result from the OCIO display transform. I > have attached a couple screen grabs of a test just using a ramp to see > clearly and only changing the view transform. > > I can confirm that all of the channels and layers have the exact same data > values yet you can see how they appear. In the test attached im using the > OCIOdisplay node just to show them all at once however this is the same > results as switching between luts in the viewProcess and viewing the layers > directly. > > Anyone else experiencing this? > > Regards > > Andrew > > > –––––––– > > MIRADA > Purveyors of Handmade Storytelling, > Since 2010 > > 4235 Redwood Avenue > Los Angeles, CA 90066+1 424 216 7470mirada.com > > Please consider the environment before printing this email. > > This communication is confidential and may contain legally privileged > information related to Mirada. If you are not the named recipient, please > contact us immediately and delete this message and attachments. You must not > copy, use or disclose this communication, or any attachments or information > in it, without our prior consent. All opinions, conclusions and other > information expressed in this message not of an official nature shall not be > deemed as given or endorsed by Mirada unless otherwise indicated by an > authorized representative independent of this message. > > > On 07/05/2012 09:15 AM, Sean Looper wrote: > > Andrew, > > Another reason is that OCIO defines LUTs for RGB channels only. It would > be difficult in many cases and impossible in others to determine which > transformation to apply to the alpha channel data. Aside from the reasons > why you wouldn't want a transform applied to non-image data (i.e. alpha, > depth, uv, etc), when you look at transforms that contain cross-talk > between channels, even attempting to derive a 1D LUT from a 3D one for the > purpose of applying to a data channel would produce unreliable results. > > -sean > > > > On Wed, Jul 4, 2012 at 5:45 PM, randmin <[email protected]> wrote: > > Because usually the alpha is nothing more then transparency values so it > is represented in a way that best resembles how it is applied to the data. > You alpha isn't getting and CC where as your rgb and other channels have > to have a proper color look to be blended. (alpha blending is linear > multi. why would you want it to do anything else?) > > Randy > > On Jul 3, 2012, at 4:54 PM, [email protected] wrote: > > So using the OCIODisplay now with the viewerProcess set to none does > give me the same result as using selections in the viewerProcess as it > should and yes the transforms are applied to all layers and channels except > the alpha. > > This is a desired result you say? Why would you want your alpha not > represented the same as everything else? > > Andrew > > –––––––– > > MIRADA > Purveyors of Handmade Storytelling, > Since 2010 > > 4235 Redwood Avenue > Los Angeles, CA 90066+1 424 216 7470mirada.com > > Please consider the environment before printing this email. > > This communication is confidential and may contain legally privileged > information related to Mirada. If you are not the named recipient, please > contact us immediately and delete this message and attachments. You must not > copy, use or disclose this communication, or any attachments or information > in it, without our prior consent. All opinions, conclusions and other > information expressed in this message not of an official nature shall not be > deemed as given or endorsed by Mirada unless otherwise indicated by an > authorized representative independent of this message. > > > On 07/03/2012 10:52 AM, Sean Looper wrote: > > The OCIO Viewer LUTs are just OCIODisplay nodes. Try inserting an > OCIODisplay node in your graph and viewing from there with your Viewer LUT > set to "None". Pick an obvious transform from the "view transform" knob and > cycle the "layer" knob through your various layers. You *should* see the > transform applied to whichever layer you select. What you shouldn't see is > the transform being applied to the alpha channels. > > Let us know if you see anything different than the above. > > -sean > > > > On Mon, Jul 2, 2012 at 3:58 PM, <[email protected]> wrote: > > Hey Sean, > > I'm using the "rec709 (default)" from the viewer lut pulldown though srgb > has the same issue and I dont have any other view luts currently installed. > We have a custom OCIO config originating from opencolorio.org > > A quick and clear test is to make an RGBA ramp and compare the RGB and the > A through different viewer luts and none. > > If no one else is seeing it perhaps its to do with our OCIO setup. > > Andrew > > Date: Fri, 29 Jun 2012 14:01:21 -0700 > From: Sean Looper<[email protected]> > Subject: Re: [Nuke-users] 6.3v8 OCIO display lut > To: Nuke user discussion<[email protected]> > Message-ID: > < > ca+dgjnax09z0blpa2xogbqr_ofdbkfw0ehwp2gg1h9z6dvp...@mail.gmail.com> > Content-Type: text/plain; charset="windows-1252" > > Hey Andrew, > > Can you clarify a bit? In 6.3v8, the shipped LUTs seem to apply correctly > to non-rgba channels, but not to the alpha. This is the desired behavior. > At one point there was a bug in OCIO that caused the LUTs to only apply to > RGBA, but that fix seems to be picked up in Nuke 6.3v8. Which LUT are you > selecting in the Viewer LUT pulldown? Are you using a custom OCIO config or > the one that ships with Nuke? > > Sean > > > > On Fri, Jun 29, 2012 at 12:18 PM,<[email protected]> wrote: > > It appears that the forced OCIO display lut in 6.3v8 is only applying to > the RGB channels and not the alpha or other layers. > > My "layer" option in the OCIOCDisplay panel is set to all. Though changing > this to other options doest not have any affect. > > Anyone else experiencing this? > > -Andrew > > -- > Compositing Supervisor > –––––––– > > MIRADA > Purveyors of Handmade Storytelling, > Since 2010 > > 4235 Redwood Avenue > Los Angeles, CA 90066 > +1 424 216 7470 > mirada.com > > Please consider the environment before printing this email. > > This communication is confidential and may contain legally privileged > information related to Mirada. If you are not the named recipient, please > contact us immediately and delete this message and attachments. You must > not copy, use or disclose this communication, or any attachments or > information in it, without our prior consent. All opinions, conclusions > and > other information expressed in this message not of an official nature > shall > not be deemed as given or endorsed by Mirada unless otherwise indicated by > an authorized representative independent of this message. > > > ______________________________**_________________ > Nuke-users mailing list > [email protected].**co.uk<[email protected] > >, > http://forums.thefoundry.co.**uk/<http://forums.thefoundry.co.uk/> > http://support.thefoundry.co.**uk/cgi-bin/mailman/listinfo/**nuke-users< > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users> > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://support.thefoundry.co.uk/cgi-bin/mailman/private/nuke-users/attachments/20120629/797f3ea4/attachment-0001.htm > > > > > _______________________________________________ > 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 [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 > > > > _______________________________________________ > 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 [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 > > > _______________________________________________ > 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 [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 >
_______________________________________________ Nuke-users mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
