lumi masking

[iago]

@rui

That's great news friend! :) I'm really glad that you also tested the script, checked the visuals on TV, and confirmed that this method (a combination of taking the luma offset down by 2 and sharpening the picture with UnFilter) is effective against the black-blocking issue without hurting the picture quality.

best regards,
iago


@Koepi,

I'm downloading the clip now. I'll report back my comments after I check it on TV.

ciao,
iago

[Didée]

Iago,

first of all, a big THANK YOU for all your valuable testing.

One thing I noticed, and I wondered, because you´re a HiQuality guy:[...]
Matrix Chapter 2 [...]
mpeg2source("D:\MATRIX\MATRIX.d2v",CPU=4)
From my (little) experiences, Marc´s PP mod of mpeg2dec looses much detail with PP on.
See also this (http://forum.doom9.org/showthread.php?s=&postid=187229) post of mine.

Are the results really OK for you?

[Koepi]

On "Last Boyscout" that PP with CPU=4 indeed looses too much detail, I've to redo that movie.
Currently retesting "Contact" with unfilter(5,5) added to the script, and using the "good-picture-hvs" matrix from ReferenceDivx (which indeed looks yummie, dunno what picture quality that produces, but the matrix itself looks nice and promising) - let's see how it works out. Maybe using lumi masking is a bad idea in these scenarios?

Best regards,
Koepi

EDIT: using that unfilter(5,5) gives back a little detail, Didée :)

EDIT2: stupid me! restarting contact without unfilter-usage. the movie is "over-sharp" on the DVD already so this slight softening effect is just helping the quality - i did it all wrong way ;) last boyscout needs it, contact doesn't. *sigh* I've to think a little more before encoding ;)

[iago]

@Didée,

I read your post in the avisynth forum too. Actually I agree with you. That's why I started my testings with cpu=6, then went on with cpu=4, and finally came to test with no cpu ;)... However, Koepi is right, using UnFilter and LanczosResize (maybe MPEG quantization type as well) helps to compensate a bit for this loss of detail. But as many times discussed before, finally it comes to personal preferences: some like it sharp, some like it soft; some prefer to use Lanczos, some prefer to use Bilinear. And regarding this issue, there "is" already a solution: using no cpu parameter at all ;).

Since my (and maybe everyone's) "major aim" in this thread was to especially focus on the black-blocking issue, I actually discarded a bit the remaining issues such as the one you mentioned, as there were already some solutions for these, but there was still no working/effective solution for the ugliest problem, that is blocks-in-black.

And happily "a combination of sharpening with UnFilter(5,5) and lowering luma offset by 2" helped to resolve this problem finally. In all the above scrips tested and used, I think these two (sharpening with UnFilter(5,5) and luma offset-> -2) are the most reasonable, effective, and generally-agreeable-upon keypoints and all the rest can be more freely tweaked as to suit your taste.

best regards,
iago

P.S.: Btw, I guess you were right when saying (in another thread) that the actual AR of Matrix is something like 2.50:1, rather than 2.35:1 ;)... Now I'm resizing it 640*256...

[iago]

@Koepi

I watched the test clip on TV. Surprisingly, I didn't notice much black-blocking in it (just a bit on the left side of the screen when Bruce is opening the door, and only a bit on the jacket of the boy at the right side when the two boys are looking into the car), although you didn't use UnFilter but only applied lumoff=-2. However, I think the clip was not that dark in general ;). I would like to have a look at some more dark scenes actually to be sure. In my tests so far (with Ghost Dog and Matrix), lumoff=-2 alone (without UnFilter) was not enough the get rid of black-blocking problem...

Though it didn't display much black-blocking, the overall quality was not so impressing as you remarked. Too much smearing and blockiness in general (when Bruce turns his back, his white shirt looks terrible for example). Maybe lumi-masking was the cause of this "general decrease" in quality?..

As a result, I think that we must take "sharpening with UnFilter" and "lumoff=-x" as a *method* to solve the black-blocking problem, but of course the values can be changed as well according to the source, as I conclude from Koepi's test clip.

But as to my tests, UnFilter(5,5) and lumoff=-2 seems to be a generally-agreeable-upon combination suitable for "most" sources, in terms of keeping compressibility within a reasonable range, avoiding an excessive darkening effect, and not hurting the picture quality.

of course these are just my personal opinions ;)
kindest regards,
iago

[MaTTeR]

@iago,

It sounds like you think we don't need the PP CPU=x function now to help eliminate the darnened blocks if I understand your last 2 posts correctly. Guess I'll try again using Unfilter and lumoff=-2 alone. Wonder how mSharpen would compare to Unfilter in terms of quality and performance?

[iago]

@MaTTeR,

Regarding specifically black-blocking problem, I don't think pp levels have much effect on it. But I'll do some 2-pass and constant quant. tests with Matrix to confirm this feeling ;).

I think cpu=x mostly helps reduce blockiness "in general" (not in black areas), and using it we also gain more compressibility, however as discussed above, (concerning different personal tastes) this can lead to an oversmoothing effect as well.

If we come back to black-blocking again, since our *method* ;) is based on sharpening the image with UnFilter(+,+) and (for clean sources) trying to keep the original noise as much as possible rather than eliminating it, it "might" be even better to use no cpu=x at all and apply only lumoff=-2. But as I said, it requires some more testing! ;)

kind regards,
iago

[Koepi]

Thanks for the comments iago, I agree with them and your observations.

But as stated in my edit above, it depends on the movie if you need to sharpen it again or not - contact is nearly uncompressable because it's "oversharpened" in the sources, the noise is amplified by it etc., so there it's not dangerous to not sharpen it additionally to lnaczos resize.

I'll redo last boyscout after this 2pass without PP, that should keep the sharpness as well (or with PP and unfilter(5,5)).

Regards,
Koepi

[iago]

@Koepi,

OK friend! ;) I'll be looking forward to hearing about the results of your new encodes. Please keep us all informed about the results you get.

best wishes,
iago

edit: I agree with you, for sources that are already razor-sharp ;), why use LanczosResize!? ;)

[Dali Lama]

Iago,

I have tried your method and it looks great. Although I havn't had a chance to check it on TV. I was wondering if you could give this setup a shot.

ColorYuy2(cont_u=30,cont_v=30,hscale=50,x=200,y=200)

It doesn't darken the movie and I think there isn't much blocking in the dark areas, but I don't have a way to check on tv.

If this works then there are two ways to do it. If not, your method is great.

Good Job,

Dali

[iago]

@Dali

Sure, I'd be glad to try it. But can you please check the ColorYUY2 parameters that you provided? I get the below error message when using the parameters in your post:

ColorYUY2 does not have a named argument "hscale"

thanks,
iago


@MaTTeR,

Using cpu=x or not using it at all does not have an effect "on black-blocking issue" as I can see from my tests. Currently I'm testing UnFilter(5,5) and lumoff=-2 without cpu=x, and I notice neither positive nor negative impact of it on black-blocking issue.

(However, compressibility, deblocking, deringing and smoothing due to the use of cpu=x is a different issue to be discussed imho, as already being done in the related avisynth thread.)

I'd also be very glad to hear about your test results.

kind regards,
iago

[cjv]

Well I have to say that a combination of luma -2 and unfilter(5,5) combined with MPEG quant sure make a beautiful picture. :) I have tested a few 2 min samples from LOTR, both at constant quant 2, on the TV. Even without Unfilter, that annoying mpeg-4 blocking seems drastically diminished, and in my eyes unfilter only serves to make the picture more detailed, (which at quant 2 is not a bad thing)

Most of my 2-min clips are approx 40 megs, but once unfilter is added they jump up to 48-50 megs, and over the 178 mins of the movie, I feel this will hurt compressibility too much. I could always move to h263 quant possibly, but I feel this introduces too much smoothing for a 3CD rip. Anyways, I will use MPEG, lanczos resize w/luma -2 tomorrow, and see how it turns out visually.

cjv

[trbarry]

I have been following this thread with some interest but no understanding of what is going on or why UnFilter sharpening could be helping here.

But capture cards and TV circuits have something called Coring that can be set to change all luma values under a certain threshhold to zero. But if, say in DScaler, the coring level is set too high then it will produce black blocks on the screen in dark grey areas as certain pixels fall under the threshhold. I wonder if a similar phenomena is at work here for some reason?

If so it might be fixable with a filter that ensured there were no blacker than black pixels, or no pixels lower than some given level.

- Tom

[Dali Lama]

Iago,

You need the new version that just came out, I think its v12 or something. If you can't find it I will attach it once I get to my computer.

bye,

Dali

[cjv]

About the LOTR, using hvs best matrix, lanczos, lumaoff -2 and unfilter, it unfortunately drops compressibility to 47%. :(
I must say,though, that at const quant 2, it reproduces the DVD 100%!! But using 4 cds is too much for me and I want to keep the AC3.

I will try this combo on Training Day and Fight Club, as they seem to compress well when using 2CDs, and report back the visuals tomorrow (yea, video compression on a P4 laptop just doesn't cut it!)

cjv

[yaz]

hi all !

i'm happy about unifying this thread again. thanx, koepi !

some short notes now (time's not on my side:-))

@trbarry:
i suggested this trick of sharpening to iago. i don't know xactly why does it work, but it does. i guess, it's beacause of sharpening the noise being always present whatever source we use. this way the codec can't smooth out so harshly the regions having low luma noise. anyway, it's just a guess.
btw, i don't use unfilter, as it doesn't work for me. it accepts only some distinct values, say, between 30-40 it works only with 31 and 39. all other give an 'illegal call' in avisynth. can u xplain me, why does it do?

@iago:
use only filters u xactly know what they do. i don't like coloryuy2, cus i don't know what does the different arguments mean & how are they defaulted. (actually, i know only 6 japanese words, but i don't even know how are they written:-)
no blame on u(!) but cyuy2 has lotsa arguments. i guess, tv-pc transformation differs from the corresponding levels() just because of its arguments not set properly.

@koepi:
just a (sh)idea. maybe i'm wrong, but ... afaik, lumi masking is based on the idea of using different(higher) quants on low luma macroblocks. would it be possible to invert this effect? i mean a kinda 'inverse masking' applying lower quants on these blocks. it may help against black-blocking. maybe i'm completely wrong, but it'd worth a try.

@all:
try hq-quant ! it gave me xxlent results concerning black-blocking. the idea (reverting 'modulation' effect) is great! i luv it ! (the question above was inspired by this:-)

about compressibility. it's the factor everybody seems to be anxious about. yes, the tricks we use against blocking would decrease it (in some instances significantly) but ...
xvid (2pass) is extremely good in keeping target filesize. i'm not a perfectionist (like koepi:-), i accept differences in the 100kB range. xvid has never hit this range whatever i tried against blocking. so, no use of being so anxious !

hormonally yours
yaz

ps don't lame me, i do it on my own !

[rui]

Originally posted by yaz
...about compressibility. it's the factor everybody seems to be anxious about. yes, the tricks we use against blocking would decrease it (in some instances significantly) but ...
xvid (2pass) is extremely good in keeping target filesize. i'm not a perfectionist (like koepi:-), i accept differences in the 100kB range. xvid has never hit this range whatever i tried against blocking. so, no use of being so anxious...

Well, the problem is that, when trying to keep the filesize, with a movie that is less compressible, i believe xvid will rise the quantizers. So the movie will look worse. If one can increase compressibility (without smoothing too much, but this implicates personal choices and tastes), then the movie would look better.

[Koepi]

Dunno if I posted that already, but XviD is so flexible... e.g. you can circumvent using lumi masking, which particularly overquantizes some regions, with using the HVS_GOOD matrix (if heading for 1CD using h.263 quant type). My first results are promising.
Setting luma offset to -2 like iago suggests helps compressability, too, though for PC monitor playback you have to increase brightness on playback.
For TV playback, some more noise is always helpful, so using unfilter(5,5) increases the sharpness even of noise, so it gets encoded (well, if not quantized in bad heights like quant=10 or something), so alltogether you can tweak your encodings to look good quite easily it seems ;)

Just wanted to mention what I experienced so far when testing different things..

Best regards,
Koepi

[yaz]

hi rui !

Originally posted by rui


Well, the problem is that, when trying to keep the filesize, with a movie that is less compressible, i believe xvid will rise the quantizers. So the movie will look worse. If one can increase compressibility (without smoothing too much, but this implicates personal choices and tastes), then the movie would look better.

ehmm .. yes/no. imho, u oversimplify the things. a bit :-) of course, if a movie is less compressible, it needs higher quantizers to fit to the same target size. but, imho, it does not mean worse looking in general. say, with the sharpen trick black-blocking can be decreased. of course, the bits lost in this region must be regained somewhere else (so as to fit the same target size). i don't know how xvid spreads bits over the movie, but i can imagine even that it takes these bits from completely different scenes. but(again:-), say, it takes from different regions of the same frame. who can tell whether the new look will(!) be better or worse than that of having those shitty black-blocks. it may be better or worse. as compressibility can't be established before 1st pass so the effect of these kinda changes can't be predicted so easily. u should give it a try. in add, lookin good or bad is quite subjective. just as u wrote :-)

hormonally yours
yaz

[iago]

@Koepi

Well, OK, I decided to break my silence! ;) And you have a "new" e-mail and a "new" PM. Please check them! ;)


@Dali Lama

Neither ColorYuy2(cont_u=30,cont_v=30,hscale=50,x=200,y=200) nor ColorYUY2(opt="coring") could solve the black-blocking problem in my tests (v0.12 used).


@yaz

* Once again, many thanks for inspiring this (sharpening) method. And I "think" the same as you do about how/why sharpening helps handling this black-blocking issue.

* -> ...'inverse masking' applying lower quants on these blocks. it may help against black-blocking...
I really would like to have such an option one day too, though I don't know if it's possible! ;)

* OK, we'll keep discussing ColorYUY2 with Dali in private from now on ;)...


@all

I agree with yaz that new modHQ is really good, but the good-HVS matrix posted by ReferenceDivx is really worth a try imho, in terms of increasing compressibility even better than h263, and still keeping a pretty good image quality as well as eliminating noise successfully. (Koepi also discussed that in the related thread.)

Also, "lumoff=-2 and UnFilter(5,5)" combination "doesn't" lead to such a drastic decrease in compressibility but only to a minor one, and compared to its benefits on solving one of the ugliest problems -> black-blocking, it's nothing to bother imho. Moreover, this minor decrease may well be compensated using different encoding and resizing parameters/methods (HVS-good-matrix, not LanczosResize but another resizing method, setting some cpu levels in Marc FD's mpeg2dec.dll, etc.)


kindest regards,
iago


EDIT: Sorry, I didn't notice the last two posts by yaz and Koepi before mine, which discuss similar things as well ;)...

[rui]

yaz, i didn't explained myself very well.
I am big fan of iago's script. I see all my movie in tv-out, so this is a great improvement to me :)
I was only talking about the compressibility thing.
I too believe that the gains we have by using iago's script are much higher than the losses we have in compressibility.

To iago: sorry, i didn't wanted to sound like a critic :o
Your work is VERY apreciated. Thanks :)

[yaz]

hi all !

instincted by the enthusiasm & efforts of iago (& being angry with myself on being so loose-minded) i returned back to the roots. i captured some short clips from a noisy tv channel & i tried to brush my mind about what to do with them to make acceptable lookin encodes.

i tried 4 different codecs (all in 2pass, wout any filter, all shots checked on tv). wout further detailes, xvid far the best in keeping target size & in handling low luma regions (i've known it, but why not strengthen ?:-)
it is very interesting to watch how the different codecs suffers from the low luma parts. only one surprising experiment: encoding a steady clip (only minimal, slow movements, say, clouds on the sky or so) meant serious problem for most of the codecs. they can't do anything with the dark(er) parts of the scene. they were full of black blocks sometimes almost steady but sometimes even whirling around.
xvid made also heavy blocks, but this blocks gave back always the contours and sometimes even the shades in the dark parts. i luv it, really! but ...
when i tried to use anything but modHQ (my present favourite) everything went wrong. the blocks went more blurry (h263/mod) or got a quite funny whirling pattern (mpeg). the new hvs matrices gave something very close to mod.
when i switched lumi masking on i was able to reproduce the contours but the shades had gone (independently of what kinda quant matrix i used). in add, these parts became flat somehow. i can't put it all together now, but it seems, as if lumi masking would not only raise the quants on dark regions but 'sweep' them somehow. on the other hand, it works definitely against HQ. (blocking is more heavy with it than wout)

okay, just some short experiments, maybe digestable :-)

hormonally yours
yaz

[iago]

@hello yaz and everybody

Just a very short confirmation based on my own experiences and observations so far: lumi-masking really does more harm than good and decreases the overall quality of the encode whatever quantization type or encoding parameters you use! You'll be much better off if you keep your hands off it! ;)

Well, modHQ being really nice, I still like built-in MPEG quantization actually and in my tests with DVD sources so far, MPEG was the one which seems to handle black-blocking issue more successfully than others, keeping more of the original source noise in those low luma regions as well as more details and a better colour representation throughout the movie.

When it comes to compressibility, I usually prefer to pay the price with BilinearResize in really difficult/extreme cases, rather than using another quantization type, about most of which (including h263) I still have my doubts (or maybe better to say, find less appealing to "my eyes") unfortunately.

best regards,
iago


EDIT: btw, quantization -> detail removal factor ? ;)

If so, imho here lies the real dilemma actually. For instance:

* You choose MPEG quantization (which keeps more details and noise) -> compressibility down -> higher quantizers used in the encode (which sweeps away more details again) -> result: details are lost due to higher quantizers.

* You choose h263 quantization (which removes some details and noise) -> compressibility increase -> lower quantizers used in the encode (which removes less details/or keeps more details) -> result: details were already lost with h263 quantization in the beginning.

So far I have usually preferred the first routine (MPEG quantization) and applying bilinear resize or some light filtering such as TemporalSoften(1,5,0) with it in really difficult, hard-to-compress cases, which seemed "a better working" solution to me, but I really would like to hear about your comments and opinions on this issue...

[MoonWalker]

Originally posted by iago
So far I have usually preferred the first routine (MPEG quantization) and applying bilinear resize or some light filtering such as TemporalSoften(1,5,0) with it in really difficult, hard-to-compress cases, which seemed "a better working" solution to me, but I really would like to hear about your comments and opinions on this issue...

At last :)..

100% of my movies are done with TemporalSoften(1,5,0) and MPEG...It removes almost all the MPEG noise and it has a very very small loss of detail(I only observe it at Vdub with frame-by-frame comparison)..Note that my rips are all 2CD's cause I keep the AC3 track :)

MoonWalker

[kilg0r3]

i usually use temporalsoften 2,3,3 or 2,2,2 which IMO removes the same amount of noise but leaves more detailes than 1,5.

another setting i like is convolution3d 0,1,8,3,5,3,0. to smoothe on the chroma plane only, is quite effective regarding a gain of compressability while the detail, for the eyes, comes mainly from luma and hence remains. just for the fun of it try convolution3d 0,1,50,3,50,3,0. it blurres not as much as expected, and, strangely enough produces no color ghosting. (iknow this expresses only my lack of understanding regarding the inner workings of the filter).

cheers to all

[iago]

Well, perhaps some of these issues about filtering are more suitable to be discussed in the avisynth forum; however, discussing these methods together with their effects when using different quantization types and custom matrices and from a xvid-encoding focus makes it inevitable for them to find their way into this XviD thread ;), and this is really useful imho...

So... ;) filtering luma and/or chroma to what extent, with which parameters, and what results in the end?! Which offers more compressibility without losing fine details, is it possible keeping the noise especially in low luma regions (adaptive denoising?) and filtering the rest, etc. etc... ;)

AFAIK, human eye is more sensitive to changes in the luma plane rather than chroma, and most image information/data is stored already in the luma plane regarding the encoding process? So...

Well, it would really be nice to discuss all these imho! ;)

kindest regards
iago


edit: To be honest, recently I'm conducting some really weird (:D) tests on filtering, trying some aggressive parameters with different filters (using MPEG quantization type) just to see their effects ;)...

[cjv]

I've been playing around with some custom matricies lately, but for archival l've been using (for the time being) h263/bicubic0.6 for 1CD rips, and MPEG/tsoften(1,5,0)/lanczos (if there's bits to spare) or h263/lanczos for 2CD. And yea, I think temporalsoften w/MPEG looks really great, really helps to remove that MPEG noise.

In my opinion, iago's c3d(0,4,4,4,4,2.8,0) will without a doubt get rid of 99% of background noise/grain, (I was shocked at how well it works), at the expense of a bit of details lost in the faces..but then again, you also want to keep the grain because that is also part of the DVD..a tough call sometimes.

I'm debating whether to try lumi masking (or something crazy) on a movie I'm currently trying to encode. Even with c3d(0,4,4,4,4,2.8,0), bicubic 0.5 and h263, first pass is still 2.8+ gigs!..and at quant 2 still looks somehwat crappy and blurry.

@iago: are you still using lumoff/unfilter even with MPEG quant?


cjv

[Lefungus]

Useless post. Can be deleted by moderators. Sorry !

[cjv]

@lefungus: In avisynth 2.06 (the newest) temporalsoften2() is implemented as temporalsoften().
or
http://users.win.be/dividee/TemporalSoften2.zip

cjv

[iago]

Originally posted by cjv
@iago: are you still using lumoff/unfilter even with MPEG quant?@cjv

Absolutely! ;) (unless I can saturate the codec with MPEG quantization ;), which seems to be the only alternative to "lumoff=-2 and unfilter(5,5)" trick I have seen so far, with the difference that MPEG quant2 mostly "keeps" the source noise in dark/black areas as well and that is something tolerable/not annoying/or even preferable/ but almost impossible! ;))

regards,
iago


edit: However, some sources that are already sharp enough or that contain some heavier film noise (I'm not sure about that, maybe both) might not require any UnFilter at all and only lumoff=-2 can be the adequate solution.

[yaz]

hi all !

i went on my little ugly clips. next i tried to combine filtering & encoding. i used some very basic avs scripts and fast recompress. results :
- icreasing stepwise the 'strength' of denoising has a quite 'strange' effect. light denoising improves quality (i mean the overall look of the encoded clips, special attention to black-blocks, watched on tv) but after awhile it degrades again. the 'mirror-cleaned' clips seem almost as ugly as the original noisy ones.
my guess : complete removal of such heavy noise i have here removes too much detailes & increases too much the compressibility, so the codec starts 'blocking' in the low luma(noise) ranges. indeed, these almost noiseless clips seem on pc rather like noisy cartoons. contours okay, but almost no shades anywhere. this overfiltration effect i call 'cartoonizing'. some people like this effect (i don't) but it's definitely increases blocking.
- filtering chroma has much less effect on quality than that of luma. it seems not only the human eye is less sensitive to chroma noise :-)
- denoising must be in tune with quant type. say, lighter denoise+h263 is (almost) equivalent to stronger denoise+mpeg. compare() shows some difference but i can't see it on tv.
- hq improves not only the look of dark regions but that of the light ones. it's not as surprising. this mode is intended to 'mpegging' the high quant blocks which are not necessarily dark. say, at the same level of denoising the shot of a(n almost) clear blue sky looks much(!) better with hq than with h263 or hvs. it prompts, we should concentrate on low luma-noise regions. i mean the regions where luma changes gradually & (very) slowly. anyway, blocking in light regions is much less visible than in dark ones (esp on tv). but it's there!
- instead of noise removal i tried noise decreasing. as i'm not aware of any avs filter making it, i merged the clean and the orig (noisy) clip. at some combination of merging weight and filter strength the look is almost what i want. however, these factors must be tuned very carfully. so as to make it less tedious, i suggest to examine the noise patterns removed by the filters. it's quite easy and straightforward with vd_avs. i used a script like this.

orig=avisource(clip)
filt=filter(orig,args)
subtract(orig,filt)

replace clip/filter()/args with the appropriate names. it gives back the noise removed, imposed in a flat mid-grey background. for improving contrast, u can add levels at the end.

- btw, levels() is always decreases blocking even if no denoising is applied. i used levels(~16,1,~240,0,255). when using symmetrical expansion, it doesn't decrease the average brightness. i guess, the effect is very similar to 'over-sharpen', as it increses the contrasts all over the frame. anyway, it's more effective with noise-decrease than wout & it improves the look of slightly noisy clips than that of the 'mirror-cleaned'. (so, it may help with dvd-like sources too)

that's what i have so far. pls, comment/criticize as heavy as u want. just to make it clear; i have very noisy sources, i take it intendly + i don't think that any of the aboves would be a general conclusion. we have no 'ultimate solutions' or 'magic sticks' (i think, we'll never have:-)

y

[iago]

hello again,

I tested TemporalSoften(1,5,25) with MPEG quantization on a longish chapter of U-Turn which I find representative of the whole movie, (Btw, it is a very hard-to-compress source that has almost all the features to force the limits of a codec and includes a good deal of source grain/noise) just to see its (possible negative) effects due to chroma filtering. I think/agree that TemporalSoften(1,5,0) will do well on "most" sources, filtering luma lightly and increasing compressibility without hurting details, especially when used with MPEG quantization.

When I tried to filter luma a bit heavier with TemporalSoften(1,~10,0), the result really turned out to be crappy. However, TemporalSoften(1,5,25) also worked very well with this source, without decreasing the quality, and it brought some additional increase in compressibility due to chroma filtering too.

Some pre-work and analyzing/testing on our sources with some different filtering and encoding parameters before we start the actual encoding process will always be really useful imho.

I think the most important factor that determines "how and with what parameters" we will apply filtering is nothing but the source itself.

best regards,
iago

[Didée]

U-turn really was 'fun' to encode - and the fact it was a TV-cap made things not easier.

More onTopic:
I have to check this one again for darkblocks - I didn´t bother by that time.
BUT I remember EXACTLY that, in few scenes, some large shadows (in high contrast scenes) turned sometimes to greenish, up to next KF. Hah, caught!
(And the raw cap was already deleted when I realized...scream!!)

[yaz]

hi all !

@iago:
use tempsoft() only if your source has really temp-noise. in general, the filter must(should) be fitted to the noise intended to remove. problems :
- what to call noise? the noise is an integral part of the picture holding relevant information/details.
- how to characterize it? i mean its distribution/character along (at least) the time&space scale. anyway, i would appreciate other characterizations too.
as i'm not aware of any tool for that,
-i use that small script (outlined in my former post). it doesn't characterize the noise but makes visible that part of the picture the filter would change/remove. i try it for all filter having any sense to use, all alone & in chain. yeah, it's a bit tedious, but it's worth.
-i prefer decreasing the noise instead of its complete removal esp with heavy noise. its complete removal turns the look almost as ugly as the original.

tempsoft(>5) is a heavy weapon. ghosting/edge degradation/tiling/fake chroma/... , some examples i've faced.
try filtering Y&U(V) separately & in this order. in most instances, a proper luma filtering makes quite unnecessary the chroma filter. if needed, a reverse order is better. filter chroma 1st & then luma. a step-by-step approach works much better than doing all at once.
say, compare tempsoft(1,x,y) with tempsoft(1,0,y).tempsoft(1,x,0) ! sometimes there is a significant difference.

@Didée
greenish fake can be caused by many different sources : ivtc problems, side-effect of luma filter, chroma filter scaled improperly, some filter have such kinda side effect (say, earlier versions of resizers did it). make a step-by-step investigation by removing/replacing the filters in the chain. if it does not help, try to change the args one-by-one.

y

[Didée]

yaz,

I still have the script, but not the source ...

BUT I am almost sure that this was one of the (very, very) few cases where I used lumi-masking!
Seems lumi-masking and me will never become friends ...

[trbarry]

I'm still wondering if this is some sort of coring issue. If the blocks are only a problem on TV's then it may be that some TV's have a problem with displaying values < 16. (blacker than black)

If so then it would be a simple matter to just handle it during output. Optionally ffdshow could have an option to change all values less than 16 (luma, chroma?) to either 0 or 16. I'm not sure which one, probably 16.

But that way clips that really were supposed to be in PC Scale (Full Luma Range) would still display properly on VGA. And it only takes about 3 assembler instructions to force 8 pixels to either 0 or 16 if they are below that.

What I'm really wondering is if due to luma masking or some other processing you can have black (at 16) blocks fall below the threshhold, amplifying small changes. But if that's what is happening it could be easily fixed with a display time option.

It might be an interesting experiment, but one I can't do here.

- Tom

[Marc FD]

ffdshow new levels filter is exactly what i needed. :devil:
it's the ultimate solution for TV ouput :cool:

[kilg0r3]

@marcFD

how do you configure it for tv?

[yaz]

hi all !

Originally posted by trbarry
I'm still wondering if this is some sort of coring issue. If the blocks are only a problem on TV's then it may be that some TV's have a problem with displaying values < 16. (blacker than black)
If so then it would be a simple matter to just handle it during output. Optionally ffdshow could have an option to change all values less than 16 (luma, chroma?) to either 0 or 16. I'm not sure which one, probably 16. ...


yes/no (again) most(!) tvs have such kinda luma scaling problem. i'm not an expert of it but as some guys explained it (years ago) it's a problem of different spread of scales. the luma scale on (most) tv is narrower(~224) than on pc(~256). dunno whether it still holds true, but i have the same tv as was that time :-)
in add, there can be many other sources. just think of the way the picture gets to the tv screen. player/decoder/tvout driver(s)/card driver(s)/... most of us have also a vcr somewhere along the line.
the tvo card itself can generate such blocks. once we tested 3 different tvo cards and they were quite different as regards look on tv. say, my good old asus is xtremly good in blocking. & there's the ever problem of support. cards having good output (~matrox) may be very weak in software support and reversly, good support for weak output (~asus)

(@marc)
postproc levelling is not the same as making it preproc as the latter changes the bit(rate)/quantizer distribution resulting in quite different encodes.

@both of u
would u be so kind to explain me why your filters (mostly unfilter, focus2) give me exceptionals & illegal calls at some settings. (ok, it's offtopic here, but my question washed away with 0 answer in the avisynth forum)

y

[iago]

-> If the blocks are only a problem on TV's then it may be that some TV's have a problem with displaying values < 16 ... (trbarry)

I really have big doubts (or I am almost sure) that the black-blocking issue is NOT only a problem on TVs. TV viewing makes them only more visible than they are on PC monitor.

Say you have an encode displaying black-blocking problem on TV. If you watch this same encode on PC monitor, BUT in a (totally) dark environment and with increased brightness/contrast settings of your monitor (I mean with no self-deception ;)), you can see that those blocks are already there in the encode itself!..

I'm pretty sure of this, since with the LightFrame option of my 17" Philips 107T 21 monitor (even not necessarily in a dark viewing environment) I can create almost the same TV-like viewing conditions and observe the black-blocking issue clearly on my monitor too.

It's more related with the encoding process (of dark/black areas) and codecs' behaviour imho.

best regards,
iago


EDIT: @yaz

Can you please modify the below script so that I can use your denoising routine below that you mentioned before in one of your posts:

orig=avisource(clip)
filt=filter(orig,args)
subtract(orig,filt)

(I really wanna test it, but sorry I couldn't exactly understand how to use the parameters you gave - I'm a bit short of time and overly confused/exhausted due to my working conditions these days ;))

Script:

LoadPlugin("C:\MPEG2DEC_PP\MPEG2Dec3.dll")
mpeg2source("D:\TEST\UTURN\CHAPTER18.d2v",cpu=0)
crop(12,16,696,544)
BicubicResize(640,352,0,0.5)


Modified Script with your routine: ?
(using TemporalSoften or UnFilter(-,-) for example)


Thanks in advance,
and best regards,
iago

[yaz]

Originally posted by iago
-> If the blocks are only a problem on TV's then it may be that some TV's have a problem with displaying values < 16 ... (trbarry)

I really have big doubts (or I am almost sure) that the black-blocking issue is NOT only a problem on TVs. TV viewing makes them only more visible than they are on PC monitor.
...
It's more related with the encoding process (of dark/black areas) and codecs' behaviour imho.


yes, one of its reason is the codec itself. however, if u see that block only under such conditions as u outlined, imho, it's not (so) serious on pc, is it ? :-)

Originally posted by iago
yaz : Can you please modify the below script so that I can use your denoising routine below that you mentioned before in one of your posts:

orig=avisource(clip)
filt=filter(orig,args)
subtract(orig,filt)

(I really wanna test it, but sorry I couldn't exactly understand how to use the parameters you gave - I'm a bit short of time and overly confused/exhausted due to my working conditions these days ;))

Script:

LoadPlugin("C:\MPEG2DEC_PP\MPEG2Dec3.dll")
mpeg2source("D:\TEST\UTURN\CHAPTER18.d2v",cpu=0)
crop(12,16,696,544)
BicubicResize(640,352,0,0.5)

Modified Script with your routine: ?
(using TemporalSoften or UnFilter(-,-) for example)


sorry for my being so ... short :-) try something ...

LoadPlugin("C:\MPEG2DEC_PP\MPEG2Dec3.dll")
orig=mpeg2source("D:\TEST\UTURN\CHAPTER18.d2v",cpu=0)
crop(12,16,696,544)

filt=TemporalSoften(r,t,0)

return subtract(orig,filt).BicubicResize(640,352,0,0.5)

... like this. change r(radius) and t(threshold) to see what tempsoft removes at that certain setting. it is a greyish picture with the noise pattern.

y

ps if u want the 'noise-reductor' i can send it too :-)

[iago]

Originally posted by yaz
yes, one of its reason is the codec itself [...] imho, it's not (so) serious on pc, is it ? :-)@yaz

You're right, as it (hardly) seems (on monitors), it's not so serious on PC :-). But I just wanted to point out once more that the problem is still there if you don't take special care of it by lumoff and/or sharpening etc, though it is much less visible on PC :-).

Btw, I still couldn't make your modified script work: it gives avisynth errors all the time, and I gave in/up in the end (but not without a fight ;)).

And of course I'd be glad to get your noise-reductor.

regards,
iago

[yaz]

Originally posted by iago

...
Btw, I still couldn't make your modified script work: it gives avisynth errors all the time, and I gave in/up in the end (but not without a fight ;)).

And of course I'd be glad to get your noise-reductor.


oops. what kinda 'avisynth error' u got ? ouuyeah, i see, u must (i should have) specify clip for tempsoft. use : TemporalSoften(orig,r,t,0), it must work. (f...me:-(( just to make everything clear, u must put numbers instead of 'r' & 't'. this way tempsoft clears only the luma channel.

noise-reduction :
it goes in the same way, but instead of subtracting u should use MeregLuma/Chroma() or Layer(). say, add this ...
MergeLuma(filt,orig,w)
... to the script, insted of subtract(). here, w is the 'weight' governing what extent orig(inal noise) is merged. it varies 0-1.
another possibility is dnr2(). here u can specify a lower threshold for filtering, thus the low level noise is kept back, so there's no need for post-merge. check it with the 'noise-checker' :-)))

y

[iago]

@yaz

sample script:
--------------------------------------------------------------------
LoadPlugin("C:\PROGRA~1\GORDIA~1\MPEG2Dec3.dll")
orig=mpeg2source("D:\TEST\UTURN\CHAPTER18.d2v",cpu=0).crop(12,16,696,544)
filt=TemporalSoften(orig,1,7,0)
return subtract(orig,filt).BicubicResize(640,352,0,0.5)
--------------------------------------------------------------------

Well, finally I made it work as above :). It's really interesting to see/observe the filtered/removed noise pattern this way, tweaking the radius and luma threshold values of TemporalSoften. Thanks again.

ciao,
iago

[yaz]

@iago :
(it worx:-))

pls,
- read my reply above
- have a look at the '...psychovisual...' thread in avisynth forum. the tool is coming up what we really need :-) my biggest problem at the moment is that i can't make smoothing dependent gradually on luma. amof, i can't make stepwise/thresholded/any kinda smoothing of that kind:-( luma-masking makes terrific artifacts for me.
--there's a vd filter (kcnr?) making the opposite i want, so maybe it's not impossible.
--the 'conditional' filter in vd may help, but actually i don't know how to make it work in avisynth.

y

[JimiK]

Sorry I can't contribute to the latest discussion, but there is an observation I made I want to share. I'm using MarcFDs' mpeg2dec3.dll (beta5). With fast=true, it's really lightning fast, but I observed an increase of blocks in dark areas and unfilter doesn't help. With fast=false everything is O.K.
@MarcFD
In the Avisynth forum you wrote, that you think your memory would be the speed limiting factor. I've also got a AthlonXP 1600+, but only 256Mb SDRam and I also get 50fps. So I think CPU optimization will still help.

Best regards,
JimiK

[kilg0r3]

@Jimik

i think the speed of memeory not the amount is the limiting factor.

[-h]

I just looked at the source from Nic's site, and things could be sped up by using dequantization assembly from XviD (or libavcodec if you want to convert it to nasm format).

I assume transfer and interpolation assembly is inside the .obj files regarding motion compensation?

-h

[JimiK]

I'm sorry I abused this thread. I just wanted to address this to MarcFD and just appended it to my "real" post. Just this before I stop abusing the thread: I think MarcFD also thinks that the speed of his memory is the limiting factor. So I told him I've only got SDRam (he's got DDRRam) and the same CPU and I get the same decoding speed as he does.
I'm afraid I did not understand what -h posted. Was it addressed to what I posted or to some of the post above? Was it posted in the right thread?
-h If you were referring to the stuff I posted: I was not talking about Nic's work. Can XviD (Mpeg4) code be reused to decode Mpeg2? I'm sorry if I got it all wrong.

Sorry again,
JimiK

[iago]

[...] have a look at the '...psychovisual...' thread in avisynth forum. the tool is coming up what we really need :-) my biggest problem at the moment is that i can't make smoothing dependent gradually on luma [...] (yaz)

@yaz,

I've been following the related thread for a while, and I'm really hopeful about the results to come out too. Also, if I'm not mistaken, we're referring to a similar process when I say what we "most urgently" ;) need is an "adaptive/selective denoising" method/filter with the flexibility/option of selecting what areas in the image to denoise depending on the luma levels. (i.e. denoising light/un-dark parts of the image more while keeping the noise as untouched as possible in dark regions.)


@JimiK,

Did you use lumoff (for example "-2") too? And if everything is fine with the default setting (fast=false), it might be a problem occuring due to "fast=true". However, I can't say this for certain since I haven't tried fast=true yet.


best regards,
iago