ColorMatrix v2.3

[G_M_C]

1)How do you know it is PCscale? use script with just AVCSource and ColorYUV(analyze=true) and check loose min luma.

Did that, and thats how i know.

1)2) why are you converting it to YUY2? why don't you leave it in YV12?


Converting to MPEG2 using CCE (to be precise: Replace the crappy PQ of the video-track of one of my backups with a new and better one)

1)3) Why fft3D? Denoising ?

Yes, to help compression + it is needed (using low sigma-values, after resizing from HD to SD).

5) I don't know AVCSource and I cant google any relevant page, but if deblocking=false disables deblocking even if clip uses in-loop deblocking, this can lead to catastrophic results.

Read all about it on doom9's forum, only not here but here:
http://forum.doom9.org/showthread.php?t=122598

No catastrophic results known, and it is not relevant in this case.

In other words: I know what i'm doing, so above tips are known to me.

1)4)
I think there won't be any significant difference, but maybe would be better put it after FFT3D, so it will work with more colors.

Thx for this answer; But how do you think it works best on more colors ?

My hypothesis for option 1 was was because i do not know if luma getss "cut off" or otherwise broken when i use ConvertToYUY2() on PC-scale input.

If the conversion wont give those problems, than i wanted to use option 2 because any rounding-off errors or other noise (if any) that comes with the conversion gets corrected, and rest of the script can use the as much luma/chroma information i can give it (The FFT is needed anyway).

In the end i want to lose as less color/luma info as possible before giving it to CCE. In other words: The higher the quality the better
(=Didee-like encoding quality-standards ;) )

[KillerZero]

1) its strange, as it must look very dark in every player, that is why I'm asking.
ConverttoYUV2 just upsamples chroma, so it shouldn't cut off anything.
Nearly every filtering works best if it has highest bitdepth possible, i dont know why should be fft3D different.
Thx for link, but I still think that turning deblocking off is bad idea, though it may work on some streams. It's definitely not worth speed gain.

[G_M_C]

1) its strange, as it must look very dark in every player, that is why I'm asking.


Yes actually it does, thats when i discovered it (assumed that it would be TV scale on my first try). Dark tones are way to dark, and light tones are "overshined". The whole image looked like I turned up contrast to the max on my TV.

But thx for the help, i think i'll use option 1)

:)

[Alain2]

What is your graphic card?
X1600pro, using catalyst 06.8, media player classic output VRM9 renderless. Using the default / overlay renderer I do get yv12 displayed with the 0-255 scale, it's in VRM9 (that I want to use) that it is kept at 16-235 if ffdshow outputs yv12, but converted to 0-255 if ffdshow outputs rgb.
You definitely not using avisynth for encoding, only for decoding.
Yes ok, was tlaking fast. I use avisynth to pre-process my input (read by dgdecode for instance) with filters and send the resulting raw yv12 to the encoder (lagarith first, then x264).
And it is nothing contradicting to what I said - only what encoder can do is write colorimetry info to stream and all what decoder can do is to give colorimetry info to next filter if it's present in stream, but in encoding/decoding process itself is no slightest difference. It's only relevant for YV12<-->RGB conversion, so if we want it to be played properly ffdshow must be able to pass colorimetry info to graphic card.
Ok, I see your point, but still, my input is being processed by avisynth filters before being sent to the encoder, and I very much doubt that you would get a colorimetry info in the raw yv12 output of avisynth. Thus if you have a yv12 with no colorimetry sent to the encoder, ok you say it encodes it, and maybe add a colorimetry flag as well for the driver that will convert to rgb. That is this colorimetry flag I was thinking about: aren't xvid and x264 supposed to add by default rec601 flag whereas CCE is choosing rec709 be default ? In any case, you have to treat your yv12 stream according to this colorimetry flag of the encoder, meaning if it's not the same than your initial source, then a convertion as per colormatrix is necessary...

[KillerZero]

Strange, I have 9600XT and it uses 16-235 --> 0-255 RGB even with VMR9 renderles, if video isn't higher than 720 lines...
I don't know about XVID, but X264 leaves it undefined by default. I bet that xvid does the same, Rec601 is just default for SD video, so it is chosen by graphic driver if it's not specified.

[tritical]

I've made a new version that fixes the source==dest error when using d2v or hints, and that removes the 'scaling' parameter and replaces it with a boolean 'clamp' parameter (true will use limiter before and after, false wont). I read through the last 4 pages and I'm not sure whether anyone wanted the default for dest/mode to change to Rec.709 when the input has HD res? If so speak up, or if there are other changes wanted speak up also... otherwise I am just going to leave everything else as is.

[IanB]

...default for dest/mode to change to Rec.709 when the input has HD res?I think that might be a bad idea.

Having behaviour change depending on image dimensions is poor. Besides where do you set the threshold, H>576, W>720, H>=720, W>=1280, half way between, ....

If it is an issue that require fundamental thought then it probably should not have a default, i.e. the parameter must always be specified.

[wozio]

To clarify some things about yuv->rgb conversion whn using VMR9 on ATI.

This is really up to drivers how this color conversion is done. Decoder has nothing to tell here unless he outputs rgb data. Now ATI drivers uses two color matrixes depending on resolution of incoming image, if images has 720 lines or more then hd matrix is used, otherwise sd matrix. You can see comparision how it looks like here:

http://forum.doom9.org/showthread.php?p=988268#post988268

It looks very similar between ffdshow's yuv->rgb conversion and ati's vmr9 sd color matrix but difference to vmr9 hd matrix is bigger.

It would be great that decoders would pass color information to VMR9 using mentioned DXVA_ExtendedFormat but it is unknown how it is supported in drivers. As far as I see decoders have this information from stream.

At least from version 7.3 of drivers ATI started to extend all yuv inputs into PC scale.

I don't know how it looks like on nvidia cards.

[Dr.Khron]

Sorry to drag down the level of the discourse, but I've got a noobie question...

Ok, so I started inserting ColorMatrix into my AVS files... I'm working on some TV episode DVDs, so this is my syntax:
DGDecode_mpeg2source("D:\Ripping\S03E01.d2v", info=3)
ColorMatrix(hints=true, interlaced=true)

When I preview the file in AvsP, I see no difference at all when I add and remove the ColorMatrix line. From what I've gathered from reading this thread, this has to do with how I've got my FFDshow setup (I'm running a recent install of the CCCP). What can I do to change my FFDshow settings so that I can properly preview the changes that ColorMatrix makes to my AVS output?

Or should I just assume that fixes something, and use it for all of my .d2v content?

Thanks for any advice.

[Adub]

Maybe your original video was already rec.601, although it is doubtful. Also, depending on the size of your preview in AvsP, it may be hard to tell the difference. I usually can see the difference if I load the avs file into MPC and play it at fullscreen. Just look for parts of the video that should be black and compare them to the borders that are automatically inserted by MPC, if they are the same level of black, then it worked correctly, if not, you have some more work ahead of you.

[Wilbert]

Just look for parts of the video that should be black and compare them to the borders that are automatically inserted by MPC, if they are the same level of black, then it worked correctly, if not, you have some more work ahead of you.
ColorMatrix doesn't change the black level, so i'm not sure what you are referring to here. If the level of black is the same, it doesn't mean ColorMatrix did anything (like you said, if the source is Rec.601 for example).

[canuckerfan]

for special cases of deinterlacing, as in repal... should cm be used before with the interlaced paramatre set to true (this won't handle the odd progressive frame correctly) or use it after repal with it set to false (now that all frames are progressive)? I've tried both and they seem to work, even the hints seem to survive after repal.

[Cunhambebe]

I would like to thank the author for the new verion. Keep up the excellent job! :)

[Dr.Khron]

Update to my earlier issues:

Ok, so now I better understand how ColorMatrix works. The reason I wasn't seeing a difference is becuase, as Merlin7777 suggested, the source material was already in Rec.601; see the OutputDebugString below:

[3144] ColorMatrix: frame 426: detected colorimetry from d2v = 6 (Rec.601)
[3144] ColorMatrix: frame 426: returning src frame... no conversion required (d2v)


So, in this case, I have no need for ColorMatrix at all. :)


However, my research has brought up two new questions.

First, what does the the "interlaced" parameter do? According to the documentation, "if your video is YV12 and is interlaced you need to set this parameter to true."
In my experimentation, adding it and removing it made no difference.

Second, adding the "hints" parameter to my DGDecode line appears to screw up the de-interlacing, adding in artifacts.

DGDecode_mpeg2source("D:\Ripping\S03E01\S03E01.d2v", info=3)
colormatrix(hints=true, debug=true)

[896] ColorMatrix: frame 0: detected hint = 6 (Rec.601)
[896] ColorMatrix: frame 0: returning src frame... no conversion required (hints)
http://img484.imageshack.us/img484/3057/89873172wa8.jpg


DGDecode_mpeg2source("D:\Ripping\S03E01\S03E01.d2v")
ColorMatrix(debug=true)

[896] ColorMatrix: frame 0: using YV12 Rec.709->Rec.601 conversion (MMX).
http://img484.imageshack.us/img484/6397/38560236ie6.jpg

Why do the hints effect the de-interlacing?
Are the hints being passed to the wrong filter?


EDIT: To reiterate, adding or removing the "interlaced=true" parameter to either of the above srcripts DOES NOT change the output.

[canuckerfan]

yea, do hints survive such filters as repal?

[tritical]

All the interlaced parameter does is internally invoke Separatefields() before colormatrix and invoke weave() afterwards. The reason for doing this is that colormatrix has to get u/v values for every y value. In progressive yv12 luma lines 0/1 share chroma line 0, luma lines 2/3 share choma line 1, etc... However, in interlaced yv12 luma lines 0/2 share chroma line 0, luma lines 1/3 share chroma line 1, etc... So using interlaced=false on interlaced yv12 will result in some luma lines using chroma values from a different field. That will be fine as long as there isn't motion, but in moving areas it will be bad. That's why it is better to accidently use interlaced=true on progressive frames than to accidently use interlaced=false on interlaced frames.

Next question is is it better to use colormatrix before or after an interlaced->progressive conversion. Theoretically, if your conversion is perfect, it would be better to run colormatrix afterwards on the progressive frames. In practice, you probably couldn't tell the difference. I will say that in the case of ivtc it's probably better to run colormatrix afterwards if only for the fact there will be fewer frames (so less processing time will be required).

Now about hints. The hints from dgdecode are stored in the least significant bit of the first 64 pixels in the Y plane (or just the first 64 pixels for yuy2) of the image. Whether or not they will survive a specific filter or function depends entirely on whether or not that filter alters those 64 pixels. Most of the time you'd just have to try and see. If you set hints=true in colormatrix, and colormatrix doesn't detect any valid hints then it will throw an error. So if you don't get any error messages it should be fine.

@Dr.Khron
Could you show us the debug output from colormatrix in both cases (with/without hints). Also, if you are using colormatrix before ivtc and dgdecode is outputting yv12 then you must use interlaced=true or things will definitely get screwed up.

[Dr.Khron]

@Tritical:

Ok, I edited my previous message to include the debug output. Yes, I am using it before IVTC, but as I mentioned, adding or removing the "interlaced=true" parameter doesn't seem to effect the output.

Seems to me the best way to pass info to the ColorMatrix filter is to use the .D2V arguments... when I fooled around with that it never caused any issues, just the "hints=true" syntax.

[tritical]

What is the rest of your script? What happens if you don't use colormatrix? Could you post a small clip so that I can duplicate the behavior?

[foxyshadis]

One quick way of keeping the hints:
Mpeg2Source()
o=last
.... # do things
MergeHints(o)
ColorMatrix(hints=true)

Mergehints is part of... Decomb, I think? I don't think hints can totally survive a framerate conversion, since pieces of different frames (which may have different matrices) are merged; but accepting that such transitions are quite rare, a simple Mergehints(o.ChangeFPS(framerate)) should be sufficient.

[Dr.Khron]

What is the rest of your script?

Here ya go. Notice that it has no ColorMatrix, since this video doesn't need it.
#import Mpeg video and correct colors
DGDecode_mpeg2source("D:\Ripping\S03E01\S03E01.d2v")

#De-interlace
edeintted = AssumeTFF().SeparateFields().SelectEven().EEDI2(field=-1)
tdeintted = TDeint(edeint=edeintted,order=1)
tfm(order=1,clip2=tdeintted).tdecimate(hybrid=1)

#Resize
LanczosResize(640,480) # Lanczos (Sharp)

#noise filter
Undot() # Minimal Noise

What happens if you don't use colormatrix?
The clip come out just fine.

Could you post a small clip so that I can duplicate the behavior?

You mean like a D2V file for a small piece? Wouldn't you need the entire VOB for that?

[Boulder]

You mean like a D2V file for a small piece? Wouldn't you need the entire VOB for that?He'll need a small VOB sample so he can try it out himself.

[canuckerfan]

upon frameserving (via mpc), the results WITHOUT colormatrix is favourable (at least in my eyes) to the one WITH colormatrix. if this clip were to be fed through CCE, would not using cm keep the reults favourable? or am I missing something?

oh and just in case...
ColorMatrix(mode="Rec.601->Rec.709",opt=0,hints=true,threads=0)

[Alain2]

Edit3: I got it, VMR7 renderless and both VMR9 modes render colors correctly only with resolution < 720 lines. For 720p or higher, they really expect PC scale. Maybe bug in drivers? I'll try upgrade to newest catalyst.
Ok I got it now, in vrm9 renderless I got the same...
To save some cpu time (for encoding ^^) I stopped outputting rgb32 but keep yv12 in ffdshow, and uses ffdshow resizer in bicubic mode to 1600 x 0, which gives me a nice output on my lcd, and do the convertion as you mentionned to pc levels (funny to see that ticking / unticking the resize in ffdshow changes the levels to TV/PC realtime). vertical dimension 720 is the hardlimit apparently (1280x718 keeps TV levels, 1280x720=PC levels). It apparently also changes the color decoding as well from my tests; it looks like <720 --> rec601, and >=720 --> rec709... What a mess !:eek:
(WinXP, MPC, VRM9 renderless, X1600pro with ATI catalyst 6.8, ffdshow Mar 22 2007)

[FredThompson]

You'll see similar problems with automatic imposition of chroma range limiting. IMNSHO, this is all ill-conceived idiot-proofing for analog TV output.

I've gone to Flash video for computer playback of anything with a computer-based component such as a pure white background or scanned images because the "helpful automatic conversions" you've mentioned really screw things up.

[kumi]

Tritical posted (http://forum.doom9.org/showthread.php?p=975906#post975906) here on the 26th of March about a new version that fixes the source==dest error. Is that available for download anywhere? The most recent Colormatrix .ZIP on his site is dated January of this year.

Edit: and it doesn't have the "source==dest" error fixed.

[woah!]

this might be a silly question, but should i use this with a HD-DVD AVC source? i know this is used for mpeg2 sources but how about VC1 AVC sources?

[MLS]

Alright I read this whole thread because to be honest this filter and its uses are very confusing; and the documentation and the people in this thread do not make it clear.

What is unclear here and further muddied from the last few pages is the all important question of When is this filter supposed to be used and how?

There are a few competing opinions here, also further confused by the 0-255/16-235 PC/TV issue.

One party claims it doesn't matter what the source colorimetry, or what you convert to, if the resolution is below 720 then the 601 coefficients will be used to display the picture, this chosen by the video card, if it is above, then the 709 coefficients will be used. This would imply no other possibilities exist for PC playback.

The other party says that the colorimetry must be converted based on what you are converting to. If it is MPEG-4, the decoders will use the 601 coefficients by default and thus a problem arises from 601 coefficients being used on what is supposed to be using 709 coefficients. If MPEG-2 is the destination format, then you want to match the colorimetry that the encoder will place in the stream. Resolution does not affect it in any way.

Am I correct in my summary?

If so, then the correct filter applications would be thus:

** If Party1 is correct:

- If destination resolution is < 720 AND source colorimetry is not Rec.601 THEN convert to Rec.601.

- If destination resolution is >= 720 AND source colorimetry is not Rec.709 THEN Convert to Rec.709.

- Else Leave it be?

** If Party2 is correct:

- If destination format is MPEG4 AND colorimetry is not 601 THEN Convert to Rec.601.

- If destination format is MPEG4 AND colorimetry is Rec.601 THEN Do nothing.

- If destination format is MPEG2, convert colorimetry based on what encoder will place in MPEG2 stream by default; if it places nothing (CCE), then use Rec.709 as per specs.

- If destination format is OTHER, ???.

Hope I'm not further confusing things, I'm attempting to make sense of the discussion in the last 20 pages.

/MLS

[Dr.Khron]

Well... Since I had problems with using the filter when it wasn't needed, this is what I do: I test each source with the Debug flag.

I add ColorMatrix using the D2V option, and add Debug=true.

Then I fire up DeBugView, and put a few frames through AvsP. The text in DeBugView tells you EXACTLY what the colors for the source material are, and wether or not you need to use the filter. If I don't need it, I remove it. Pretty simple.

[Wilbert]

@MLS,

If destination resolution is < 720
KillerZero, said the height mattered, not the width.

I used to think that Party2 is correct, and that's how it's described in the docs.

However, as KillerZero pointed out:

Yes, you are completely wrong. Encoder nor decoder doesn't expect anything. It just encodes/decodes YV12 picture. Conversion to RGB is done by graphic card. And it selects color matrix depending on resolution.
It's a bit difficult to give correct guidelines, so i have to think about that for a while. The problem is that there might not be a good way to do this.

Consider the following example which shows the problem:

Suppose we encode to mpeg-2 with CCE and source is Rec.709. CCE writes Rec.709 is the header of the mpeg-2 stream (or more correctly, it leaves the colorimetry empty like you say). The problem is that since you are encoding to 720x480/576, Rec.601 is used by your graphics card to covert the decoded YV12 stream to RGB for display. This implies that it is displayed incorrectly. (Btw, i'm not sure that this also happens with software dvd-players which are not based on DirectShow.)

If want to avoid this we should encode "correcting for Rec.601". But in this case the encoding (with CCE) contradicts with the header of mpeg-2, which clearly says that Rec.709 should be used for decoding. I do not like doing this.

Perhaps others can share their mind about this ugly problem.

[Revgen]

this might be a silly question, but should i use this with a HD-DVD AVC source? i know this is used for mpeg2 sources but how about VC1 AVC sources?

All H.264/AVC and VC1 videos on HD-DVD's and Blu-Ray are BT.709 colorimetry.

[Revgen]

Alright I read this whole thread because to be honest this filter and its uses are very confusing; and the documentation and the people in this thread do not make it clear.

What is unclear here and further muddied from the last few pages is the all important question of When is this filter supposed to be used and how?

There are a few competing opinions here, also further confused by the 0-255/16-235 PC/TV issue.

One party claims it doesn't matter what the source colorimetry, or what you convert to, if the resolution is below 720 then the 601 coefficients will be used to display the picture, this chosen by the video card, if it is above, then the 709 coefficients will be used. This would imply no other possibilities exist for PC playback.

The other party says that the colorimetry must be converted based on what you are converting to. If it is MPEG-4, the decoders will use the 601 coefficients by default and thus a problem arises from 601 coefficients being used on what is supposed to be using 709 coefficients. If MPEG-2 is the destination format, then you want to match the colorimetry that the encoder will place in the stream. Resolution does not affect it in any way.

Am I correct in my summary?

If so, then the correct filter applications would be thus:

** If Party1 is correct:

- If destination resolution is < 720 AND source colorimetry is not Rec.601 THEN convert to Rec.601.

- If destination resolution is >= 720 AND source colorimetry is not Rec.709 THEN Convert to Rec.709.

- Else Leave it be?

** If Party2 is correct:

- If destination format is MPEG4 AND colorimetry is not 601 THEN Convert to Rec.601.

- If destination format is MPEG4 AND colorimetry is Rec.601 THEN Do nothing.

- If destination format is MPEG2, convert colorimetry based on what encoder will place in MPEG2 stream by default; if it places nothing (CCE), then use Rec.709 as per specs.

- If destination format is OTHER, ???.

Hope I'm not further confusing things, I'm attempting to make sense of the discussion in the last 20 pages.

/MLS

The whole 720p mess is with VMR 9 renderers. If you want to use a renderer similar to VMR9 without the BT.709 issues than you're better off using the Haali Video Renderer. You can choose the Colorimetry setting in the renderer which is something the VMR9 renderer won't allow a user to do.

Otherwise, you're better off sticking to old-fashioned overlay renderer.

[DeathWolf]

VMR9 should be avoided anyway. The large color inaccuracies it has in many of its conversions are, in my humble opinion, unacceptable.

[canuckerfan]

Tritical posted (http://forum.doom9.org/showthread.php?p=975906#post975906) here on the 26th of March about a new version that fixes the source==dest error. Is that available for download anywhere? The most recent Colormatrix .ZIP on his site is dated January of this year.

Edit: and it doesn't have the "source==dest" error fixed.
yes, I am curious about this as well. wondering if a version is floating around with this fix.

[kumi]

FYI I sent tritical a PM a few days ago about it, let's wait and see.

EDIT: Good news, Tritical said he'll put up the new version soon.

[kypec]

Good news, Tritical said he'll put up the new version soon.
Is it available yet?
More than 2 months have passed and there is still only v2.1 announced in the beginning of this thread which is dated 18th Jan 2007 :confused:

[vega22]

Always we are worried about the color in the video but we forgot the serious color problems that have ours displays. There is an enormous emptiness in the subject correction of display color, and we needed effective tools to solve it.

I have a probe to calibrate my LCD. Therefore, I know the real coordinates of points R-G-B in my display (all saturated).
My real gamut is much more wide that standard 601 and 709. Therefore, I have all the appropriate colors there, but my matrix expresses everything unfaithfully

Could be implemented in this filter the option to introduce your real display gamut to use it like corrector (real gamut display->standard color space conversion)?:eek:

[Wilbert]

Could be implemented in this filter the option to introduce your real display gamut to use it like corrector (real gamut display->standard color space conversion)
Just curious. Is this a wise idea to do? What if you buy a new display one day?

[vega22]

Just curious. Is this a wise idea to do? What if you buy a new display one day?

...The day when the store lets to me to prove with my probe all your displays before paying. Anyway, do not exist displays calibrated. Mine it´s a month old. 1300$...Very very good grayscale, noise and gamma...but...

[tritical]

Well, finally a new version: [link removed]. Changes:
- Changed the integer scaling parameter to a boolean parameter named clamp
(scaling 1/2 were redundant)
- Fixed source==dest error when using d2v or hints
- Fixed thrdmthd being switched internally (i.e. backwards versus the behaviors
described in the readme)

@Dr.Khron
I looked into the issue you reported back in April and it turns out that it is a problem with tfm and info=3 in dgdecode and not colormatrix.

[Guest]

I looked into the issue you reported back in April and it turns out that it is a problem with tfm and info=3 in dgdecode Is there something I need to fix in DGDecode?

[tritical]

Actually, it seems I spoke too soon and there isn't a bug in anything. What's happening is that tdeint() is detecting the hints from dgdecode() thinking they are from telecide(), and then decides not to deinterlace because of them. The solution is to set hints=false in tdeint.

DGDecode_mpeg2source("D:\Ripping\S03E01\S03E01.d2v",info=3)
colormatrix(hints=true,interlaced=true)
edeintted = AssumeTFF().SeparateFields().SelectEven().EEDI2(field=-1)
tdeintted = TDeint(edeint=edeintted,order=1,hints=false)
tfm(order=1,clip2=tdeintted).tdecimate(hybrid=1)

[kumi]

thank you for the new build!

With version 2.2 and DVD-Rebuilder, it's now possible to do automatic, "set it and forget it" colorimetry conversion with this script pasted into the Filter Editor:

LoadPlugin("X:\Path\To\ColorMatrix.dll")
P:ColorMatrix(dest=0, hints=true)
I:ColorMatrix(dest=0, hints=true, interlaced=true)

Of course you need to enable hinting with MPEG2SOURCE_OPTS=info=3 in your REBUILDER.INI file, and change the dest parameter if using an encoder that expects something other than Rec.709.

How cool is that?

[FredThompson]

2.1 does that. It was in the notes a few builds prior of DVD-RB Pro. It's a very nice method.

[kumi]

Actually that was impossible with 2.1: the "source==dest" error kept coming up.

[FredThompson]

You missed the "c:" macro which was added to DVD-RB Pro scripts recently:

c:ColorMatrix(hints=true, opt=0)

This will use ColorMatrix only if it is needed.

[cweb]

Well, finally a new version: ColorMatrix v2.2 (http://bengal.missouri.edu/~kes25c/ColorMatrixv22.zip).

hi!

I guess the title of this thread should be updated :)
thanks for your work!

[JarrettH]

what's new in 2.2? :p

[Boulder]

http://forum.doom9.org/showthread.php?p=1038118#post1038118 ?

[yesgrey]

tritical,
Could you tell me how to calculate the conversion matrix coefficients?
For example these:
" +0.7152, +0.0722, +0.2126, // Rec.709 (0)
-0.3850, +0.5000, -0.1150,
-0.4540, -0.0460, +0.5000, "

Where do you start from and which are the equations?

Thanks.

[Wilbert]

v1.10 contains a text file "coefficients.txt" where those coefficients are derived.