1. Ocio-Dev
  2. Topics

vd16 and alpha channels PS -> Nuke

Brendan Bolles <bre...@...>
 

On Nov 21, 2013, at 8:54 AM, Ashley Retallack wrote:

I was wondering what the best practice is to get an acurat result from nuke as far as compositing a vd16 image with an alpha from photoshop with a linear space. As the result always come out very different to what I have in photoshop. The only way to get a result that is the same is by merging in vd16 space and the converting back to linear afterwards.

Is there a safe way to convert a vd16 image with alpha to linear and have it combine with a similar result as combing two vd16 images.

You will get different results when comping in linear vs. video spaces. It's an order of operations thing and really can't be helped. Easiest thing is to comp the layers in video space and then convert the result to linear. If you're inserting an element in between, you might want to convert it to video space.

The standard Over operation with fully opaque pixels should work the same in either case, but when you have transparency or other modes like Add, you will see changes. If you must comp those layers in linear, you can make color corrections and other adjustments to try to compensate for the differences you're seeing, but you won't be able to get it to match exactly.


Brendan
Ashley Retallack <ashl...@...>
 

Cool,

Thanks for the reply. Yes that's what I thought. so it's more that comp and reprojections need to over in the space space as the matte painting was done in rather than trying to correct the alpha to work with the converted color.

Cheers

Ash



On 21 November 2013 17:27, Brendan Bolles <bre...@...> wrote:
On Nov 21, 2013, at 8:54 AM, Ashley Retallack wrote:

> I was wondering what the best practice is to get an acurat result from nuke as far as compositing a vd16 image with an alpha from photoshop with a linear space. As the result always come out very different to what I have in photoshop. The only way to get a result that is the same is by merging in vd16 space and the converting back to linear afterwards.
>
> Is there a safe way to convert a vd16 image with alpha to linear and have it combine with a similar result as combing two vd16 images.


You will get different results when comping in linear vs. video spaces.  It's an order of operations thing and really can't be helped.  Easiest thing is to comp the layers in video space and then convert the result to linear.  If you're inserting an element in between, you might want to convert it to video space.

The standard Over operation with fully opaque pixels should work the same in either case, but when you have transparency or other modes like Add, you will see changes.  If you must comp those layers in linear, you can make color corrections and other adjustments to try to compensate for the differences you're seeing, but you won't be able to get it to match exactly.


Brendan

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/groups/opt_out.



--
Ashley Retallack | Pipeline Engineer 

BlueBolt Ltd | 15-16 Margaret Street | London W1W 8RW | T: +44 (0)20 7637 5575 | F: +44 (0)20 7637 3296 | www.blue-bolt.com |
Troy Sobotka <troy.s...@...>
 

Assuming I understand the issue...

On Nov 21, 2013 10:02 AM, "Ashley Retallack" <ashl...@...> wrote:
> Thanks for the reply. Yes that's what I thought. so it's more that comp and reprojections need to over in the space space as the matte painting was done in rather than trying to correct the alpha to work with the converted color.

If the alpha is associated, it must be predivided prior to linearization.

The reason is due to a luminance collision. A standard sRGB or 709 inverted TRC looks at a value of 0.5 identically when alpha is associated.

For example, a value of red 0.2 looks exactly the same as an associated alpha version of 1.0 red at 0.2 alpha. The resultant luminance will be off when linearized via an inversion of the TRC.

Predivide if associated and you shouldn't have any issues.

With respect,
TJS
Ashley Retallack <ashl...@...>
 

Hi Troy,

Thanks for the reply. If I was to do this in a nuke context what would the process be, it this no different to doing an unpremult before color transform and a premult afterwards? In which case it does not work as the colors are so different now the alpha associated with it multiple against the wrong value. 

Or do you mean that the alpha it'self needs to be treated first, in which case how do I go about doing this to compensate for the values?

Many thanks

Ash



On 22 November 2013 02:24, Troy Sobotka <troy.s...@...> wrote:

Assuming I understand the issue...

On Nov 21, 2013 10:02 AM, "Ashley Retallack" <ashl...@...> wrote:
> Thanks for the reply. Yes that's what I thought. so it's more that comp and reprojections need to over in the space space as the matte painting was done in rather than trying to correct the alpha to work with the converted color.

If the alpha is associated, it must be predivided prior to linearization.

The reason is due to a luminance collision. A standard sRGB or 709 inverted TRC looks at a value of 0.5 identically when alpha is associated.

For example, a value of red 0.2 looks exactly the same as an associated alpha version of 1.0 red at 0.2 alpha. The resultant luminance will be off when linearized via an inversion of the TRC.

Predivide if associated and you shouldn't have any issues.

With respect,
TJS

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/groups/opt_out.



--
Ashley Retallack | Pipeline Engineer 

BlueBolt Ltd | 15-16 Margaret Street | London W1W 8RW | T: +44 (0)20 7637 5575 | F: +44 (0)20 7637 3296 | www.blue-bolt.com |
Troy Sobotka <troy.s...@...>
 


On Nov 28, 2013 4:49 AM, "Ashley Retallack" <ashl...@...> wrote:
> Thanks for the reply. If I was to do this in a nuke context what would the process be, it this no different to doing an unpremult before color transform and a premult afterwards?

The predivide has to happen prior to TRC inversion.

If the issue is alpha / luminance based, the read node has a “Premultiplied” radio box.

This should take the associated alpha image, predivide it, apply the inverted TRC / transfer curve, then apply the alpha again.

If you attempt to do a similar thing from within a Nuke node chain, the error would already be baked into the data buffer.

With respect,
TJS
Ashley Retallack <ashl...@...>
 

> If you attempt to do a similar thing from within a Nuke node chain, the error would already be baked into the data buffer.


Does this include if you have raw switched on in the read node and than do the unpremult -> OCIOColorspace -> Premult method?




On 28 November 2013 19:43, Troy Sobotka <troy.s...@...> wrote:


On Nov 28, 2013 4:49 AM, "Ashley Retallack" <ashl...@...> wrote:
> Thanks for the reply. If I was to do this in a nuke context what would the process be, it this no different to doing an unpremult before color transform and a premult afterwards?

The predivide has to happen prior to TRC inversion.

If the issue is alpha / luminance based, the read node has a “Premultiplied” radio box.

This should take the associated alpha image, predivide it, apply the inverted TRC / transfer curve, then apply the alpha again.

If you attempt to do a similar thing from within a Nuke node chain, the error would already be baked into the data buffer.

With respect,
TJS

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/groups/opt_out.



--
Ashley Retallack | Pipeline Engineer 

BlueBolt Ltd | 15-16 Margaret Street | London W1W 8RW | T: +44 (0)20 7637 5575 | F: +44 (0)20 7637 3296 | www.blue-bolt.com |

1 - 6 of 6