Re: [Nuke-users] Mixing footage with different PARs (Pixel Aspect Ratio)

[Sven Schönmann]

Lovely, that makes it perfectly clear. Thank you Howard.

Cheers



On Thu, Feb 16, 2017 at 11:34 AM, Howard Jones  wrote:

> Developing on what Frank said…
>
> This is a question I always ask applicants…"When should you premultiply an
> image”.
>
> Everyone knows when you unpremultiply (grading etc) but the premultiply
> usually gets them.
> The answer is (at least) when you apply some sort of filter - blurs are
> the most obvious but this case is also included.
>
> If you resize/distort before you pull the key you are adding an extra
> filter to the pixels which will affect the edge pixels between the FG and
> GS background.
> If you key first -> premult (if not already) -> resize you get better
> keying.
>
> So I always teach that you key first then apply transforms/blurs etc…
> Attached is a clear example - transforms/reformats are a more subtle
> version of the same issue.
>
> *Howard **Jones*
> Visual Effects Supervisor
> m: 07973 265624 | e: how...@axis-vfx.com | w: www.axis-vfx.com
>
> set cut_paste_input [stack 0]
> version 8.0 v6
> ColorWheel {
>  inputs 0
>  format "1920 1080 0 0 1920 1080 1 HD"
>  gamma 0.45
>  name ColorWheel1
>  selected true
>  xpos -609
>  ypos 49
> }
> Constant {
>  inputs 0
>  color {0 0.18 0 0}
>  format "1920 1080 0 0 1920 1080 1 HD"
>  name Constant1
>  selected true
>  xpos -756
>  ypos 42
> }
> Merge2 {
>  inputs 2
>  also_merge all
>  name Merge1
>  selected true
>  xpos -756
>  ypos 192
> }
> set N272982a0 [stack 0]
> Dot {
>  name Dot1
>  selected true
>  xpos -791
>  ypos 301
> }
> set N222cfb40 [stack 0]
> Primatte3 {
>  data { 5
> 0 30234 0
> 65552
> 0 5
> 30234 30234 30234 0
> 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
> 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
> 62610.5 51924.2 63740.3 130560 29931.7 130560 67594.9 130560 130560
> 54507.8 130560 130560 130560 36601 29607.6 130560 130560 37640.2 28902.9
> 70357.7 130560 130560 130560 130560 45538 76605.6 130560 130560 130560
> 130560 130560 130560 58657.1 57368 74691.7 24586.9 130560 130560 130560
> 130560 78099.9 32000.7 130560 130560 130560 130560 130560 130560 130560
> 130560 130560 48726.9 33024.8 54468 130560 130560 130560 130560 130560
> 130560 130560 130560 130560 37876.2 25811.6 27999
> 62610.5 51924.2 63740.3 130560 29931.7 130560 67594.9 130560 130560
> 54507.8 130560 130560 130560 36601 29607.6 130560 130560 37640.2 28902.9
> 70357.7 130560 130560 130560 130560 45538 76605.6 130560 130560 130560
> 130560 130560 130560 58657.1 57368 74691.7 24586.9 130560 130560 130560
> 130560 78099.9 32000.7 130560 130560 130560 130560 130560 130560 130560
> 130560 130560 48726.9 33024.8 54468 130560 130560 130560 130560 130560
> 130560 130560 130560 130560 37876.2 25811.6 27999
> -0.100098 -5.10213e+13 -5.10213e+13 3023.4 5.15366e+13 5.15366e+13
> -0.100098 -9.60827e+12 -9.60827e+12 3023.4 9.70531e+12 9.70531e+12
> -0.0998535 -8.85095e+13 -8.85095e+13 -3023.4 -5.15366e+13 -5.15366e+13
> -0.0998535 -1.95939e+13 -1.95939e+13 -3023.4 -1.1409e+13 -1.1409e+13
> -0.100098 -1.25055e+13 -1.25055e+13 3023.4 1.26318e+13 1.26318e+13
> -0.100098 -2.35502e+12 -2.35502e+12 3023.4 2.37881e+12 2.37881e+12
> -0.0998535 -3.08712e+13 -3.08712e+13 -3023.4 -1.79754e+13 -1.79754e+13
> -0.0998535 -6.83416e+12 -6.83416e+12 -3023.4 -3.97934e+12 -3.97934e+12
> -0.182617 -4.06321e+14 -4.06321e+14 2981.77 5.0827e+13 5.0827e+13
> -0.182617 -4.06321e+14 -4.06321e+14 2981.77 5.0827e+13 5.0827e+13
> -0.182617 -4.06321e+14 -4.06321e+14 -2981.77 -5.0827e+13 -5.0827e+13
> -0.182617 -1.13364e+14 -1.13364e+14 -2981.77 -3.05385e+13 -3.05385e+13
> -0.182617 -7.00732e+13 -7.00732e+13 2981.77 7.65082e+13 7.65082e+13
> -0.182617 -1.13047e+13 -1.13047e+13 2981.77 1.7253e+13 1.7253e+13
> -0.182617 -4.06321e+14 -4.06321e+14 -2981.77 -5.0827e+13 -5.0827e+13
> -0.182617 -4.15241e+13 -4.15241e+13 -2981.77 -2.29466e+13 -2.29466e+13
> -0.182373 -4.06321e+14 -4.06321e+14 2981.77 5.0827e+13 5.0827e+13
> -0.182373 -5.27139e+13 -5.27139e+13 2981.77 8.04509e+13 8.04509e+13
> -0.182617 -4.06321e+14 -4.06321e+14 -2981.77 -5.0827e+13 -5.0827e+13
> -0.182617 -4.06321e+14 -4.06321e+14 -2981.77 -5.0827e+13 -5.0827e+13
> -0.182373 -4.06321e+14 -4.06321e+14 2981.77 5.0827e+13 5.0827e+13
> -0.182373 -2.03286e+13 -2.03286e+13 2981.77 2.21955e+13 2.21955e+13
> -0.182617 -9.95334e+13 -9.95334e+13 -2981.77 -5.50031e+13 -5.50031e+13
> -0.182617 -4.23091e+13 -4.23091e+13 -2981.77 -1.13974e+13 -1.13974e+13
> -0.23584 -5.24559e+14 -5.24559e+14 2338.61 3.98637e+13 3.98637e+13
> -0.23584 -5.24559e+14 -5.24559e+14 2338.61 3.98637e+13 3.98637e+13
> -0.235596 -5.24559e+14 -5.24559e+14 -2338.61 -3.98637e+13 -3.98637e+13
> -0.235596 -5.24559e+14 -5.24559e+14 -2338.61 -3.98637e+13 -3.98637e+13
> -0.23584 -5.24559e+14 -5.24559e+14 2338.61 3.98637e+13 3.98637e+13
> -0.23584 

Re: [Nuke-users] Mixing footage with different PARs (Pixel Aspect Ratio)

[Howard Jones]

Developing on what Frank said…

This is a question I always ask applicants…"When should you premultiply an 
image”. 

Everyone knows when you unpremultiply (grading etc) but the premultiply usually 
gets them.
The answer is (at least) when you apply some sort of filter - blurs are the 
most obvious but this case is also included.

If you resize/distort before you pull the key you are adding an extra filter to 
the pixels which will affect the edge pixels between the FG and GS background.
If you key first -> premult (if not already) -> resize you get better keying. 

So I always teach that you key first then apply transforms/blurs etc…
Attached is a clear example - transforms/reformats are a more subtle version of 
the same issue.

Howard Jones
Visual Effects Supervisor
m: 07973 265624 | e: how...@axis-vfx.com | w: www.axis-vfx.com

set cut_paste_input [stack 0]
version 8.0 v6
ColorWheel {
 inputs 0
 format "1920 1080 0 0 1920 1080 1 HD"
 gamma 0.45
 name ColorWheel1
 selected true
 xpos -609
 ypos 49
}
Constant {
 inputs 0
 color {0 0.18 0 0}
 format "1920 1080 0 0 1920 1080 1 HD"
 name Constant1
 selected true
 xpos -756
 ypos 42
}
Merge2 {
 inputs 2
 also_merge all
 name Merge1
 selected true
 xpos -756
 ypos 192
}
set N272982a0 [stack 0]
Dot {
 name Dot1
 selected true
 xpos -791
 ypos 301
}
set N222cfb40 [stack 0]
Primatte3 {
 data { 5
0 30234 0
65552
0 5
30234 30234 30234 0
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
62610.5 51924.2 63740.3 130560 29931.7 130560 67594.9 130560 130560 54507.8 
130560 130560 130560 36601 29607.6 130560 130560 37640.2 28902.9 70357.7 130560 
130560 130560 130560 45538 76605.6 130560 130560 130560 130560 130560 130560 
58657.1 57368 74691.7 24586.9 130560 130560 130560 130560 78099.9 32000.7 
130560 130560 130560 130560 130560 130560 130560 130560 130560 48726.9 33024.8 
54468 130560 130560 130560 130560 130560 130560 130560 130560 130560 37876.2 
25811.6 27999
62610.5 51924.2 63740.3 130560 29931.7 130560 67594.9 130560 130560 54507.8 
130560 130560 130560 36601 29607.6 130560 130560 37640.2 28902.9 70357.7 130560 
130560 130560 130560 45538 76605.6 130560 130560 130560 130560 130560 130560 
58657.1 57368 74691.7 24586.9 130560 130560 130560 130560 78099.9 32000.7 
130560 130560 130560 130560 130560 130560 130560 130560 130560 48726.9 33024.8 
54468 130560 130560 130560 130560 130560 130560 130560 130560 130560 37876.2 
25811.6 27999
-0.100098 -5.10213e+13 -5.10213e+13 3023.4 5.15366e+13 5.15366e+13
-0.100098 -9.60827e+12 -9.60827e+12 3023.4 9.70531e+12 9.70531e+12
-0.0998535 -8.85095e+13 -8.85095e+13 -3023.4 -5.15366e+13 -5.15366e+13
-0.0998535 -1.95939e+13 -1.95939e+13 -3023.4 -1.1409e+13 -1.1409e+13
-0.100098 -1.25055e+13 -1.25055e+13 3023.4 1.26318e+13 1.26318e+13
-0.100098 -2.35502e+12 -2.35502e+12 3023.4 2.37881e+12 2.37881e+12
-0.0998535 -3.08712e+13 -3.08712e+13 -3023.4 -1.79754e+13 -1.79754e+13
-0.0998535 -6.83416e+12 -6.83416e+12 -3023.4 -3.97934e+12 -3.97934e+12
-0.182617 -4.06321e+14 -4.06321e+14 2981.77 5.0827e+13 5.0827e+13
-0.182617 -4.06321e+14 -4.06321e+14 2981.77 5.0827e+13 5.0827e+13
-0.182617 -4.06321e+14 -4.06321e+14 -2981.77 -5.0827e+13 -5.0827e+13
-0.182617 -1.13364e+14 -1.13364e+14 -2981.77 -3.05385e+13 -3.05385e+13
-0.182617 -7.00732e+13 -7.00732e+13 2981.77 7.65082e+13 7.65082e+13
-0.182617 -1.13047e+13 -1.13047e+13 2981.77 1.7253e+13 1.7253e+13
-0.182617 -4.06321e+14 -4.06321e+14 -2981.77 -5.0827e+13 -5.0827e+13
-0.182617 -4.15241e+13 -4.15241e+13 -2981.77 -2.29466e+13 -2.29466e+13
-0.182373 -4.06321e+14 -4.06321e+14 2981.77 5.0827e+13 5.0827e+13
-0.182373 -5.27139e+13 -5.27139e+13 2981.77 8.04509e+13 8.04509e+13
-0.182617 -4.06321e+14 -4.06321e+14 -2981.77 -5.0827e+13 -5.0827e+13
-0.182617 -4.06321e+14 -4.06321e+14 -2981.77 -5.0827e+13 -5.0827e+13
-0.182373 -4.06321e+14 -4.06321e+14 2981.77 5.0827e+13 5.0827e+13
-0.182373 -2.03286e+13 -2.03286e+13 2981.77 2.21955e+13 2.21955e+13
-0.182617 -9.95334e+13 -9.95334e+13 -2981.77 -5.50031e+13 -5.50031e+13
-0.182617 -4.23091e+13 -4.23091e+13 -2981.77 -1.13974e+13 -1.13974e+13
-0.23584 -5.24559e+14 -5.24559e+14 2338.61 3.98637e+13 3.98637e+13
-0.23584 -5.24559e+14 -5.24559e+14 2338.61 3.98637e+13 3.98637e+13
-0.235596 -5.24559e+14 -5.24559e+14 -2338.61 -3.98637e+13 -3.98637e+13
-0.235596 -5.24559e+14 -5.24559e+14 -2338.61 -3.98637e+13 -3.98637e+13
-0.23584 -5.24559e+14 -5.24559e+14 2338.61 3.98637e+13 3.98637e+13
-0.23584 -9.14883e+12 -9.14883e+12 2338.61 5.01208e+12 5.01208e+12
-0.235596 -5.24559e+14 -5.24559e+14 -2338.61 -3.98637e+13 -3.98637e+13
-0.235596 -2.28964e+13 -2.28964e+13 -2338.61 7.15614e+12 7.15614e+12
-0.182617 -4.06321e+14 -4.06321e+14 4824.61 8.22399e+13 8.22399e+13
-0.182617 -4.06321e+14 -4.06321e+14 4824.61 8.22399e+13 8.22399e+13

Re: [Nuke-users] Mixing footage with different PARs (Pixel Aspect Ratio)

[Sven Schönmann]

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  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, 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 
> 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 
>> 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, 
> 

Re: [Nuke-users] Mixing footage with different PARs (Pixel Aspect Ratio)

[Frank Rueter|OHUfx]

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, 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 > 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
> 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 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



___
Nuke-users mailing list
Nuke-users@support.thefoundry.co.uk
,http://forums.thefoundry.co.uk/ 

Re: [Nuke-users] Mixing footage with different PARs (Pixel Aspect Ratio)

[Sven Schönmann]

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  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 
> 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 list
Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users

Re: [Nuke-users] Mixing footage with different PARs (Pixel Aspect Ratio)

[Frank Rueter|OHUfx]

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 > 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 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
 


___
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

Re: [Nuke-users] Mixing footage with different PARs (Pixel Aspect Ratio)

[Sven Schönmann]

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 
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 list
Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users

Re: [Nuke-users] Mixing footage with different PARs (Pixel Aspect Ratio)

[Frank Rueter|OHUfx]

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 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