lumi masking

[iago]

-> 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.


@soulfx

Actually ColorYUY2 doesn't "reduce" blocks-in-black better than a levels adjustment, but it totally "eliminates" them, which is the real magic ;). Regarding your above arguments:

1)

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

I have tried it exactly like that (and then with some tweaking as well), but it simply doesn't work. Blocks are all around again as a result.

2)

I have also tried tweak(bright="whateva") ;), together with ColorYUY2(levels="TV->PC") with no success.

I haven't tried tweaking the saturation yet, and it may be worth a try ;). I think what you mean by Tweak(sat="whateva") is "decreasing" the saturation with that parameter (default: 1.0), and use it together with ColorYUY2(levels="TV->PC") ?

best regards,
iago

[Marc FD]

Hi iago.

could you try if playing with lumagain/lumaoff in my mod can help ??
i implemented it only to simplify testing for you in fact ;)

maybe something like lumaoff=-20,lumagain=138 ??

if this does not work, i've a new idea to test (darkensmoother) :D

[JimiK]

Iago,

I know you're an excessive tester and I agree with you in most of the points. But my tests (only short test encodes) show slightly different results.

For me the level settings supposed by soulfx reduce the blockiness in the movie. You're right, it's not completely the case, but it's better than an "ordinary" encode while it's still on the same brightness level. If you increase the brightness to compensate for the darkening of the ColorYUY2 some blocks will show up again.

I also tested by setting the luminance gain under DVD2Avi to a higher level. The compressibility suffered badly and the results were not perfect.

The problem I have with ColorYUY2 is that blocks seem to remain at the transition from dark parts to lighter parts. You know, where things are still dark, but not dark enough for it to paint it black.

Right now I'm encoding a full movie with the 'soulfx-settings'. I'll keep you posted about the results.

Btw. where is 'tweak' included? Is it in another special version of Avisynth or is it an ordinary plugin?



Best regards,

JimiK

[iago]

-> Hi iago.

could you try if playing with lumagain/lumaoff in my mod can help ??
i implemented it only to simplify testing for you in fact

maybe something like lumaoff=-20,lumagain=138 ?? ;)

if this does not work, i've a new idea to test (darkensmoother) :D

Hello Marc,

First, thanks a lot for your ongoing efforts and valuable works both in general and on this ugly problem! ;) I'm sure, sooner or later, we're gonna solve it. BTW, I have already started using your mpeg2dec.dll, with cpu=6, to achieve really better results than the regular mpeg2dec in terms of blockiness and deringing, but I haven't tried it on this "blocks-in-black/impure black" issue yet.

Can you confirm or correct the below sample script please:

----------------------------------------------------------------
mpeg2source("D:\MOVIE\MOVIE.d2v",cpu=6,lumaoff=-20,lumagain=138)
----------------------------------------------------------------

Also, do you suggest using it with or without ColorYUY2?


thanks and best regards,
iago

[Marc FD]

definitivelly without.

ColorYUY2 is not designed for that at all.
the benefit you see is a side effect.

i'll try a specialized filter to do intense, pure, dark, sweet, ect... more black than black black.

you script line seems good. but the values i gave are just a start point. some tweaking is needed.

i recommand you to use avisynth's Histogram() function to help with tweaking. it's very usefull.

[iago]

@JimiK

You are right, the below script helps to retain the original brightness of the movie, but in my tests it didn't resolve the blocks-in-black issue (maybe a bit better compared to an ordinary encode, but absolutely much inferior to ColorYUY2 alone), so it simply didn't achieve its aim.

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

Still, I'd be glad to hear about your test results.


Regarding "tweak", it's an internal filter of avisynth, which you can use simply by adding such a line to your avs script:

tweak(bright=5) or tweak(sat=0.5) just for example...

best regards,
iago


EDIT: Thanks for confirming and clearing it up Marc, I'll take your values as a starting point for my tests.

[iago]

Marc,

The script that you confirmed:

mpeg2source("D:\MOVIE\MOVIE.d2v",cpu=6,lumaoff=-20,lumagain=138)

gives the following error message when trying to load into VirtualDub:

Script error: mpeg2source dos not have a named argument "lumaoff" (or "lumagain")

iago

[kilg0r3]

hi iago.

man i really don't know how you manage to accomplish these gigantomaniac testing efforts. great!

one short thing did you ever try to use lumamasking together with ColorYUY2, and, if so , what were your results? thanks so much.

[JimiK]

What we needed is a "movie" room, where you could have the same light conditions all the time. The problem is: when it's day and everything around is light, you almost see only black in dark scenes when using ColorYUY2. But when it's dark around and you didn't use it for your encode, you can see so many blocks in dark areas. Maybe we should encode all movies twice and label them with "view only in dark environment" or "... in light environment" ;)
What I forgot to mention in my last post is, that when I used the new ffdshow and set the levels to 20, I got a decent picture (lighter) without such a big increase in blocks, as when adjusting the brightness (movie was encoded with ColorYUY2).

EDIT: Thank you iago. Tweak was introduced in Avisynth 2.05 and I was still using 2.04

Greetings,
JimiK

P.S. off topic: what I wanted to say, I've been following this forum for almost a year now. It's so cool how many test are done and how many good ideas come up in this forum. You guys are really amazing, both, developers and testers. Keep up the great work!

[Marc FD]

sorry iago.
it was lumgain and lumoff.
take a look at the readme file ;)

[droolian01]

Hi there.

I've written my first 'function' or whatever you call it. Please note that i am not a programmer (last time i did anything like that was at school with a BBC micro!!!!) hence some probably obvious errors (but not to me!).

History/idea - this script will produce selective darkening in only the dark areas of a video and leave the rest of the video 'as is' so as to negate the 'dark block' problem. It uses 3 masks each derived from the source clip to incrementally darken the selected area. I used just one mask originally but to get any serious block reduction i noticed the edges between masked and unmasked areas to be too sharp, hence the 3 gradually stronger (and gradually smaller) mask areas. If you could view them they would look like a contour map of a hill with the 3 boundry lines equivalent to contour lines.

###############################################################################
# DBK (or Dark Block Killer) #
# Attempts to reduce the appearance of 'dark blocks' by selectively darkening #
# dark areas and leaving the rest of the video untouched #
# All values have the same funtion as in LEVELS, with "threshold" being the #
# value that gets treated as 'dark' and "amount" is the amount of darkening #
# in these areas #
###############################################################################


function DBK(clip "clip", int "threshold", int "amount")
{
overlaya=levels(clip,amount/3,1,255,0,255)
overlaya=resetmask(overlaya)
mask_clipa=levels(greyscale(clip),threshold,1,threshold+1,255,0)
overlay_clipa=Mask(overlaya,mask_clipa)
finala=layer(clip,overlay_clipa,"add",255,0,0,0)
overlayb=levels(clip,(amount/3)*2,1,255,0,255)
overlayb=resetmask(overlayb)
mask_clipb=levels(greyscale(clip),(threshold/3)*2,1,((threshold/3)*2)+1,255,0)
overlay_clipb=Mask(overlayb,mask_clipb)
finalb=layer(finala,overlay_clipb,"add",255,0,0,0)
overlayc=levels(clip,amount,1,255,0,255)
overlayc=resetmask(overlayc)
mask_clipc=levels(greyscale(clip),threshold/3,1,(threshold/3)+1,255,0)
overlay_clipc=Mask(overlayc,mask_clipc)
finalc=layer(finalb,overlay_clipc,"add",255,0,0,0)
return finalc

}

#
# how to use
# avisource("source.avi")
# filters.......
# Resize(xxx,xxx)
# ConvertToRGB32()
# DBK(10,15)
# converttoyuy2() (or rgb etc...)


If you substitute the 'return finalc' with 'return mask_clipc' (or mask_clipa or mask_clipb) you can see where the masks work (white = where the darkening will take effect).

Threshold - is the value that any pixel in the source clip will be 'filtered' (actually <= this value) - i suggest a value of 10.

Amount - is the value by which the filtered area is darkened.

All these values are a in LEVELS so must be 0 - 255 (i havent put any silly values in yet, but why put them in there anyway???)

Hope you serial testers out there get your teeth into this and give me some feedback.

Yours

scott

[iago]

-> sorry iago.
it was lumgain and lumoff.
take a look at the readme file

Marc,

They are defined as "lumaoff" and "lumagain" in the readme file of "mpeg2dec pp mod b2" too ;), which is the one I use. I don't know whether you've updated the regarding info in the readme file of "mpeg2dec pp mod b3" that you have announced in the avisynth forum, but it hasn't been validated yet I guess.

Anyway, thanks for the information: I'll try them as "lumoff" and "lumgain" ;).

best regards,
iago

EDIT: Well, "lumoff" and "lumgain" works, yes... But in the readme file of "mpeg2dec pp mod b3", these parameters are still named "lumaoff" and "lumagain" ;). BTW, I have upgraded to "mpeg2dec pp mod b3" now.

[iago]

@kilg0r3

In my tests using lumi masking with colorYUY2 didn't lead to any problems concerning the blocks-in-black issue: colorYUY2 still performed its job perfectly (when lumi masking enabled) regarding the problem. Imho it may only be an option to increase compressibility and to compensate for the compressibility decrease introduced by ColorYUY2.

But in general, so far my experience is that lumi masking "decreases the overall quality" of the encode, introducing more blockiness and artifacts, and *personally* I always leave it unchecked ;).

@droolian1

That's very nice. I really wonder what the results will be both in terms of the blocks-in-black ;) issue (as I call it) and in tems of compressibility.

@soulfx and all,

using ColorYUY2(levels="TV->PC") with tweak(sat=0.75/0.80) gave me some good results in terms of restoring back/down the saturation increase introduced by colorYUY2, and it also gained back some ~3% of the compressibility that was lost due to colorYUY2 use. But I still didn't like the colors, that seem to have changed noticably.


best regards,
iago

[JimiK]

Hi,
I just wanted to share my results. Avisynth script:
mpeg2source("E:\video_ts\13th\vts_01.d2v",cpu=6)
crop(0,9,702,553)
SimpleResize(656,352)
Levels(0,1,255,16,235)
ColorYUY2(Levels="TV->PC")

In dark scenes there are quite little pixels. It's not perfect, but you have to see that the compression ratio is 2.5:1. So I think it almost impossible to get away with no blocks. The brightness is all right, just as if no level tweaks were used. But the picture is very soft. I used h263 in both passes, but I didn't think it could smooth the movie that much, because I used SimpleResize which should deliver a sharp picture.

So long,
JimiK

[yaz]

hi all !

i follow this thread for awhile & i decided to summarize my findings on "deblocking the dark regions" many times but these days i'm pretty short in time. maybe this weekend.

now about some things just occured.

Originally posted by JimiK
Levels(0,1,255,16,235)
ColorYUY2(Levels="TV->PC")
:rolleyes:

imho, u're on a wrong way with it. afaik, levels is a brightness/contrast filter in rgb & it does luma transformation in yuv. coloryuy2 does the same. i've done a short test & i guess, coloryuy2("tv->pc") does something like levels(~16,1,~240,0,255). not xactly, but it's very very close. (more tests needed). so ...
accordingly, the script above does (almost) nothing. 1st u shrink the scale & then xpand. of course, "it's regain the original contrast" (iago) but, imho, distorts the scale (yaz:-).
in add, putting levels 1st would increase the noise in the low luma region. maybe the revers order, but ... i should think of it more thoroughly

as far as i remember, the original topic was 'how to decrease blocking seen on tv", but i have the bad feeling that some of u test results only on pc. it's never the same! pictures looking awful on pc may look good on tv (that's what i should sum up:-) pls, check your results always(!) on tv.

@droolian
converting rgb<->yuv may result in blocking as it introduces some kinda scale distortion. check it out, a script is given for it in avs_help.
anyway, your script is quite impressive, but i don't really understand what's it for. gimme some time, i'll check it out.
i use something similar for doing a luma masked noise removal, but the script is not at hand, i'd drop it if u're interested.

@iago
'black-blocking' on tv has many different sources. once we summed them up in the nandub forum & we put together lotsa tricks to decrease them, but i haven't found this thread :-( ok, it was a year ago or so.
until i brush up my mind, try these tricks:
- do not(!) remove fine noise from the picture. some filters can thresholding not only the upper but the lower value for smoothing (say, tempcleaner, dnr2ver06). try to keep back some fine noise in the low luma regions & encode this. for me, it decreases dark blocking. i got some avs script to do this, i try to collect them. imho, it's much better than imposing noise in postproc (say, with ffdshow)
- use some kinda xtra sharpening. it causes a kinda twinkling/ringing on pc screen, but increase contrast on tv. in add, it increses the noise in the dark regions which may help preventing that shitty blocking.
- use always the max resolution available & try to beat the limits given in some maquals. (of course, keep it in a reasonable range:-) it may help agains blocking
- ...
oops, i got some other 'stupid' trick, but i'm running outta time, if u're interested i try to collect my memories.

hormonally yours
yaz

ps before u start lame me, i must confess, i'm really that :-)

[JimiK]

yaz,
the idea was, that ColorYUY2 does more than levels. So you could hold the brightness by adjusting it with "levels" and get rid of most of the dark blocks with ColorYUY2. But after some more short tests I have to say you're right. There is almost no difference and on one scene I would even say the one without these level tweaks is better. And you're right with the guess that I don't watch the movies on my TV. I'd love to (couch (TV) more comfortable than chair (PC)), but sadly I don't have a graphics card with TV out. So I can only contribute with tests how to eliminate blocks on PC and hope it works as well for TV. I'm sorry, but there is no PC-block thread.
@ Marc FD
I'm curious if your new project "darkensmoother" :) will work. I've tried an test encode with your mpeg2dec luma settings and have to say, you already got a filter that makes the blackest black I've ever seen (whole picture) ;) Well, I guess some more testing and tweaking from my side is required.

Best regards,
JimiK

[iago]

@yaz

It's really nice to see you step into this thread, share your opinions with us, and provide everyone with your valuable experiences :).
(the yaz from those old nandub times?..;))

Well, just a few words for now: ;)

* Yep,
Levels(0,1,255,16,235)
ColorYUY2(Levels="TV->PC")
is really of "no" use in terms of solving the black-blocking issue, as I also had stated in one (or more than one? ;)) of my previous posts.

* ColorYUY2(levels="TV->PC") indeed does something "like" levels(~16,1,~235-240,0,255), but not exactly. ColorYUY2 eliminates the black-blocks problem (with its a lot discussed side-effects of course); however levels(16,1,235,0,255) for example cannot achieve the same result as ColorYUY2 in my tests.

* I usually encode 640*... and very rarely go below that and I don't use any extra filtering (except test purposes), therefore I hadn't tried any extra sharpening filter before either. I'll try that. Maybe together with LanczosResize as well?! (But what about compressibility? ;))

* I agree that it would be much better to solve the problem "as much as possible" during the encoding stage, trying to keep the original noise, rather than post-processing with noise during decoding. I'd be very glad to try your avs scripts for that purpose.

* Also, imho, lumi-masking is a real "no-no" if we want less black-blocks in our encodes; and MPEG quantization is also more effective than h263 regarding the issue.


@JimiK

Since the "look" of an encode on PC and on TV "may be" totally different in terms of visual quality and black-blocking, regarding the solution of this issue, I guess we "have to" take TV as the reference viewing source.

Also, Marc's new mpeg2dec pp "is" as effective as ColorYUY2 in solving the black-blockiness issue, but still suffers from the same problems: compressibility decrease and losing the original colors. lumoff=-20 was an effective value in my tests to solve blocks-in-black the problem, but lumgain=138 (you're right) makes the picture even darker than ColorYUY2. When you go higher (lumgain=160-170) you begin to get closer to the original brightness of the movie, but paying the price with even more decrease in compressibility. As a result, you can try lumoff=-20,lumgain=170 as a starting point for your tests and tweak these values as you desire, but remember the higher the lumgain value, the less the compressibility!

@all

I guess we can now put aside ColorYUY2 and start tweaking with lumoff and lumgain values of Marc's "mpeg2dec pp mod b3" to achieve the same powerful effect as ColorYUY2 (and with the same loss in compressibility ;)), and besides that, there are much more tweaking possibilities with it to regain the original brightness as much as possible using "lumgain" parameter.

OK, that's all for now,
kindest regards,
iago

[iago]

Hello everybody,

I just wanted to share a good news with you. I guess finally I have found a way to beat down the ugly blocks-in-black problem as effectively as possible, without darkening out the encode as ColorYUY2 does, keeping the brightness as close to original as possible, and without decreasing compressibility drastically.

I don't want to say that it is the perfect or the only method, but at least it is the method that has worked best for "me" so far, and wanted to share it with everyone.

First of all, I want to thank to yaz, who inspired me to try this (sharpening) method with his comments in the "lumi-masking" thread; and of course to Marc FD, who coded "mpeg2dec pp" with the lumoff and lumgain parameters, and to trbarry for his great UnFilter filter.

Well, for the tests, I used Marc FD's mpeg2dec.dll pp, Koepi's 23092002-1 build, MPEG-custom HVS matrix for quantization type, constant quantizers up to 8, both BicubicResize(0,0.6) and BilinearResize, trbarry's UnFilter.dll in script3, and checked the visuals "only" in terms of black-blocking issue.

Here are the test results:
(1500 frames from a dark source to best spot the black blocks, and constant quantizer 4)


script1 (normal encode without filtering):
------------------------------------------
LoadPlugin("C:\MPEG2DEC_PP\MPEG2DEC.dll")
mpeg2source("D:\TEST\TEST.d2v",cpu=6)
crop(4,8,-4,-8)
BicubicResize(640,352,0,0.6)

file size: 3332 kb
visuals: full of black-blocking/a real shitty look

script2 (ColorYUY2 encode):
---------------------------------
LoadPlugin("C:\MPEG2DEC_PP\MPEG2DEC.dll")
LoadPlugin("C:\MPEG2DEC_PP\ColorYUY2.dll")
mpeg2source("D:\TEST\TEST.d2v",cpu=6)
crop(4,8,-4,-8)
BicubicResize(640,352,0,0.6)
ColorYUY2(levels="TV->PC")

file size: 4046 kb (~20% decrease in compressibility)
visuals: no black-blocking/encode too dark and many details lost


script3 (UnFilter(5,5) and lumoff=-2 encode):
--------------------------------------------
LoadPlugin("C:\MPEG2DEC_PP\MPEG2DEC.dll")
LoadPlugin("C:\MPEG2DEC_PP\UnFilter.dll")
mpeg2source("D:\TEST\TEST.d2v",cpu=6,lumoff=-2)
crop(4,8,-4,-8)
UnFilter(5,5)
BicubicResize(640,352,0,0.6)

file size: 3436 kb (~3% decrease in compressibility)
visuals: no black-blocking/almost the same as or very close to original brightness/almost all details preserved


Yes, these are the results I have got. It seems "script 3" is the "Ultimate Script" ;), but of course still open to tweaking and maybe even bettering ;). I hope you give it a try too, and report back your comments. Atm, I'm very pleased with the results I've got and starting a full 2-pass encode using the parameters in script3.

I hope this works for you too, to free your encodes from black-blocking problem, without decreasing the compressibility noticably and without darkening out your encode. At least, just give it a try! ;)


kindest regards to all,
iago


P.S.: lumoff=-2 and UnFilter(5,5) cannot eliminate the problem when used separately. It is the above combination of two that provided the solution for me.

[soujir0u]

Great! What about the encoding speed?

[ookzDVD]

@iago,
Sorry, I was not notice the forum recently,
what is "black-blocking" problem exactly ?

I have problem encoding "panic room", the movie almost dark
in every scene, every time I try to encode I always got bad
blockiness in the dark scene :(.

[Dali Lama]

Iago my friend. Nice name, Ultimate Script!! :sly:

I just wanted to mention that before I tried full encode with it I noticed vertical lines on the image due to the Unfilter. It shows up when using MPEG/Custom matrices. I just wanted to let you know, I don't believe its due to your script though, because that unfilter by itself caused that for me.

Keep up the good work,

Dali

Update: When I use Unfilter(10,10) those vertical lines are gone??

[yaz]

hi iago (& all) !

1st of all : your pleasure is my pleasure :-)) anyway, i'm not happy about that u split the original thread. somebody (a moderator ?) should close that officially & reference/link it here. otherwise we loose the opinions/results posted there or we must devide ourselfs. that's my bad experience. ok, i'd stop grumblin :-)

sorry for not having time to go into details but lemme some quick adds
your solution here
- is(can be) effective if the source is a good quality dvd (even that have some kinda noise espec in the low luma regions. it's our luck:-))) a 'noisy' source is a different part of life
- solves only one possible source of blocking. that's what i call 'black isn't black' problem. it's the result of the improper scaling. the luma scale on tv is narrower than on pc. if u wanna get the same 'look' on tv u must(!) (down)scale. afaik, levels(16,1,240,0,255) is the proper transformation, but correct me pls, if i'm wrong. it was discussed xtensively in the dvd2avi forum earlier but i can't find that thread anymore (why can't i find that good old threads?:-(

Qs:
- what does your script whit shallow luma gradients ? i mean, where luma changes very slowly. (e.g. a dim room, light in one corner) i guess, it'd help that too but it'd be tested.
- what about sharp luma gradients ? (e.g. dark scene & then a sudden lumma change; a bomb, flashlight or so. say, intro scene in matrix, when the torchlight zooms in) my guess is the same as above, but ... test.
- what about sources with heavy noise ?
(i don't blame u ! i just wanna outline further problems i know:-)

adds:
- 1500 frames ... seems too short for me. maybe, it's enough for one effect, but may be misleading if u consider encoding too. the bitrate distribution may be quite different if u take only that short part or a bigger one. (think of people like me making always 2pass encoding:-) i use 10-20 mins from a film trying to take it so as to contain as many problematic effects as possible.
- u can be much 'braver' with unfilter. try harder settings too, but be careful, at some args it crashes for me ('illegal calls' & so, dunno why)

lemme know your opinions about

hormonally yours
yaz
(yeah, the lamer from the 'good old nandub times':-)))

[iago]

@Koepi

I think yaz is right. Can you please attach this new thread to the end of "lumi-masking" thread? I first thought it "might" be better to start a new thread and discuss this black-blocking problem separately, but yeah it's likely to break the unity this way, and possibly will be better to go on in the old lumi-masking thread ;)...

@yaz

You are right. It was only a very short test, focusing only on "one" problem and a bit on compressibility, and leaving the rest to be checked later "after" the main issue is resolved. (BTW, I always do full 2-pass encodings too ;).) Absolutely more tests should be done, especially two-pass tests, with different quantization types such as h263 and MPEG (default), with different resizing methods (I tested not only BicubicResize(0,0.6) but BilinearResize too, as an option for more compressibility and to compensate for the possible extra-sharpening effects), and with tweaking the Unfilter strength parameters as well.

I guess I'll try (or we'll all have to try) to answer the questions in the "Qs:" part of your post when we finish our two-pass test encodes and check the visuals, this time concentrating on "other aspects" of the encode as well, since the major problem, the "black-blocking" problem, seems to be really beatable with the above method.
(Imho, noisy sources might require to be treated "completely" in a different way and with additional filters too. Currently "I" prefer to focus on clean sources actually.)


@Dali Lama

Ahoy my friend! ;) I also noticed those vertical lines with Unfilter(5,5) and MPEG-custom matrix. But do you say they don't occur in other quantization types (which is good imho)?? Maybe tweaking the Unfilter vertical sharpen parameter a bit down can also be a solution for that?

@ookzDVD

Well, I see better now that it wasn't a good idea to part from the original "lumi-masking" thread, where the issue was discussed in detail.

@soujir0u

All I can say is that, Unfilter is really fast even on my poor Cel900! ;)


kindest regards to all,
iago

[fANMIR]

@iago

I am looking forward to test your scripts but I don't have access to my encoding computer in a few days. So do you mind if I ask you to bring us some pics of your results? I would be very happy to compare screenshots with my eyes 15 cm before monitor ;) .I wonder how those operations affect picture quality ( I like very much sharp images but I hate those black blocks :) )

cya !

[Koepi]

I merged the splittet thread upon iago's request.

Regards,
Koepi

[HarryM]

Luma-masking (actual version implemented in XviD) is FINALLY AND REALLY correct, please?
Can I use it without risk? :)

[Koepi]

You have always the risk that you can see compression artefacts...

But it's "more correct" than the "in-between" one which was in the code as doom9 tested the codecs last time...

Regards,
Koepi

[rui]

Originally posted by iago
...I used Marc FD's mpeg2dec.dll pp...

I am sorry for asking for this, but i looked and looked and coudn't find any link to download MarcFd's mpeg2dec.dll :(
Could someone point where can i get it? (i already visited Marc's site, but it wasn't there)

Many thanks.

[iago]

@Koepi,

Thanks a lot for removing back the thread ;).


@Dali Lama,

You're right Dali, mpeg/custom quantization seems to cause/increase vertical lines issue of UnFilter. Imho, it seems safer to go with h263 quantization for now. Also, the more you sharpen, the more you have vertical lines, and the more you lose compressibility. Therefore, a combination of UnFilter(5,5) and lumoff=-2 used with h263 quantization type (and as a personal preference with LanczosResize) seems to be the most reliable and effective combination for me, in terms of both eliminating black-blocking very successfully and still keeping compressibility decrease within a very small range (and also in terms of avoiding the vertical-lines effect as much as possible ;)).

Currently I'm doing some two-pass tests with Matrix Chapter 2, I will post back the results and write my comments when finished. (BTW, I have already encoded a full movie "Ghost Dog" with great success using the previously mentioned script, with no black-blocking problem and with no annoying side-effects for this specific rip.)

best regards,
iago

edit: rui: you can find it here: http://forum.doom9.org/showthread.php?s=&threadid=34253&pagenumber=2

[rui]

thanks buddy :)

And sorry for not being hable to find it. The rules are for everyone, so my post was a little off :o

[iago]

Hello everybody again,

After my full two-pass encode of Ghost Dog (a rather dark movie in general) came out really good, without any black-blocking, without much compressibility decrease, and without any visible side-effects, using the above mentioned script; I went for trying it on "another source" to see if it can still achieve its aim.

And the result was much better and really much more impressing than the regular/unfiltered encode.

Well, here are the test parameters and results:
-----------------------------------------------
* Matrix Chapter 2 (generally dark content with both high-motion and low-motion scenes)

* Koepi's 23092002-1 build, two-pass - internal curve compression and linear scaling ("alt. curve system" disabled and high/low values in "two pass" is set 0/0), h263 quantization, no lumi, Max-Min I-frame intervals: 300-5, quantizers capped: 2-6/2-12, payback proportionally, payback delay: 300, aiming for 14336 kb (which corresponds to a bitrate of ~645 kBit/s)

* visuals checked on TV.

* script1 (normal encode/no filtering)
----------------------------------------
LoadPlugin("C:\MPEG2DEC_PP\MPEG2DEC.dll")
mpeg2source("D:\MATRIX\MATRIX.d2v",CPU=4)
crop(0,84,716,408)
LanczosResize(640,256)
----------------------------------------
Quantizer distribution for 2nd pass:
Q:2:939
Q:3:3601
Q:4:9

Visuals: full of black-blocking problem as expected, very ugly look.

* script2 (UnFilter(5,5) and lumoff=-2 encode)
-----------------------------------------------
LoadPlugin("C:\MPEG2DEC_PP\MPEG2DEC.dll")
LoadPlugin("C:\MPEG2DEC_PP\UnFilter.dll")
mpeg2source("D:\MATRIX\MATRIX.d2v",CPU=4,lumoff=-2)
crop(0,84,716,408)
UnFilter(5,5)
LanczosResize(640,256)
-----------------------------------------------
Quantizer distribution for 2nd pass:
Q:2:713
Q:3:3808
Q:4:28

Visuals: totally free of black-blocking problem, sharp and impressing quality with no other annoying side-effect

At least for me, this ugly problem seems to be solved (the solution is represented by script2 here) and I'm really glad for that ;). Hope you find it useful too, to free your encodes from those ugly blocks-in-black! ;)

best regards to everyone,
iago

[Marc FD]

@iago
can you try a little Blur2() 0.8x1 or 0.4x2 in the place of Unfilter ??
i wonder if it's faster and/or give the same good result.

[Swede]

I just wanted to say a big thank you to all you guys. Especially the infamous serial-tester Iago. I've been following this thread for a long time and so far my personal tests have confirmed your conclusions, using MarcFD's mpeg2dec has clearly shown an improvement of my encodes.
Thnx for your efforts guys!

[Koepi]

Iago,

that's good news :)
Can you test that with lumi masking activated as well please, just to see if we still can try to gain compression? ;)

Thanks a million,

serefe,
Koepi

[iago]

@Koepi

Yes friend, tested and confirmed! ;) (using the same above script for the same source with the same encoding parameters) It works with lumi-masking too. And below is the quantizer distribution of the lumi-masking enabled encode:

Quantizer distribution for 2nd pass:
Q:2:734
Q:3:3784
Q:4:31

sevgiler, ;)
iago


@Marc,

Sorry I couldn't test Blur() yet, but I'll try it asap. Once again, thanks for your "mpeg2dec pp mod" with lumoff/lumgain parameters, which actually helped a lot.

regards,
iago


@Swede,

Thanks for your kind comments, with a big friendly :) from notorious iago...

[Koepi]

Thanks iago,

that's really nice to know.
Let's see if a "[ ] optimize for TV output" switch will make it into XviD... setting luma offset to -2 can be easily done I think, so you just need post processing on the source, and unfilter.dll to work against the softening effect of that...

Wow, that's quite useful knowledge.. :)

Thanks a million again,

best regards,
Koepi

[iago]

@Koepi,

Yes my friend, that would be great actually, making it internal to XviD ;). But I'm still waiting for some more feedback from other people to confirm "my" test results. I hope good news and/or some potential problems that I may not have noticed (if there are any) with this method are reported back here so that we can all feel more comfortable and sure about the effectiveness of the method, which has worked without any problems for me so far.

kindest regards "dostum" ;)
ciao,
iago

[Koepi]

@iago,
I'm currently testing this with "the last boyscout" - with lumi masking, and no unfilter to work against a small softening effect of post processing (the picture suffered when using that).
Unfortunately, I can't test on TV out as I have no TV set, but I can at least report if it looks ok on PC ;)

I already wrote to the XviD developer list to make the core developers aware of this possibly simple solution to this problem :)

Serefe my friend,

take care,
Koepi

[Koepi]

Iago,

since I don't have a TV set, I may upload a small clip from the final encoding - I don't know which bandwidth you have, but could you test that sequence for "errors" then? I'll PM/mail you the link then...

Thanks,
Koepi

[iago]

@Koepi

I'd be glad to test it on TV (especially in terms of black-blocking issue I guess?) ;). Can you also please attach your full avs script and your encoding parameters with the uploaded clip? (I guess you didn't use UnFilter, but only "mpeg2dec pp" from Marc and luma offset: -2 in your encode?)

Anyway, waiting for it pal ;),
iago

[Koepi]

The encoding will last another 2 1/2 hours from now, after that some mux'ing, cutting out an appropiate scene,... in about 3 hours from now (~17:30h your time) you'll have mail ;)

Yes, you're right, my AVS script looks like this:

mpeg2source("D:\Video_TS\lastboyscout.d2v",CPU=4,lumoff=-2)
Crop(6,73,702,430)
Trim(0,145980).LanczosResize(640,272)+Trim(145981,0).BilinearResize(640,272)

Lumi masking activated, search precision 6, h.263 quant type, external linear scaling, targeted size 627102kb, compression ratio a little below 2:1, const. credits @quant 20.

Regards,
Koepi

[iago]

@Koepi,

OK. After 17:30 I'll check my e-mail. ;)

regards,
iago

P.S.: In my tests so far, lumoff=-2 alone (without sharpening with UnFilter) was not enough to get rid of the black-blocking problem.

[iago]

@Marc,

@iago
can you try a little Blur2() 0.8x1 or 0.4x2 in the place of Unfilter ??
i wonder if it's faster and/or give the same good result. I'd be glad if you make it clear which parameters do you want me to test with Blur2(?) and/or Sharpen2(?). I guess a range of -1.0/1.58 is accepted for Blur2, and a range of -1.58/1.0 for Sharpen2 ?..

Thanks,
iago

[rui]

Well, i have made some small tests using iago's script to the letter, but using Referencedivx HVS "best" matrix.
I still haven't come into any problems with those vertical lines that were mentioned when using this script with mpeg/costum mpeg. Also, in comparison to mpeg, Referencedivx costum matrix lowers a little bit the size of the final avi when making constant quantizer encoding (after reading the readme, i saw that he is trying to achieve the same mpeg quality but with a lower filesize), but i couldn't spot any problems in the image, like those that were reported when using "ultimate" matrix from Dali. So, this could be good to counter the little increase in size that happens when using Lanczos and iago's script to avoid the "black" problem.

EDIT: i just wanted to say that i experienced the clips i made in my tv-out, and iago is a true wizard :)

[Marc FD]

Blur(a) = Sharpen(-a)

i think Unfilter(+,+) could be replaced by Blur2(+,+)
just a though. i'm not sure at all.

[trbarry]

With positive numbers UnFilter is a sharpen filter. I haven't used Blur2 but it sounds like a soften filter, so you would think the signs would be reversed from UnFilter.

- Tom

[Koepi]

[992] Quantizer distribution for 2nd pass:
[992] Q:2:922
[992] Q:3:86002
[992] Q:4:58672
[992] Q:5:385

mux'ing the movie now and doing a visual check, then cutting out a piece for iago to review (if I don't fall above some bad things[tm] myself).

Regards,
Koepi

[Marc FD]

sorry tom, i didn't know.
strange that sharpening helps !!
i don't understand at all. it's like "black magic" for me :D

[iago]

@Marc

I guess if we gonna give it a try, we should use either Sharpen2(+,+) or Blur2(-,-) (which are the same after all, no?), since as trbarry pointed out UnFilter(+,+) is "sharpening" the picture, which is one of the keypoints of the above method to get rid of black-blocking problem.

regards,
iago

(P.S.: I have tested Sharpen2(1) to see if it could be an alternative to Unfilter(5,5), but with no success at all. File size almost doubled, but still it could not eliminate the black-blocking issue.)

[Marc FD]

i think it's because Unfilter use a bigger kernel.
i've not the skills to modify magic spells yet ;)