Vielen Dank for your time on this matter, Frank! ;)

Concerning grain - Neat Video will be my friend.

Have a great day...

Sven


On Thu, Feb 16, 2017 at 2:45 AM, Frank Rueter|OHUfx <fr...@ohufx.com> wrote:

> I personally always lean towards working on the original stuff before
> introducing anything that may be arbitrary (such as filters for the
> reformat).
> That way things always seem more predictable and transferable between
> multiple shots.
> E.g. if you chose a filter for the reformat that sharpens a lot that, that
> might create havoc with a subsequent key.
> Depending on the footage you also need to think about how to reconcile the
> grain/noise patterns to match the different plates. Obviously one plate
> will have stretched noise.
>
> However, it always comes down to testing things properly and making an
> informed decision in context of the footage.
> As long as the workflow is based on an informed decision and not the
> result of random trial&error, I do believe in the ol' "if it looks good you
> are right".
>
> Cheers,
> frank
>
>
>
> On 16/02/17 2:09 PM, Sven Schönmann wrote:
>
> Ok, one last thing: I have a couple of raw greenscreen plates and their
> according graded versions. Is there a "right way" to do the keying process?
>
> 1) pull the key/matte from the undistorted plate -> distort the resulting
> matte plate & the graded plate
>
> 2) distort the raw & graded plate -> pull the key from the distorted raw
> plate
>
> Way one seems more "correct" and clean to me. Way two might result in a
> slightly worse greenscreen plate with wrong or missing details because of
> the transforming process. Or is this wrong and both ways result in a
> mathematically equal result?
>
> Thanks again!
>
>
>
>
> On Thu, Feb 16, 2017 at 1:47 AM, Frank Rueter|OHUfx <fr...@ohufx.com>
> wrote:
>
>> Just remember that pixel aspects are just a concept to correlate the
>> physical resolution of an image to what it should look like.
>> There is no such thing as a non-square pixel in this context, so it's
>> either making the images appear to be (un-)distorted via a viewer setting
>> (based on a factor called "pixel aspect") or physically (un-)distorting
>> them. The latter is required when combing different PAs, the former is
>> required to view the images the way the final output media will show them
>> (i.e. seemingly undistorted).
>>
>> When this gets confusing it's best to turn off the pixel aspect
>> compensation in the viewer so what you see is what you get.
>>
>>
>>
>> On 16/02/17 10:50 AM, Sven Schönmann wrote:
>>
>> Righty, I was expecting that.
>>
>> Thank you for getting back on this Frank.
>>
>> On Wed, Feb 15, 2017 at 10:10 PM, Frank Rueter|OHUfx <fr...@ohufx.com>
>> wrote:
>>
>>> If you mix different PAs you have no choice but to physically
>>> squeeze/stretch to match.
>>> I tend to set up Reformat nodes to bring the supplementary clips in line
>>> with the main plate and ensure that transform concatenation is solid.
>>>
>>> But that's pretty much it. Technically using a 0.5 scale in your
>>> transform is fine too. You have to do what you have to do.
>>>
>>>
>>>
>>>
>>> On 16/02/17 5:31 AM, Sven Schönmann wrote:
>>>
>>> Hey everyone,
>>>
>>> I have the same situation like Lee has in the forum:
>>>
>>> https://community.foundry.com/discuss/topic/129006
>>>
>>> In my case I hit the point that mighty Frank is mentioning:
>>>
>>> "Unless you are mixing different aspect ratios you should not have to
>>> physically un-squeeze the footage (which would only introduce filter hits)."
>>>
>>> So, that's exactly my case. How should I approach the workflow when
>>> bringing in standard square pixel footage to merge? Using a Transform with
>>> a width of "0.5" seems awfully wrong. Is doubling the pixel width of my
>>> anamorphic footage the correct way? Seems also not very attractive to
>>> double the pixel count...and also some filter issues like Frank mentioned.
>>>
>>> Cheers
>>>
>>> Sven
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Nuke-users mailing listnuke-us...@support.thefoundry.co.uk, 
>>> http://forums.thefoundry.co.uk/http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
>>>
>>> _______________________________________________ Nuke-users mailing list
>>> Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
>>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
>>
>> _______________________________________________
>> Nuke-users mailing listnuke-us...@support.thefoundry.co.uk, 
>> http://forums.thefoundry.co.uk/http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
>>
>> _______________________________________________ Nuke-users mailing list
>> Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
>
> _______________________________________________
> Nuke-users mailing listnuke-us...@support.thefoundry.co.uk, 
> http://forums.thefoundry.co.uk/http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
>
>
> _______________________________________________
> Nuke-users mailing list
> Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
>
_______________________________________________
Nuke-users mailing list
Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users

Reply via email to