Color change with d7000 footage

[sKRUVEN]

Ive got some Nikon D7000 footage that im trying to run through avisynth with QTInput and it looks good when loaded through virtualdub (both with and without ConvertToYV12) but when encoded with megui x264 there is a change in brightness and colors. So I thought that this would do the trick
ColorMatrix(mode="Rec.601->Rec.709")
ConvertToYV12(matrix="Rec709")
but i got this error "converttoyv12:invalid "matrix" pamameter (RGB data only)". What am I doing wrong?

[Yellow_]

I'd avoid QTInput for such and use ffmpegsource2 instead, Quicktime is best avoided, not sure why you're using converttoyv12 except that by default QT will convert to yuy2 and squeeze the luma in your source if its anything like what it does to Canon h264AVC

You missed the dot out between Rec & 709?

Is your source restricted luma? Is your source BT601?

[Gavino]

ConvertToYV12(matrix="Rec709")
but i got this error "converttoyv12:invalid "matrix" pamameter (RGB data only)". What am I doing wrong?
As Yellow_ says, you might be better off using ffmpegsource2, but the error here is that 'matrix' is only needed (and only accepted) when converting to and from RGB, not for conversion between YUY2 and YV12. Just leave out the matrix parameter here.

You missed the dot out between Rec & 709?
In the 'Convert' functions, there is no dot - they use "Rec601" and "Rec709" (but "PC.601 and "PC.709").
However, ColorMatrix does require a dot, so there is an inconsistency between them.

[sKRUVEN]

I'd avoid QTInput for such and use ffmpegsource2 instead, Quicktime is best avoided, not sure why you're using converttoyv12 except that by default QT will convert to yuy2 and squeeze the luma in your source if its anything like what it does to Canon h264AVC

You missed the dot out between Rec & 709?

Is your source restricted luma? Is your source BT601?

Cant realy avoid Quicktime since it records to a .mov container. And meGUI only accepts yv12.

This is what mediaInfo says: Matrix coefficients BT.470-6 System B, BT.470-6 System G, BT.601-6 625, BT.1358 625, BT.1700 625 PAL, BT.1700 625 SECAM, IEC 61966-2-4 601
So i guess that its bt601. Dont realy know were this goes wrong but I use mpc for comparing the clips and it outputs rgb so can it assume that its bt.709 since it hd and theres were it goes wrong? But if this was true both the original h264 .mov and my x264 .mp4 should look darker. So it should be a problem with x264. megui or is it mpc/decoder problem? And as I said it looks like the source with or without converttotv12 in virtualdub fast recompress, and if I understand this is because there is no rgb conversion?

edit. I tried FFmpegSource2 but when I load the script in meGui it crashes. In virtualdub QTInput and FFmpegSource2 looks the same.

edit2. I ran the clip through Premiere Pro and got the same change as with megui.

[Motenai Yoda]

try colormatrix("Rec601->Rec709")

[Yellow_]

Cant realy avoid Quicktime since it records to a .mov container. And meGUI only accepts yv12.

You certainly can avoid Apple Quicktime and use FFmpegSource2 instead, I have a Canon 550D and do every day. But that's your choice. And your source should be YV12 via FFmpegSource2 it'll be YUY2 via QTInput, that's what Apple Quicktime via QTInput does as default, from what I've seen with Canon h264.

This is what mediaInfo says: Matrix coefficients BT.470-6 System B, BT.470-6 System G, BT.601-6 625, BT.1358 625, BT.1700 625 PAL, BT.1700 625 SECAM, IEC 61966-2-4 601
So i guess that its bt601.

Color Matrix yes, when going to RGB such as extracting an accurate and worthwhile image from the h264 source or any YCC source.

Dont realy know were this goes wrong but I use mpc for comparing the clips and it outputs rgb

I don't know mpc, but with something like Virtualdub or AVSPmod it's best to add ConvertToRGB(whatever matrix Rec or PC to suit your source) in your avs script for the sole purpose of accurate RGB images. Hash it out or remove it before encoding. ;-)

The 'standard' conversion from YCC to RGB will scale your full range luma if you have that in your source and possibly use the wrong Color Matrix, reds go to orange for example interpreting a BT601 as BT709 and the luma scaling will increase contrast, crushing your shadows.

so can it assume that its bt.709 since it hd and theres were it goes wrong? But if this was true both the original h264 .mov and my x264 .mp4 should look darker. So it should be a problem with x264. megui or is it mpc/decoder problem? And as I said it looks like the source with or without converttotv12 in virtualdub fast recompress, and if I understand this is because there is no rgb conversion?

edit. I tried FFmpegSource2 but when I load the script in meGui it crashes. In virtualdub QTInput and FFmpegSource2 looks the same.

Looks can be deceiving. ;-)

edit2. I ran the clip through Premiere Pro and got the same change as with megui.

Means nothing, Premiere depending on version (anything pre CS5) does a typical conversion to RGB, scaling your luma, if it's full range.

Suggest establishing exactly what your source is, add Histogram(mode="classic") after ffmpegsource2 and see where your luma is. If is't in the brown, then it's full range, so PC matrix apply. If it's not in the brown it may be that your camera doesn't do full luma, the Canons h264 is, best way to tell is exposing to clip in camera and test with the histogram.

I don't quite understand why you want to transfer the matrix, unless you're loosing it from the header in your encode, check with mediainfo. It's common for players to go on pixel count when a specific color matrix is not declared or ignore it completely and generally BT709 will be used for HD, your source is 601, so there will be a color shift in that case.

I don't use meGUI so I don't know why it crashes with FFmpegSource2, I find it very stable.

[poisondeathray]

Note FFMS2 changed behaviour in 2.16 (maybe it was 2.15 ?) , Canon and Nikon DSLR clips were decoded full range YUV (Y' 0-255) , now they are 16-235 Y' like Quicktime API

If QTInput and FFVideoSource() look the same in the preview of vdub or avspmod , then it's likely you are using recent FFMS2


But if this was true both the original h264 .mov and my x264 .mp4 should look darker.


How are you determining all this ? How are you determining what the "original" looks like? ie. How is it setup ? e.g. do you have 1 player open, check, then close it ? What renderer? What decoder ? What player ?

Difference between Rec601 and Rec709 won't be a big difference in luminance (ie. it won't be darker or brighter) - there will only be slight shift in colors.

[sKRUVEN]

You certainly can avoid...
Ok I got FFmpegsource2 working now and I checked with Histogram(mode="classic") and it stoped before reaching brown and as poisondeathray said FFMS2 now uses 16-235 so that should be correct right?

This looks the same as only ffmpegsource2("C:\clip.mov") both in colors and brightness in virtualdub. ffmpegsource2("C:\clip.mov")
ColorMatrix(mode="Rec.601->Rec.709")
converttorgb(matrix="Rec709")

I then did 2 encodes one with converttoyv12() and one with converttoyv12()
ColorMatrix(mode="Rec.601->Rec.709") after comparing them I saw that red looked like orange in the one with only converttoyv12. So I got the luma range and matrix worked out but when comparing my encode to the original my still looks darker.


And yes im loosing the header and from what ive read about the header options under V.U.I in x264 they dont seem to be that supported. It's common for players to go on pixel count when a specific color matrix is not declared or ignore it completely and generally BT709 will be used for HD This was my perception about it aswell thats why I wanted to convert it to rec709.



ow are you determining all this ? How are you determining what the "original" looks like? ie. How is it setup ? e.g. do you have 1 player open, check, then close it ? What renderer? What decoder ? What player ?
I use MPC-HC with multiple players opened and switching between them. EVR custom pres and internal decoder.
And when comparing the scripts I use virtualdub fast recompress.

edit. ffmpegsource2("C:\clip.mov") this looks the same as my final encoded version for some reason so I guess the problem is with mpc-hc displaying the d7000 footage or ffmpegsource2/QTInput. Thanks for the help guys :)

[TheFluff]

Note FFMS2 changed behaviour in 2.16 (maybe it was 2.15 ?) , Canon and Nikon DSLR clips were decoded full range YUV (Y' 0-255) , now they are 16-235 Y' like Quicktime API

If this has changed, it's libavcodec (or libavformat) that changed something, not FFMS2 itself.

In any case, if you want to know what FFMS2 (or rather, libavcodec) thinks about the color range of a clip, you can use
subtitle(string(FFCOLOR_RANGE))
which will display:

0 if the color range is unknown or unspecified
1 if libavcodec thinks the output is limited range (16-236), or
2 if libavcodec thinks the output is full range (0-255).


You can also get the color matrix in a similar fashion with
subtitle(string(FFCOLOR_SPACE))
which will display:

0 if the video is RGB
1 if the video uses Rec.709 coefficients
2 if the color matrix is unknown or unspecified
4 if the video uses FCC coefficients (almost the same as Rec.601)
5 if the video uses BT470BG coefficients (exactly the same as Rec.601)
6 if the video uses SMPTE170M coefficients (exactly the same as Rec.601)
7 if the video uses SMPTE240M coefficients (almost the same as Rec.709)


This completely illogical and inconsistent numbering is a result of being compatible with the MPEG-2 spec.


Speaking of which, we should probably add some of this metadata we export in secret to the FFInfo() function...

[Yellow_]

Note FFMS2 changed behaviour in 2.16 (maybe it was 2.15 ?) , Canon and Nikon DSLR clips were decoded full range YUV (Y' 0-255) , now they are 16-235 Y' like Quicktime API

I've checked this for myself and yes 2.15 exhibits 'correct' behaviour, no scaling luma, 2.16 does exhibit luma scaling. :-)

QT can and does decode full luma, here: http://forum.doom9.org/showpost.php?p=1509030&postcount=109 so don't think 16 - 235 has anything to do with QT API, BUT the issue with full range luma is that if it is flagged ON, and Canon .movs are, the flag causes QT to decode as 16 - 235, switch the flag OFF and QTInput decodes as 0 - 255, confirmed here:

http://forum.doom9.org/showpost.php?p=1522549&postcount=126

So as it stands QTInput does not work correctly, nor does FMMS2, with full range luma flagged ON at least, Nikons may or may not be full luma may or may not be flagged.

Samples:

Correct:

http://www.yellowspace.webspace.virginmedia.com/Painter_FMMS215_PC601-histo.png

Incorrect:

http://www.yellowspace.webspace.virginmedia.com/Painter_FMMS216_Rec601-histo.png

http://www.yellowspace.webspace.virginmedia.com/Painter_FMMS216_PC601-histo.png

Lower color information, spiked histogram.

Testing the same .MOV with Blender using FFmpeg from git does a 'correct' full range luma conversion, no spiked histogram. Problem lies with FFMS2 2.16 it would appear.

Difference between Rec601 and Rec709 won't be a big difference in luminance (ie. it won't be darker or brighter) - there will only be slight shift in colors.

Luma wise no, but color wise yes, depending on colors in source obviously, red/pinks will go orange. As we know.

Ok I got FFmpegsource2 working now and I checked with Histogram(mode="classic") and it stopped before reaching brown and as poisondeathray said FFMS2 now uses 16-235 so that should be correct right?

Not necessarily, if your source is full luma then no it's not right as FMMS2 2.16 is not right IMHO. Sorry TheFluff, I'm very grateful we have the plugin at all. It is right if the Nikon doesn't encode using full luma, you really need to test a sample that is ETTR, exposed to the right and making use of the full luma. Suggest using FMMS2 2.15 as a comparison. :-)

after comparing them I saw that red looked like orange in the one with only converttoyv12. So I got the luma range and matrix worked out but when comparing my encode to the original my still looks darker.

Your still should look darker than a 'correctly, for the purposes of analysis that is' extracted YCC to RGB video frame, as there hasn't been the typical mapping 16 to 0, 235 to 255, your video frame via AVIsynth will show the levels in the video not the interpretation to RGB by a player. AVISynth gives the control to do that. :-)

However if your source is full luma, clipped to 16 - 235 then expanded to 0 - 255 RGB then it will look brighter still. :-) Think I've got that the right way round.

And yes im loosing the header and from what ive read about the header options under V.U.I in x264 they dont seem to be that supported. This was my perception about it aswell thats why I wanted to convert it to rec709

Are they not? I'm pretty sure declaring color matrix is in x264, certainly fullrange flag is available. But perhaps transfer to 709 is safer, if player handling is unknown.

edit. ffmpegsource2("C:\clip.mov") this looks the same as my final encoded version for some reason so I guess the problem is with mpc-hc displaying the d7000 footage or ffmpegsource2/QTInput. Thanks for the help guys :)

You may want to revisit it.

If this has changed, it's libavcodec (or libavformat) that changed something, not FFMS2 itself.

Could you check? FFmpeg from git does no clamping of luma. Results using FMMS2 do show clamped luma. Maybe the ffmpeg build in FFMS2 is with respect, 'dodgy', now corrected in ffmpeg git?

[TheFluff]

Could you check? FFmpeg from git does no clamping of luma. Results using FMMS2 do show clamped luma. Maybe the ffmpeg build in FFMS2 is with respect, 'dodgy', now corrected in ffmpeg git?

You're correct, under certain circumstances FFMS2 will always rescale the input to limited range, and it's a bug in FFMS2 itself (more specifically, with the settings it passes to swscale). I'll try to get that fixed ASAP.

[Yellow_]

You're correct, under certain circumstances FFMS2 will always rescale the input to limited range, and it's a bug in FFMS2 itself (more specifically, with the settings it passes to swscale). I'll try to get that fixed ASAP.

Many thanks for the confirmation.

[sKRUVEN]

Yellow_ I used FFMS2 v2.15 with Histogram and you were completly right its full range :). So what should I do now, should I encode it with full range flag in x264 and hope that players will display it correctly? And what about the colormatrix should I use PC range now when i need to use converttoyv12 for megui beacause it looks like players still assume 709. Looks like its the same specc on the d7000 as ypur 550d whats your workflow? It feels like I have two options, flag it as fullrange and rec601 in x264 or convert it to tv range rec709 to avoid confused players and video sharing sites.

[Yellow_]

Yellow_ I used FFMS2 v2.15 with Histogram and you were completly right its full range :). So what should I do now, should I encode it with full range flag in x264 and hope that players will display it correctly?

Well, after all discussion, for final delivery and playback, I go to 16 - 235 luma. But all operations prior to that, making sure all steps respect full range luma if the source is. :-)

And what about the colormatrix should I use PC range now when i need to use converttoyv12 for megui

Using FFMS2 you shouldn't need to ConvertToYV12, FFMS2 will give you that by default. QTInput didn't, it gave you YUY2 and may have been the thing that tripped meGUI up. :-)

beacause it looks like players still assume 709.

Yes, transferring the matrix to 709 is probably the safest.

For a simple YCC to YCC encode like you have here, there's really not much more to it.

It's only when something starts screwing with the source, in this case QTInput & FFMS2 1.6 in the process of doing that encode and the analysis steps that follow to work out why something doesn't look right, including screenshots from players and conversions to RGB outside of a tool like AVISynth, that it really is a benefit to know your source and the way to extract meaningful info in general. I'm still learning. :-)

Looks like its the same specc on the d7000 as ypur 550d whats your workflow?

That varies a lot depending on job and time available. :-)

[sKRUVEN]

got around converttoyv12 thing in megui with FFmpegSource2("C:\.mov", colorspace = "yv12")

So for final video i will use this FFmpegSource2("C:\.mov", colorspace = "yv12") #2.15
ColorYUV(levels="PC->TV")
ColorMatrix(mode="Rec.601->Rec.709")

Thank you so much for clearing this out, its been bothering me for quite some time but ive never got around to realy get down and dirty to figure all this out.
Oh and one last thing should i use clamp with colormatrix? Im sorry but getting really tired so im to lazy to read up on it, I dont know what it does but I have a feeling that it has something to do with this.

[Yellow_]

Do you mean coring in ColorYUV? Clipping range to 16 - 235 rather than squeezing? If so no I don't use coring or Opt as it is in ColorYUV.

[Blue_MiSfit]

Another option:

1) Remux MOV to MKV with MKVMerge
2) DirectShowSource("foo.mkv", audio=true) # Making sure you have Haali Media Splitter and a good H.264 decoder like ffdshow installed

This should give you another reference point... DirectShow can be cranky but it will probably work :)

Derek

[TheFluff]

Many thanks for the confirmation.

http://forum.doom9.org/showthread.php?p=1526871#post1526871

try this build and see what happens

[Yellow_]

Looks good. :-)