ColorMatrix v2.3

[OvejaNegra]

HI. After reading all this i'm a little confused about colormatrix. So i will post some questions/doubts and please feel free to correct me:

1- A source (like DVD for example) can use different coefficients for the color. The encorders like XVID, DIVX or X264 (or are we talking about the decoders?) use Rec.601. So colormatrix reads the info from DGindex (using hints or the d2v project) and : Converts the source coef to rec601 (to match the encoders/decoders or IF the source is already rec 601 it stays untouched.

2- The data inside my x264 encoding is YV12 (i will go back here later).
3- When i open a VOB file with DGIndex it converts to RGB (only for the preview of course) AND correct the levels of chroma and luma because the maximum black and white (for example) is just 236 and 16 (that will give me gray and allmost white in a PC with out correction). So it "scales" the range to 255-0. That's why i see a nice picture in my DGindex preview.
4- When i open my favorite avs script in my VDUB the same happens in the preview. (and i see a nice picture).
5- My X264 encoder process the data from my script (it's YV12) and the levels pass untouched, only if i insert colormatrix (hints=true) it will make a correction if necesary (but only in the coeffients, not in the YC levels right?).

6- The encoders won't alter the coefficients of the video or correct anything.

7- In the decoding stage (THIS IS THE PART THAT CONFUSE A LOT OF PEOPLE I THINK).The decoder (like ffdshow) pass the data in YV12 to the video renderer (like VMR9) and the renderer send the data to the video card (something like that). NOW, in some part, someone should scale the levels again (because my PC monitor is 0-255). The renderer or the video card driver BUT sometimes for several reasons that does not happens. And i don't have my nice image (some people think they are not using colormatrix correctly but colormatrix has nothing to do with this).

8-My fresh and new compressed MKV+X264+AAC does not look as nice as in the previews.

What can i do? (Appart of course of having updated drivers, directx and all that stuff)

a) Change the renderer in MPC (VMR9 works bad for me but overlay mixer do the trick, but i lose the subtitles)
b) Cancel the YV12/YUY2 etc output in ffdshow, it will output converted RGB. Looks nice for me but i loose speed with high resolutions.
c) Enable the levels filter in FFDshow and set the input to 16-235 if i remember well and the output to 0-255. That will scale the range. I don't loose speed
and looks fine for me.


If we start talking about bigger resolutions and different matrix things can be more complicated. Enough for me.

9- Haali Renderer makes the corrections? (but i will loose the subtitles if i use it).

10 -Where should i put colormatrix (hints=true) in my script if:

a) I'm encoding a pure interlaced movie (of course i should put the interlaced=true).
b) I'm using forced film in a 100% film movie.
c) I'm using honor pulldown flags with anime/hybrid DVD and TIVTC and all that stuff.

Please fell free to correct me. Use the number of the question to avoid innecessary quotes (10a, 3, etc)

I'm trying to understand the concept but it's a little "complicado" (complicated, in spanish)

Thanks.

[Wilbert]

1- A source (like DVD for example) can use different coefficients for the color.
Yes.

The encorders like XVID, DIVX or X264 (or are we talking about the decoders?) use Rec.601.
If you request RGB from them, they will use Rec.601. Otherwise they will leave them unaltered.

So colormatrix reads the info from DGindex (using hints or the d2v project) and : Converts the source coef to rec601 (to match the encoders/decoders or IF the source is already rec 601 it stays untouched.
Yes.

2- The data inside my x264 encoding is YV12 (i will go back here later).
Yes.

3- When i open a VOB file with DGIndex it converts to RGB (only for the preview of course) AND correct the levels of chroma and luma because the maximum black and white (for example) is just 235 and 16 (that will give me gray and allmost white in a PC with out correction). So it "scales" the range to 255-0. That's why i see a nice picture in my DGindex preview.
Yes. (Btw it's 235, and not 236.)

4- When i open my favorite avs script in my VDUB the same happens in the preview. (and i see a nice picture).
Yes. Note that it assumes Rec601.

5- My X264 encoder process the data from my script (it's YV12) and the levels pass untouched, only if i insert colormatrix (hints=true) it will make a correction if necesary (but only in the coeffients, not in the YC levels right?).
Yes. Irc, it will clip the data if you set levels=false. (I'm too lazy to look it up right now ...)

6- The encoders won't alter the coefficients of the video or correct anything.
Usually they don't. (Some do if you feed them RGB.)

7- In the decoding stage (THIS IS THE PART THAT CONFUSE A LOT OF PEOPLE I THINK).The decoder (like ffdshow) pass the data in YV12 to the video renderer (like VMR9) and the renderer send the data to the video card (something like that).
Yes.

NOW, in some part, someone should scale the levels again (because my PC monitor is 0-255).
Yes, if your source is YCbCr [16,235].

The renderer or the video card driver BUT sometimes for several reasons that does not happens. And i don't have my nice image (some people think they are not using colormatrix correctly but colormatrix has nothing to do with this).
Yes. As you note below, VMR9 doesn't scale the levels back.

8-My fresh and new compressed MKV+X264+AAC does not look as nice as in the previews.

What can i do? (Appart of course of having updated drivers, directx and all that stuff)

a) Change the renderer in MPC (VMR9 works bad for me but overlay mixer do the trick, but i lose the subtitles)
Yes.

b) Cancel the YV12/YUY2 etc output in ffdshow, it will output converted RGB. Looks nice for me but i loose speed with high resolutions.
Yes.

c) Enable the levels filter in FFDshow and set the input to 16-235 if i remember well and the output to 0-255. That will scale the range. I don't loose speed and looks fine for me.[/QUOTE]
Yes. Are you sure about this? Because i suspect you will also loose speed here.


9- Haali Renderer makes the corrections? (but i will loose the subtitles if i use it).
Irc, you can adjust these settings in Haali renderer.


10 -Where should i put colormatrix (hints=true) in my script if:

a) I'm encoding a pure interlaced movie (of course i should put the interlaced=true).
b) I'm using forced film in a 100% film movie.
c) I'm using honor pulldown flags with anime/hybrid DVD and TIVTC and all that stuff.
This should be covered in this thread (probably a few pages back).

[OvejaNegra]

Wilbert: THANK YOU!!!
I have now a new PC with a nice Nvidia GF7300, i don't loose speed using the RBG conversion or the leves correction, but i need more testing with HD resolutions.

I have a a very old Celeron 1.2 GH with Ati RAGE PRO II. With the conversion to RGB my videos with 704 X 480 are allmost unplayable. But with the levels setting everything is fine. Maybe i will loose speed with higher resolutions (like 1280 X 720) but with standard DVD my celeron is ok.


Levels=false? i can't find that here: http://avisynth.org.ru/docs/english/externalfilters/colormatrix.htm#options ???

If i'm using the software player X, most of them use overlay mixer as the default renderer, and i set ffdshow to output RGB: The overlay mixer will overcorrect the levels or with let them untouched? (because it assumes that the correction is already done)? Usually i use MPC but sometimes i test other players.

The overlay mixer ALWAYS correct the levels fine OR it's using the video card for that (and some times will fail if the card is crap or the drivers have bugs). On the other hand, if the correction is done in the overlay mixer, it's software+cpu. Why i dont loose speed? Yes i know that even the most crappy onboard chip decodes YV12 / IYUV but what about the correction of the levels?

I'm just looking for the most safe+trustable+easy way of doing the levels correction (just for telling my friends, not for me). It seems to me that the levels setting in FFDSHOW is safer but since the decoded data is YV12 then the overlay mixer in CoreMedia player (for example) will overcorrect the levels and screw everything. Or it can detect (even with YV12) that the levels are already corrected? I think not.


So, in the end the safer combination is MPC + VMR9 (if you want SSA subtitles in anime) + levels correction or MPC + VMR9 (if you want SSA subtitles in anime) + RGB forced output (if your pc can handle it) or MPC + HAALI (and the ffdshow subtitles). Or don't do anything and leave the work to the Overlay Mixer (IF you can trust in that quartz.dll :) ).

And finally: How can i (by visual inspection) check if my correction is fine? Like comparing the final frame in my player with a preview of the same in VDUB mod (using AVS serving)?

Any advice of how the avs script should be? Or DirectShowSource () it's enough?

NO WAIT! i have one more question: If i open one AVI in VDUB using AviSource () or in Premiere (using of course the VCM codecs) the correction still happens or something may fail? I'm sure Vdub will make the corrections but Premiere, not so sure. I hear rumors about premiere messing with the YV12 colors.


Thank you for your attention.

[tom942]

I don´t really know if this info is useful, but I'm going to post it.

I was playing with Indiana Jones and the Kingdom of the Crystal Skull and The Sleeping Beauty 50th Anniversary (both DVD R2 PAL Spain) and in my case, they are the first DVD's that I found with the colorimetry flag setted and they are really, really new.

When I opened it with DGMPEGDec 1.4.5, I've seen that the Colorimetry field reported: ITU-R BT.470-2. When I saw this, I opened in version 1.5.3, and it reported the same info without asterisk so the stream was flagged, wasn´t it?.

I post this because when I read the threads and FAQ's always it is supposed or assumed that DVD works with 601, but it is not sure, am I wrong?.

If these two new DVD's are correctly flagged, then can we say that BT.601 is the correct color matrix for DVD's MPEG2?.

So when we feed the streams to CCE or HC it should also be set to 601 and not 709?.

I hope this thing helps, if not, just ignore it :).

Regards.

[frank]

BT.601 stands for all standard TV with tube (standard color space) an analog SCART interface.
CCE only encodes BT.601, so you have to use colormatrix in every case for 709 flagged input.

But if you own a modern player with upscaling and HDMI connected to a flat screen TV (only these can show the enhanced color space), then you can use 709 if you have such coder.

[Alex_ander]

CCE doesn't write colormetry data to file header (DGIndex will use * symbol for the assumed info for SD). It will produce the same YUV type, as on input, but the player will always use BT601 coefficients for RGB output, so yes, in case the source before encoding is BT709, you need ColorMatrix for turning it into BT601.

[manono]

When I opened it with DGMPEGDec 1.4.5, I've seen that the Colorimetry field reported: ITU-R BT.470-2. When I saw this, I opened in version 1.5.3, and it reported the same info without asterisk so the stream was flagged, wasn´t it?.

I post this because when I read the threads and FAQ's always it is supposed or assumed that DVD works with 601, but it is not sure, am I wrong?.
ITU-R BT.470-2 is exactly the same as ITU-R BT.601. There's nothing unusual about it and I see it from time to time.

[smok3]

my source is 0-255 RGB huffyuv avi, how should i use this filter for this encoders:
a. hcenc
b. x264
c. wmv
or should i just change the levels to 16-235? tnx.
(this is practical question)

[Adub]

What resolution are your target formats?

Are you going to be creating a DVD with this? Or is it going to be stored on a computer for personal use?

[tom942]

The idea of my initial post was just to give another two evidences that when DVD's MPEG2 is flagged, it reports BT.601. They also reports that are progressive, when they normally were wrongly flagged as interlaced, at least in PAL zone.

I just post it, because when I read the FAQ's about if a DVD uses BT.601 it is only assumed or supposed, but I don´t see a firm statement that says: it is sure that DVD's MPEG2 stream use BT.601 always when you are doing a DVD to DVD backup.

For instance, when I read the FAQ's it says that CCE doesn´t expect a concrete color matrix, but if I continue reading, then says that one people says that it expects 601 and others, 709. In the same FAQ, it says that HC expects 709, although confirmation is needed. Then, I don´t know what to do :).

As these two DVD's have been just released, I thought that it was a good idea to let you know this findings and I would like to know if it is good to "force" to use BT.601 when doing a DVD to DVD backup :).

Regards :)

[smok3]

Merlin7777:

yes, one export will be dvd, x264 will be for flash and one version will be HD, wmv will be web.

source is 1280x720, dvd will be anamorfic pal.

[tom942]

In summary:

If I use CCE, Basic or SP(2), to do a backup of a DVD, doing all the steps by hand or using DVD-RB (for instance), I should use BT.601 because it is ¿sure? that CCE expects as input this color matrix, shouldn´t I?

If I use HC, what color matrix should I use?, which one HC expects, 601 or 709?. I have read the FAQ, and it says 709, but it needs confirmation...

Any advice? :).

[Alex_ander]

There was a separate thread with some useful analysis:
http://forum.doom9.org/showthread.php?p=1193065#post1193065

As for what CCE expects, then according to its manual (SP), in some cases (when it needs conversion between YUV&RGB32) it uses BT601 coefficients. In case you feed YUY2 or any avi file that can be decompressed to YUY2, the manual doesn't mention any calculations of ColorMatrix' style.

[tom942]

@Alex_ander

I was re-reading the link (and some of the threads) that you gave me (this is the FAQ that I was talking about).

If I understood it right, when I'm doing a backup from DVD to DVD, using DGIndex, DVD-RB or other similar, there is no need to use ColorMatrix meanwhile I do not convert to RGB. I don´t talk of upconvert to HD or downconvert to SD.

CCE doesn´t expect a concrete color space. It doesn´t do internal color conversion while encoding.

The same applies to HC encoder, deesn´t it?

The doubt that I've got comes because in that link says HC expects 709, but reading Hanks's posts, he seems to say that HC doesn´t expect a concrete color space, is it right?

In the past I have used the line "Colormatrix (mode=rec.601->rec.709)" but if I undestand it right, I don´t need to use it anymore neither CCE nor HC, is it right?.

[Adub]

@smok3
You may get a kick out of this thread:
http://forum.doom9.org/showthread.php?t=133982&highlight=color+information+bt.601

However, here is what I believe is correct:

Use Rec.601 for HCenc. Be sure to set the flag correctly when you encode it with HCenc.

For the x264 flash, since it will be SD, I believe you also use Rec.601.
For the HD x264, use Rec.709.

For WMV, I have no idea. My best suggestion would be to try both and see which one looks better. This approach can be applied to all of the above encoding situations.


@tom942
Yes, it's sounding like you are right. There should be no need for colormatrix when going from DVD to DVD. The trick with CCE is that it wants YUY2 input, but that is about it. DVD-RB should handle this all correctly for you.

And if you look at HCenc's documentation, I believe that it likes Rec.601 for SD and Rec.709 for HD. Again, refer to the above link that I posted for more information.

[tom942]

Thank you Merlin7777 :).

I was reading that thread (that Alex_ander already point me before) and there was a point that confuse me:

What encoders expect BT.709?
HCenc, any other encoder that by default flags the output stream as BT.709
(verification would be appreciated)

But then, after re-reading nearly all threads, I found tests that Hank done with his encoder and I can undestand that it doesn´t expect anything. It takes what you give him.

http://forum.doom9.org/showthread.php?p=1061520#post1061520

As you said, I suppose that Hank is following the rule of 601 for SD and 709 for HD.

What I'm looking for is that I want do the correct steps with the apps. Later, if my DVD player do other things, it doesn´t mind me, because it wouldn´t be my fault.

Thank you for your time and answers :).

P.S.: This was the table I used to follow. I found it here some time ago:

Source_Colorimetry------------------Encoder-------------------Conversion_to_Use
Rec.709----------------------------CCE/HC/QuEnc-------------No Conversion or 'Rec.601 -> Rec.709 with hints=true'
Rec.601----------------------------CCE/HC/QuEnc-------------Rec.601->Rec.709 or 'Rec.601 -> Rec.709 with hints=true'
Rec.709----------------------------TMPGEnc------------------Rec.709 -> Rec.601 or 'Rec.709 -> Rec.601 with hints=true'
Rec.601----------------------------TMPGEnc------------------No Conversion or 'Rec.709 -> Rec.601 with hints=true'

As you can see, it was the opposite :).

[Adub]

Rec.709----------------------------CCE/HC/QuEnc-------------No Conversion or 'Rec.601 -> Rec.709 with hints=true'

That table seems screwed. Why would one use the 601->709 conversion on a source that is already 709? It makes absolutely no sense.

[tom942]

I don´t know.
It is a table that was in the forum before last year color matrix discussion. I found it when everybody assumed that DVD's MPEG2 was 709 due to the way that old versions of DGMPGDec report the absence of the colorimetry flag.

[smok3]

about luma range (and flash playback);

a. puting the whole 0-255 'RGB' range into yv12 -> x264 and then playing that back via flash seems wrong (the blacks are clipped? dunno...), doing the pc->tv conversion before will give more acceptable results (if little washed out)

about DVD;

b. i fed hcenc with squashed range (16-235) and again it seems a bit washed out (with mpui or vlc), but more black would look wrong again as it seems

:confused:

[fano]

I'm having some problem resing a 632*264 video to 1920*108p and using colormatrix to restore the right colors.
I see a little band on the right part of the image: it seems as a repetition of a part of image.

In this screenshot you can see clearly what is the problem:
http://img155.imageshack.us/img155/6725/garbagedresizehalfresax4.png

This the avisinth script that I'm using:


setMtmode(2)
ColorMatrix(mode="Rec.601->Rec.709")
ffdshow_setDAR(ffdshow_dar_x, ffdshow_dar_y)
MT("hqdn3d(2)", threads=4)
DisposeAxis(1920, 1080, ffdshow_dar_x, ffdshow_dar_y)
MT("Spline16Resize(da_w, last.height)", threads=4)
MT("Spline16Resize(last.width, da_h)", threads=4, splitvertical=true)


If I delete the colormatrix line or pospone it after resize the colored line disappear... but Colormatix after resize has not effect, right?

There is a known solution for this or maybe is a bug?

Thanks for your help,
fanoI

[tritical]

There's a bug in the mmx/sse2 routines causing it not to process the last (width&15) for sse2 and (width&7) for mmx worth of pixels for non mod 16 and non mod 8 widths respectively (you end up with whatever values happen to be at that those memory locations in the destination frame). A temporary fix is to set opt=0 to force the C routines. I'll put up a fixed version later tonight, it just needs one line changed.

[fano]

I've tried to add opt=0 and now works right!

Thanks for your help,
fanoI

[tritical]

I put up v2.4 on my website. Only change was fixing this little problem.

[fano]

Ok I'll try it tonight :)

[vucloutr]

hi, got a problem with colormatrix (using the latest 2.4).

LoadPlugin("..\DGDecode.dll")
DGDecode_MPEG2Source("file.d2v")

ColorMatrix(d2v="file.d2v")
Source is a MPEG2 HDTV .ts and I used DGIndex 1.5.3 for indexing.
With this script, I get an error message "ColorMatrix: d2v and filter frame counts do not match!"
Without the .d2v param and with info=3&hints=true i get strange colors in some frames.
normal.png (2.3 MB) (http://a.imagehost.org/view/0910/normal)
strange.png (2.1 MB) (http://a.imagehost.org/view/0561/strange)

any help is appreciated :)

[tritical]

If you turn on debug output what source colorimetry does it detect for the good frames and the bad frames? That d2v error about frame count mismatch will only trigger if multiple colorimetrys are present. Could you post a sample?

[vucloutr]

debugview log says: 00000173 14.75968838 [1248] ColorMatrix:1784: frame 86432: detected hint = 1 (Rec.709)
00000174 14.75977802 [1248] ColorMatrix:2908: frame 86432: using YV12 Rec.709->Rec.601 conversion (SSE2).
00000175 15.04918671 [1248] ColorMatrix:1784: frame 86433: detected hint = 4 (FCC)
00000176 15.04928112 [1248] ColorMatrix:2908: frame 86433: using YV12 FCC->Rec.601 conversion (SSE2).
first is the "normal" frame and second is the "strange" one.

here's a sample (.7z ~45MB) (http://www.megaupload.com/?d=37043OPD) (P4S5VV0RD: fw48czlqw94bgt g-f45tw-3.6mw.56w-v3mn)

[tritical]

There were two bugs causing problems. First was that the d2v parsing was never updated for v16 DGIndex project files. This didn't effect colorimetry detection in v16 d2vs, but frame count detection was incorrect (only a problem if multiple colorimetrys were present). Second, there was a bug in the mmx/sse2 routines used for FCC<->Rec.601 conversions that caused incorrect U plane values. Both problems are fixed in v2.5 on my website.

[vucloutr]

thanks!

edit: whoops ^^

[canuckerfan]

if a conversion from 601 to 709 has been done. can it be reversed by just calling colormatrix again and changing the destination to 601? I realize it would just be best to go back and not do the conversion in the first place.

[Wilbert]

if a conversion from 601 to 709 has been done. can it be reversed by just calling colormatrix again and changing the destination to 601? I realize it would just be best to go back and not do the conversion in the first place.
Sure. Use mode="Rec.709->Rec.601".

[leeperry]

http://thumbnails14.imagebam.com/5155/6cd6d751549075.gif (http://www.imagebam.com/image/6cd6d751549075)

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

http://thumbnails9.imagebam.com/5155/7e837451549079.gif (http://www.imagebam.com/image/7e837451549079)

why would it change the levels :confused:

[Keiyakusha]

Hi. I'd like to ask something about colormatrix...

Here (http://img230.imageshack.us/img230/3301/infoor.png) is info from DGIndex about my DVD.
Here (http://img156.imageshack.us/img156/7328/29471546.png) is a screenshot, taken in VirtualDub using avisynth script with only one line in it: Mpeg2source("VTS_01_1.d2v")
Here (http://img156.imageshack.us/img156/667/kkkkkkkk.png) is a screenshot of the same frame, but taken with following script: Mpeg2source("VTS_01_1.d2v",info=3).Colormatrix(hints=true,interlaced=true)
It looks like screenshots are the same, but here (http://img83.imageshack.us/img83/1112/13520879.png) is what I see after overlaying them using "difference" and boosting levels.

I expected to see no difference at all or to see much more difference... So all is fine here, this is how it should be? Am I doing something wrong?

[Keiyakusha]

After reading many nice posts by manono in this (http://forum.doom9.org/showthread.php?t=134684) thread, I think maybe the difference on my screens appears because of clamping some levels after applying colormatrix. Indeed such things shouldn't be done 'behind the back'.

[leeperry]

indeed, RTFM helped me a lot too :D

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

[leeperry]

XhmikosR has been kind enough to compile an ICL11/SSE3 version of ColorMatrix, on the aforementioned call(on 4 threads w/ a 3.2Ghz Q6600) I get a 3% speed improvement(going from 593 to 609 fps): http://www.mediafire.com/?n2gumty1zyn

[Keiyakusha]

XhmikosR has been kind enough to compile an ICL11/SSE3 version of ColorMatrix, on the aforementioned call(on 4 threads w/ a 3.2Ghz Q6600) I get a 3% speed improvement(going from 593 to 609 fps): http://www.mediafire.com/?n2gumty1zyn

Thanks :goodpost:

[Wilbert]

XhmikosR has been kind enough to compile an ICL11/SSE3 version of ColorMatrix, on the aforementioned call(on 4 threads w/ a 3.2Ghz Q6600) I get a 3% speed improvement(going from 593 to 609 fps): http://www.mediafire.com/?n2gumty1zyn
Please, include the source. Thanks.

[XhmikosR]

So you need the ICL project files? Because that's the only thing that's different and that I changed the File Info to distinguish it from the normal build.
Anyway, here (http://www.mediafire.com/?sharekey=3f33c77c2cf9ce25ab1eab3e9fa335ca5d770fd2dc6da976) is the package with the source included.

[JoeH]

Thanks for your great tool. I use it all the time.

I was wondering if it would be feasible to prepare a 64-bit version. I have been looking at squid_80's 64 bit version of AVISynth and related 64-bit plugins that he has prepared, and he has everything I use in AVISynth ready in 64-bit except ColorMatrix.

I have no idea what that would imply, but if it is something feasible it would be great! Thanks again.

[leeperry]

hi tritical, I was wondering if you had any idea about this: http://forum.doom9.org/showpost.php?p=1341393&postcount=1751

problem of chroma alignment possibly? any idea how to get the same exact output as ffdshow please?

:thanks:

[yesgrey]

any idea how to get the same exact output as ffdshow please?
When you use t3dlut, the conversion between BT.601 and BT.709 coefficients is performed like this:
1) up-sample chroma from 4:2:0 or 4:2:2 to 4:4:4
2) convert BT.601 -> BT.709
3) sub-sample chroma from 4:4:4 to 4:2:0 or 4:2:2
I'm not sure about Colormatrix, but I think it will work similarly...
When you use ffdshow it's a different thing, because you are not converting YV12->YV12 or YUY2->YUY2, you are converting YV12->RGB32, and in this kind of conversion, you don't need to downsample the chroma at the end.

Summing up, you only could be able to get the same output as ffdshow if you use it like ffdshow. With t3dlut, you should set it for YV12->RGB32, and not for YV12->YV12 as you are performing in your examples. With Colormatrix, that's not possible, because it only performs conversions between YV12/YUY2->YV12/YUY2.

[leeperry]

ok, but we had the same problem when I wanted to get the same output from your LUT as I was getting from the PS script...and at some point, we did! you told me there was some hiccup in the LUT code and made a bugfix :o

I'll try to fix the 601>709 LUT conversion .ini file, and hopefully I'll have more details about what's "broken" to give to tritical.

[yesgrey]

hopefully I'll have more details about what's "broken" to give to tritical.
I don't think there's anything that tritical could "fix".
From what I understand, the difference between Colormatrix and t3dlut is that the later let's the user define which chroma placement to consider, while the former always assume it internally.
I believe the problem is due to the last step of chroma sub-sampling, so I don't think it could be fixed, because there is nothing to fix...;)

[leeperry]

well, maybe he could allow to choose the chroma alignment? :o

[yesgrey]

well, maybe he could allow to choose the chroma alignment? :o
First, try with t3dlut chroma alignment options. If it doesn't solve the problem, adding the chroma alignment to Colormatrix will not help also...

[leeperry]

First, try with t3dlut chroma alignment options. If it doesn't solve the problem, adding the chroma alignment to Colormatrix will not help also...
I've just tried all the possible settings in t3dlut/yv12toyuy2 and yuy2toyv12...what works the best is t3dlut(cplaceU=1) + yv12toyuy2(itype=0):

http://thumbnails23.imagebam.com/6152/1e2c9361511788.gif (http://www.imagebam.com/image/1e2c9361511788)

but if you compare to these, ffdshow still looks slightly better IMHO: http://forum.doom9.org/showpost.php?p=1341393&postcount=1751

still would be pretty cool if tritical could allow to change the chroma placement in ColorMatrix() http://forum-images.hardware.fr/images/perso/otakonleboss.gif

[tritical]

To match ffdshow you probably need to set itypeU=1 in t3dlut. Since by default t3dlut uses cubic interpolation for 4:2:2->4:4:4, which utilizes 4 pixels, so the end points of the kernel will still be spanning those color blocks. Anyways, I think basing what looks best on that one image is not a good idea. It contains big blocks of color with hard transitions and mpeg1 chroma placement... so of course duplication and mpeg1 chroma placement assumption in t3dlut/yv12toyuy2 will look best on it. However, I could easily generate an image where that combination will look much worse than cubic interpolation with mpeg2 chroma placement assumed. Anyways, with respect to colormatrix there is nothing to change in regards to chroma alignment since it does not upsample. It converts directly YUV->YUV, to get the UV values for computing the new Y samples it uses nearest neighbor. That is, in YV12 each set of 4 luma pixels ((x,y)(x+1,y)(x,y+1)(x+1,y+1)) uses the U and V pixels at (x>>1,y>>1) in the U and V plane respectively.

[leeperry]

ok, thanks for the feedback tritical...if you say that this doesn't matter(even on a wide projection screen), I wholeheartly believe you http://forum.slysoft.com/images/smilies/agreed.gif

[Shinji-kun]

I encoded an MPEG-2 file to MPEG-4 AVC (x264). Would colormatrix be necessary in this situation. The brightness does seem a little off.