Hi,
We are having problems with the ScannedGrain node in 6.3v5 under Linux.
When rendering, what seems to be happening is that if you have a batch/chunk
size set to 1 it will only use one frame for the grain sample and render static
grain over the sequence, if you have a larger chunk size like
Hi Christoffer,
we ran into this exact same problem just last week, contacted the
foundry and was told this is a known issue and has been logged as bug
#22989.
The work around we found was to set expressions to your frame numbers
or seed in order to get the result that you're looking for.
How are Nuke users handling workflows in which they need to deliver images
with alpha that will be composited in sRGB space not linear space?
Essentially we have a situation where you would need to find equations for
u and v such that (xy + z(1-y))^(1-2.2) = (uv + z^(1-2.2)(1-v)).
My initial
I wouldn't think that SSD performance has any baring on r3d performance. I
think you're CPU bound. Most NUKE footage is only about 45MBs @ 24p. I
don't think any computer without a red-rocket can decode that fast.
On Sun, Nov 13, 2011 at 4:23 AM, Adrian Baltowski
adrian...@poczta.onet.plwrote:
well it depends on how it decodes the footage. There are plenty of
apps that can play back r3d in real time even before the red rocket
existed. Even Color can play it back in RT. Its just that most of
those apps when in playback mode decode at a lower setting which is
usually fine when its
BUMP!
Has anyone seen this behaviour in any version of Nuke? Any ideas what is
causing it?
Thanks,
Mike
On 13 November 2011 12:11, Mike Owen mjno...@gmail.com wrote:
Hi,
In Nuke v6.3v1, sometimes when creating a read node with an exr sequence,
we get the actual read node label in the DAG
If I'm not mistaken Color could playback 1k in real time, not 4k.
-deke
On Monday, November 14, 2011, Randy Little randyslit...@gmail.com wrote:
well it depends on how it decodes the footage. There are plenty of
apps that can play back r3d in real time even before the red rocket
existed.
