Andrew, Part of what you are running into is a difference in paradigms between Nuke and OCIO. Nuke has historically been *somewhat* agnostic regarding the purpose of channel data. OCIO, on the other hand, explicitly recognizes red, green and blue channels as separate from other channel types. By choosing to configure Nuke to leverage OCIO for color management, you've chosen to abide by OCIO's design and assumptions. You may be able to argue that OCIO should treat non-rgb channels differently, but since OCIO is not designed only for Nuke, it has other requirements and cannot necessarily be influenced by how each software package defines things like "channels".
Regarding the screenshots you've supplied, can you paste that script into pastebin so I can take a look? Also, we use our own custom OCIO config, so I'm not familiar with the ones that ships with Nuke. Is that "rec709" transform one that ships with Nuke or a custom one? -sean On Thu, Jul 5, 2012 at 1:45 PM, <[email protected]> wrote: > ** > 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
