lumi masking

[iago]

Hi everybody,

I wonder if it's time to say our last words (or to share our opinions and experiences once again) on the formerly "handle-with-care" :) option, lumi masking, with Koepi's 08082002-1 build. I recall that not a long while ago lumi masking in both passes was a big no-no.

And today... is it one of our generally-agreed-upon issues that it is better to use lumi masking in both passes for a better curve treatment (as Koepi advised for the test encodes when he released the 08082002-1 build) Or is it still an option to *handle with care*, likely to ruin some encodes and produce artifacts, without which you can feel much safer?

I'd be very pleased if you share your opinions on this subject.

best regards,
iago (still unsure :))

[ookzDVD]

@iago,

I'm just finishing my Kate and Leopold, with Koepi's latest build
08082002, and luma enabled in the both pass.

I think the result is fine (at least for me). ;)

[rui]

I also have used lumi, both the old(new) and the new (old) code :D, in both passes, and never had problems with it.

In the case of the old(new) code, the one that created such a fuss in SPR, i never encoutered those problems, but like i said in one post, i never encoded SPR with it. But, after those events, i got some movies i had encoded using it, and looked with special attention to the most darker scenes, and must say that i could spot some imperfections, mostly blocks jumping around in the dark.

Using the new (old) lumi code, i already encoded Galdiator, using ogg quality 0,4 sound, to 1 cd , and must say that, after browsing the movie a little, for a 1 cd encode, it looks mighty good. But i didn't watched the all movie yet.

So my vote is for lumi in both passes.

[BiaTch 5.0]

I used 27072002-1 to encoded from hell (PAL/Field De)both passes & I got pinky arifacts in the background then just second pass and all was fine.

[iago]

@BiaTch 5.0

I was especially referring to the 08082002-1 build ;).

thanks everybody,
iago

[rui]

Originally posted by iago
@BiaTch 5.0

I was especially referring to the 08082002-1 build ;).

thanks everybody,
iago

To BiaTch 5.0: I believe that the 2707 build was using the old (new) lumi code. Maybe that's the cause of your results. Did you tried with the new build?

[iago]

@ookzDVD and rui

Well... I generally hold the same opinion as you, and my vote is for lumi masking in both passes too :). Still, I'll do another test encode (to make myself absolutely believe in this) with the 08082002-1 build. Two rips of the same movie, heading for 640000 kb video size with the exact same parameters (without AltCC in order not to put the blame on it later :)), except that one will be with lumi masking in both passes, and the other with no lumi masking at all.

Then I'll compare the results in terms of both visual quality/artifacts especially in dark scenes and compressibility/average quants. If I notice any problems after watching and frame-by-frame analyzing both encodes, I'll let you know, together with the screenshots for comparison.

But I guess it will take some time, 'cause currently I've already been doing some other encodes.

with my best regards to all,
iago

[iago]

After Koepi's reply to my question in the "Results of some Alt.CC testing" thread, which was about altCC and default two pass CC, I decided to make the above mentioned test about lumi masking using the altCC parameters Koepi suggests:

altCC: medium aggression/high500/low90/strength30/I-frame boost: 0/payback delay: 250

so long,
iago

[BiaTch 5.0]

Originally posted by rui


To BiaTch 5.0: I believe that the 2707 build was using the old (new) lumi code. Maybe that's the cause of your results. Did you tried with the new build?

No, I have not got the dvd any more, but if I get it again I'll show my results.

[iago]

Hello everybody,

Here are the results of the lumi masking test done with the 08082002-1 build. The same movie is encoded twice, with the exact same parameters, except that in one encode lumi masking is used in both passes, and in the other no lumi masking is used at all. Respectively, I'll refer to these encodes as "LUMI" and "NOLUMI" here and in the screenshots I provide for comparison.


Movie: The Score (119 min)
resolution/resize: 640*272/neutral bicubic
video size: 645000 kb

First Pass:
UltraHigh
H.263

Second Pass:
UltraHigh
Modulated
Min-Max I-frame: 2-4
Min-Max P-frame: 2-8
I-frame boost: 0
Below I-frame: 10
I-frame bitrate reduction: 30
Bitrate payback: 250 (bias)
AltCC: medium/500/90/strength:30
Enabled automatic bonus bias calc.

Max-Min I-frame intervals: 250-1 (both passes)
SCD threshold: 50 (both passes)

credits: 31quant


Results (LUMI)

DebugView analyzer for XviD codec v0.10 by MoonWalker
e-mail : s_ilias@gmx.net

Quantizers Analisis
---------------------

Quantizers Used For Movie :
------------------------------
Quant 2 Used : 2783 Times, Percentage Used : 1.63%
Quant 3 Used : 101929 Times, Percentage Used : 59.86%
Quant 4 Used : 61221 Times, Percentage Used : 35.95%
Quant 5 Used : 3476 Times, Percentage Used : 2.04%
Quant 6 Used : 519 Times, Percentage Used : 0.30%
Quant 7 Used : 258 Times, Percentage Used : 0.15%
Quant 8 Used : 99 Times, Percentage Used : 0.06%

Average Quantizer Used for Movie : 3.402

Quantizers Used For Credits :
--------------------------------
Quant 31 Used : 8293 Times.

MPEG Quantization Type Used 113005 timed, Percentage Used : 63.28%

H.263 Quantization Type Used 65573 timed, Percentage Used : 36.72%

Quantizers prevented from rising too steeply 0 times


Intra-Frame (Key-Frame) Quantizers
------------------------------------

Movie
-------
Quant 3 Used : 536 Times, Percentage Used : 79.29%
Quant 4 Used : 98 Times, Percentage Used : 14.50%

Credits
---------
Quant 31 Used : 42 Times, Percentage Used : 6.21%

Number Of Consecutive I-Frames : 9

Inter-Frame (P-Frame) Quantizers
------------------------------------

Movie
-------
Quant 2 Used : 2783 Times, Percentage Used : 1.56%
Quant 3 Used : 101393 Times, Percentage Used : 56.99%
Quant 4 Used : 61123 Times, Percentage Used : 34.36%
Quant 5 Used : 3476 Times, Percentage Used : 1.95%
Quant 6 Used : 519 Times, Percentage Used : 0.29%
Quant 7 Used : 258 Times, Percentage Used : 0.15%
Quant 8 Used : 99 Times, Percentage Used : 0.06%

Credits
---------
Quant 31 Used : 8251 Times, Percentage Used : 4.64%


Frame Analisis
----------------

Number Of Intra-Frames (Key-Frames) : 676
Number Of Inter-Frames (P-Frames) : 177902
Total Number Of Frames : 178578

0.38% of the Movie is Intra-Frames (Key-Frames)
99.62% of the Movie is Inter-Frames (P-Frames)


Size Analysis
----------------

1-Pass Size : 1210679771 Bytes or 1182304 KBytes
Scaled Size : 656193554 Bytes or 640814 KBytes
Actual Size : 656176664 Bytes or 640797 KBytes

Usefull Statistics
------------------
Compressibility : 54.20%
Relative Quality of XviD avi : 58.79%
Absolute Quality of XviD avi : 95.79%


Results (NOLUMI)

DebugView analyzer for XviD codec v0.10 by MoonWalker
e-mail : s_ilias@gmx.net

Quantizers Analisis
---------------------

Quantizers Used For Movie :
------------------------------
Quant 2 Used : 1704 Times, Percentage Used : 1.00%
Quant 3 Used : 93312 Times, Percentage Used : 54.80%
Quant 4 Used : 73227 Times, Percentage Used : 43.00%
Quant 5 Used : 1925 Times, Percentage Used : 1.13%
Quant 6 Used : 113 Times, Percentage Used : 0.07%
Quant 7 Used : 3 Times, Percentage Used : 0.00%
Quant 8 Used : 1 Times, Percentage Used : 0.00%

Average Quantizer Used for Movie : 3.445

Quantizers Used For Credits :
--------------------------------
Quant 31 Used : 8293 Times.

MPEG Quantization Type Used 103309 timed, Percentage Used : 57.85%

H.263 Quantization Type Used 75269 timed, Percentage Used : 42.15%

Quantizers prevented from rising too steeply 0 times


Intra-Frame (Key-Frame) Quantizers
------------------------------------

Movie
-------
Quant 3 Used : 1218 Times, Percentage Used : 86.75%
Quant 4 Used : 144 Times, Percentage Used : 10.26%

Credits
---------
Quant 31 Used : 42 Times, Percentage Used : 2.99%

Number Of Consecutive I-Frames : 51

Inter-Frame (P-Frame) Quantizers
------------------------------------

Movie
-------
Quant 2 Used : 1704 Times, Percentage Used : 0.96%
Quant 3 Used : 92094 Times, Percentage Used : 51.98%
Quant 4 Used : 73083 Times, Percentage Used : 41.25%
Quant 5 Used : 1925 Times, Percentage Used : 1.09%
Quant 6 Used : 113 Times, Percentage Used : 0.06%
Quant 7 Used : 3 Times, Percentage Used : 0.00%
Quant 8 Used : 1 Times, Percentage Used : 0.00%

Credits
---------
Quant 31 Used : 8251 Times, Percentage Used : 4.66%


Frame Analisis
----------------

Number Of Intra-Frames (Key-Frames) : 1404
Number Of Inter-Frames (P-Frames) : 177174
Total Number Of Frames : 178578

0.79% of the Movie is Intra-Frames (Key-Frames)
99.21% of the Movie is Inter-Frames (P-Frames)


Size Analysis
----------------

1-Pass Size : 1265838928 Bytes or 1236170 KBytes
Scaled Size : 656193878 Bytes or 640814 KBytes
Actual Size : 656182560 Bytes or 640803 KBytes

Usefull Statistics
------------------
Compressibility : 51.84%
Relative Quality of XviD avi : 58.06%
Absolute Quality of XviD avi : 95.67%

-----------------------------------------------------------

Finally, I'm making no comments this time, and leaving the evaluation job up to you :). Also I'm providing screenshots (taken in VirtualDub) of both encodes (LUMI/NOLUMI) for those who are interested.

so long,
iago

[iago]

Sorry for the double post; it was not my fault, though. (Must be some problem occured related with the "preview reply" button.) Two posts above are exactly the same :(.

Hope the screenshots attachment gets approved soon so we can talk about the results more accurately.

best regards to all,
iago

[Koepi]

Which double post?

Just kidding. I delted one of them :)

Regards,
Koepi

[iago]

@Koepi

LOL! Either need my glasses or have to sober up soon ;). Thanks anyway.

iago :D

[iago]

Hello again,

Well, after so much trying and spending long hours on test encodes and after watching both encodes (LUMI and NOLUMI) very carefully, I would like to comment a bit on the results.

First of all, it is very clear that using lumi masking in both passes is very helpful in terms of increasing compressibility (LUMI: 54.20%, NOLUMI: 51.84%) and in terms of reaching lower quantizers (obviously more 2 and 3 quantizers) for the movie.

Secondly, comparing the two encodes frame by frame and judging by (only) the screenshots (of the darkest and most likely-to-be-problematic scenes) would be absolutely misleading (after all, you can't see much difference, can you? ;)), since when you watch and compare the two encodes (using ffdshow and of course choosing "decode using XviD" in the codecs tab and selecting "IDCT: XviD" in the Miscallenous tab), you can't spot any quality loss or artifacts in the "both passes LUMI" encode.

Next, the settings used in the first and second passes and the AltCC parameters (suggested by Koepi) really seem to work fine and both encodes (LUMI/NOLUMI) are really impressing and of pretty high quality :).

Finally, of course I choose to keep the "both passes LUMI" encode for my 1cd rip (with 0.100q ogg) of this movie. And my vote is now (with much more certainty) for "lumi masking in both passes" ;).

best regards to all,
iago

[ookzDVD]

@iago,

Thank you for your testing, I really apreciate that,
and I really support your test result. ;)

[MaTTeR]

Originally posted by BiaTch 5.0
I used 27072002-1 to encoded from hell (PAL/Field De)both passes & I got pinky arifacts in the background then just second pass and all was fine.

I'm actually seeing these artifacts also on 3 out of the last 6 movies I ripped using the 08-08 build. I thought the culprit might be the alt-cc settings so I disabled and still seeing the same issue. Hope to post full details and screenshots about it this weekend.


In regards to Lumi...I've never stopped using it since day one on both passes. It was always clear to me the advantages of using it, especially since the old code provides more compressibility over all. Remember, lumi-masking is going to work on bright scenes just as well as drak scenes. So for a bright movie(Mary Poppins? LOL), you should see some nice results with it as well.

[BiaTch 5.0]

Originally posted by MaTTeR


I'm actually seeing these artifacts also on 3 out of the last 6 movies I ripped using the 08-08 build. I thought the culprit might be the alt-cc settings so I disabled and still seeing the same issue. Hope to post full details and screenshots about it this weekend.


In regards to Lumi...I've never stopped using it since day one on both passes. It was always clear to me the advantages of using it, especially since the old code provides more compressibility over all. Remember, lumi-masking is going to work on bright scenes just as well as drak scenes. So for a bright movie(Mary Poppins? LOL), you should see some nice results with it as well.
Have you tried encoding with Lumi disabled or only In second pass?.

[MaTTeR]

Originally posted by BiaTch 5.0

Have you tried encoding with Lumi disabled or only In second pass?.
I actually tried with it disabled and still had nasty artifacts appearing. I have not tried just using it in the 2nd pass alone though. I'll give that a shot before I post the screenshots tomorrow.

[Koepi]

There might be no need for screenshots, it's possibly a bug which is investigated ATM.

Hopefully the fix is in CVS soon :)

Regards,
Koepi

[MaTTeR]

Thanks so much Koepi;) Do let me know if you need the screenshots and encoding details.

[iago]

Hello all,

Well, my purpose is absolutely not to revive an old thread, where some important conclusions regarding the issue have already been drawn. Still, I find it most proper to first discuss the matter in this thread as an introduction to the topic.

And I assume, most people are "generally" using their PC monitors to watch their encodes, just like me ;). However, when it comes to TV, the quality of any rip is totally another story, and even your most "trusted" and "perfect" looking rips may well frustrate you when you watch them on TV without lowering brightness and contrast, or sometimes even when you watch them on your monitor especially in a dark environment, with a rather high resolution, full brightness and contrast, and no extra lights in the surrounding! (So, those who don't bother watching their rips with such monitor settings and in totally dark environments, and those who don't want/need/have TV output for any reason might totally ignore this post! ;))

OK, lately I've been doing a couple of tests, *with* and *without* lumi masking; using Koepi's 04092002-1 build, and statsreader 1.6 to linear-scale the curve for external cc (with the already well known parameters to all: Motion search:6 / hi-lo:0-0 / altCC disabled, etc.), to have a look at the problem of blockiness in dark areas. Also, these tests are/were not limited to XviD only. (SBC and DivX502 Pro, more or less, but still absolutely exhibiting the same problem in dark areas, were also tested several times, just resulting in the same ongoing problem.)

Back to XviD, the aim of all these tries was to see if there would be any difference/improvement towards eliminating this problem by tweaking some settings, and mainly by disabling "lumi masking", my all-time 'usual suspect' concerning this issue ;).

Surprisingly, after all these tries with XviD and other codecs mentioned (well, actually these tries of mine have been going on for a very very long time ;)), I concluded that the problem hasn't got much to do with lumi masking/luminance correction in XviD/SBC respectively, nor with psychovisual enhancements in DivX502Pro. Whatever you do, you cannot eliminate them totally! It seems to be (as always discussed) more or less an innate problem to all codecs. And that's why there are options such as "noise" in ffdshow and "film-effect" in DivX5 decoder...

And now comes the interesting/striking point: Concerning XviD again, the only rips in all my tries that displayed this problem *least* (though certainly still having the problem to some extent) were the ones with MPEG/MPEG quantization and with Bicubic Resizing (=/> 0,0.5), which possibly "preserved" the original DVD noise more than the others. DVD noise is also clearly distinguishable especially in dark areas of the films (not in the form of ugly blocks of course but as "noise") when you watch the DVD carefully on monitor or on TV with the above mentioned settings.

Finally, these are only my "personal" observations for a long period of time, might contain mistakes, and absolutely open to/requires much discussion and sharing of experiences, which might even initiate a step towards the solution of a well-known but still unsolved problem.

Maybe, (in order to solve this major-irritating problem) we should totally change our attitude towards encoding and try to "keep" the *noise* of the original DVD as much as possible instead of trying to "eliminate" it...


Important Note: All the above argument is about "regular/normal movies" and "DVD rips of such movies"; not about TV content, anime, etc. Also, a solution "may" or "may not" be fully possible technically of course, but still this might be taken as just a different look/perspective to the encoding process and our encoding habits ;).

P.S.: You can try enabling "Noise" in ffdshow with "Old noise algorithm" and "Uniform noise" with "luminance noise strength=8" (chroma noise strength=0) to observe "the difference/the most possible original DVD-like effect" and see these blocks in dark areas almost completely disappear, though that's not a perfect solution to the problem of course ;).


kindest regards to all
and many thanks for taking the time to read such a long and boring post ;)

iago

EDIT: Well, I guess I have to add SimpleResize, the great non-smoothing, non-filtering ;) filter by trbarry, besides "Bicubic Resize =/> 0,0.5" too.

[Marc FD]

i noticed many times blocking in black scenes when i used my TV out.
for example in an anime (Noir) i wanted to see on my TV (16/9) :
It was SBC compressed and the blocking in dark areas was horrible.
Even ffdshow with new noise 80/40 PostPproc cpu-6 200% and the image was still horrible to see !!
Using Black-Expand on my TV help a bit.
In the end, i used Levels() and it was very good. but too slow :( for playback.

Now,i see a very simple way to get rid of this annoying effect :
Make Lumi-Masking in Post-Processing stage.
Could even be done fast using the DC value of each MB, no ?
I can try this with my MPEG2Dec PP mod, but i'm too lasy to move my computer near my TV :D

and it's only for DVD playback (i love to use BSplayer to see DVDs ;) )
not to play avi's (the PP should be built in the decoder)

I suggest you to try Levels() (of course you tweak the values)
If you see improvements, we could (any avs dev.) MMX optimise it.

[-h]

I've been thinking of adding a switch to XviD that adds AC "noise" to blocks whose luminance is below a certain threshold. I too have just started watching MPEG-4 on a TV and the result is truly horrible, I agree.

I would rather the encoder handle improving the areas than leaving it up to the post-processor, because eventually we may not have such fine-grained control over how the post-processor behaves (think hardware MPEG-4 players).

-h

[Marc FD]

AC ? i don't remember the meaning.
can you enlighten me ?
thx.

[iago]

I've been thinking of adding a switch to XviD that adds AC "noise" to blocks whose luminance is below a certain threshold. I too have just started watching MPEG-4 on a TV and the result is truly horrible, I agree.

I would rather the encoder handle improving the areas than leaving it up to the post-processor, because eventually we may not have such fine-grained control over how the post-processor behaves (think hardware MPEG-4 players).@-h

Yes, absolutely that could be the one and best possible solution to the problem, and it would actually be great. I totally agree with you that it's much better to make it possible in the encoding process adding noise to dark areas below a certain threshold, and keeping the rest of the clean MPEG-4 picture alone. Hence, post-processing by adding noise (which might not be handled with full-control and success as you pointed out) can only be an emergency-exit to watch "poor" encodes on TV, which still contain the blocks problem; but by eliminating this "horrible" problem in the encoding stage, the "original" encode will be much improved, and that would really be a great step in the ripping world imho and open a new era for XviD to display its real perfect performance.

best regards,
iago

[Marc FD]

the problem is dumb guys (me) like _deep_ more-black-than-black black and don't like noisy stuff. (it's why i'm a h263 fan ;) )

[-h]

AC ? i don't remember the meaning.

The DCT output consists of 1 DC and 63 AC values. As the DC value is the "average" of the entire block, the only coefficients worth setting to simulate noise are the higher AC ones, which concern progressively higher frequencies.

Here (http://www.cs.sfu.ca/CourseCentral/365/li/material/notes/Chap4/Chap4.2/DCT_basis.gif) is an image with a graphical representation of the 64 coefficients and how they represent the image itself.

..it's much better to make it possible in the encoding process adding noise to dark areas below a certain threshold, and keeping the rest of the clean MPEG-4 picture alone.

The trick will be adding the right amount, without having it look just as bad only with different artifacts.

-h

[iago]

Hello again,

Well, it's getting more complicated actually, and I hate to do that but I think I have to make some corrections on my long post above, especially regarding lumi-masking, based on some new test results; though the main points discussed so far and the solution suggested by -h are still consistent and valid imho.

First of all, based on the new test results carried out with Nic's and Koepi's latest builds, using 1-pass constant quantizer 2, encoding the very beginning scenes of Matrix, with and without lumi masking, using both MPEG and h263 quantization types, and watching the test results very carefully (with no post-processing) both "on TV" and "on PC monitor with high brightness/contrast, high resolution, in completely dark environment at night with no lights on" ;), I can absolutely say that lumi-masking introduces more blockiness in dark areas and certainly causes more harm than benefits.

Briefly we can list the quality of the several quantizer 2 encodes in terms of blockiness in dark areas, from the best to the worst as follows: MPEG-NOLUMI -> H263-NOLUMI -> MPEG-LUMI ->/= H263-LUMI.

And actually the MPEG-NOLUMI encodes (both Koepi's and Nic's latest builds) were the ones closest to the appearance of actual DVD output in dark areas, bearing only the DVD-like noise rather than ugly blocks!

However, although these tests clearly show that lumi-masking is absolutely not our best-friend, there is another important issue too. The tests mentioned above are done using constant quantizer 2 in order to achieve the best possible quality with the given parameters and after that to compare the results with each other and see if lumi masking causes trouble or not. As a result, it really did!

But the point is that whenever you go higher than quantizer 2 (also tested constant quantizer 3 and 4), blocks begin to appear even without lumi-masking and whatever the quantization type (MPEG or h263) is. And as in 2-pass variable bitrate mode it's almost impossible to have an average quant 2 ;) for most movies to ensure quality and elimination of blocking in dark areas, the solution pointed out by -h is still of vital importance.

But at least, these last tests confirmed my never-ending suspicion ;) that lumi-masking was somehow and to some extent responsible for blockiness in dark areas, and now I certainly find it more secure not to use lumi-masking in my rips, and continue with MPEG/MPEG quantization as I've been already doing for a while.

And one more important point: using postprocessing with deblock/dering either with "presets" or with "custom" in ffdshow absolutely ruins the quality and introduces many more ugly blocks in dark scenes besides some artifacts. The best way for decoding XviD is using Nic's decoder filter (safely with or without postprocessing) imho. But if you "really want" to use ffdshow, use it either without postprocessing at all or only with "automatic quality control" without touching the rest in the postprocessing tab!

Well, that's all for now, and I'm really exhausted at the moment. Directly going to bed for some sleep! ;)


regards to all,
ciao,

iago

[colasonic]

Originally posted by iago
Hello all,
And I assume, most people are "generally" using their PC monitors to watch their encodes, just like me ;). However, when it comes to TV, the quality of any rip is totally another story, and even your most "trusted" and "perfect" looking rips may well frustrate you when you watch them on TV without lowering brightness and contrast, or sometimes even when you watch them on your monitor especially in a dark environment, with a rather high resolution, full brightness and contrast, and no extra lights in the surrounding! (So, those who don't bother watching their rips with such monitor settings and in totally dark environments


I think the reason is on the screen size. usually, a TV screen is much bigger than our PC screen. I don't have the experience to watch a DVDRip on a TV set, but I do know that some Rips which appear good-looking on my 17" monitor turn out to be crappy on my another PC with 19" trinitron. the reason may be the same.....

[Koepi]

As iago wrote on his first post on this thread, you should use ffdshow's noise option to get a propper image again.

Since iago saw these blocks already at quant. 3, this seems the only thing working for now. Maybe -h's attempt can help it, but I'm not sure if this doesn't blow up the video stream massively again (in size, I mean) :-/

In that case (using ffdshow's noise option) it might be possible to use lumimasking as well, but to be on the save side, for HQ TV playback you shouldn't use it.

The only option is:

You want DVD quality? Buy the DVD and keep it.
or: make a 5CD rip at quant 2.

:P

When puting movies on 1CD (from >5GB before) you have to sacrifice quality for sure. Just wanted to mention that again :)

Best regards,
Koepi

[Marc FD]

I think too that AC noise is not the solution.
Maybe iago can check it, but i think the whole problem in black areas is:
1) Black is very sensitive to quantization, because AC/DC values are near to zero and get easily quantized.
2) Many blocks are skipped int these areas (so AC noise is not a solution)
3) Lumi masking is increasing the quantizers, so it's even worse.
4) The DVD source is already bad in black areas. Rencoding it with XviD is amplificating this problem !

Maybe best than AC noise, i suggest to use a Black-Expand/Black-Normalisation Pre-Processing technique.
The Pre-Processing could be done in the DCT domain.
And using a stronger Pre-Processing with Lumi-Masking, you would even get rid of the bad black blocks...

@iago

i know it's not fair to ask it to a XviD fan, but can you compare with RV9 and it's "black pre processing" (i don't remeber the name) option. i think it worth a try to compare.
thx.

[iago]

Originally posted by Marc FD
@iago

i know it's not fair to ask it to a XviD fan, but can you compare with RV9 and it's "black pre processing" (i don't remeber the name) option. i think it worth a try to compare. thx.

@Marc FD,

I would absolutely do that if I had any experience with RV9 ;), but unfortunately I don't... Maybe someone else could try that and post the results, since RV9 (in Doom9's latest comparison) really seems to have solved this issue to some extent.

Yes, maybe all we need is "more black and black"! ;)

best regards,
iago

[Marc FD]

Originally posted by iago

Yes, maybe all we need is "more black and black"! ;)


Not exaclty. We need to correct the "bad black" on the sure to get "true black". DCT is allergic to "almost-black-but-not-exaclty-black black"

I think it's how RV9 makes the trick.
And i see how it could be done by XviD too :devil:

Since i'm going to implement XviD's Pre Processing, it could be a very usefull task to start with.

[iago]

Originally posted by iago
And one more important point: using postprocessing with deblock/dering either with "presets" or with "custom" in ffdshow absolutely ruins the quality and introduces many more ugly blocks in dark scenes besides some artifacts. The best way for decoding XviD is using Nic's decoder filter (safely with or without postprocessing) imho. But if you "really want" to use ffdshow, use it either without postprocessing at all or only with "automatic quality control" without touching the rest in the postprocessing tab!Well, it seems that even Nic's decoder filter causes this (more) blocking problem in dark areas when deblock and dering options are enabled! So to be on the safer side, either ffdshow or Nic's XviD decoder I go *without* postprocessing ;).

best regards,
iago

P.S.: I really wonder if I'm lucky or not to have a TV output and a Philips 107T21 17" monitor with LightFrame option on it to notice *all* these ugly blocks in dark areas!. Perhaps, I could be much happier *without* them! ;)

[Marc FD]

can you please try with Levels ?

[Dali Lama]

@all

This is a great topic. One which should be hammered out until resolved, I believe. I tried to start a similar thread in the AVIsynth forum about restoring the blackness of a film, but maybe I wasn't too clear.

@ Iago

Recently I found a filter called ColorYUY2. It is made by a Japanese person. It has a really useful feature that restores the levels of a film from TV-->PC or PC-->TV.

Simply input:

ColorYUY2(Levels="TV->PC")

I would be delighted to see what you find when you try this filter before resize and no other filtering concerning the blockiness in black areas. For me it seems to significantly reduce them.

@ MarcFD

I believe that you were mentioning this when you spoke of levels, correct? And yes, I have used RV9 a fair amount and can contest that it handles black much better than other codecs. However, their black restore filter simply darkens the movie too much. Also, try out that ColorYUY2 filter, it seems to darken the movie, but retain original contrast and saturation.

One other note, I am using the Lanczos3 Resize filter after ColorYUY2. This may also help in achieving the better encoding in dark areas.

Lets solve this pesky problem!!

Dali

[-h]

2) Many blocks are skipped int these areas (so AC noise is not a solution)

AC noise would prevent the block from being skipped.

Maybe best than AC noise, i suggest to use a Black-Expand/Black-Normalisation Pre-Processing technique.

How would it work though? If you blacked out a large area with thresholding to pure black, you're going to get the same ugly blocks at boundary areas (and an odd smooth block on TV where you expect to see some kind of texture).

MPEG-4 and pure black are nasty things to get working. Whatever technique gets used in the end, it'll just require a heap of testing I suppose.

-h

[Marc FD]

agreed.
we need testing.
It's why i propose :
- To pre-filter / post-filter with Levels just to see if it's good.
- To see how RV9 handles this problem with it's special tool.

PS : The Black Expanding technique i propose is different and more complex than Levels. I think you can smooth it spatially in the DCT domain to avoid blockiness. Need to be tested....

[iago]

Originally posted by Dali Lama
@ Iago

Recently I found a filter called ColorYUY2. It is made by a Japanese person. It has a really useful feature that restores the levels of a film from TV-->PC or PC-->TV.@Dali Lama,

Thanks a lot for the info you provided about this filter. I tested it several times and it really did a great job, just suiting my needs! As you also said, it seems to darken the movie a bit, but at least it doesn't ruin the encode ;). I applied it just before SimpleResize, and made numerous tests "with" and "without" using it to compare the difference, with constant quantizers up to 10, and even with the "guilty" ;) lumi masking, as well as using h.263 quantization type too. As a result, in all my tests, it performed a fantastic job, eliminating all blocks in dark areas, and converting them to pure clean black colour.

For the time being, until an innate solution within the codec itself is achieved, I guess I'll certainly use that filter without hesitation in my encodes.

And for now, until the revolutionary step of implementing an innate solution is taken, the other possibility stands as adding noise in ffdshow (uniform ~8 with old noise algo), which is absolutely an inferior solution compared to the above filter's job imho.


kindest regards and many thanks again,
iago

[-h]

For the time being, until an innate solution within the codec itself is achieved, I guess I'll certainly use that filter without hesitation in my encodes.

That sounds like a nice solution. I wouldn't like XviD's default behaviour to be altering the input (i.e. preprocessing) though, and as well as this method works I would still like to investigate one that doesn't resort to changing levels.

Of course the levels system could be integrated as a "preserve black" or "optimize for TV" option or however it should be categorized.

-h

[Marc FD]

i wouldn't be surprised at all if this filter is doing exactly what i described...
but it doesn't matter now.

can you compare the filesizes ?
can you try this filter for the playback of a bad compressed (with ugly blocks in dark scenes) source ?

[Dali Lama]

Originally posted by Marc FD
can you compare the filesizes ?


Yes! :D

I am really ecstatic about the results of this test comparing filesize/perceived video quality in dark scenes.

Clip used...

Opening of Rush Hour (2min 40s):

Dark and clean video, should be a good test for viewing any noise produced by the codec in dark scenes.

This is the structure of the AVS used:

# Plugins
LoadPlugin("C:\DOCUME~1\Desktop\DVDENC~1\Avisynth\mpeg2dec.dll")
LoadPlugin("C:\DOCUME~1\Desktop\DVDENC~1\Avisynth\decomb.dll")
LoadPlugin("C:\DOCUME~1\Desktop\DVDENC~1\Avisynth\ColorYUY2.dll")
LoadPlugin("C:\DOCUME~1\Desktop\DVDENC~1\Avisynth\lanczos3.vdf")
#
# SOURCE
mpeg2source("C:\Rush Hour\RushHour.d2v")
#
# IVTC
Telecide(guide=1,post=false)
Decimate(cycle=5)
#
# Filter
ColorYUY2(Levels="TV->PC")
#
# CROPPING
crop(5,57,712,367)
#
# RESIZING
Lanczos3Resize(640,272)

------------------------------------------

Test:

Used H.263 @ Quant 2

With ColorYUY2 filter - 47.3MB

Without ColorYUY2 filter - 40.2MB

Analysis:

I believe that these are excellent results. Why? Because this is exactly what I wanted this filter to do. By adjusting the levels suited to the PC monitor, the filter demands higher bitrate in dark scenes. I have always believed that the pragmatic solution
to blocking in dark scense is to give it more bits. At last, this filter does this.

Of course the differences in visual quality is very small at such a low quantization.
-------------------------------------------

Test 2:

Used H.263 @ Quant 8

With ColorYUY2 filter - 8.94MB

Without ColorYUY2 filter - 7.72MB

Analysis:

Once agains the filter is forcing the codec to give more bits to the dark scenes. The result? Even at quant 8, the ColorYUY2 filter is able to provide a relatively excellent picture in dark scenes. Without the filter, the blocks are prevailent in lots of dark shades. Furthermore, the picture of brighter scenes are not affected either!! This is the best part, it doesn't seem to damage the brighter scenes in favor of the dark ones.
-------------------------------------------

Note: Since the respected Iago and I find this filter useful and the fact that it is hard to find, I will attach the filter here for others to experiment or begin using in their encodings.

Satisfied and Exuberant,

Dali

[iago]

@Dali Lama and all,

I'm really glad that (after digging into the issues of lumi-masking and blockiness in dark areas again and again) we've finally reached a (temporary or maybe permanent ;)) solution regarding this matter, which imho is/was the most annoying problem for all kinds of rips. Though I haven't performed any 2-Pass/full-encode tests yet, the filter really gave the exact desired results in all my constant quantizer tests with the opening scenes of Matrix (up to quant 10 - with both MPEG and h.263 quantization types, and lumi-masking enabled or not).

Currently, I've started a two-pass encode of Matrix using MPEG quantization and no lumi-masking. When finished I will report back my opininons and comments on the full rip results.

As for compressibility, as far as I can comment based on my short tests, and parallel to Dali Lama's results, the filter seems to decrease compressibility by ~10-15; however, compared to its great job, this is no longer much of a problem I guess. Also, since the filter seems to work without causing any problems with h.263 and lumi masking too, as long as no trouble is encountered with these options, this decrease in compressibility may well be compensated by using these options as well.

Here is a sample avisynth script:

LoadPlugin("C:\filters\mpeg2dec.dll")
LoadPlugin("C:\filters\colorYUY2.dll")
LoadPlugin("C:\filters\SimpleResize.dll")
mpeg2source("D:\MOVIE\MOVIE.d2v")
crop(2,80,718,418)
ColorYUY2(Levels="TV->PC")
SimpleResize(640,272)

BTW, in my tests with SimpleResize, the filter's speed was pretty good too, almost close to the no-filter speed.


@Dali Lama,
You can also apply the filter after cropping and before resizing to gain some extra speed, no?


ciao,
iago

[colasonic]

Hi, where can I find this "colorYUY2.dll"?

thanks.

[Koepi]

I don't want to sound stupid, but which colour scale did you choose when creating the d2v project file in dvd2avi?

Did you choose "TV sclae" and "colorspace: YUV"?

Do you notice a difference when using different scales? (e.g., when selecting "PC scale" instead of "TV scale" compressability is ~10-15% worse.... reminds you of something? We back then choose the "TV scale" since it wasn't giving us bad artefacts... or was it vice versa?)

*whistle*

Regards,
Koepi

[Sharro]

I sound stupid...

I have been using pc scale and yuv colorspace . ..this is the correcT right?

Glad to see u back Koepi (still #doom9 Efnet is missing u).

All the best.

Take Care

Sharro

[iago]

@Koepi

In dvd2avi I used the same old procedure to create the d2v file: "YUV Colorspace" and "PC Scale". Then I used the above script to encode Matrix (MPEG/MPEG-No Lumi). The result is really good in terms of blocks in dark (or maybe better to say blocks in black or almost-black) areas. I mean, they are all gone, as mentioned before. So the main problem (for me) is solved, though the average quantizer jumped up a bit.

But, after reading your post, there comes the question: what happens (in terms of both compressibility and blockiness) when we choose "YUV Colorspace" and "TV Scale" to create the d2v file, which I have never tried so far actually (maybe the basic point I was/we were missing?)?

Is that what you mean Koepi? (Sorry if I haven't got it clearly?)

I'll do some tests with two different d2v files, both in YUV colorspace, but one "PC Scaled" and the other "TV Scaled", using constant quantizer mode (for example quant4). And I'll see how this affects compressibility and blockiness.

Anything you want to suggest for further convincement?

thanks,
iago

[Bluedan]

Using the above avisynth script with colorYUV2 filter, how does it decrease encoding speed ?
Still suitable for average user on PIII@667MHz?
And if you use Lanczos resize filter in addition? Speed issue?
Thx.

[iago]

@Bluedan

I guess I'd told that before in one of my above posts ;). It makes almost no difference in encoding speed (but I didn't use lanczos3, I used SimpleResize for resizing).

regards,
iago

[Bluedan]

@iago
sorry pal, maybe to excited to read carefully before. thank you though

so I address this exclusively to dali lama who obviously has worked with lanczos filter excessively ;) :

how does it affect speed ?