colormatrix with bluray source, yes or no?

[OvejaNegra]

When doing conversions using dgdecode with DVDsources to xvid/x264 i always used color matrix.

The same applys to bluray -> x264 ?
Im serving my source like this:


v=LWLibavVideoSource("H:\TORA\ch1\00000.m2ts.lwi", stream_index=-1)
a=LWLibavAudioSource("H:\TORA\ch1\00000.m2ts.lwi", stream_index=1)
AudioDub(v,a)
Spline36Resize(1280,720)


Do i still need to use colormatrix (or any other correction method) on this source?

Do i need to put anything on the x264 command line (like coheficients, color transfer or anything like that)?

Or just serve and encode?

I used search but the only information i found was about using colormatrix when scaling and downsizing.

thanks.

[Keiyakusha]

Assuming your source is bluray, Colormatrix is only needed if you do a resize from HD to SD.
If your source is not bluray, you only want to use colormatrix if you for some reason are not happy with original colorimetry or do a resize from SD to HD
So the answer is no.

Do i need to put anything on the x264 command line (like coheficients, color transfer or anything like that)?

Yes. Always. Regardless of whether you use colormatrix or not. If this info is not present, the player or other software must guess it. Which is fine, usually, but not always. Once new 4K BDs will be out, this is will likely be even more important. If you specify that, you don't have to actually use colormatrix at all (assuming the player/renderer will obey this information). But converting (if needed) AND specifying it is a safest choice.

[OvejaNegra]

Thanks for your help:
according to media info from mpchc the m2ts reports nothing (maybe there is a better tool to extract info from m2ts stream)
the source is bluray

i have doubts with these options:

videoformat -> undef / unknown
fullrange -> on?
colorprim ->bt709? (do al the bluray discs use bt709?)
transfer ->bt709? (do al the bluray discs use bt709?)
colormatrix->bt709? (do al the bluray discs use bt709?)
chromaloc = 0?
nal-hrd->none?

i found this info, dont know if its accurate:



More specifically:

–colormatrix specifies what coefficients are used when converting YUV to RGB. This is the one you want to use.
–colorprim specifies what color primaries (see for example the Wikipedia page about sRGB) the RGB uses. Setting this properly most likely requires knowledge of the studio equipment used to master the stream and/or its settings, so just leave it undefined. No one without a color calibrated monitor would ever notice or care, even if decoders/renderers actually supported this.
–transfer specifies the gamma curve used for the RGB. Like –colorprim, setting this correctly probably requires knowledge you don’t have, so don’t set it at all. Again, only people with calibrated studio monitors will ever notice or care.

TL;DR: Use --colormatrix bt709 if your source is a HD transport stream; --colormatrix bt470bg if it is an SD transport stream.
source: http://mod16.org/hurfdurf/?p=116


thanks again

[wonkey_monkey]

I think youi'll probably want Full range samples to be off. As I recall "On" is the default and is usually wrong (as YUV video should have Y in the 16-235 range). It trips me up all the time, and I end up with lower-contrast videos.

[hello_hello]

The way I understand it:

colormatrix = the method for converting the video to RGB on playback. It should always be bt709 for HD.
transfer = the gamma curve. bt709 & bt601 use the same gamma curve.
colorprim = once the video is converted to RGB, it'd display most accurately on a monitor calibrated to.... ie bt709 or bt601 primaries. I think HD displays are supposed to be bt709.

The Video Usability Info (http://www.chaneru.com/Roku/HLS/X264_Settings.htm#Video_Usability_Info) has absolutely no effect on how the video is encoded. it's just information written to the video stream.

As far as I know you'd probably only want to specify colormatirx when encoding, unless you can obtain the other info from the video stream, but I doubt any player would pay any attention to anything but colormatrix anyway.

Fullrange = off (default (http://www.chaneru.com/Roku/HLS/X264_Settings.htm#fullrange)). Pretty much all video is limited range (with the exception of formats such as mjpeg and maybe DV)

Chroma sample location. I don't touch it myself. http://git.videolan.org/?p=x264.git;a=blob;f=doc/vui.txt
nal-hrd http://www.chaneru.com/Roku/HLS/X264_Settings.htm#nal-hrd

From the DGIndex manual:
Colorimetry - Displays the colorimetry scheme used by the stream. Note that if the stream does not declare the colorimetry, then ITU-R BT.709* is reported for HD video, and ITU-R BT.470-2* is reported for SD video. The * character indicates that the stream did not declare the colorimetry

From the colormatrix manual:
hints:
DGDecode v1.20 or newer can output colorimetry hints in the video stream which ColorMatrix can read in order to automatically determine the source coefficients. To enable this, set info=3 in mpeg2source() and set hints=true in ColorMatrix() as shown below:

The way I understand it, by default Colormatrix will convert bt709 to bt601, which you want it to do for standard definition but not for high definition. For standard definition you'd normally use it in combination with DGDecode like this:

Mpeg2source("D:\video.d2v", info=3)
ColorMatrix(hints=true)

Which I'm pretty sure would be the same as:

Mpeg2source("D:\video.d2v", info=3)
ColorMatrix(hints=true, mode="Rec.709->Rec.601")

For HD video I think you'd need to use it like this so it'll convert to bt709 when the source isn't bt709, but when it is bt709, it'll leave it alone.

Mpeg2source("D:\video.d2v", info=3)
ColorMatrix(hints=true, mode="Rec.601->Rec.709")

I generally don't use colormatrix at all and just assume HD is bt709 and SD is bt601 and re-encode it as is. If I'm downscaling (or upscaling) I'd manually convert the colours and set the x264 colormatrix option accordingly. That'd be regardless of the format of the source video (mpeg2 or h264 etc) ie for downscaling HD to SD:

ColorMatrix(mode="Rec.709->Rec.601", clamp=0)

[videoh]

The way I understand it, by default DGDecode will convert bt709 to bt601
Maybe I misunderstood you, but DGDecode does not perform any colorimetry conversions.

[feisty2]

always a pain in the ass when "color" stuff gets to be the problem
converting "matrix" alone is, not very correct more or less
"matrix" "transfer" and "primaries" are a set of interactive parameters work together as one to represent a certain part of colors from CIE 1931 (the very first color standard covering every single visible color to human vision, and device independent of course, kind like the royal of all color related stuff)
primaries = how red exactly is the red here (green, blue likewise), it decides the coordinates of 3 elementary colors (cannot be represented as some mixed stuff of other colors, they are the purest thing here, they get to mix each other to produce other colors) on CIE system
transfer = a function that connects physical intensity and perceived intensity (aka gamma)
matrix = a matrix to separate luminance and chrominance
so, see, HDTV got a different "matrix" not because "oops, the old bt.601 sucks ass, I don't like it, let's make some crazy new crap", "709" matrix is there because HDTV picks different primaries from SDTV, so a new matrix is needed to separate luminance and chrominance of the image based on this new primaries.
pointless to apply "709" matrix on clips with "601 NTSC/PAL" primaries cuz you can't get correct luminance and chrominance with this matrix, the "luminance" is not the exact luminance and so is the chrominance, the "matrix" does not serve as it's supposed to, and "601" matrix on "709" primaries, likewise
if you are that desperate to change the color system, don't just convert the matrix, convert to CIE 1931 and apply a whole new set of different color system.

[Keiyakusha]

The way I understand it, by default DGDecode will convert bt709 to bt601

Same as videoh i have troubles understanding this part and everything that follows. DGDecode can only report colorimetry if it is specified in headers (most of the time not)

Which I'm pretty sure would be the same as:
Mpeg2source("D:\video.d2v", info=3)
ColorMatrix(hints=true, mode="Rec.709->Rec.601")
No. ColorMatrix(hints=true) is placebo and in most real-life situations does nothing with regard of the colorimetry because most streams on dvds do not have colorimetry info specified and assumed to be Rec.601 by DGDecode. (and if it will be specified, it will be Rec.601 anyway) It may perform some other stuff by default like levels clipping but its usefulness is questionable.
This might be different for HDTV mpeg2 captures though. I'm not sure if they have proper Rec.709 flags and what happens in this case, but it would be very bad to convert it to Rec.601 and if DGDecode is doing this, that would be a serious bug/flaw. So getting rid of ColorMatrix entirely seems like a good idea. Only use it for SD<->HD conversions.

ColorMatrix corrects the colors of MPEG-2 streams of dvds. More correctly, many MPEG-2 streams use slightly different coefficients (called Rec.709)
Sorry, but this is bullshit.
DVDs whatever don't have colorimetry specified or do have it specified. In 1st case you assume "601" and set x264 accordingly, in second you take whatever is specified and specify it in x264. In either case you don't need to convert anything (unless you do a SD-HD resize). So if ColorMatrix(hints=true) is converting something, whatever output you get is wrong,

Edit: only if you want to convert video to RGB somewhere inside the avs script, you must specify correct colorimetry. But you don't need colormatrix for that either, avisynth's ConvertTo*** functions have a way to deal with that. Perhaps this was not always the case.

[OvejaNegra]

Every time i see something about colormatrix or color representation it becomes a discussed topic, the information is very unclear / obscure most of the time.

Fullrange: Histogram("classic") on avisynth confirms that the video is in fact limited so: Fullrange -> off (default)
Colormatrix: DGAVC Index reports BT709* (undetermined-> assumed) so i dont know what to put here , BT709 because "all HD Streams are with bt709" or leave it undefined"

As far as i remember the problem with colormatrix and SD sources was the fact that MPEG4 always assumed BT601 so you have to convert BT709 to BT601 BUT with h264 you can specify whatever you want, so no need for colormatrix if you are converting to h264.

BUT AGAIN: Since most of the time BT601 is expected on SD streams and BT709 is expected on HD streams (and some renderers expect it like that) you need to use color matrix for resolutions changes.

So basically:
BT709 for SD-> HD output (convert if source is not) and flag to x264
BT601 for HD-> SD output (convert if source is not) and flag to x264 (nothing to do if using xvid).
HD -> HD:
BT709 -> Do nothing and flag to x264
BT601 -> Convert to 709 and flag to x264
Unspecified -> ????? Do nothing at all or flag to x264

Please correct me if im wrong

[Keiyakusha]

the video is in fact limited
Videos on TV/DVD/BD and likely every official streaming service are never fullrange. Only if you'll do it yourself. They could be technically PC range but that would be some noise or other garbage most of the time.

DGAVC Index reports BT709* (undetermined-> assumed)
That is what you'll see for most HD streams. Set it to 709 in x264.

MPEG4 always assumed BT601 so you have to convert BT709 to BT601
The problem is, colormatrix docs only mention DVDs. DVDs are never BT709.
Edit: in fact if a DVD player strictly follows the spec and the stream is flagged as 709, it is supposed to refuse to play it.
True that MPEG4/ASP (divx/xvid) does not have colorimetry information, but if this info is not present, assumption is made by the player/renderer based on resolution, not format. MPEG4 itself does not assumes anything.

BT709 for SD-> HD output (convert if source is not) and flag to x264
BT601 for HD-> SD output (convert if source is not) and flag to x264 (nothing to do if using xvid).
HD -> HD:
BT709 -> Do nothing and flag to x264
BT601 -> Convert to 709 and flag to x264
Unspecified -> ????? Do nothing at all or flag to x264

Marked bold - no. Why? Never convert anything. However you are very unlikely to find such a stream anyway. Edit: but if you'll chose to convert it will not be wrong.
For unspecified, assume that all DVD are 601, all Blurays are 709 and specify accordingly (note that 4k blurays will use yet another colorimetry)

[feisty2]

Just don't convert anything
Avisynth got no ability to convert primaries last time I checked
And converting matrix alone is not very reasonable like I said at #7

[OvejaNegra]

Thanks to all.
I remember all the avisynth examples about using color matrix with dgdecode for converting to Xvid, and the reasons were not very clear to me.
But now i have two final questions:
What was the point of color matrix (before the hdtv/bluray existence)? An mpeg2 stream with BT709? From where? TV capture?
This: http://forum.doom9.org/showthread.php?t=82217 mentions

ColorMatrix corrects the colors of mpeg2 streams of dvds. More correctly, those mpeg2 streams are encoded using a different set of coefficients as used by AviSynth's color conversion routines or by the XviD/DivX decoders

Again, what streams with bt709?

Keiyakusha:
The problem is, colormatrix docs only mention DVDs. DVDs are never BT709.
Edit: in fact if a DVD player strictly follows the spec and the stream is flagged as 709, it is supposed to refuse to play it.

Second final question:
Is there any proper way of converting from one to another on avisynth (without using colormatrix), i know this would imply converting to and from RGB but i want to know.

if you are that desperate to change the color system, don't just convert the matrix, convert to CIE 1931 and apply a whole new set of different color system.

Thanks

[feisty2]

Second final question:
Is there any proper way of converting from one to another on avisynth (without using colormatrix), i know this would imply converting to and from RGB but i want to know.


nah, it goes way beyond RGB, CIE 1931 is required here (all RGB colorspaces are derived from CIE 1931)
and you'll need a 3D expression to go from RGB to XYZ, something like mt_lutxyz, but with higher precision, like floating point
you can do it with std.Expr in vaporsynth, and, I don't really know if there is an "avisynth Expr" out there

[Keiyakusha]

ColorMatrix corrects the colors of mpeg2 streams of dvds. More correctly, those mpeg2 streams are encoded using a different set of coefficients as used by AviSynth's color conversion routines or by the XviD/DivX decoders
Again, what streams with bt709?

I guess only author of the plugin can answer that. Other than that, we can't even guess. That quote makes absolutely no sense.
"corrects the colors of mpeg2 streams of dvds" - there's nothing to correct
"encoded using a different set of coefficients as used by AviSynth's color conversion routines" - What different set? What routines? Avisynth is not converting anything. This is only matters when you convert from YUV to RGB, and you don't. And even if you do, avisynth supports both conversions, Rec601 and Rec709


Is there any proper way of converting from one to another on avisynth (without using colormatrix), i know this would imply converting to and from RGB but i want to know.

Not sure if I got you right, but assuming you have Rec601 YV12 source, to make it 709 this should do the job:

ConvertToRGB32(matrix="Rec601").ConvertToYV12(matrix="Rec709")

But this is more destructive than using colormatrix.

[hello_hello]

Maybe I misunderstood you, but DGDecode does not perform any colorimetry conversions.

Yeah, I should have said colormatrix. I've corrected my previous post.

[hello_hello]

No. ColorMatrix(hints=true) is placebo and in most real-life situations does nothing with regard of the colorimetry because most streams on dvds do not have colorimetry info specified and assumed to be Rec.601 by DGDecode. (and if it will be specified, it will be Rec.601 anyway) It may perform some other stuff by default like levels clipping but its usefulness is questionable.

Sorry, but this is bullshit.
DVDs whatever don't have colorimetry specified or do have it specified. In 1st case you assume "601" and set x264 accordingly, in second you take whatever is specified and specify it in x264. In either case you don't need to convert anything (unless you do a SD-HD resize). So if ColorMatrix(hints=true) is converting something, whatever output you get is wrong,

You're free to do it however you like, but me.... I try to make sure my SD encodes are BT.601 and my HD encodes are BT.709. If that means converting the colours when downscaling/upscaling, I convert them. That way, if a player isn't paying attention to the info written to the video stream and the colorimetry used is based on resolution, the video should display correctly.

Same as videoh i have troubles understanding this part and everything that follows. DGDecode can only report colorimetry if it is specified in headers (most of the time not)

Wrong. If it's not specified, DGDecode reports bt.601 for SD and BT.709 for HD. It's in the DGDecode html file. You're bound to have trouble following if you're assumptions are incorrect.


The problem is, colormatrix docs only mention DVDs. DVDs are never BT709.
Edit: in fact if a DVD player strictly follows the spec and the stream is flagged as 709, it is supposed to refuse to play it.
True that MPEG4/ASP (divx/xvid) does not have colorimetry information, but if this info is not present, assumption is made by the player/renderer based on resolution, not format. MPEG4 itself does not assumes anything.

I don't use colormatrix when encoding DVDs myself, but there's plenty of old posts here at doom9 where posters have stated GSpot shows a DVD as BT709. Reputable posters too, such as the author of AutoGK (len0x).

The colormatrix docs might only mention DVDs but the DGDecode docs mention HD video too.

Colorimetry - Displays the colorimetry scheme used by the stream. Note that if the stream does not declare the colorimetry, then ITU-R BT.709* is reported for HD video, and ITU-R BT.470-2* is reported for SD video. The * character indicates that the stream did not declare the colorimetry.

So if you're using DGDecode's hints with colormatrix, I see no reason why it shouldn't work exactly as I described for HD video.

Mpeg2source("D:\video.d2v", info=3)
ColorMatrix(hints=true, mode="Rec.601->Rec.709")

That should convert to bt.709 if the source isn't bt.709, and leave the colors alone if it's already bt.709. Personally, I don't think it's worth bothering with. Just as DVDs all seem to be bt.601, all HD video is BT.709, so colormatrix won't be doing anything.
Except of course for the plethora of x264 standard definition bt.709 encodes in existence that were encoded from HD sources without converting the colours, but aside from the sins committed by some people when downscaling and re-encoding, HD should always be BT.709 and SD should be bt.601.

[hello_hello]

As far as i remember the problem with colormatrix and SD sources was the fact that MPEG4 always assumed BT601 so you have to convert BT709 to BT601 BUT with h264 you can specify whatever you want, so no need for colormatrix if you are converting to h264.

When re-encoding YV12 video, if you don't convert to another colorspace during encoding (converting to RGB to keep VirtualDub filters happy might be an example) then you're just encoding the video "as-is". The colorimetry choice isn't made until it's converted to RGB on playback. So if it's YV12 in and YV12 out, the colorspace won't change unless you deliberately change it.

It's not completely accurate to say MPEG4 (ie Xvid) or x264 "expect" bt.601, because while that's true, it's only when the encoder input is RGB. Then the encoders have to decide which colorimetry to use when converting to YV12.
If you're re-encoding a YV12 Bluray/DVD video though, the encoders just re-encode it. They're oblivious to the colorimetry required for playback, so it doesn't matter if it's bt.601 or bt.709. In the case of Xvid, it can't write the colorimetry info to the video stream as x264 can, so ideally you should ensure it's correct (bt.709 for HD and bt.601 for SD) because the player will pick the colorimetry based on resolution. So converting bt.709 to bt601 when downscaling is a good idea. In the case of x264, it can write the colorimetry info to the video stream and in a perfect world all players would use the written colorimetry. In the real world though, I doubt that's always the case. Depending on how you're playing video using a PC.... the player and renderer etc.... and assuming the video card drivers work correctly and/or don't interfere, there's still a pretty good chance the colorimetry info written to the stream will be completely ignored and the choice will be made based on resolution.

Again, what streams with bt709?

If I remember correctly the DVD spec and the mpeg2 spec don't always agree. Even though DVDs contain mpeg2 video.
DVDs are supposed to be bt.601, but for standard definition mpeg2, if there's no colorimetry written to the video stream the spec says you're supposed to assume bt.709, not bt.601. So the difference there might account for it.

If you search through old threads here, you'll find posts where it's claimed a DVD is bt.709. Originally, DGDecode reported bt.709 if there was no colorimetry info written to the video stream, because the original consensus was DVD video should be bt.709.
That's long since changed, and DGDecode now reports bt.601 for DVDs when there's no colorimetry info written to the stream. Most of the early posts on colorimetry and colormatrix here are before my time, but you may still find screenshots indicating VirtualDub displays DVD video with the wrong colorimetry.... or something along those lines.
I don't know why the consensus changed, but I suspect DVD video hasn't changed and crappy video card drivers were causing the wrong colorimetry to be used in the early days. That's just my theory.....
There was an Avisynth page containing a list of video card drivers explaining when those drivers get things wrong, but I can't find it at the moment. It may have been removed. The info would be very out of date.

By the way, if you do convert to RGB and back to YV12 during encoding, by default Avisynth and VirtualDub and their filters all convert to RGB using bt.601. That's fine, even for HD, because by default they'll all convert the RGB back to YV12 using bt.601 as well. It's one of those times when two wrongs does make a right. If you convert to RGB and back using the same colorimetry each time, the colors won't change, even if it's not the same colorimetry that'll be used to convert to RGB on playback. :)

[hello_hello]

I have a question... while I'm thinking about it. Good old AutoGK has two colour correction options in it's settings. When colour correction is enabled you can choose between "accurate" and "fast". AutoGK comes with colormatrix, so I assume that's what it uses for colour "correction" if required (in combination with hints from DGDecode), but I've never known what the difference is between the two colour correction options. Does anyone know?

[Groucho2004]

If I remember correctly the DVD spec and the mpeg2 spec don't always agree. Even though DVDs contain mpeg2 video.
DVDs are supposed to be bt.601, but for standard definition mpeg2, if there's no colorimetry written to the video stream the spec says you're supposed to assume bt.709, not bt.601. So the difference there might account for it.
DVD Video uses a sub-set of MPEG-2, see here (http://dvd.sourceforge.net/dvdinfo/dvdmpeg.html).

[hello_hello]

always a pain in the ass when "color" stuff gets to be the problem
converting "matrix" alone is, not very correct more or less
"matrix" "transfer" and "primaries" are a set of interactive parameters work together as one to represent a certain part of colors from CIE 1931 (the very first color standard covering every single visible color to human vision, and device independent of course, kind like the royal of all color related stuff)
primaries = how red exactly is the red here (green, blue likewise), it decides the coordinates of 3 elementary colors (cannot be represented as some mixed stuff of other colors, they are the purest thing here, they get to mix each other to produce other colors) on CIE system
transfer = a function that connects physical intensity and perceived intensity (aka gamma)
matrix = a matrix to separate luminance and chrominance
so, see, HDTV got a different "matrix" not because "oops, the old bt.601 sucks ass, I don't like it, let's make some crazy new crap", "709" matrix is there because HDTV picks different primaries from SDTV, so a new matrix is needed to separate luminance and chrominance of the image based on this new primaries.
pointless to apply "709" matrix on clips with "601 NTSC/PAL" primaries cuz you can't get correct luminance and chrominance with this matrix, the "luminance" is not the exact luminance and so is the chrominance, the "matrix" does not serve as it's supposed to, and "601" matrix on "709" primaries, likewise
if you are that desperate to change the color system, don't just convert the matrix, convert to CIE 1931 and apply a whole new set of different color system.

That all sounds nice in theory, but in reality if I downscale HD video and convert it to bt.601, the SD version looks the same as the HD version to me, color-wise. A question.....
If I didn't convert the colours and simply wrote bt.709 to the video stream, on the occasions I'm using a media player that pays attention to the colorimetry info, in what way would the video display differently?. The original required bt.709 when converting to RGB on playback, while the encode now requires bt.601 because I converted the colours.

Maybe I'm missing something but I thought bt.601 and bt.709 used exactly the same gamma, and even if the colorprim parameter wasn't generally ignored by players, why wouldn't it still be correct? If the source video displays as it should on a bt.709 calibrated display, shouldn't the downscaled version also display the same way?

The original video probably looks like this:

Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709

After I convert the colours and downscale I normally only tell x264 to write the matrix coefficients, but if I was more enthusiastic, or I always knew the correct values, I'd get it to write all three like this:

Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.601

Why wouldn't the encode display exactly like the source given I've only changed the matrix coefficients to reflect the change in colorimetry?

[feisty2]

shit won't happen to the color if you applied a casual twisted color system to some vid, it shares the same CIE result like the one with a "scientific" color system anyways, doesn't really matter if the vid is 4:4:4, scientific or not, it always leads to the same CIE value, and that's why matrix like "YCgCo" exists.
but if the vid got a subsampled chroma, that would be a whole new story, the wrong matrix would send some luminance to chroma planes, and chroma planes will be subsampled and we all know what will happen next...

[hello_hello]

I'll confess I'm not really sure if that was an answer to my question.

[feisty2]

And I'm not really sure what was the question
Like I said, shit won't happen color wise, the down side is subsample related, if subsample didn't exist, YCgCo would be way better than 601 or 709, it gives zero rounding error converting between YUV and RGB

[Wilbert]

No. ColorMatrix(hints=true) is placebo and in most real-life situations does nothing with regard of the colorimetry because most streams on dvds do not have colorimetry info specified and assumed to be Rec.601 by DGDecode. (and if it will be specified, it will be Rec.601 anyway)
I'm pretty sure it will assume Rec.709 when the colorimetry is not specified in the header. Perhaps that was only the case in older versions, but i'm too lazy to look it put in its documentation.
I guess only author of the plugin can answer that. Other than that, we can't even guess. That quote makes absolutely no sense.
"corrects the colors of mpeg2 streams of dvds" - there's nothing to correct
"encoded using a different set of coefficients as used by AviSynth's color conversion routines" - What different set? What routines? Avisynth is not converting anything. This is only matters when you convert from YUV to RGB, and you don't. And even if you do, avisynth supports both conversions, Rec601 and Rec709
Guess i'm the guilty one. Of course it only matters when converting from YUV to RGB (or back). That should be clear when reading the rest of the documentation. There used to be a time when the consensus here was that dvd's were encoded assuming Rec709. The next to last version of the MPEG-2 specs said that Rec709 should be assumed when the colorimetry was not specified in the header of the stream. In the last version they changed that to 'assumed to be implicitly defined by the application', in other words can be anything. See http://avisynth.nl/index.php/Colorimetry for more details.

The general consensus nowadays is that Rec601 should be assumed for dvd's, regardless when the colorimetry is present in the header. I'm not saying that's wrong, but we can't be 100 percent sure unless some actually got that from the dvd specs itself.

Btw, where is the quote "encoded using a different set of coefficients as used by AviSynth's color conversion routines" coming from? Perhaps i wrote that one day, but it is not in the current (or 2007) documentation.

[Keiyakusha]

I'm pretty sure it will assume Rec.709 when the colorimetry is not specified in the header. Perhaps that was only the case in older versions, but i'm too lazy to look it put in its documentation.

Latest version definitely assumes 601 for SD, 709 for HD. Not sure about older ones... I'm curious to check, but no idea where to get them.
Edit: found some old ones. dgmpgdec150+ assume rec601.


Btw, where is the quote "encoded using a different set of coefficients as used by AviSynth's color conversion routines" coming from?

Well I simply re-quoted the post above but I do recall seeing it somewhere.

Edit: By the way, first english-language link in google leads here (http://avisynth.org.ru/docs/english/externalfilters/colormatrix.htm), where it says something different:
ColorMatrix corrects the colors of MPEG-2 streams of dvds. More correctly, many MPEG-2 streams use slightly different coefficients (called Rec.709) for storing the color information than AviSynth's color conversion routines or the XviD/DivX decoders (called Rec.601) do, with the result that DivX/XviD clips or MPEG-2 clips encoded by TMPGEnc/QuEnc are displayed with slighty off colors (which looks like a small difference in brightness). This can be checked by opening the MPEG-2 stream directly in VDubMod.
... but even if we'll ignore Rec.709 and TMPGEnc (no idea how it works) parts, the bold part is still unclear. Why avisynth is mentioned here? I suppose some old avisynth version always assumed Rec601 and documentation was never corrected. But if it was meant as a workaround, it is strange that the plugin itself isn't performing YUV-RGB conversion. Then, there are decoders that always assume Rec.601 if RGB was requested? Even if yes, that's just a broken decoder, not to mention that usually RGB will not be requested (so the conversion will be done by downstream software using it). Adjusting video to match the behavior of some specific playback software is not really a good idea. So this part of the documentation is needlessly confusing (assuming this one is up to date)

[OvejaNegra]

Not sure if I got you right, but assuming you have Rec601 YV12 source, to make it 709 this should do the job:
ConvertToRGB32(matrix="Rec601").ConvertToYV12(matrix="Rec709")
But this is more destructive than using colormatrix.

Got it, yes its very destructive. I was asking for the more "99.9999%" accurate conversion, but off course is too much.

You're free to do it however you like, but me.... I try to make sure my SD encodes are BT.601 and my HD encodes are BT.709. If that means converting the colours when downscaling/upscaling, I convert them. That way, if a player isn't paying attention to the info written to the video stream and the colorimetry used is based on resolution, the video should display correctly.

i always assumed that was the main porpuse of colormatrix (because Xvid / MPEG4 dont have that info on the stream) even now with x264, there is the risk of decoders ignoring the info and work according to resolution.

[DarkSpace]

I see so many people here who ask themselves what can be done for people who use buggy software (video decoders that don't pass the colorimetry information to the video renderer, video renderers that ignore colorimetry information that they get from the decoder), so I feel I should raise the question of whom this truly benefits:

Those who use buggy software are unlikely to care about precise colorimetry. If they do care, they should switch to a different software anyway.
Those who use software that properly handles this stuff will, at best, experience no negative effects from such a conversion. Usually, I'd expect that the matrix adaption will indeed harm quality.

So, the matrix adaption brings no real benefit to those whom it's supposed to help (those who should change their playback environment anyway*), while harming those who are already doing it right.
* If anyone is going to mention ffdshow and avisynth processing, I'm just going to tell them to manually insert colormatrix into the avisynth script themselves, if ffdshow can't handle colorimetry.

You'll notice that I have little to no sympathy for people who use broken software. I think that is all right, though, because it's already 2015, and stuff like LAV Filters, which respects colorimetry information, has been around for a long time already. Additionally, I remember that, also quite a while back, MPC-HC fixed EVR (perhaps only EVR-CP, I don't remember that well) to respect colorimetry information also, so the point that there are too few common video renderers that respect colorimetry information, if present, is also invalid.

You'll also notice that I only mentioned software. If the goal is playback on hardware players, then my reasoning becomes invalid, because then the act of "simply switching playback environments" becomes that much harder. And although I'm still in favor of using something that actually does it right for playback, even in those cases, I can acknowledge that this is unreasonable.

[hello_hello]

I'm still runing XP on the PC I use as a media player. I have no particular need to change OS. It works fine. I'm fairly certain the colorimetry info is ignored when using the MPC-HC/EVR combination just as it is with most other renderers. I could use MadVR, but I prefer not to.

I care about colorimetry. It's why,
- I always use rec.601 for SD and rec.709 for HD.
- If I need to correct the colorimetry on playback, I can do it manually with a pixel shader. Or several other ways.

I'm still not clear as to how converting the colours "harms those who are already doing it right" (those using software that obeys the colorimetry, I assume), and in the real world encoded video is rarely only played back using a single device, software or hardware, and my switching to different playback software has no effect on the colorimetry that'll be used by the media player built into the TV in the family room, or the Bluray player connected to the TV in the living room etc. Using a colorimetry which is "most likely" to be displayed correctly seems logical to me.

Btw, where is the quote "encoded using a different set of coefficients as used by AviSynth's color conversion routines" coming from? Perhaps i wrote that one day, but it is not in the current (or 2007) documentation.

I'd be guessing "AviSynth's color conversion routines" refer to Avisynth's colour conversions from RGB to YUV etc being rec.601 by default. "Encoded using a different set of coefficients" possibly refers to encoders that always write rec.709 to the video stream, or assume RGB should always be converting using rec.709, so if you want the video to display correctly by a player that obeys the colorimetry info......
Maybe there's no longer encoders like that, but the HCenc encoder is mentioned here:

Color coefficients and Colormatrix usage summary (Q and A) (http://forum.doom9.org/showthread.php?t=133982#post1090068)

[hello_hello]

And I'm not really sure what was the question

I have a Bluray video. I re-encode it. I use no other filtering aside from colormatrix to change the colorimetry to rec.601.
(Of course normally I wouldn't do so unless I was downscaling to SD).
On playback I use a player that obeys the colorimetry info written to the video stream. I use the same TV/monitor each time.

The original Bluray video would look like this:

Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709

After I convert the colours, I'd tell x264 to write this:

Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.601

The question was, how/why would they display differently?
I'm not sure how your references to subsampling apply.

[hello_hello]

i always assumed that was the main porpuse of colormatrix (because Xvid / MPEG4 dont have that info on the stream) even now with x264, there is the risk of decoders ignoring the info and work according to resolution.

Exactly, which is why it's a good idea to use rec.601 for SD and rec.709 for HD when encoding with Xvid, and convert the colors accordingly when downscaling/upscaling, because Xvid can't write the colorimetry info, so the playback device must assume a colorimetry based on resolution.
I still don't understand why that was best practice for years, but because x264 has the ability to write the colorimetry info, it's now a sin to follow the same rule.

[feisty2]

I have a Bluray video. I re-encode it. I use no other filtering aside from colormatrix to change the colorimetry to rec.601.
(Of course normally I wouldn't do so unless I was downscaling to SD).
On playback I use a player that obeys the colorimetry info written to the video stream. I use the same TV/monitor each time.

The original Bluray video would look like this:

Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709

After I convert the colours, I'd tell x264 to write this:

Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.601

The question was, how/why would they display differently?
I'm not sure how your references to subsampling apply.

there will be NO color difference between these 2 copies

[hello_hello]

there will be NO color difference between these 2 copies

Well that makes me feel a bit better. If there was a reason why converting the colours would have a detrimental effect, I'd reconsider whether doing so was a good idea. Is there a circumstance when converting the colours that way while re-encoding video would be detrimental?

Of course much of the time the colour primaries, transfer characteristics and matrix coefficients aren't known. I just checked a Bluray rip on my hard drive and MediaInfo doesn't show info for any of them. So I guess all I can do is assume the source matrix coefficients are rec.709 and write that to the video stream when encoding, or write rec.601 if converting the colours. My understand is it's best not to specify anything for colour primaries or transfer characteristics unless you actually know what they should be, so unless I do, I don't. I assume that's the right thing to do?

[feisty2]

Is there a circumstance when converting the colours that way while re-encoding video would be detrimental?

I assume that's the right thing to do?

Q1: like I said earlier, standalone matrix conversion will do some extra harm to luminance if your source file and encoded file are both not 4:4:4, because some luminance will be assumed as "chrominance" and get subsampled, and you lose some luminance data for this

Q2: I guess so.

EDIT:
the precise and more correct way to convert from HD to SD, SD to HD likewise
0. expand to PC range
1. resample to 444
2. convert to gamma compressed RGB with matrix "709"
3. convert to linear RGB with "709" transfer
4. convert to CIE XYZ with "709" primaries
5. convert to CIE Lab
6. scale to SD
7. convert back to CIE XYZ
8. convert to linear RGB with "601 NTSC" or "601 PAL" primaries
9. apply "709" transfer
10. apply "601" matrix
11. resample to 422/420 or keep it as 444
12. shrink to TV Range

[hello_hello]

So when I asked earlier if the example source and encode will display the same way, the answer was yes, because the colours will display the same way, but now it's no because the luminance might be a little different?

To be honest, about the only time I convert the colours is when downscaling, or if for some reason I think the source was encoded with the wrong colorimetry, and if I'm re-encoding/downscaling I'm probably going to be applying other filtering such as noise removal and/or sharpening anyway. I might try the 12 step colour conversion method one day, but if I'm taking a high definition video and downscaling it to standard definition it'd have to offer a noticeable quality improvement. Considering the "damage" already being inflicted on the picture through downscaling and other filtering, I'm not sure it'd make enough difference to matter.

[Sparktank]

the precise and more correct way to convert from HD to SD, SD to HD likewise
0. expand to PC range
1. resample to 444
2. convert to gamma compressed RGB with matrix "709"
3. convert to linear RGB with "709" transfer
4. convert to CIE XYZ with "709" primaries
5. convert to CIE Lab
6. scale to SD
7. convert back to CIE XYZ
8. convert to linear RGB with "601 NTSC" or "601 PAL" primaries
9. apply "709" transfer
10. apply "601" matrix
11. resample to 422/420 or keep it as 444
12. shrink to TV Range

Interesting.
This almost looks like the dither_resize16 process.
Dither_convert_yuv_to_rgb(...)
Dither_y_gamma_to_linear
Dither_resize16
Dither_y_linear_to_gamma
Dither_convert_rgb_to_yuv(...)

Except, I dont apply 444 and PC range first (and TV range last, then 420/422). (and also don't do that CIE XYZ & CIE LAB thingy)
I've always been curious about that, though.
For DVD processing.

[feisty2]

Interesting.
This almost looks like the dither_resize16 process.
Dither_convert_yuv_to_rgb(...)
Dither_y_gamma_to_linear
Dither_resize16
Dither_y_linear_to_gamma
Dither_convert_rgb_to_yuv(...)

Except, I dont apply 444 and PC range first (and TV range last, then 420/422). (and also don't do that CIE XYZ & CIE LAB thingy)
I've always been curious about that, though.
For DVD processing.


Dither_convert_yuv_to_rgb(...) = 0. 1. 2.
Dither_y_gamma_to_linear = 3.
Dither_resize16
Dither_y_linear_to_gamma = 9.
Dither_convert_rgb_to_yuv(...) = 10. 11. 12.

[Sparktank]

:thanks: saving.txt

[feisty2]

and also don't do that CIE XYZ & CIE LAB thingy

CIE XYZ is required to convert primaries
CIE Lab is required to prevent linear light artifacts (dark halo, see http://www.imagemagick.org/Usage/resize/#resize_lab)

[Sparktank]

Interesting reads.

Although, tyring to implement to YV12 movies (AVC/VC-1/MPEG2) with avisynth, I can't see myself converting a whole movie to PNGs for a process.

Still going through some limited google searches to this forum for CIE LAB.
There's a lot to catch up with and read.
Got myself a good mini-ebook to compile here.