files look different in shake

	Re: files look different in shake by Les Stuck on Apr 1, 2009 at 9:47:42 pm "You can load Shake's Viewer Lookup controls into the Parameter tab, and change the viewerGamma parameter to .818 to preview how your composition will look in Final Cut Pro's Canvas window. This only changes how your image is displayed in the Shake Viewer, and does nothing to change the Gamma of the script's final rendered image." ...taken from this extensive article on the subjectl: http://support.apple.com/kb/HT2912 www.stuckfootage.com Respond to this post   •   Return to posts index

	Re: files look different in shake by David Coiffier on May 27, 2009 at 3:36:45 pm FCP 'send to shake' command is just overcool, and works really well, as long as you strictly have ASCII clip names (no accent, no punctuation, that kinda things). ProResHQ is definitely the good choice to work with between FCP, Shake (latest version only), and AE4 (and not CS3!!). The gamma issue is even more complex than Apple says, but to make it short, FCP is always right, and can be used as a reference. Now FCP outputs correctly any YUV file, and it's about the only one to do it correctly. Really. Scary but real... The hard stuff is giving realtime output thru video board onto your HD monitor. While being in FCP, no issue, files are already YUV. But what any other app ? Shake, AE, or anything else are RGB only apps. So you must 'emulate' YUV from RGB, to provide feedback onto your HD monitor. The .818 does NOT fix the gamma issue. It is actually just getting the gamma linear, but not correctly. I've just posted in another thread my workaround for getting right gamma when working in Shake. Here is a copy : The correct video gamma isn't just obtained from RGB values with a single ratio conversion, as claimed by Apple. The wrong way of getting 'right' gamma is to set broadcast monitor gamma to .818, you get when dividing native RGB mac gamma (1.8) by video native gamma (2.2). But as we all noticed, this does not fix density shift. BTW, shift occurs not between Shake and FCP, but rather between YUV output driven by realtime converted RGB values (your Shake broadcast monitor feature) and real YUV coded file, read thru your video board, with no conversion. My workaround is based on linear HDCAM ramp, captured with FCP. When played back in FCP, profile monitor shows a perfectly linear ramp (flat slope). When seen thru Shake monitor feature, with a monitor gamma set to 0.818, ramp is indeed linear, except in the lowest values where you can clearly see an exponential attack instead of linear attack, causing black too bee too deep, and the linear part to start too late, giving an ovrall too deep gamma as well. So FCP doesn't display too light blacks, but Shake is displaying too deep blacks... I managed to manually correct the ramp with a colorcorrect node, to get it start at the right place, and with a linear slope all the way. Now I've done this, I set viewer gamma to .818 and then add my colorcorrect node that gives pretty correct linear gamma. This node is only usefull when working, and you need to remove before rendering, as this correction is only to get correct output on your broadcast monitor. Note that when this node is active, you computer viewer appears way too bright, so you really have to work only with your HD monitor... My ColorCorrect node is set this way, in TMV values : master controls : flat low controls : Gain V = 2 Gamma V = 1.17 mid controls : Gamma V = 1.17 Hope I was clear, and this workaround will be useful, cause it's a real issue when color timing with Shake... Respond to this post   •   Return to posts index