[Tig] FCP7 problem
pat at creativitymedia.co.uk
Tue Aug 19 10:37:29 BST 2014
Legal vs full range is another way to collect grey hairs, but this wasn't what wrecked my DCP.
This particular nasty only affected the very bottom end of the luminance range. Highlights and mids weren't touched. Bringing the same Pro Res 4444 QT into After Effects and creating a DPX sequence, and from there into Easy DCP fixed it, whereas sending the same QT straight into Easy DCP resulted in crushed shadow. To my mind this means that different programs still interpret the gamma curve of Pro Res 4444 in different ways - in this case AE did it perfectly and was able to map it to DPX, which made it understandable for Easy DCP creator.
I'm very much looking forward to the creation of a video container that makes it crystal clear exactly what it contains!
Colourist / Head of Picture
Tel: +44 (0) 203 4110 677
Mo: +44 (0) 790 9580 409
DISCLAIMER: The information contained in this email is confidential and may be subject to legal privilege. Access to this email by anyone other than the intended recipient is unauthorised. If you are not the intended recipient, you must not use, copy, distribute or disclose this email or any part of its contents or take any action in reliance on it. If you have received this email in error please notify us immediately by email or telephone.
Registered No. 7341610
On 18 Aug 2014, at 16:51, Joe Owens via Tig <tig at colorist.org> wrote:
> Sohonet www.sohonet.co.uk sponsors the TIG.
> RushTera www.RushTera.com supports the TIG.
> Correct, this is a well-documented and endlessly discussed issue, but calling it a "Gamma Shift" only touches the tip of the iceberg. If it was simply gamma, you would not get illegal pedestal values.
> The root of the problem is that ProRes 4444 can carry either Y'CbCr or RGBA (if an alpha channel is present). It does *not* flag the content for decoding, so the interpreting software guesses one way or the other. The consequence is that 709 Y'CbCr is encoded for 0-100 IRE mapped from (in 10-bit sampling) 64-940. RGBA is mapped as if it were full scale, 0-1024. Gamma is involved as it is applied over the scaling range... which, if the wrong 0-100 target has been applied will screw up the entire grey scale.
> This is so painfully obvious on a scope -- ice-pick-in-the-forehead-obvious -- on an external SDI waveform that it isn't even a matter for speculation.
> Resolve has a handy-dandy toggle for looking at media in either range and the change -- whether the pedestal/gain levels pop up or down would be your first clue.
> I used to have this problem with so-called "uncompressed" exported out of Media Composer by NTFS drives -- imported into Apple COLOR, which would decode it properly, even though Apple Quicktime would assign the media a "no codec" appellation. The wrong scaling would come back if I attempted to render *any* Quicktime codec -- all of them failed. The solution was to export the media as .dpx sequences and recompress to something like "Uncompressed" DNxHD 175/220X or one of the ProRes family. However, that is an old story.
> The other issue of managing the ColorSync settings in Apple Preferences no longer applies beyond Leopard. Apple "fixed" that... but not really, they just took it away and made some assumptions about their clientele.
> On 2014-08-17, at 1:17 PM, Pat Wintersgill via Tig wrote:
>> There is a well documented "Quicktime Gamma Shift" issue,
> Joe Owens
> Presto!Digital Colourgrade
> 302-9664 106 Avenue
> Edmonton, Alberta T5H0N4
> +1 780 421-9980
> jpo at prestodigital.ca
> To change subscription options, see http://tig.colorist.org/mailman/listinfo/tig
More information about the Tig