Peter, Can you say whether this bug was Windows-only? Using Andrew's example, I can't reproduce it in either vanilla 6.3v8 or with 6.3v8 patched with the latest OCIO nodes. I am however, only testing on Fedora Core. I'm very interested in seeing your patch as well.
Thanks! -sean On Fri, Jul 6, 2012 at 3:23 AM, Peter Crossley <[email protected]>wrote: > 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 >
_______________________________________________ Nuke-users mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
