Dark scenes unnatural, surfaces producing a rippling effect ?
 

There is a thread in the Optimal Scripts forum dealing with "unnatural" surfaces producing a rippling effect using the old MA script. Dialhot made some suggestions about using the "new" Deen 1.0 beta (which has actually been around since August 03 and linked on http://www.avisynth.org/warpenterprises/). I PM'd him about a script using this new deen for AVI sources and here's what he sent me:

I tried this out on an hdtv capture I have in xvid format, and there are some major problems during dark scenes. For example, where there should be a clear black night sky there is instead dancing dark blue bloches. I then went out to test the other AVI optimal scripts and found that v3 and v4 were just as bad. Only v1 and v2 handled these dark scenes better, but at the sacrifice of less compression and (I think) some detail loss.

Here is a short clip of the scene in question. I invite you all to test them out for yourself and if someone can come up with a good alternative script PLEASE let me know!!! Thanks! :D

http://qlink.queensu.ca/~7jw6/chunk_1.avi

Re: Dark scenes
 

The site is currently done so I can't check but are your SURE that this site link to the NEW deen qnd not the one from 2002 ?

Did you try to add the second blockbuster line like in the V4 script ?

Hi Dialhot. Yes I know the site was down but I accessed a cached version while doing a google search and the link for deen was dated 8-03. I did add the second blockbuster line to v3 and v4 but i still think v1 handles these dark scenes better (it already includes two blockbuster lines). but as I said there is some detail lost.

On another note, I gave Mencode-ME a try using the predefined AVI filtering and it did an amazing job in these dark scenes. I find there is always blockiness no matter what incarnation of your avi optimal script I try, but with mencoder there is a general "spray" of pixelation. Not too sure how to describe it... but the problem with mencoder is there is a definite loss in sharpness and detail. Perhaps you could give it a try on the sample I included and see for yourself what I mean?

Hoping you might be able to help... thanks!

Check all my post where I used the word "grainy" and you will see that what you find interesting there is for me a big default in all mencoder output. But you have the right to like pictures shouted in a sand storm :-)

Under mencoder ? non way ! But I will try to find what can explained that V1 is better that V4 on this problem. I'll tell you.

J-Wo: I saw the sample clip that you put on. There doesn't appear to be any "dancing dark blue blotches" as you mentioned, but there is definetly a "graininess" to your video. Other than that i can't see anything wrong with it.

The sample clip is the offending dark scene from the ORIGINAL avi file. So what you need to do is try v3 or v4 script to see the "dancing blue blotches". I used CCE for encoding at Q=15, min/max bitrate = 64/4500, quantizer charactistic = 17. I am encoding for KDVD, so I compiled using DVD-Lab Pro beta 4. Here is an example of the v4 script I used:

Misty Scenes
 

I am using DIKO which essentially is using the Dialhotv4 avs script.
I have similar "wet-paint" problem when converting a thriller movie AVI clip. The moive was converted in CCE using Max Bitrate= 7000 bps, QC=25 and Q Factor=1. The AVI was an xvid with bitrate=900kps. The output KDVD Video stream was 2.5GB for 80 mins.

The movie has a lot of dark and misty scenes and the result is that all the details and texture of hairs and actors' faces become wet-paint. I think it is a consequence of over-filtering. I thought Deen() was a solution but from this thread it seems not. :(

Will removing the temporal dimension totally solve this wet-paint problem?

Could anyone suggest filters/scripts that can deal better with low bitrate and dark scenes. Or parameters in CCE that can improve the encoding.

Re: Misty Scenes
 

It should at least reduce it.
As told in private to J-Who you can also try with temporalcleaner insteed of temporalsoften. I didn't have tilme to do some tests on his current problem yet.

If you are using full DVD reso from an avi source, just forget.

I've been using a script like this for AVI sources and have had no problems:

I try to avoid temporal filtering with AVI sources if possible. The sources are usually without any extensive grain so only light filtering is needed. I also prefer codec postprocessing since I trust it does a better job than MarcFD's BlindPP. The codec gets the quantizers directly from the clip whereas BlindPP only guesstimates.

thanks for the suggestions boulder, i'll give them a try. could you tell me a bit more about codec postprocessing? I'm pretty sure I had all mine turned off. Which ones do you enable and at what settings please? Thanks!

Thank U Dialhot,

I just found the following in CCE manaul which may help to reduce the wet-paint effect:
According to the manual, for dark scenes CCE's QC should be set to higher value to reduce the contouring noise. Will give it a try :wink:

J-Wo,

I set the postprocessing in DivX at max deblocking, no deringing. Automatic post-proc adjust, both disabled. Film effect disabled. In quality settings, YUV extended mode and Disable logo ticked, others unticked. The DivX team released an updated version with some bugfixes in the decoder some time ago but they didn't change the version number. I think the latest one is v5.1.1 build 1031.

In XviD (Koepi's v1.0.1) I have deblocking for Y and UV ticked and output colorspace set as YV12. All the others are not ticked.

In CCE I've got 28 as the quantizer characteristics.

great suggestions boulder, I'll give them a try!

In your script, I was wondering if the last two lines are needed. For some reason I have never needed a converttoyuy2() or converttoyv12() at the end of my script using CCE, I have no idea why! If I can avoid colorspace conversions, I should if at all possible right? And finally is the limiter() line necessary? I've stopped using that one a long time ago based on some previous suggestions. Just wondering why you include it. Thanks!

CCE 2.50 can't work in other thing than YUY2 and need this line.
With CCE 2.6 and above, the line is no more necessary.

I've found out that CCE still needs YUY2 data, it's just that some codec does the YV12->YUY2 conversion - most likely XviD. I don't trust that so I do the conversion in the script. You can check the registry to find out which codec does the conversion, it can be found at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Drivers32 . See if there's a string vidc.yv12 and what the value is, I've got xvidvfw.dll. On a side note, I also edited vidc.yuy2 and placed huffyuv.dll there as from what I know, msyuv.dll is a bit buggy.

What comes to Limiter(), I've never had any problems.

Okay, I did a bit of testing and found that I actually get the best results with the v2 script (I previously might have mentioned v1 but I think I was wrong). Surfaces such as skies, fog, walls etc appear grainy and pixelated, which I find actually GOOD. With v2 the graininess is somewhat stable which is another good thing. With all other incarnations of avi scripts, instead of a grainy/pixelated surface I see largish blocks of colour or a rippling effect that dances around a bit, distracting the eye. I also don't like to enable post-processing in divx/xvid codec, I find the result is a little "overprocessed" and these flat surfaces don't look as good.

I'm trying to do a QC test in CCE to find that qc value is the best. To be honest I could tell a whole lot of difference from qc=10 to qc=28, except that the higher qc goes the more compression you get. Anyone got some suggestions?

here's the v2 script I'm using right now

Hi J-wo
I am also working hard to eliminate the wet-paint effect. I did some search and found that contouring noise & DCT occurs when the encoder compresses too much or the area has too few details.

One rescue is to add noise to the scene to increase the details. This coincides with your findings that V1 & V2 work better because in their scripts the BLOCKBUSTER line has max_detail=8, which add noises more generally to the frame. The V4 version has max_detail=3, making less areas are subjected to BLOCKBUSTER.

You can also add dithered noise in CCE as there is a "dither quantization" parameter.

Maybe Dialhot can advise whether adding
or to the script is a good idea to increase the details.

BTW I did some experience this morining and was much puzzled by the result. I used a script which essentially contained only resize up (GRIPFIT and GRIPCROP) and viewed the avs in VDub, prominent wet-paint effect was already very visible. The wet-paint was not there when I put the original avi in VDub. The only difference was resize. I knew that my clip was of low bitrate (around 900kps xvid) but this result was not expected as I assumed that the wet-paint was coming from other filters. Now it wasn't the case :oops:
Can someone confirm resize up will always introduce contouring noise? Will different resize methods matter? :roll:

And you didn't asked yourself why there is a second (optional) blockbuster line in my V3 and V4 script ? :-) You just agree with what was I found in my tests some months ago :lol: The second line as a max_detail set to 10.

No way. This filter gives nothing but crap. I never used it, I'll never do.

Why don't you do the test and give us the result ?
What resizer did you use in your test when you see that this is the possible source of the painting effect ?

From my own testing, these dark scenes are handled better by the v2 script than either v3 or v4 with both BB lines. It's hard to describe, but v2 makes surfaces like walls appear less blocky, has less dancing squares, it just looks "better" in my opinion. But the downside is edges are much softer and there is a lacking of detail on objects.

I'm hoping that thru my feedback you might be able to provide some suggestions to help tweak v2 a little bit, or perhaps make some updates to your v4 script. Thanks!

The purpose of V3 and more over V4 is that it should give the same results on the flat area than V2 but with less loss in the details. But you probably found a tricky source :-)

Can you test this "old" V2 but with "Deen()" insteed of the ATC line ?
(I'm still talking about the new deen, the one from august 2003).

I tested the script line by line and found the cause of my wet-paint effect was the ConvertToYUY2.
I followed the suggestion of Boulder's here to change to xvidvfw.dll and huffyuv.dll for YV12 and YUY but the result was the same.

I am using CCE 2.67 SP, which according to some reply here, accepts only YUY2 colorspace.

DIKO generates and requires YV12 at the beginning. Converting to YUY2 leads to wet-paint. Does it mean that I am stuck :x

I am curious why nobody else encounter this problem when changing from YV12->YUY2 :?:

Yes it is but as you installed Xvid you can REMOVE the line convertToYUY2 and let Xvid do the job. Boulder says it's better with avisynth but perhaps you will proof the opposite.

Personally I (try to...) NEVER use any convertTo... in my scripts :!:

Okay I did a LOT more testing (my god it can never end!). Yes, I found Deen as a replacement for ATC in V2 script to be a big improvement. The graininess in v2 is very widespread, and while I think it's great for unnatural surfaces it disturbs foreground images like people's faces. Deen helped to smooth that out. So then I went *back* to V4 and added the 2nd blockbuster line as you suggested, and now I take back what I said and think v4 *is* better, not only on details but also in compression :). Moreover, I replaced the Convolution3D line with Deen in V4, and I think that helped even more with compression and the appearance of natural surfaces. And finally I added Limiter() to the end of my script. I don't think I could tell a large difference with it or not in my encodes, but it did reduce file size again.

So currently, here is my "modified" V4 script. Dialhot if you got any more suggestions please let me know!:

I agree with Dialhot here, Uruk-Hai. I just let the codec do it as stated earlier and there's no need for it in my scripts. Haven't tried disabling it though and see if Avisynth does it better though...

:lol:
Remove the "limiter" and you have the script I personally use for all my jobs since I discovered the new Deen (5 month ago perhaps ?).

Okay, I never spoke about that, sorry :-p .
(note : I never had problem with the "official" V4 so a modification wasn't so urgent).

HAhaha okay, that's a coincidence. Could you please tell me why you don't use Limiter but others do? What are the pros/cons? Thanx.

edit: oh wait, never mind, found it! :D
http://www.kvcd.net/forum/viewtopic.php?t=9994

I did find though that compression was better with limiter() at the end... so with that being said, perhaps it does have some merit? :?:

Because I don't like to do something that is useless. But things changed a little (for others, not for me).

At first, the goal of limiter was to restraint the luma in the range [16-235] because the TV set are supposed to be hurted by extrem values (even if that is not true since years but habits are habits...).

THIS is useless : CCE, Tmpgenc, Mainconcept... all the encoder we use already clip the luma in this range by default ! So no need to have a filter to do that.

After a long time, people started to agree with that and limiter was removed form the optimal script for instance.

NOW the limiter filter is saw as an way to reduce the file size, as many other filter we use in fact, AND it was reintroduced in the script for this purpose. Just like you do.

But I'm not sure it's so harmless on the result (the "dark green blacks" phenomena is probably due to this limiter...)

excellent answer my friend. I'm giving the modified V4 script with Deen() a try now. Please keep us posted on any suggestions/update you come up with! They are no doubt invaluable to us all.

reply
 

well, well, :D
thead very interesting....
I will use yours script if I can.....
And I would to know when to use the second blokbuster in the script.

thank you very much..


byby

You mean dark grey, right? The borders that are added in the Avisynth script are actually dark grey as their luma value is probably 16 :!:

@zagor
Hum... it's hard to say exactly when. The problem is that you need to doa test for that.
In fact, personally, as I always use CQMatic to calculate the CQ, I look at the sample that it left on the disk at the end of its work. Then I look into the dark areas to see if there is "dancing" block in the flat areas (these are the so called "DCT blocks"). If there is, I do again the process with the second line.

@boulder
For some people they appear dark green, and I never understood why. Probably a matter of wrong gain on the Green component in their TV.
(you can also change the gain indivually for each color on your PC monitor, you see what I mean ?).

For the borders, that's true that when we tried to see if tmgpenc does clip or scale of the luma into the range [16-235] we discovered that all internal commands of avisynth ouptut in that range ! Impossible to generate a true dark (luma=0) even with the command "blackclip" :!:

Yes, it's probably related to some wrong settings. I've never had such behaviour. Black is black is dark grey :lol:

That's true, I also found that out a long time ago, trying to get pure black out of Avisynth.

reply
 

please, can you tell me if your dll is this?

deen.dll 245.760 byte

In the readme file is call:

(Deen 1.0 beta 1)


thanks


by

This is the correct one.