I think I am skirting the realm of what I can say in a public forum as a lot of 
this is company specific. The Josh Pines style conversion will avoid negative 
values the resulting linearised file, and it will also ensure that middle grey 
( log code value 445) will be converted to a linear value of .18 or to use the 
photographic term 18% grey.  If you have a copy of Marcie handy you can use the 
445 swatch and see this. Its pretty crucial.

As Jonathan pointed out negative values are to be avoided in almost all 
standard image manipulation operations, you do not want to have negative values 
coming into merges and other things like keyers. 

Now for the necessarily vague answers

As grain in a linear space results in  both and additive and subtractive 
effects on pixels you will want to ensure that you are not generating negative 
values when you grain. Many people cited this as a reason for going back to log 
in thqe old Shake days but there are definitely simple work arounds if you are 
using grain tools which expect linear inputs.

Generally speaking Gamma coorection of any sort on an image is to be avoided at 
all costs, this includes the type of pedastal correction that you are speaking 
about. It is much simpler to just raise values by a nominal amount and then 
adjust your vLUT to compensate rather than introduce an non-linear curve into a 
linear compositing space. If you are going to comp film anyway most people are 
working with a 3d film output lut rather than the default sRGB.

> Subject: Re: [Nuke-users] Grade clamping
> From: [email protected]
> Date: Thu, 21 Apr 2011 19:34:10 -0700
> To: [email protected]
> 
> So, after your read node, drop a grade node in the tree. Set the offset to 
> .03. This will make everything washed out, so set your gamma to, say, 0.8. 
> Season to taste with this. When you get it dialed, take the same grade node, 
> copy it, and paste it right before your write node. Open up the node to view 
> the properties, and put a check in the "reverse" box.
> 
> When working with the footage, it's going to look slightly different than the 
> original plate, and a little lifted. This won't matter, you'll be reversing 
> the grade out at the end of your comp, so your VFX supe won't know the 
> difference, and your negative code values will be preserved.
> 
> 
> On Apr 21, 2011, at 7:17 PM, Hugo Leveille wrote:
> 
> > Degraining step involve more data on the server and quality loss at some 
> > point
> > 
> > Might be acceptable on some project, but with some project where the vfx 
> > sup won't even watch the comp in dailies if there is a difference with the 
> > original plate (figurely speaking) it won't do it
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > --
> > Hugo Leveille
> > Compositing TD
> > Vision Globale
> > [email protected]
> > 
> > Sent from my iPhone
> > 
> > On Apr 21, 2011, at 10:08 PM, "Brad Friedman" <[email protected]> wrote:
> > 
> >> Proper grain management includes a degraining step and a regrain step. 
> >> 
> >> On Apr 21, 2011, at 10:05 PM, chris <[email protected]> wrote:
> >> 
> >>> On 4/21/11 at 3:18 AM, [email protected] (Brad Friedman) wrote:
> >>>> You probably should not even be applying a grade node
> >>>> before grain management. No sense color correcting values
> >>>> that are chemical noise. The question is: what is your
> >>>> d-min value after proper degraining?
> >>> 
> >>> actually in this case we want to keep the grain, that's why
> >>> it's shot on film ;)
> >>> 
> >>> and i don't want to color correct it, i just want to keep it
> >>> unaffected through the pipeline. obviously if the sub 95
> >>> values are clamped by the filmrecorder in the end, then this
> >>> is a moot point (guess the only way to be sure is to ask the
> >>> guys who are operating the recorder) ... but there are still
> >>> situations where we want to keep the unclipped data, even if
> >>> it's only grain texture (like adding a lens flare, which
> >>> would bring up the sub 95 values to something visible).
> >>> 
> >>> ++ chris
> >>> 
> >>> ps: tried to build the pdx formulas in nuke if anybody is
> >>> interested in playing around.. hope i didnt mess things up:
> >>> 
> >>> set cut_paste_input [stack 0]
> >>> push $cut_paste_input
> >>> Expression {
> >>> temp_name0 pdxLogReference
> >>> temp_expr0 455
> >>> temp_name1 pdxDensityPerCodeValue
> >>> temp_expr1 0.002
> >>> temp_name2 pdxNegativeGamma
> >>> temp_expr2 0.6
> >>> temp_name3 pdxLinReference
> >>> temp_expr3 0.18
> >>> expr0 "pow(10, ((red * 1023 - pdxLogReference) * 
> >>> pdxDensityPerCodeValue/pdxNegativeGamma)) * pdxLinReference"
> >>> expr1 "pow(10, ((green * 1023 - pdxLogReference) * 
> >>> pdxDensityPerCodeValue/pdxNegativeGamma)) * pdxLinReference"
> >>> expr2 "pow(10, ((blue * 1023 - pdxLogReference) * 
> >>> pdxDensityPerCodeValue/pdxNegativeGamma)) * pdxLinReference"
> >>> name pdxLog2Lin
> >>> selected true
> >>> xpos -430
> >>> ypos -118
> >>> }
> >>> Expression {
> >>> temp_name0 pdxLogReference
> >>> temp_expr0 455
> >>> temp_name1 pdxDensityPerCodeValue
> >>> temp_expr1 0.002
> >>> temp_name2 pdxNegativeGamma
> >>> temp_expr2 0.6
> >>> temp_name3 pdxLinReference
> >>> temp_expr3 0.18
> >>> expr0 "(pdxLogReference + log10( max( red, 0.00000001 ) / pdxLinReference 
> >>> )*pdxNegativeGamma/pdxDensityPerCodeValue) / 1023"
> >>> expr1 "(pdxLogReference + log10( max( green, 0.00000001 ) / 
> >>> pdxLinReference )*pdxNegativeGamma/pdxDensityPerCodeValue) / 1023"
> >>> expr2 "(pdxLogReference + log10( max( blue, 0.00000001 ) / 
> >>> pdxLinReference )*pdxNegativeGamma/pdxDensityPerCodeValue) / 1023"
> >>> name pdxLin2Log
> >>> selected true
> >>> xpos -430
> >>> ypos -74
> >>> }
> >>> 
> >>> _______________________________________________
> >>> Nuke-users mailing list
> >>> [email protected]
> >>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
> >> _______________________________________________
> >> Nuke-users mailing list
> >> [email protected]
> >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
> > _______________________________________________
> > Nuke-users mailing list
> > [email protected]
> > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
> 
> _______________________________________________
> Nuke-users mailing list
> [email protected]
> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
                                          
_______________________________________________
Nuke-users mailing list
[email protected]
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users

Reply via email to