Problem viewing DSLR video on PC?

Started by skydragon, October 11, 2012, 09:40:05 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

skydragon

Edited to add ; I've left this thread intact, to show the full dialogue, but basically, I now understand that if I try to preview .MOV video clips straight from my Canon 600D (T3i) using my Win7 PC and either Windows Media Player or VLC, the clips will be displayed wrongly in terms of contrast.

What I found out (thanks to help as below) was that the .MOV video files from an EOS camera can be incorrectly played back on a PC, giving a video preview that is wrong in terms of levels and contrast.

I had originally thought there was something wrong with my Sony Vegas Studio NLE software. But in fact I now realise that I was experiencing two 'problems' (misunderstandings on my part) all along, which caused my confusion in what contrast/levels the EOS video clips should preview.

1. Was how  Windows Media Player or VLC played back the EOS .MOV clips on my PC.

2. Was that unless you apply a Computer RGB to Studio RGB level FX to the 8-bit Sony Vegas Studio timeline, the H264 encoder will not compress the video levels of a EOS .MOV file correctly.

(I wonder how many people play EOS .MOV video files on their PC and experience 'dark' footage with incorrect contrast, without realising there is a problem in how they are previewing the video files....? Hopefully this thread will help others who experience the same problem as I did).


-----------------------------------------


Some (many?) Sony Vegas users have probably already figured this out...

But I've just wasted a few days trying to figure out why video from my Canon 600D (T3i) DSLR didn't seem to colour correct or export from Sony Vegas Studio 12 well - the resulting (rendered-out as H264 .mp4) finished video when played back on my PC or uploaded to Vimeo was crushed blacks/detail and blown highlights.

Edited to add - unless you apply a Computer RGB to Studio RGB level FX to the Sony Vegas Studio timeline, the H264 encoder will not compress the video levels of a EOS .MOV file correctly.

Why...read on below (this contains some generalisations, but you'll get my point)

A Canon EOS DSLR's video files are Computer RGB (cRGB 0-255) I use a Canon 600D but I believe the same applies to 7D, 550D, etc

When you view the .MOV clips straight from the EOS camera on a PC using windows media player etc all is well. Windows media player etc handles playback of cRGB 0-255 video correctly.

If you then load the .MOV clip into the timeline of Sony Vegas whilst using a standard default 8-bit vegas project (I don't think this applies to 32 bit projects? But these aren't the standard and I don't use them due to PC speed) the cRGB video clip is automatically converted by Sony Vegas from cRGB 0-255 into sRBG 16-235 (Studio RGB). There is no warning message or notification, his sRGB fact isn't  made clear anywhere as far as I know.

Edited to add - This statement is not correct. The .MOV stays on the vegas timeline as 0-255

So what you may ask...

Well the Sony Vegas preview monitor and the playback monitor both work as standard in cRGB colour space. So you are now viewing a sRGB video in a cRGB viewer. The end result is a dull, washed out look to someone viewing it. As a user unaware of why this is being caused, you then alter the levels and colour to correct the washed out look (wrongly as there is actually nothing 'wrong' with the video clip itself, just your viewing of it in cRGB space) and you end up applying completely wrong levels/correction as a result. Due to Sony Vegas Studio not having any meters or histograms, it makes the whole situation even more confusing.

When you then render out the Vegas timeline as a H264 video, the resulting render has the blacks/detail all wrong (amongst other things). Edited to add - unless you apply a Computer RGB to Studio RGB level FX to the Sony Vegas Studio timeline, the H264 encoder will not compress the video levels of a EOS .MOV file correctly.

The workaround answer, is to apply a 'Studio RGB to Computer RGB' level correction (there is a preset) on the main Vegas preview window. Carry out all your edits, levels and corrections, in the knowledge that your preview window is now visually 'correct' and then when you have completely finished, then remove the 'Studio RGB to Computer RGB' level correction preset, just before you render out the timeline (ie. you must remove the 'Studio RGB to Computer RGB' level correction preset you previously applied to the preview monitor).

Hopefully this info will save someone else having the same hassle.

Apologies to anyone who thinks the above is obvious and to all those out there using 'proper' software with meters etc ;-)
Canon 600D with Battery Grip, ML 2.3, Sigma 17-50mm 2.8, Swivi viewfinder loupe, RJ Follow focus. Loupe, FF and Camera/Battery Grip mounted on a 4mm thick alloy plate.

skydragon

Update;

Ok...I think I'm getting somewhere now, in terms of understanding the 'problem'.

I've just realised... that If I try to play back a .MOV video file from my Cannon 600D (t3i) on my PC using windows media player or VLC player, it plays the video levels back incorrectly, in terms of the blacks getting darkened. I presume this is down to the 0-255 range of the video being expanded by the player and the blacks (and whites?) getting clipped?

If I open and play back a .MOV video file from my 600D on my PC using Apple Quicktime player, it then plays back correctly.I don't normally use QT player, so hadn't seen this.

(As an aside if I deselect 'Use hardware YUV-RGB conversion' in VLC Player's preferences, it then also plays back the .MOV video correctly...any ideas why?)

So...now I know that I've been viewing 'darkened' video clips all the time outside of my editor, back to Sony Vegas...

If I use a 'Computer RGB to Studio RGB levels' FX applied to the Cannon .MOV clips in the Vegas Studio  timeline, then the resulting H264 .mp4 output render is 100% ok and then also plays back ok in all the players on my PC

As a 2nd test if I use Adobe Premiere Pro CS6 and put the Cannon .MOV files straight on the Premiere timeline with no FX and render them straight out H264 .mp4, then the resulting render is 100% ok and then also plays back ok in all the players on my PC

I presume that both of the above H264 output renders result in a sRGB .mp4 file which the players are happy with?

Phew...surely this shouldn't be this difficult ??!!??

The core problem was the fact that my previewing of my camera's .MOV files on my PC desktop using WMP and VLC, resulted in me believing that contrast/levels were different to what they really were...and then doubting the NLE software...

Example of what I mean in terms of video at https://vimeo.com/51237605
Canon 600D with Battery Grip, ML 2.3, Sigma 17-50mm 2.8, Swivi viewfinder loupe, RJ Follow focus. Loupe, FF and Camera/Battery Grip mounted on a 4mm thick alloy plate.

1%

I thought video and photos were shot in sRGB. I've always converted (if necessary) to at least 16 bit intermediate and used 32bit vegas projects. Final result is usually rendered to that and then converted to different formats with something that renders faster than vegas.

Worth checking into though as to what actual color space is and how its handled. All vegas is good for is cutting + audio, any kind of correction is for AE + other programs. I never play back clips just in WMP/VLC expecting final result. After they're rendered/converted they look like what I did to them....

deleted.account

Quote from: skydragon on October 11, 2012, 09:40:05 PM
Some (many?) Sony Vegas users have probably already figured this out...

But I've just wasted a few days trying to figure out why video from my Canon 600D (T3i) DSLR didn't seem to colour correct or export from Sony Vegas Studio 12 well - the resulting (rendered-out as H264 .mp4) finished video when played back on my PC or uploaded to Vimeo was crushed blacks/detail and blown highlights.

Why...read on below (this contains some generalisations, but you'll get my point)

A Canon EOS DSLR's video files are Computer RGB (cRGB 0-255) I use a Canon 600D but I believe the same applies to 7D, 550D, etc

h264 is YCbCr (YCC for short) they don't create RGB, two different color models. They're not cRGB whatever that is, 'Computer RGB', Sony speak I guess.

QuoteWhen you view the .MOV clips straight from the EOS camera on a PC using windows media player etc all is well. Windows media player etc handles playback of cRGB 0-255 video correctly.

What WMP does depends on the underlying DirectShow codec decompressing the h264 and that can vary. But what happens generally is that the media player handles the YCbCr to RGB conversion, which can be in combination with the graphics card, hardware assisted and as a result levels handling can vary.

The Canon MOV's are encoded into the h264 with full 8bit levels, well luma is chroma not. The feed to the camera h264 encoder in camera is raw JFIF YCC that is chroma and luma normalised over the full 8bit range, it isn't RGB.

The MOV files are flagged 'fullrange' by the encoder to flag to the decompressing codec / media player to squeeze the h264 full range levels into 16 - 235 YCC before it's converted into RGB. This is because full range 8bit YCC doesn't fit in 0 - 255 RGB. 8bit speak.

Problem is that older NLE's / codecs / media players may ignore the full range flag or simply handle the source as 16 - 235 and not squeeze the levels before conversion to RGB and chop off levels below 16 and above 235, expand the remaining levels over 0 - 235 and the contrast looks wrong, is wrong. So trusting a media player to give the right results or to extract screengrabs is not a good idea unless it's color managed like Media Player Classic or test first. VLC is a prime candidate.

Here's a test that contains a fullrange flagged file and non fullrange flagged file:

http://www.yellowspace.webspace.virginmedia.com/fullrangetest.zip

VLC, depending on settings will not necessarily show the output correctly, if you don't see the 16 & 235 text then VLC isn't setup right. If the 16 - 235 text does show you're good to go. same for any media player.

Also media players RGB conversion might not even use the right luma coeffs, ie: BT601 or BT709. So pinks can go to orange. Typical result of doing a transcode of BT601 flagged Canon MOVs to any other YCC codec like DNxHD which are all assumed BT709 at HD resolution, resulting in orangey skin tone for example. Ok in camera but not in the mangled transcode and playback. mediainfo will show what luma coeffs are used or assumed. Earlier Canon's like T2i are BT601. 5D MK III is BT709 anyway. Best check before conversion to RGB.

QuoteIf you then load the .MOV clip into the timeline of Sony Vegas whilst using a standard default 8-bit vegas project (I don't think this applies to 32 bit projects? But these aren't the standard and I don't use them due to PC speed) the cRGB video clip is automatically converted by Sony Vegas from cRGB 0-255 into sRBG 16-235 (Studio RGB). There is no warning message or notification, his sRGB fact isn't  made clear anywhere as far as I know.

The difference between 8bit & 32bit projects is to do with YCC to RGB conversion that any NLE does these days and precision.

First the YCC to RGB conversion, as said full range 8bit YCC doesn't fit in 8bit RGB, in fact 16 - 235 YCC doesn't fit completely into 8bit RGB, probably only 35% is transferable the rest can generate invalid RGB values in 8bit RGB and can appear as gamut clipped white artifacts, but NLE's work RGB so what to do?

Live with it or work in a 32bit RGB workspace, this allows the full YCC to be transferred and color processed in RGB, the idea at 8bit is that 16 - 235 YCC maps to 0 - 255 RGB the whole 0 - 1 thing in 32bit speak, anything outside of 16 - 235 can create negative values: ie: below 0 and values above 1, these can be held and used at 32bit wihout gamut clipping, allowing us to grade the output into the 0 - 1 RGB range for encoding back out to 16 - 235 YCC.

Display of coarse is still 8bit and should be based on a 16 - 235 YCC to 0 - 255 RGB conversion, not 0 - 255 YCC to 0 - 255 RGB which Vegas appears to do then at least in 8bit project, but at 32bit it's only the display, not the processing, so there is far far less chance of gamut clipping in 32bit, giving us room to grade without loss from dodgy YCC to RGB conversion.

YCC encoded output from the NLE should always have 16 - 235 levels unless h264 and we reflag the output 'fullrange', that's only possible to do with h264 which has a VUI Options extension to the specification. Annex 5.

For 8bit RGB image sequence output as long as the correct initial luma squeeze is done in YCC to RGB and a BT601 color matrix used, then the levels / contrast etc will be ok in RGB for Canon MOV's. Everything falls in the 0 - 255 RGB (0 - 1 range).

For cameras that shoot 16 - 255 YCC and don't flag the source full range, ie: outside of 16 - 235 like the Sony NEX5n, FS100 etc in an MTS container, I don't think are flagged full range, so it can be more important for those camera sources to be used in a 32bit workspace.

For RGB image sequences converted at 32bit precision in the NLE where YCC levels go beyond 16 - 235 or for Canon MOV's when no levels squeeze has been done then a image format like EXR is required that can store RGB levels range < 0 and > 1.

The 32bit precision part of the process maps at the 8bit YCC range is mapped into the 65536 levels range of 32bit it allows greater precision in color processing.

QuoteSo what you may ask...

Well the Sony Vegas preview monitor and the playback monitor both work as standard in cRGB colour space.

There's no such thing as cRGB, it's sRGB in the monitor, sRGB / BT709 are the primaries that define the gamut. What you seem to be inferring is that Vegas displays the sRGB from the YCC (rec709) to sRGB (RGB) source assuming full 8bit levels rather than 16 - 235 limited range?

QuoteSo you are now viewing a sRGB video in a cRGB viewer. The end result is a dull, washed out look to someone viewing it. As a user unaware of why this is being caused, you then alter the levels and colour to correct the washed out look (wrongly as there is actually nothing 'wrong' with the video clip itself, just your viewing of it in cRGB space) and you end up applying completely wrong levels/correction as a result. Due to Sony Vegas Studio not having any meters or histograms, it makes the whole situation even more confusing.

The underlying problem is the decompression of the original h264 source and handling of that by any vid card intervention that Vegas may use, if the fullrange flag is respected the YCC will be squeezed into 16 - 235 YCC, then converted to 8bit RGB (16 - 235 to 0 - 255 RGB) for playback and that will be correct preview. Going back to the full range luma test files.

QuoteWhen you then render out the Vegas timeline as a H264 video, the resulting render has the blacks/detail all wrong (amongst other things).

The workaround answer, is to apply a 'Studio RGB to Computer RGB' level correction (there is a preset) on the main Vegas preview window. Carry out all your edits, levels and corrections, in the knowledge that your preview window is now visually 'correct' and then when you have completely finished, then remove the 'Studio RGB to Computer RGB' level correction preset, just before you render out the timeline (ie. you must remove the 'Studio RGB to Computer RGB' level correction preset you previously applied to the preview monitor).

Hopefully this info will save someone else having the same hassle.

Apologies to anyone who thinks the above is obvious and to all those out there using 'proper' software with meters etc ;-)

I've heard this too, but had to respond as all the Sony speak about cRGB etc is just plain bad.

skydragon

Thanks y3llow for taking the time to reply with such a detailed answer, much appreciated.

For me, as a newcomer to DSLR video, it's a real learning curve and eyeopener to now appreciate and learn that WMP and VLC don't playback my camera's .MOV files coreectly.

I've always 'expected' a standrard media player to 'correctly' play back a common type of media file. ...mistake in my part ;-)

I need to read your post a few more times to absorb all the onfo, but it was most helpful, thanks.
Canon 600D with Battery Grip, ML 2.3, Sigma 17-50mm 2.8, Swivi viewfinder loupe, RJ Follow focus. Loupe, FF and Camera/Battery Grip mounted on a 4mm thick alloy plate.

deleted.account

Quote from: skydragon on October 13, 2012, 02:40:19 AM
Update;

Ok...I think I'm getting somewhere now, in terms of understanding the 'problem'.

I've just realised... that If I try to play back a .MOV video file from my Cannon 600D (t3i) on my PC using windows media player or VLC player, it plays the video levels back incorrectly, in terms of the blacks getting darkened. I presume this is down to the 0-255 range of the video being expanded by the player and the blacks (and whites?) getting clipped?

It's taking the 16 - 235 levels range and mapping to 0 - 255 RGB without first squeezing the YCC levels into 16 - 235.

QuoteIf I open and play back a .MOV video file from my 600D on my PC using Apple Quicktime player, it then plays back correctly.I don't normally use QT player, so hadn't seen this.

I'd suggest not using QT or QT player for anything, really. :-) QT / Player converts the 4:2:0 YCC to 4:2:2, and auto adjusts levels. Results will vary, not reliable.

Quote(As an aside if I deselect 'Use hardware YUV-RGB conversion' in VLC Player's preferences, it then also plays back the .MOV video correctly...any ideas why?)

You're telling VLC to get the vid card / driver to do the YCC to RGB conversion, whether that gets done correctly and that the right color matrix is used, ie: BT601 for T2i, BT709 for 5D MK III is anyone's guess depending on vid card and driver version.

QuoteSo...now I know that I've been viewing 'darkened' video clips all the time outside of my editor, back to Sony Vegas...

If I use a 'Computer RGB to Studio RGB levels' FX applied to the Cannon .MOV clips in the Vegas Studio  timeline, then the resulting H264 .mp4 output render is 100% ok and then also plays back ok in all the players on my PC

Perhaps double check with the fullrangetest.zip

QuoteAs a 2nd test if I use Adobe Premiere Pro CS6 and put the Cannon .MOV files straight on the Premiere timeline with no FX and render them straight out H264 .mp4, then the resulting render is 100% ok and then also plays back ok in all the players on my PC

Premiere CS5, 5.5 & 6 use MainConcept h264 codec and they respect the Canon h264 stream ' fullrange' flag so the full range levels of the Canon h264 get squeezed into 16 - 235 YCC before conversion to RGB, which has to be done at some point before encoding out. The encoded out h264 is no longer full range levels, it's 16 - 235, different from the incoming Canon h264.

The correct levels range for YCC is 16 - 235 (240 for chroma) so that the 'correct' YCC to RGB conversion is more likely done in the multitude of media player / codec handling out there and there is no reliance on the fullrange flag, which is only available in h264 anyway.

QuoteI presume that both of the above H264 output renders result in a sRGB .mp4 file which the players are happy with?

Phew...surely this shouldn't be this difficult ??!!??

No sRGB is RGB color model and has a 2.2 gamma curve applied so it's Display Referred :-). The h264 is YCbCr color model and has a rec709 gamma curve applied which differs from sRGB and rec709 is Scene Referred. This really only matters when linearizing the source in a 32bit float linear RGB workspace ensuring the correct reverse gamma function is applied.

QuoteThe core problem was the fact that my previewing of my camera's .MOV files on my PC desktop using WMP and VLC, resulted in me believing that contrast/levels were different to what they really were...and then doubting the NLE software...

Example of what I mean in terms of video at https://vimeo.com/51237605

Yep, a common problem and why it is not a good idea to rely on a media player for any kind of analysis or screen grabs because so much interpretation of the YCC source happens before we actually see a result on our RGB monitors, a tool like AVISynth will prove much better for that.

Also a decent color managed and calibrated screen combined with a tested and color managed media player helps.

**EDIT**

Posted whilst you were replying, you're welcome.

KarateBrot

QuoteThe core problem was the fact that my previewing of my camera's .MOV files on my PC desktop using WMP and VLC, resulted in me believing that contrast/levels were different to what they really were...and then doubting the NLE software...

A great tool (especially for compositing work) is the "RV" viewer from Tweak Software.
If you donate a RED EPIC to me you officially are very cool ;)

skydragon

Thanks again, all is becoming clearer to me now.

Starting with AVIsynth and using your fullrangetest samples I need to now work out what player I'm going to use on my Win7 PC moving forwards.

KB - the RV software looks an amazing tool, but unfortunately as a hobbiest/amateur it is out of my price league.
Canon 600D with Battery Grip, ML 2.3, Sigma 17-50mm 2.8, Swivi viewfinder loupe, RJ Follow focus. Loupe, FF and Camera/Battery Grip mounted on a 4mm thick alloy plate.

deleted.account

hi, skydragon. Media Player Classic offers Color Management & control over levels. Also VLC will do the job too, just need to test with the fullrange samples and tweak settings. Alternatively ffmpeg's ffplay will do the job too.

http://ffmpeg.zeranoe.com/builds/

A static build will provide ffplay in the bin folder.

Good luck.

**EDIT**

If using AVISynth, makes sure to download ffmpegsource2 for your import plugin and add to a script like this:

ffmpegsource2("mymov.MOV", threads=1)

http://code.google.com/p/ffmpegsource/