Andrew,
When applying a 3D matrix transformation to an RGB triplet, each output channel
is constructed using weights from all 3 channels (red, green, and blue). So in
this scenario, where would you expect the transform for the alpha come from?
The first channel? A weighted average of all 3? Or some other manufactured
weighting factor that would have to be defined separately from the matrix (or
applied as a 4x4)?
Applying LUTs/transforms to alphas isn’t really a great idea in any scenario,
and can be dangerous in many. If you end up forgetting you have one applied
(put a shot away for a few days/weeks, jump around a lot, etc.) or hand a
script off to another artist, someone could waste time trying to troubleshoot a
problem that isn’t there.
-Nathan
From: [email protected]
Sent: Thursday, July 05, 2012 1:45 PM
To: [email protected]
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]> 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 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/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:
<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]> 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 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
_______________________________________________
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
