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 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.
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]>
*To:* Nuke user discussion <[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]>
*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 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.
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] <mailto:[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]
<mailto:[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 7470
mirada.com <http://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.
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]
<mailto:[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 <http://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]
<mailto:[email protected]>>
Subject: Re: [Nuke-users] 6.3v8 OCIO display lut
To: Nuke user
discussion<[email protected]
<mailto:[email protected]>>
Message-ID:
<ca+dgjnax09z0blpa2xogbqr_ofdbkfw0ehwp2gg1h9z6dvp...@mail.gmail.com
<mailto:ca%2bdgjnax09z0blpa2xogbqr_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]
<mailto:[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 <http://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].**
<mailto:[email protected].**>co.uk
<http://co.uk/><[email protected]
<mailto:[email protected]>>,
http://forums.thefoundry.co.
<http://forums.thefoundry.co./>**uk/<http://forums.thefoundry.co.uk/>
http://support.thefoundry.co.
<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]
<mailto:[email protected]>,
http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
_______________________________________________
Nuke-users mailing list
[email protected]
<mailto:[email protected]>,http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
_______________________________________________
Nuke-users mailing list
[email protected]
<mailto:[email protected]>,
http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
_______________________________________________
Nuke-users mailing list
[email protected]
<mailto:[email protected]>,
http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
_______________________________________________
Nuke-users mailing list
[email protected]
<mailto:[email protected]>,http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
_______________________________________________
Nuke-users mailing list
[email protected]
<mailto:[email protected]>,
http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
_______________________________________________
Nuke-users mailing list
[email protected]
<mailto:[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
