see ya

[quote author=yellow link=topic=290.msg4267#msg4267 date=1334779674] Interpretation and subjective generalisation. With regard to Canon (any model) vs GH2 skin tone comment & video is actually YCbCr not RGB comment.[/quote] [quote]I am sorry. English is not my native language. Are you saying that using RGB workspace means misinterpretation and results in bad colors? [/quote] Sorry, I was trying to leave my comment open for discussion and interpretation. I was suggesting that as a YCbCr to RGB color space conversion is done for those RGB scopes and the preview window that so much is judged from including making assertions that skin tone is better on Camera A than Camera B are all products of a interpretation of the native YCbCr source, even putting GH2 and Canon files in the same NLE project side by side proves nothing unless the conversion to RGB method can be assured and preferably controlled as each uses different methods in encoding. Hence the image to illustrate the variance depending on interpretation in conversion to RGB.

Interpretation and subjective generalisation. With regard to Canon (any model) vs GH2 skin tone comment & video is actually YCbCr not RGB comment. Please see below a composite image, consisting of the same selected area from a single frame off a single Canon MOV video file repeated 12 times. To clarify the same selection of the same frame number of the same Canon MOV. Non of the selections have been graded yet they appear different in tone as a result? Not saying that GH2 isn't better than Canon. Frankly not interested, more to choosing a camera than that. [img]http://www.yellowspace.webspace.virginmedia.com/skintone.png[/img]

Just tranfer the color matrix of you mkII sources to BT709 and that should be sufficient. Then both mkII and III will be BT709 which is the default for HD unless flagged in the stream otherwise. How you transfer the matrix you'll need to search, I use Avisynth but may not be suitable for you, your NLE hopefully has a filter or something to transfer the matrix BT601->BT709. The color matrix relates to conversion of YCbCr sources to RGB and therefore playback. With regard to the other query, as soon as you transcode or import Canon native files your full luma gets squeezed and then expanded back to so called RGB levels by the NLE because of the h264 having metadata in the header of the stream signalling full range luma so instead of just leaving levels where they are the NLE squeezes luma 16 - 235 in order to do the typical 16 YCC maps to 0 RGB and 235 YCC mapped to 255 RGB in order to maintain levels when the data is RGB in the NLE for color processing but in the process you loose fine gradation of original levels. It can be clearly seen when it happens by thickened horizontal lines at regular intervals in your luma waveform monitor. I explain here: www.blendervse.wordpress.com transcoding is unnecessary to fix full luma handling a simple remux with a VUI Options aware tool like a custom build of MP4Box will surfice as explained in the blog post. But if transcoding for playback reasons you could remux to dump the metadata and you'll be able to transcode to any codec you like and keep full luma including Prores. Whether this process is suitable for Mac I don't know.

[quote]The colour space of video is now broadcast HDTV standard Rec. 709 (thanks for the discovery, David Newman on Twitter). The 5D Mark II had the old standard definition 601 colour space, which didn’t make any sense at all[/quote] Ok, so this is where the total misinformation has come from about rec709, and the wrong assumption that David was talking about restricted 16 - 235 luma which he wasn't. ;-) David was talking about the Color Matrix not the color space.  Canon MOV's have always been rec709 color space. That is the color primaries have always been rec709/sRGB and the transfer curve has always been rec709. And being rec709 doesn't mean it has to be restricted 16 - 235, it can be full range luma. Just like old SD DV BT601 sources can be full range luma. Have to test the source to find out. The color matrix has changed from BT601 to BT709 with the mk III I guess because so many transcoded the MOVs and lost the BT601 declaration in the header and therefore due to pixel count being HD BT709 is assumed by the media player / NLE so getting the color matrix wrong means pinks go to orange in previews so bang goes skin tone. :-) David was surprised that Canon's were BT601 Color Matrix when I asked him on Cineform Insider back in Nov 2010: [url=http://www.blogger.com/comment.g?blogID=13372801&postID=4688493609703624231]http://www.blogger.com/comment.g?blogID=13372801&postID=4688493609703624231[/url]

[quote author=5DGH link=topic=456.msg2898#msg2898 date=1332567338] Or, maybe it's because 16-235 mk iii is misread as 0-255. Ppro does that.  Try 16-235 on the new PhotoShop CS6 (interpret footage -> HDTV, REC. 709 16-235). [/quote] Seriously that is bad misinformation, mkIII is not 16 - 235 luma it's full range. This is the second reference to mkIII being 16 - 235, where have you read or assumed it's no longer full range. The myth needs busting. :-) What version of Ppro are you talking about. CS5 squeezes the full range into 16 - 235 so it previews correctly which is unhelpful but that's what it does unless the native Canon MOVs are remuxed and the flag switched off.

Andrew, sorry but you are totally wrong on the rec709 section of your MKIII review, it still is full range not 16 - 235, looking at Dan Chungs samples for example, with Avisynth they're clearly full luma. [url=https://vimeo.com/38728208]https://vimeo.com/38728208[/url] What has changed is the color matrix from BT601 to BT709 this only affects any conversions to RGB, like for preview and color processing, probably done because when users transcode they generally loose the BT601 color matrix reference, so before BT601 would have been incorrectly replaced with BT709 as BT709 is default for HD when nothing is declared in the header, as a result pinks would shift to orange, now that mis representation won't happen. Also Canon MOVS are still flagged as 'full range' in the header of the h264, so any codec like QT immediately squeezes the luma 16 - 235 bringing it into the NLE to ensure it encapsulates the full range data, this is unnecessary for an NLE like CS5 to avoid the luma sqeeze the full range flag just needs switching off. But if decoded with a codec that just decompresses without scaling luma, it's clear to see mkIII sources are still full luma. Finally I'd suggest avoiding 5DToRGB well at least the beta, may be that's updated now, because the test I did with it recently with Canon MOVs showed that in fact 5DToRGB scales the luma 16-235 in transcodes to DNxHD for sure. Only the color matrix has changed. A link to a couple of test files to illustrate codec handling of Canon MOVs. [url=http://www.yellowspace.webspace.virginmedia.com/fullrangetest.zip]http://www.yellowspace.webspace.virginmedia.com/fullrangetest.zip[/url] And a link to a Canon MOV (T2i) illustrating what really is in a full range file where the flag has been switched off to see how a NLE handles them differently depending on flag on/off.. Personally I think that the Canon MOVs should be quickly remuxed and the flag switched off to avoid unnecessary luma squeezing. [url=http://www.yellowspace.webspace.virginmedia.com/flagoff.mp4]http://www.yellowspace.webspace.virginmedia.com/flagoff.mp4[/url] Due to the codecs honoring of the full range flag any transcoding with tools like Mpegstreamclip will also squeeze the luma.