Re: [Nuke-users] [OT] UHD Monitor for Comping

[Sven Schönmann]

Marten is right. I bought a 4K monitor for my windows workstation and had
to sell it after a week. Everything in the GUI is so tiny-tiny-small that I
had to guide my wacom pen in one hand with the other hand to be able to
click the checkboxes in the shuffle node! ;)

Cheers

Sven


On Mon, Mar 20, 2017 at 5:25 PM, Marten Blumen  wrote:

> 4K monitors and Nuke are a less than optimal combination currently, until
> hDPI is supported properly.
>
> On 21 March 2017 at 05:12, Igor Majdandzic 
> wrote:
>
>> Hey guys,
>> I am about to purchase a new monitor, the LG27MU67-B.
>>
>> Any experience with big resolution monitors and nuke? All will be under
>> win10.
>>
>> Cheers,
>> Igor
>>
>>
>> 
>> Send from the Road
>>
>> Igor Majdandzic
>> Compositor, TD, Supervisor
>> @Chimney Frankfurt
>>
>> ___
>> 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] nuke download?!

[Sven Schönmann]

Also wasted a couple of minutes of my life searching for the download on
the website. I always ended up searching my emails with the release-info
and the embedded link to the download.

Foundry? Come on...

Cheers

Sven


On Tue, Mar 7, 2017 at 5:23 PM, adam jones  wrote:

> hey there
>
> this has recently fucked me over also.
>
> i am not sure if this will work but……
>
>
> https://www.thefoundry.co.uk/products/download_product.php?
> file=Nuke10.5v2-mac-x86-release-64.dmg_type=standard
>
>
> https://www.thefoundry.co.uk/products/download_product.php?
> file=Nuke10.5v2-linux-x86-release-64.tgz_type=standard
>
>
>
> https://www.thefoundry.co.uk/products/download_product.php?
> file=Nuke10.5v2-win-x86-release-64.zip_type=standard
>
>
> being that we purchased on line these are the links we have.
>
> re the foundry, we missed a deadline due to this screw
>
>
>
>
>
> On 8 Mar 2017, at 3:12 AM, Gary Jaeger  wrote:
>
> Wow, this new site…
>
> so I’m searching for what used to be front and center - the download
> button. I’ve been looking for a while and now I’m laughing. I seriously
> can’t find where to download 10.5. I’m logged in. Am I supposed to
> “Download Trial”? I can download the Release notes, which is lovely. I
> tried a search (Search for anything) but no matter what I type nothing
> shows up in the text field.
>
> Anybody have a direct link? Maybe I’ll try the trial link...
>
> *Gary Jaeger */ 650.728.7957 <(650)%20728-7957> direct / 415.518.1419
> <(415)%20518-1419> mobile
> http://corestudio.com
>
> ___
> 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] where to find colour edge gizmo

[Sven Schönmann]

Hi Javier,

the gizmo is inside the files that Hugo has linked in the video
description. Here is the link:
https://www.dropbox.com/s/hic9754ov3armp2/06_Relight_Nuke.zip?dl=0

Cheers

Sven


On Fri, Feb 24, 2017 at 4:47 PM, javier gonzalez 
wrote:

> Hey guys am following hugo guerra in youtube and he use a lot the
> gizmo colour edge, i search in nukepedia and no luck, i know exist
> Edge Extend 2 and others but know its a matter of find it. anyone?
> thanks
> ___
> 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] NukeX 10.0v6 and Sapphire OFX 10.000 crashing

[Sven Schönmann]

Finally found the problem. Cropping the image was the right direction. But
be shure to deselect the "Black Outside" option in the crop (or use a
reformat). Even the one pixel bounding box created by the crop leads to
nonstop crashing on my machine.

Thanks again Howard...you saved me a lot of headache!

Sven


On Wed, Feb 22, 2017 at 5:46 PM, Sven Schönmann <sven.schoenm...@gmail.com>
wrote:

> Hi Howard,
>
> that might be the trick. I had problems with a specific clip earlier which
> was pre-rendered with autocrop. After manually resetting the bounding box
> to the full frame it seemed to me that the crashes became less. I'm gonna
> check my script about bounding boxes...but that might be it!
>
> Thank you!
>
> Sven
>
>
> On Wed, Feb 22, 2017 at 5:39 PM, Howard Jones <how...@axis-vfx.com> wrote:
>
>> Put a crop before the spahirre plugin - the rotos may be changing
>> Bounding boxes and I’m not convinced Saphirre likes that
>>
>> *Howard **Jones*
>> Visual Effects Supervisor
>> m: 07973 265624 | e: how...@axis-vfx.com | w: www.axis-vfx.com
>>
>> On 22 Feb 2017, at 16:21, Sven Schönmann <sven.schoenm...@gmail.com>
>> wrote:
>>
>> Hi everyone,
>>
>> I got massive problems with using the Sapphire OFX plugins in Nuke. Hard
>> crashing without any error message or something every 2-3 minutes. Using
>> the versions mentioned in the subject line. Tried also different Nuke
>> versions and downgraded to Sapphire Version 9.03. Same issues.
>>
>> Are there any known problems with Sapphire I'm not aware of? I'm not even
>> working IN the Sapphire Nodes, just tweaking mattes and rotos that affect
>> the Sapphire nodes eventually.
>>
>> Out of ideas...
>>
>> 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
>>
>>
>>
>>
>> *A X I S V F X*
>>
>> The Bottle Yard Studios
>>
>> Whitchurch Lane
>>
>> Bristol BS14 0BH
>>
>>
>>
>> axis-vfx.com
>>
>> ___
>> 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] NukeX 10.0v6 and Sapphire OFX 10.000 crashing

[Sven Schönmann]

Hi Howard,

that might be the trick. I had problems with a specific clip earlier which
was pre-rendered with autocrop. After manually resetting the bounding box
to the full frame it seemed to me that the crashes became less. I'm gonna
check my script about bounding boxes...but that might be it!

Thank you!

Sven


On Wed, Feb 22, 2017 at 5:39 PM, Howard Jones <how...@axis-vfx.com> wrote:

> Put a crop before the spahirre plugin - the rotos may be changing Bounding
> boxes and I’m not convinced Saphirre likes that
>
> *Howard **Jones*
> Visual Effects Supervisor
> m: 07973 265624 | e: how...@axis-vfx.com | w: www.axis-vfx.com
>
> On 22 Feb 2017, at 16:21, Sven Schönmann <sven.schoenm...@gmail.com>
> wrote:
>
> Hi everyone,
>
> I got massive problems with using the Sapphire OFX plugins in Nuke. Hard
> crashing without any error message or something every 2-3 minutes. Using
> the versions mentioned in the subject line. Tried also different Nuke
> versions and downgraded to Sapphire Version 9.03. Same issues.
>
> Are there any known problems with Sapphire I'm not aware of? I'm not even
> working IN the Sapphire Nodes, just tweaking mattes and rotos that affect
> the Sapphire nodes eventually.
>
> Out of ideas...
>
> 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
>
>
>
>
> *A X I S V F X*
>
> The Bottle Yard Studios
>
> Whitchurch Lane
>
> Bristol BS14 0BH
>
>
>
> axis-vfx.com
>
> ___
> 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] NukeX 10.0v6 and Sapphire OFX 10.000 crashing

[Sven Schönmann]

Hi everyone,

I got massive problems with using the Sapphire OFX plugins in Nuke. Hard
crashing without any error message or something every 2-3 minutes. Using
the versions mentioned in the subject line. Tried also different Nuke
versions and downgraded to Sapphire Version 9.03. Same issues.

Are there any known problems with Sapphire I'm not aware of? I'm not even
working IN the Sapphire Nodes, just tweaking mattes and rotos that affect
the Sapphire nodes eventually.

Out of ideas...

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

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

[Sven Schönmann]

0 130560 130560 130560
> 130560 130560 130560 130560 102437 24586.9 130560 130560 130560 130560
> 102437 32000.7 130560 130560 130560 130560 130560 130560 130560 130560
> 130560 130560 130560 130560 130560 130560 130560 130560 130560 130560
> 130560 130560 130560 37876.2 25811.6 27999
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> -1 -1 -1 -1
> -1 -1 99 99
> -1 -1 -1 -1
> 0.05 0.376684 0.436684
> 0.05 0.376684 0.376684
> 0.05 0.376684 0.376684
> 0.05 0.376684 0.376684
> 0.05 0.376684 0.376684
> 0.05 0.376684 0.376684
> 0.05 0.376684 0.376684
> 0.05 0.376684 0.376684
>   }
>
>  primBodydata { 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 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0 0 0 0
> 0 0 0

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

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 <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 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 <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 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] Mixing footage with different PARs (Pixel Aspect Ratio)

[Sven Schönmann]

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

Re: [Nuke-users] CPU cores vs clock speed

[Sven Schönmann]

Hi all,

lots of good input here.

One thing that confuses me: I was assuming that rendering in Nuke (not in
background mode) would only affect one CPU - especially when rendering a
quicktime movie file. But when I render a file, all my CPUs give full
throttle. At least that is what my CPU-Meters tell me.

Does Nuke render multi-threaded by default?

Cheers

Sven


On Wed, Nov 9, 2016 at 8:44 AM, J Bills  wrote:

> I know it depends on lots of things - but would it be safe to say from
> purely a processor standpoint - the benefits of more cores comes at render
> time, but in an interactive gui session, a faster clocked 4/6/8 core
> machine would be preferable?  Since single threaded horsepower counts for
> quite a bit, and there's only so much that multithreading helps.
>
> I've seen freelancers and one-person shows working from home that seem
> happy with a single 20-36 core machine to take care of their rendering
> needs all in one. But I would think that would be overkill at a shop with a
> solid renderfarm - and you'd just need to focus on interactive session
> power and somewhat disregard rendering.
>
>
>
>
> On Tue, Nov 8, 2016 at 11:07 AM, Daniel Hartlehnert  wrote:
>
>> Hi Michael,
>>
>> I have no direct answer for your question, there are just some things i
>> think are worth considering:
>> Much RAM is not only helpful in general, but more cores also need more
>> memory to do their calculations! Otherwise the system will start swapping
>> and the speed boost is gone.
>> Also, the more cores you have, the faster the bus system has to be in
>> order to keep the cores busy. Data might not be transfered from/to cores
>> fast enough, so they start
>> to sit idle waiting for the rest of the system to catch up.
>>
>> So all in all i would agree with everybody else: higher clock speed over
>> more cores.
>>
>> Daniel
>>
>>
>> Am 08.11.2016 um 16:28 schrieb michael vorberg > >:
>>
>> Thanks for the feedback
>>
>> Am 08.11.2016 16:01 schrieb "Frank Harrison" :
>>
>>> Right now, for NUKE/NUKEX specifically, a hIgher clock speed would be
>>> better. In a future release you will likely see more benefit from a higher
>>> number of cores.
>>>
>>> hth
>>>
>>> On 8 November 2016 at 14:38, michael vorberg 
>>> wrote:
>>>
 I was referring mostly to using nuke
 I know adding as much RAM as possible is helpful, GPU does not matter
 so much but CPU I'm not sure.

 Am 08.11.2016 14:48 schrieb "Rakesh Malik" :

> That depends a lot on the workload, especially these days when the
> processors' clock speeds are so dynamic, in that a 2.5GHz processor can
> overlock itself to over 3GHz. Desktop processors that are designed around
> more robust cooling solutions than mobile processors have even wider
> "turbo" ranges.
>
> Generally, adding more cores gives you more computing power overall,
> so it's more a question of how well the software you're using can take
> advantage of parallelism during rendering. Most software runs in a single
> thread, so adding cores has no direct benefit, but most of the higher end
> solutions in color grading and VFX are heavily threaded and get pretty 
> good
> utilization out of additional cores.
>
> The GPU is another major variable to consider; some software leans
> heavily on the GPU and doesn't use the main processor for computing, and
> some that do a surprisingly good job of consuming both.
>
>
> -
>
>
> [image: --]
>
> Rakesh Malik
> [image: https://]about.me/WhiteCranePhoto
>
> 
> Director of Photography
> http://www.WhiteCranePhotography.com
> 
>
>
>
> On Tue, Nov 8, 2016 at 3:54 AM, michael vorberg <
> pingkin...@googlemail.com> wrote:
>
>> Hi,
>> When buying a new workstation would I benefit more from a CPU with
>> higher clock speed and less cores or do more cores with lower speed give 
>> me
>> overall more render speed?
>>
>> Or is this all a "depends on" question?
>>
>> Greetings,
>> Michael
>>
>> ___
>> 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 

Re: [Nuke-users] Windows 10 / ProRes files viewer

[Sven Schönmann]

Hi Sam,

great...thanks! I will definitely have a look into it. Sounds really good.

And +1 for "tired of VLC"...

Sven


On Wed, Sep 21, 2016 at 4:31 PM, Marrocco, Sam <
smarro...@ringsidecreative.com> wrote:

>
>
> On 9/21/2016 8:35 AM, Sven Schönmann wrote:
>
>> Hey Guys,
>>
>> a little bit offtopic here (sorry) but what do you guys use for just
>> checking ProRes Quicktimes very fast in the OS?
>>
>>
>>
>
> I suggest you look into MPV. It's a derivative of MPlayer that uses
> ffmpeg-related components. We've been experimenting with it for a bit
> for approval viewing and having some good results. Self-contained and
> can be embedded into your own player code if you have programmers
> available. Seems more reliable (for us, at least) than VLC, which always
> seems buggy. Plus, we got tired of VLC's buggy jog controls. MPV also
> plays back uncompressed quicktimes, which seems to crash VLC depending
> which release you use. Free, and cross platform for Windows, Mac and Linux.
>
>
>
> sam marrocco | chief technical officer
> ringside.cutters.flavor.picnic.moonlink
>
> 248 548 2500 w
> 248 910 3344 c
>
> ringsidecreative.com
>
> <http://ringsidecreative.com/>
>
> ___
> 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] Windows 10 / ProRes files viewer

[Sven Schönmann]

Just tried this one: http://www.telestream.net/switch/

Works great...didn't know it had native ProRes support.

Sven


On Wed, Sep 21, 2016 at 3:14 PM, severin mathiesen <seve...@gimpville.no>
wrote:

> VLC ?
>
> 2016-09-21 14:35 GMT+02:00 Sven Schönmann <sven.schoenm...@gmail.com>:
>
>> Hey Guys,
>>
>> a little bit offtopic here (sorry) but what do you guys use for just
>> checking ProRes Quicktimes very fast in the OS?
>>
>> I made the switch to Windows 10 on my private machine (after using Macs
>> for nearly 15 years) and this is one thing that I'm missing. I want to
>> avoid to install the Quicktime Player on Windows, because it basically
>> sucks, is very slow and just annoying.
>>
>> Native ProRes Support in Resolve, Adobe Suite and Nuke runs great without
>> having to install any codec on the system.
>>
>> Is there any program that lets you open ProRes files very fast? I don't
>> need any extras for this...just basically see the file.
>>
>> 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
>>
>
>
>
> --
>
> *Severin Mathiesen*  | Compositor/3D Artist | Gimpville AS
> 
> ---
> M: +47 97 75 42 57 | seve...@gimpville.no
> <http://mail.gimpville.com/WorldClient.dll?Session=VUZDFZT=BlankMessageBody>
>  | www.gimpville.no
> 
> ---
> Øvre Slottsgate 17 | 0157 | Oslo | Norway
>
>
> ___
> 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] Windows 10 / ProRes files viewer

[Sven Schönmann]

Hey Guys,

a little bit offtopic here (sorry) but what do you guys use for just
checking ProRes Quicktimes very fast in the OS?

I made the switch to Windows 10 on my private machine (after using Macs for
nearly 15 years) and this is one thing that I'm missing. I want to avoid to
install the Quicktime Player on Windows, because it basically sucks, is
very slow and just annoying.

Native ProRes Support in Resolve, Adobe Suite and Nuke runs great without
having to install any codec on the system.

Is there any program that lets you open ProRes files very fast? I don't
need any extras for this...just basically see the file.

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

Re: [Nuke-users] extend edge pixels

[Sven Schönmann]

Hey,

check out Nukepedia for gizmos...for example:

http://www.nukepedia.com/gizmos/filter/edgeextend

Cheers

Sven


On Tue, Sep 20, 2016 at 9:48 PM, Gary Jaeger  wrote:

> Anybody have a good way of extending the edge pixels of a premulted image?
> for instance, if I had an image masked by a circle, just to take the edge
> pixels and extend them out xx amount? Sort of like an unpremult but more :0
> Does that make sense?
>
> *Gary Jaeger */ 650.728.7957 direct / 415.518.1419 mobile
> http://corestudio.com
>
>
> ___
> 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] Smart Vector Render

[Sven Schönmann]

Hi Group,

I'm using the new Smart Vectors with unexptected success. Anyway...there
are two things that bother me:

1. I have a 250 frames long exr-sequence. When creating the smart vectors
and nuke crashing at frame 240, you have to render everything again because
when I start a new render at frame 240 he generates a black frame as frame
2400 as a "starting point" and creates the next frames as a reference to
this frame. Did I get this correct? In that case you'd have to render the
whole 250 frames again. Any way to render from any frame with regards to
the original first frame?

2. Because Smart Vector is not an ordinary write-node, I have no success in
rendering multi-threaded with the bg render-gizmo. Any way to do this?

Thanks everyone! Have a great day...

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