lumi masking

[droolian01]

Hi there.

I do all my computing though my tv (second hand sony trinitron 29 inch) using wireless keyboard and mouse as i like to lie around lazyly on my sofa! So everyone of my avs scripts ends with

levels(5,1,255,0,255)

I find this little tweak makes very little difference to the overall brightness of the xvid but does help to reduce the effect of the blocks in dark areas. I have always avoided lumi masking as it seemed that MORE bits were needed in dark parts of a film to correct this.

This is such a vital topic for xvid, and i will eagerly monitor this thread.

Good stuff!

[iago]

Originally posted by droolian01
This is such a vital topic for xvid, and i will eagerly monitor this thread.I totally agree with you. This problem has always been the most annoying and persistent one for me since my very first encodes. And I'm really glad that we've come to a point of overcoming it finally ;).

Now, back to Koepi's questions on dvd2avi PC or TV scaling matter: After another session of testing, initiated by the doubt that Koepi has managed to let loose onto me (LOL! ;)), here are the results:


Matrix (frames 0-3746)
Koepi's 04092002-1 binary - constant quantizer 4
dvd2avi 1.76 - VirtualDub 1.4.10 fast recompress

Compressibility:

Matrix_Mpeg_Lumi_PCScale(original): 19822 kb
Matrix_Mpeg_Lumi_TVScale(original): 19822 kb
Matrix_Mpeg_Lumi_PCScale_colorYUY2: 22922 kb
Matrix_Mpeg_Lumi_TVScale_colorYUY2: 22922 kb

Visuals:

No difference between the PC scaled and TV scaled original encodes: Both has the same annoying problem of ugly blocks all around in dark/black areas.

No difference between the PC scaled and TV scaled colorYUY2 encodes: Both has pure clean black color in such areas and has excellently eliminated the problem ;).


And some other results that could be useful (if read properly ;)):

Matrix_Mpeg_NoLumi_PCScale_colorYUY2: 23692 kb
Matrix_Mpeg_Lumi_PCScale_colorYUY2: 22922 kb
Matrix_h.263_Lumi_PCScale_colorYUY2: 22846 kb


Final comments:

1) Using PC Scale or TV Scale (YUV Colorspace) in dvd2avi has no influence on file size and quality (with or without colorYUY2). The results are absolutely the same.

2) colorYUY2 filter works with lumi masking and h.263 quantization without any problems, performing the same excellent job. So those who focus on "more" compressibility (which is quite understandable ;)) in addition to getting rid of ugly blocks in dark/black areas can use colorYUY2 with h.263 and lumi masking safely as well.

kindest regards,
iago

[Koepi]

Erm, the secret is not to use const quant... :) You won't notice a difference in "compressability" there. It's a matter where the YUV-ranges are cut. For TVscale, the scale is only from ~30-200, while pcscale should give all values from 0-255.

Strange that there is no visual difference... Maybe something to do with mpeg2dec.dll not respecting this value? I think those tests were done with dvd2avi 1.74 (or 1.76) and a "non tweaked" mpeg2dec.dll, sorry that I can't remember correctly (or was it even back in vfapi-times?).

Regards,
Koepi

[Swede]

Since the only difference in the *.d2v-file is YUVRGB_Scale=0 or YUVRGB_Scale=1 (in the beginning of the file) perhaps someone that's familiar with mpeg2dec.dll could verify that the .dll don't respect this value?

[Suiryc]

If I remember well DVD2AVI 1.76 do not tell in the .d2v file if you choosed PC or TV Scale. That explains why there is no difference.

[droolian01]

Hi all.

I just tried colorYUY2 and from the preview window in vdub it just seemed to fiddle with the levels, probably something like

levels(20,1,250,0,255)

which made the whole video too dark for me. I've done lots of messing with levels, tweak and even deliberately oversaturating/increasing contrast on capture settings and my conclusion is you will always get blocky dark areas with low contrast/bright settings - thats why i compromise with

levels(5,1,255,0,255)

If your aim is maximum compressability then the bits have to be re-distributed from somewhere and lumi masking therefore has its place, but it seems to me that the default behaviour of xvid (and i assume all mpeg4 codecs) involves similar sorts of redistribution.

Now i wonder if it would be possible to have an option in xvid that is the opposite of lumi masking - gives more bits to dark scenes/doesn't redistribute as many? Or just take from bright scenes only (mild lumi masking?) - although this could be a problem as i noticed that the 'white outs' in six feet under can look ugly sometimes!

This option obviously would be for the 2-3 cd encoders and would probably bump up the quants on 1 cd encodes making things uglier.

If this is nonsense i appologise in advance - and tell me where i have gone wrong with my ideas please!

[Marc FD]

Maybe i'm totally wrong, but i think you could :
- Have a clean black
- Reduce Filesize
- Keep overall quality in bright scenes
all that in the meantime.

i don't see why you couldn't....

i'll create a little C avisynth filter for test purpose, just to see if my theory is working. when i would have time :(

EDIT : MPEG2Dec is using TV/PC scale. i saw it when i played with.

[Swede]

Originally posted by Suiryc
If I remember well DVD2AVI 1.76 do not tell in the .d2v file if you choosed PC or TV Scale. That explains why there is no difference. I tested *before* I posted... The difference *is* there, in 1.76.

[trbarry]

Since the only difference in the *.d2v-file is YUVRGB_Scale=0 or YUVRGB_Scale=1 (in the beginning of the file) perhaps someone that's familiar with mpeg2dec.dll could verify that the .dll don't respect this value?

IIRC that parm only affects how to do the conversion to RGB. Since MPEG2DEC.dll always converts to YUY2 instead of RGB that parm is ignored.

- Tom

[Suiryc]

Oops sorry in fact I misunderstood with the ColorSpace (YUV or RGB) choice.

Sorry again :(

[Koepi]

Ah, ok, so it was relevant back in vfapi days - too bad. Well, then you have to correct the values like in the example above :)

Regards,
Koepi

[Dali Lama]

Originally posted by trbarry

IIRC that parm only affects how to do the conversion to RGB. Since MPEG2DEC.dll always converts to YUY2 instead of RGB that parm is ignored.


That is exactly correct Tom. If I saw the posts earlier I would have mentioned this. Furthermore, look at it this way, most DVDs are mastered for viewing on TVs therefore, if you keep the YUV options checked in DVD2AVI then the effective scale is TV. Therefore, it is necessary to perform ColorYUY2 in the AVS if the encoding will be viewed on computer monitors.

"Ah, ok, so it was relevant back in vfapi days - too bad. Well, then you have to correct the values like in the example above."
-Koepi

Yes, Koepi you got it ;)

Bluedan, there is info about the Lanczos3Resize filter in the AVIsynth Forum. But I can assure you that there is a significant speed drop from using it, but also a significant quality increase. To me, it doesn't blur or sharpen too much. Its a well known high quality resizing algorithm for photographs. Try it out, I think you'll like it.

Take Care,

Dali

[iago]

Originally posted by droolian01
I just tried colorYUY2 and from the preview window in vdub it just seemed to fiddle with the levels, probably something like levels(20,1,250,0,255) which made the whole video too dark for me. I did some 2-pass tests with Matrix Chapter 3 with the same exact Xvid parameters (mpeg/mpeg, no lumi, quantizers 2-5/2-8, internal cc with default altCC values, and setting the filesize value in such a way that (13650 kb) it would correspond to an average bitrate of 625 kBit/s). As a result coloryuy2 doesn't seem to correspond to levels(20,1,250,0,255) as can be seen in the attachment. Also, you're right, coloryuy2 really darkens the movie and only thus it can totally eliminate the blocks. But a setting of levels(20,1,250,0,255) is not relevant and it not only makes the movie much darker than coloryuy2, but also still cannot eliminate the blocks as successfully.

Originally posted by droolian01
...i compromise with levels(5,1,255,0,255)In my tests, this setting simply cannot solve the problem, with still clearly visible blocks all around, though they may be a bit less than before.

Originally posted by droolian01This option obviously would be for the 2-3 cd encoders and would probably bump up the quants on 1 cd encodes making things uglier.Well, I guess what you mean by "this option" is "ColorYUY2". I guess this is possible, but imo it depends on the source. Based on my limited tests, especially for dark movies it may really decrease compressibility considerably and therefore cause a big increase in quantizers. (However, maybe luckily maybe as a result of capping quantizers, I didn't have much "visible" or "annoying" problems in terms of quality due to higher quantizers in my full Matrix encode.)

Originally posted by droolian01
Now i wonder if it would be possible to have an option in xvid that is the opposite of lumi masking - gives more bits to dark scenes/doesn't redistribute as many? Or just take from bright scenes only (mild lumi masking?)That would really be interesting and I would happily try it too if there were such an option, though I don't know of course if such a thing is possible or not ;).

And attached you can find the (jpeg) screenshots (with no post-processing, taken in VirtualDub) from original DVD, and levels(5,1,255,0,255) encode, levels (20,1,250,0,255) encode, and ColorYUY2 encode.

regards,
iago

[Defiler]

Is it feasible to add an ffdshow feature similar to ColorYUY(), or have I fallen behind the flow of the thread?

[droolian01]

Hi all.

@iago - Thanks for the tests - coloryuy2 definitely gets rid of the blocks in the dark areas, much more than using levels. (btw my suggestion of using levels(20,1,250,0,255) was just a guess at how i thought i could recreate the contrast narrowing that seemed at the time that coloryuy2 was doing - only a guess and clearly wrong!)

I'm so impressed with your results that i am going to use it on my next encode - altough i can't be too experimental as i have a backlog of half a dozen captures to process (hd now FULL!!!) and as buffy is on 5 times per week (no repeats!) and 6 feet under once per week i have no time to re-encode and rely on people like you to show what can be done with the new toys! (thanks)

My comment about 2-3 cd encoders refered to my idea of having 'anti-luming masking' option, it did not refer to coloryuy2 which i beleve like you will increase compressibility. I mentioned the 2-3 cd encoders as i thought my idea (if possible) would be ignored as it goes against the whole idea of video COMPRESSION but i just wanted to pre-empt that argument to hopefully get some feedback from developers (ok guys assuming it is desireable - is it possible to allocate more bits to dark scenes like that?)

Thanks again

[Sharro]

Hi Everybody,

I'm getting a xvid forum addict.

Are we just talking about getting rid of blocks? I cant really figure out what these screenshots mean in terms of playback.

Is it my impression or levels(5,1,255,0,255) are the ones who bring us the brightness closer to the dvd one? I understand that will decrease compressibility but ... wouldn't it be something to take in account for 2 cd encodes (my case most of the time).

I watch my movies only on TV... so brightness/contrast/sharpness are a main issue to me.

Sorry, I just cant stay quiet...

Take care.

Keep on Thinking, Keep on Testing, Keep on Posting.

Thks.

Sharro

[Koepi]

Hm... if xomeone would now put in all these usefull things into one dll it would be cool:

think of it this way...

LoadPlugin("MPEG4tool.dll")
MPEG4tool(source="myfile.lst",tvout=yes,crop="0,76,0,76",resize="lanczos,640,272")

(and all things that are vital which I forgot, maybe a convolution3d as well ;) )

the source is assumed to be for mpeg2decoder.dll from Nic, as well as the cropping. The tvout-option is just a switch if colorYUY2("TV->PC") should be invoked or not, and finally the resize should be clear ;) .

Does this sound stupid? I'd love to see such a "swiss army knife" (the important part is to have all in one plugin, with an easy-to-use commandline, so you don't need 5 dll's and need to remember ever command you have to use with it's parameters) for encoding issues.

Best regards,
Koepi

[droolian01]

Hi Sharro

If you turn your brightness to max on your tv and zoom into the guys back on the right you will see that the coloryuy2 one is block free (they are blue-ish on my screen)

All mpeg4 codecs afaik produce these ugly blocks in dark areas/scenes, its so bad that that it can look almost like a pixelated 'ghost' hovering there. It is more noticeable on tv than computer monitors and the usual way to 'get rid' of these artifacts is to turn down the brightness on the tv - not really satisfactory.

I used levels(5,1,255,0,255) as a way of just making the 'black part blacker' to reduce this a little - but it never got rid of it. Higher values of levels messed up the contrast/made the film too dark. Coloryuy2 looks to be the best so far at sorting this problem, but i wonder if the codec couldn't be tweaked for this - that all

Hope this helps

[iago]

Originally posted by Koepi
...I'd love to see such a "swiss army knife"...That would absolutely be great Koepi! ;)

* Nic's MPEGDecoder with correct framecount without depending on "trim", and yes together with NicCrop absolutely.
* Convolution3d with the most suitable settings discovered for regular movies to increase compressibility.
* Lanczos3 resize (compressibility is very close to sharp bicubic but quality is probably better) and absolutely SimpleResize as another option.
* ColorYUY2 or correspondent "levels" settings, dealing with black color as perfectly, but without darkening the movie that much.
* The add-noise option "during the encoding process" as suggested by -h, but only applying for dark and black areas, as an alternative.
* Inverse-lumi masking, stealing bits only from very bright scenes and distributing those bits to dark scenes.

and etc., etc... ;)

Who knows, maybe one day ;)...

kindest regards,
iago

"...There is a crack in everything... That's how the light gets in..." from a song by L.Cohen


EDIT: BTW, droolian01, I guess the closest levels setting to ColorYUY2 is something like levels(16,1,235,0,255) imo, but still not as successful as ColorYUY2. Maybe ColorYUY2 is also messing with the "gamma" setting a bit, I don't know...

[iago]

Please see the images attached: One with ColorYUY2(Levels="TV->PC"), the other with levels(16,1,235,0,255).

iago

EDIT: Where is my attachment?!! ;) It's just a very small zip with only two images included! ;)

[Dali Lama]

Originally posted by iago

* Inverse-lumi masking, stealing bits only from very bright scenes and distributing those bits to dark scenes.


Iago, I think the same way. I believe the opposite of lumi-masking will work better. Think about it, can you stare into the sun??? No, because its so bright. There are many times in movies (like explosions or bright flashes or sun shots) where the human eye cannot bear to stare or notice the blocks in it. On the other hand, dark scene blocks as this thread has pointed out IS a problem.

So, as of now, no lumi-masking for my encodes (never used it either). But hopefully as Iago put it, "Inverse lumi-masking"

Maybe a new thread should be started :sly: ,

Dali

[Marc FD]

About "inverse-lumi-masking".
If you want to achieve big sizes, encode with constant quant 1.
And if it's not big enough, use zero-me.
Adaptive quantization (like lumi-masking) is _only_ able to increase quantizers. something else is meaningfull.

BTW, using Layers, Levels, Tweak and Blur combo, maybe you can achieve to get a better black. could worth a try.

@Koepi

a rippack does exactly that, no ?

[Maurizio]

Adaptive quantization (like lumi-masking) is _only_ able to increase quantizers. something else is meaningfull.

Well, wasn't said that lumi-masking goal was to remove bits
where unneeded (not likely to be seen) and to redistribuite them
in more sensitive (to eye) places ?

Maurizio

[Marc FD]

no : it only removes data.

the reallocation is done by the curve scaler :
because the frames are less big at same quant, you can use lower quants.

BTW, doom9 totally screwed his XviD-encode for his comparison by using Lumi-Masking. it's one of the most experimental features of XviD. Because i know how it works, i would never use it for a real rip.

If people don't care, they do as they wish.
Never, _never_ forget than XviD is in alpha-stage.
(it's the best MPEG-4 codec, not the more safe)

[Koepi]

"rippack"?

You mean, some stupidly collected filters and programs, like a giant gknot-centered all-in-wonder installer?

Nope. I mean just a simple, single avisynth plugin which includes all those. I want to do that stuff by hand. And don't want any programs to give me suggestions.

(I coded expert systems some years ago and know that I don't trust them if I don't know the sources/databases).

Regards,
Koepi

[droolian01]

Hi all.

@ Koepi - this super plugin sounds very good, would make life easier for routine encodes

@ Marc FD - its a shame my idea of inverse lumi masking is a non starter, i wasn't aware that the procedure was just a data remover and not a data reallocator - oh well! Your point about encoding with quant 1 and incresing sizes misses the point, an excelent encode (few if any blocks at a 'good' resolution and filesize) can be spoilt by these 'darkblocks'. Sure we can prepare the source in such a way to reduce these (coloryuy2, levels, tweak etc) but if there was any way that the codec itself could allocate bits to these areas it would be worth doing. File sizes may not increase massively, and users would have the choice of how many cd they would shoot for anyway.

@ iago - i am experimenting with putting a 'tweak(bright=15) before the coloryuy2 line in order to compensate for the darkening effect.

Telecide(blend=false)
crop(4,4,360,568)
Convolution3d (0, 6, 6, 8, 8, 3, 0)
UnFilter(40,40)
tweak(bright=15)
Lanczos3Resize(512,384)
msharpen(threshold=10,strength=150)
ColorYUY2(Levels="tv->pc")

I think this would not cause many more (if any) blocks to appear as the coloryut2 comand seems to be doing more than just a simple 'levels' type command. Have a go with this and see what you think - remember i only encode tv captures so my numbers might need adjusting for dvd rips.

Thanks again

[Swede]

Originally posted by iago
EDIT: Where is my attachment?!! ;) It's just a very small zip with only two images included! ;)Well, you do know that each attachment has to be validated.?. And we (the mods) do have a real life, at least some of us :) (I had to stop by my local pub on my way home)

[iago]

Originally posted by Marc FD
About "inverse-lumi-masking".
If you want to achieve big sizes, encode with constant quant 1.
And if it's not big enough, use zero-me.I simply cannot understand why "such" a reply arrives, instead of just explaining "why" it can be possible or not; or if it "is" possible, then what the consequences will be.

It was just an idea after all, it may be possible or not. For example, ColorYUY2 also decreases compressibility considerably and ups the average quantizer, but still it can stand as a solution to the irritating problem of blocks in dark/black areas for many users.

BTW, I'm not a "coder" but just a "user" and my actual field of study is language and literature ;). And I really "respect" all the great effort and works of the coders here in "this world" (including you) regarding filters and codec development; but I guess that shouldn't lead to an undervaluing of "users", who also deserve some respect imho or at least who expect replies without disregarding some basic rules of "communication".

Thanks,
iago

EDIT: Just like Swede did, in reply to my "attachment" question, which was a much lighter matter actually ;). And I was kind of joking actually Swede, really sorry if that upset you. Thanks anyway ;)

[Marc FD]

Originally posted by droolian01

File sizes may not increase massively, and users would have the choice of how many cd they would shoot for anyway.


:confused:

That's the problem : filesize _will_ increase massively.
more needed bitrate (2x,3x!!) in dark scenes if you want very high quality.

I think you've forget that MPEG-4 is a _very_ lossy codec.
the actual ratio of an encode is around 1/500-1/5000 of original data.

The problem of "blocks in dark areas" is _wanted_ !!
Because "blocks in dark areas" is _much_ better than "blocks on the whole movie". It's how MJPEG/MPEG-1/MPEG-2/MPEG-4/ect... codecs work.

EDIT :
@iago
Sorry, but it's just i try to explain why you can't do some things.
I try to be the more effective possible. If you want to know all the details of why it's not possible, you'll need to learn a lot of stuff on video codecs. my own knowledge is small.
Please, don't say i'm bad because i'm having bad news.

PS : If you want, i can stop to post in this thread and let you dream. i'm not wanting to be rude, nor to be bad. i'm here to help and explain if i can.

[iago]

@Marc FD

If you want, i can stop to post in this thread and let you dream. i'm not wanting to be rude, nor to be bad. i'm here to help and explain if i can. Sorry Marc, but I really don't want to prolong this argument unnecessarily. Thanks for your explanations, anyway. But remember, without dreaming first, you cannot achieve anything. And sometimes the line between the real and the unreal (of "now") is very very thin.

kindest regards,
iago

[Swede]

Originally posted by iago
EDIT: Just like Swede did, in reply to my "attachment" question, which was a much lighter matter actually ;). And I was kind of joking actually Swede, really sorry if that upset you. Thanks anyway ;) I'm not upset, not at all. I just tried to keep your joke running. ;)

[droolian01]

Oh well....that's told me!:)

As Scotty would say to Captain Kirk "ye cana change the laws of physics"
This thread has been very useful, For one i have learned a little more (very good - thanks Marc FD), i think it has been established by iago that lumi masking will increase dark-blocks. Iago has also tested a possible solution with coloryuy2 and a possible codec related tweak was suggested by -h - introducing ac noise when blocks fall below a certain lumi value (or something like that:confused: !!)

No need for harsh word - but maybe it is difficult to avoid when people are so passionate about their interests, its this which motivates users and developers to do great stuff

Keep it up !!!!

[iago]

OK, some more test results: ;)
[regarding compressibility decrease and high quantizers issue with ColorYUY2(Levels="TV->PC")]

Matrix Chapter 3 (very dark content) / XviD 2-pass Koepi's 04092002-1 build / internal curve compression / 6.UltraHigh / MPEG-MPEG / No Lumi / Max-Min I-frame intervals: 300-5 / Quantizers capped: 2-4 2-8 / payback delay: 300 / payback with bias / AltCC with default parameters / target size: 13650kb ~ 625 kBit/s

script1
-------
LoadPlugin("C:\PROGRA~1\GORDIA~1\mpeg2dec.dll")
LoadPlugin("C:\PROGRA~1\GORDIA~1\colorYUY2.dll")
LoadPlugin("C:\PROGRA~1\GORDIA~1\SimpleResize.dll")
mpeg2source("D:\MATRIX-DE\CHAP3.d2v")
crop(2,80,718,418)
ColorYUY2(Levels="TV->PC")
SimpleResize(640,272)

1-Pass Size : 27860667 Bytes or 27207 KBytes or 26 MBytes
Average 1-Pass Size : 6223 bytes

Quantizer distribution for 2nd pass:
Q:2:783
Q:3:3369
Q:4:290
Q:5:29
Q:6:6


script2
-------
LoadPlugin("C:\PROGRA~1\GORDIA~1\mpeg2dec.dll")
LoadPlugin("C:\PROGRA~1\GORDIA~1\convolution3d.dll")
LoadPlugin("C:\PROGRA~1\GORDIA~1\colorYUY2.dll")
LoadPlugin("C:\PROGRA~1\GORDIA~1\SimpleResize.dll")
mpeg2source("D:\MATRIX-DE\CHAP3.d2v")
crop(2,80,718,418)
Convolution3d(0,4,4,4,4,3,0)
ColorYUY2(Levels="TV->PC")
SimpleResize(640,272)

1-Pass Size : 20387750 Bytes or 19909 KBytes or 19 MBytes
Average 1-Pass Size : 4553 bytes

Quantizer distribution for 2nd pass:
Q:2:1547
Q:3:2897
Q:4:33

No comment! ;) (I hope vlad59 reads this thread too ;))
Screenshots from the two encodes are attached below.

regards,
iago

[iago]

Originally posted by droolian01
@ iago - i am experimenting with putting a 'tweak(bright=15) before the coloryuy2 line in order to compensate for the darkening effect.

Telecide(blend=false)
crop(4,4,360,568)
Convolution3d (0, 6, 6, 8, 8, 3, 0)
UnFilter(40,40)
tweak(bright=15)
Lanczos3Resize(512,384)
msharpen(threshold=10,strength=150)
ColorYUY2(Levels="tv->pc")

I think this would not cause many more (if any) blocks to appear as the coloryut2 comand seems to be doing more than just a simple 'levels' type command. Have a go with this and see what you think - remember i only encode tv captures so my numbers might need adjusting for dvd rips. @droolian01

I did some tests with the tweak values, with Matrix Chapter 3, trying to restore the original brightness of the movie as much as possible, and to see if ColorYUY2(Levels="tv->pc") still eliminates the blocks as properly as before when using a tweak value for brightness. I used the encoding parameters provided in my above post for the tests. As a result, tweak(bright=10) seemed to be the most matching value for brightness for this specific chapter from Matrix. However, this combination [tweak(bright=10) and ColorYUY2(Levels="tv->pc")] also exhibited some blocks in certain parts of the encode, and was not as successful as ColorYUY2(Levels="tv->pc") alone.

I tried with a setting as low as tweak(bright=6) but blocks were still visible, though the movie had already begun to get darker again ;).

So, "tweak" may be a solution to some extent of course, depending on the source, and it certainly helps to a point of compromise, but in my tests, it seems that ColorYUY2 hasn't liked it either as a companion! ;).

best regards,
iago

[droolian01]

Hi again.

I wasn't sure if using tweak(bright=whatever) would cause the blocking in dark areas to re-appear - seems it does unfortunately. This whole issue of source brightness/contrast/saturation etc is much more complicaated for me as i only process tv captures - i can adjust these settings individually for each capture whereas with a dvd rip you are presented with a 'fixed' source.

Getting authentic looking captures is something i've struggled with for some time - i feel closer now to this aim - and you have pointed me in the direction of coloryuy2: i thank you for this (and all your testing - you've probably seen certain parts of the matrix more than the editor and director did!!!)

Thanks again

[drizztcanrender]

Guys probably this will be off topic because it will involve maybe two more forums :)
I've been thinking about the effect ColourYUY2 has in a movie.It does help eliminate the blockiness in dark scenes of the film but also it makes the film even darker.So the ideal solution would be to use that in only some parts of the movie.Unfortunately the only filter i have seen doing that is the conditional filter of Mr Dmitri Schamschurko.
And i suppose ColourYUY2 works in yuv colour space,right?
So is there a way we can tweak this internally with avisynth or maybe a way to make it work with the conditional filter??
Anyways a kind of conditional filter for avisynth would be great :)
Well i guess you could do it with trim function,anyone tried that??Will be a real hassle though...

Excuse my mistakes,if i've made some,i'm still learning :) and i don't think i'll ever stop ;)

[Marc FD]

why not using ColorYUY2 in back parts of the image (Levels),
then you merge it with the brighter part (Levels,Layers) ?

[Dali Lama]

Not to hinder any possible positive results from this testing, but my feelings are that ColorYUY2 IS supposed to darken the movie. Maybe if we look at it this way. DVDs are designed to be viewed on televisions. Since, we need to watch it on PCs, it should be darkened. Similar to how images on PCs look darker than on MACs. Take a look at the DVD's darkenss on a new high end tv, with 3D comb filtering and antireflective screen. You will notice dark and rich colors. On the PC we have not been used to this. Attempts by software DVD players like PowerDVD have tried to add Theatre levels mode which darken the movie. As a result the use of ColorYUY2 to correct the levels is startling to some of us.

This comes downs to personal taste. However, lets not feel like we HAVE to lighten the movie. Maybe that's the way the film producers intended it to be?

Take Care,

Dali

[drizztcanrender]

I agree that ColorYUY2 darkens the movie,as the tests show us.But some people,as you said,dodn't want that effect.So what i proposed was to find a way to add the filter only where we have the dark-scenes,where the blocks would probably be.I'll try Marc's advice and see what happens.

[iago]

Originally posted by Dali Lama
Not to hinder any possible positive results from this testing, but my feelings are that ColorYUY2 IS supposed to darken the movie...
...This comes downs to personal taste. However, lets not feel like we HAVE to lighten the movie. Maybe that's the way the film producers intended it to be? I guess I agree with Dali. Since the main problem that was discussed at the re-beginning ;) of this thread was that even the most good-looking encodes on PC monitor, actually displayed many ugly blocks in black areas (or almost-black/impure-black areas, however we put it) when watched on TV. So the problem was "mainly" TV-viewing oriented, though it is possible that it can be observed on PC monitors too, but much less of course.

What ColorYUY2 does is solve "this" problem, and provide pure/true black color at those areas, hence eliminating the annoying blocks appearing at those areas. Also, the darkening effect is actually (more) visible on PC monitor; not on TV, which already provides a brighter viewing environment. So, after applying ColorYUY2, the picture you get "on TV" is actually not so far from the brightness of the original DVD, and also free of all these ugly blocks.

As for me, considering all that's mentioned above, the real problem with ColorYUY2 is that it decreases compressibility. But after a limited number of test encodes (absolutely more tests should be done to derive a better conclusion), I'm hopeful that, that decrease resulting from ColorYUY2 can be compensated by the use of some light Convolution3d settings, such as (0,4,4,4,4,3,0), without softening the picture much and keeping enough details, but increasing compressibility.

For watching DVD-rips (also) on TV, atm ColorYUY2 seems the best possible solution to me.

best regards,
iago

[drizztcanrender]

I guess I agree with Dali. Since the main problem that was discussed at the re-beginning of this thread was that even the most good-looking encodes on PC monitor, actually displayed many ugly blocks in black areas (or almost-black/impure-black areas, however we put it) when watched on TV. So the problem was "mainly" TV-viewing oriented, though it is possible that it can be observed on PC monitors too, but much less of course.

Try viewing them in my 21" monitor.They are visible,trust me.

[iago]

@drizztcanrender

Try viewing them in my 21" monitor.They are visible,trust me.I do ;).

iago

[Didée]

Sorry for not trying this on my on, but honestly, I do have some problems with using "layers", and unfortunaly, by now I don´t have hours and hours available for testing :(

Well, the most annoying aspect of those "dark blocks" is that they are often color-casted: greenish or purple-ish.

Wouldn´t it be helpful to remove all color from the very dark parts, say in the range [0 < luma < 16] ???

I suppose chroma information in the almost-black areas is hardly noticeable. But removing chroma in these areas probably could make the blocks less dominant?

IF this should be useful, I assume it´s not such a big effort for all the great coders out there to make a new filter out of it.

Perhaps someone could give a quick shot on this, and report the results? As I said, I have some problems with "layers".
(If someone gives a 100% working script for this purpose, using "layer", I will perform the test myself.)

[iago]

Hello all,

As long as the "black-color" problem (I guess it's better to call it this way rather than "blockiness in almost-black/impure-black areas" problem) is not totally and understandably solved I'll keep this thread up-topic ;), since I guess ColorYUY2 results are not too satisfactory for me either (darkening effect, worse color representation, etc.), though at first sight/tries it seemed the only possible "encoding-stage" solution to the problem for the time being.

What colorYUY2 does (in our example) is that it converts the levels of a TV scaled (!) encode (maybe a bit more than this considering the better effect than levels and the worse side-effects as well) to PC scale:

ColorYUY2(Levels="TV->PC") is actually something like levels(16,1,235,0,255), where 16 and 235 are the inputlow-inputhigh values (representing TV scale range), 0 and 255 are outputlow-outputhigh values for PC (representing PC scale range), and 1 stands for Gamma (correction).

And imho the whole problem may be actually related to this: the difference between the TV values for black (16) and PC values for black (0)?..

However, the interesting point is why do we get (or do we get) a TV scale in our encodes although we choose "PC scale" in DVD2AVI (as Dali Lama points out), which must accept 0 and 255 for PC scale values and therefore already "should" have solved the problem (?). Is it DVD2AVI (1.74 or 1.76 version as used by most) related, or mpeg2dec.dll related, or both, or none? And imho here lies the problem *and solution*, considering what Koepi, trbarry, and Swede discussed in their *very valuable* previous posts.

Ok, latest versions of ffdhow provides levels correction, adding noise is another alternative for post-processing; and ColorYUY2 filtering, messing with levels/layers etc. are other filtering-based choices, though none of these are the real and perfectly-working solutions! There *must* be another solution/way for the encoding stage to overcome this ugly problem.

Currently I'm doing some tests with DVD2AVI 1.74, DVD2AVI 1.76, using different scales, and frameserving with both avisynth and VFAPI. I've already got some ideas, but in order to be able to make better comments, I want to discuss these when the test encodes are over.

best regards,
iago

[Maurizio]

Well, I've got very good results using Virtual Dub filters,
simply enhancing the saturation and the contrast,
and applying the smoother filter with 0 threshold.
Regards
Maurizio

[iago]

@Hello again
@Koepi, trbarry, -h, Swede, etc. (and all other experts ;))
(especially your views would highly be appreciated)

So, about the tests:

Test parameters:
Color Space: YUV
XviD (Koepi's 04092002-1) constant quantizer 3 - MPEG quantization - no lumi
one vob from Baraka / 512*240
VFAPI -> full processing mode (crop-resize in VDub, Precise Bilinear)
AVISYNTH -> fast recompress (crop-resize in AVS, Bilinear)

After the tests, I could only reach some limited results:

1) Either with DVD2AVI 1.74 or 1.76, there *is* a difference in terms of black color (values) between the PC Scale and TV Scale modes when frameserving with VFAPI; and VFAPI seems to consider the values given by the .d2v file:

PC Scale: YUVRGB_Scale=1 (same in the .d2v file both with 1.74 and 1.76)
TV Scale: YUVRGB_Scale=0 (same in the .d2v file both with 1.74 and 1.76)

2) With DVD2AVI 1.76, there *isn't* any difference in terms of black color treatment between the PC Scale and TV Scale modes when frameserving with avisynth (mpeg2dec.dll), and the effective Scaling mode seems to be already "PC Scale" (not TV Scale) whether you choose PC Scale or TV Scale. However, as stated above, both 1.74 and 1.76 includes the difference in the d2v files: (PC Scale: YUVRGB_Scale=1 / TV Scale: YUVRGB_Scale=0). So it "seems" that it is mpeg2dec.dll that doesn't respect these values (as trbarry pointed out before if I'm interpreting his statement correctly).

3) As a result, that's why ColorYUY2(Levels="TV->PC") gives an excessive darkening effect imho. It is scaling an already PC Scaled film once more to PC Scale (blackening the movie once again), though the input values are not 16-235, but already 0-255!?

4) When watching the TV Scaled and PC Scaled encodes where VFAPI is used for frameserving, they are obviously much blockier and worse than the avisynth encodes (both avisynth encodes are exactly the same either PC Scale or TV Scale chosen: effective scaling is already PC Scale as mentioned above). Also, TV Scaled VFAPI encode looks much worse than the PC Scaled VFAPI one.

So, maybe the problem (with our regular avisynth encodes, already PC Scaled -> 0-255) is somewhere else and perhaps inevitable, which is also negating my argument in the former post and some previous arguments by others in the thread. Possibly the only solution: trying to keep quantizers as low as "possible" and apply some noise (if possible, more to dark areas as an option in the future releases of ffdshow).


Hoping more replies arrive to this thread and more opinions are put forward. (All stated above and previously are my personal opinions and experience, only an attempt with my limited knowledge, trying to derive a conclusion about the issue, and may of course contain some mistakes, which will hopefully be corrected as well).

kindest regards,
iago


P.S.: Images are attached to provide some visual aid especially to compare the different "black color treatment" with different options stated above.

[trbarry]

PC scale means the range 0-255 and TV scale is the NTSC range 16-whatever. But I have never really paid attention to what DVD2AVI does with it because I always use MPEG2DEC.dll through Avisynth, which ignores it.

The reason it ignores it is because it tells how you should convert to RGB and I avoid doing this when possible, staying with YUY2 in Avisynth and also with Fast Recompress in Vdub.

But if I was doing a conversion to RGB then I don't know whether DVD2AVI PC Scale means to convert to PC Scale or to expect PC Scale. ??

And I think at least NTSC DVD's are stored in TV Scale in a color space the same as YUY2. (same colors different bytes)

FWIW. ;)

- Tom

[Marc FD]

i've made a little test with french friends with a specific Avisynth filter, designed to enhance black a smooth way (linear) without modifying at all the other colors. the problem is, it makes the image bigger, because it increase contrast. (i can provide the bin if you want)

but i can try something else. a sort of search'n'destroy filter :
- find wide black areas
- smooth them
- darken them
- normalize chroma saturation

i need to test it, but i hope this approach would not lead to compressibility degradation.

and i still want to try to make Msmooth-like filter. don say it's not easy, i agree, but i have a lil'idea :D

and i've a lot of things to do for XviD. the problem is XviD work in YUV12 space, and avisynth not. so i'm waiting for avisynth 2.1
(because i want to make some pre-filtering and i want it avaible for XviD and Avisynth)

[iago]

@Marc FD

So nice to hear that you're working on it :). I hope your efforts give good results so that we can start using/trying your filter against this ugly problem ;)

best regards,
iago

P.S.: Looking forward to hear about the results of your tests.

[soulfx]

Hi, has anyone tried doing some tests with a levels command that would put the video back into the TV Scale and then use the ColorYUY2? Also I think the code is out there for ColorYUY2, maybe we could take a look at it and see what exactly it does.

Something like:
Levels(0,1,255,16,235)
ColorYUY2(Levels="TV->PC")

Wouldn't this keep the video from becoming too dark, but still allow ColorYUY2 to do it's "magic" since people have reported that it reduces blocks better if not completely comparied to a similar levels adjustment.

One other thing to mention. I know something was said about ColorYUY2 and it's strange effects on color. Since it's a level adjuster the color saturation will increase as you decrease the InputLevel range (ie: InputLow from 0 -> 16, InputHigh 255 -> 235). So to get about the same color as before a Tweak(sat="whateva") would have to be done.

Peace,
SoulFX