Ah, yes. I forgot. -sean
On Fri, Jul 6, 2012 at 10:25 AM, <[email protected]> wrote: > ** > Hi Peter, > > Yes i'd be interested to see the patch. We are all linux in this facility > (Debian > 2.6.32) so I cant say about windows. > > 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/06/2012 09:47 AM, Sean Looper wrote: > > 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 [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
