Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
22nd January 2022, 17:51 | #21 | Link |
Registered User
Join Date: May 2018
Posts: 184
|
hello_hello Thanks for the heads-up. I'll check it out.
From what I remember of my past testings:
Last edited by takla; 22nd January 2022 at 17:55. |
22nd January 2022, 21:44 | #22 | Link |
Registered User
Join Date: Jul 2018
Posts: 1,070
|
"Changed chroma=true to chroma=false which is also what BM3D defaults to. This change increases speed by ~50%."
It is good to add to documentation: Using chroma=false in MAnalyse may result in different colors blended blocks (with close luma values). Though it is rare enough. Disabling chroma in MDegrain typically cause great degrading of degrain ratio (increase MPEG out speed with same crf in x264 for example). If you need the more 'faster' modes - you can also set overlap to 0. It may increase speed to several times in compare with default blocksize/2 but will add some blockiness at some areas (typically with fast moving low detailed motion like fire/smoke). |
22nd January 2022, 22:40 | #23 | Link |
HeartlessS Usurer
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
|
Overlap = 0 is of course faster but quality of result is quite bad in comparison, suggest at least Overlap=2.
Gettin' the wrong answer faster is not always the best way to go. EDIT: Although I believe in days (hopefully) long gone, some Cray Computers used to sacrifice [EDIT: a lot of] precision/correctness for speed. (they may have gotten the wrong answers, but they did it incredibly quickly)
__________________
I sometimes post sober. StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace "Some infinities are bigger than other infinities", but how many of them are infinitely bigger ??? Last edited by StainlessS; 23rd January 2022 at 10:18. |
23rd January 2022, 10:38 | #24 | Link |
Registered User
Join Date: May 2018
Posts: 184
|
DTL I don't see how chroma would be affected when it is never processed?
And I have to agree with StainlessS here. Personally, I'd never use overlap=0. It destroys quality. Some speed-ups make sense, like chroma=false for HD sources. hello_hello So I ran some tests
Last edited by takla; 23rd January 2022 at 10:41. |
23rd January 2022, 13:41 | #25 | Link |
Registered User
Join Date: Jul 2018
Posts: 1,070
|
"how chroma would be affected when it is never processed?"
In the EZdenoise_v2 user can enable chroma processing. But it have not separation of chroma for MAnalyse only or for MAnalyse + MDegrain. So it either lowest quality or lowest speed. There possible in-between way with chroma enabled for degraining but disabled for MVs search. It is faster with higher quality in compare with totally disabled chroma. Also with enabled chroma for MAnalyse and typical YV12 data format there is many posts about useful increasing scaleCSAD value of MAnalyse param from default 0 to 1 or may be even 2 (max currently allowed). Adjusting of scaleCSAD if almost free for speed/performance but may visibly change degraining quality (output MPEG speed). Adjusting scaleCSAD may require re-tune of thSAD param. May be it is better to make some 'presets' in the input param so user can not think of more and more input params and its values but simply select from a set of pre-defined speed/quality presets ? The current combination of MAnalyse+Mdegrain allow to create about 10 or many more different speed/quality presets easily. Even with left to user-input 'required' control values like tr and thSAD. So the discussion will be mostly about internal script params for each preset. And not scare user of the script with tons of params to setup. I see currently low-experienced users are much more like to set some one 'human-readable' named preset instead of thinking of lots of magic numerical params. User may need a year of everyday thinking and experimenting to get more experienced and level-up in the numerical params setup of 'complex denoiser'. The x264 encoder with tons of params also have some named speed/quality presets. Last edited by DTL; 23rd January 2022 at 13:55. |
23rd January 2022, 14:35 | #26 | Link |
Registered User
Join Date: May 2018
Posts: 184
|
Ohh I see. Ok. I'll run some more tests.
And yes, I've been thinking about presets. It also came to my mind when I tested your MVtools fork. optSearchOption & optPredictorType is what I'm talking about. They could be merged into a "Preset" syntax. |
23rd January 2022, 19:05 | #27 | Link | ||
Registered User
Join Date: Mar 2011
Posts: 4,829
|
Quote:
Having said that, I ran a few quick tests using AVSMeter and a few different MDegrainNL settings (changing TR and BLKSize), with and without TrueMotion, and the result was a consistent 1% faster when TrueMotion was enabled, but I was only testing using a SD source and my computer's a bit old. Quote:
38.49fps ConvertBits(16) MDegrainNL(MT=true, TR=2, SearchBits=8) Trim(1000,1999) 30.19fps ConvertBits(16) MDegrainNL(MT=true, TR=2) Trim(1000,1999) 20.47fps ConvertBits(16) MDegrainNL(MT=true, BLKSize=8, TR=2, SearchBits=8) Trim(1000,1999) 17.61fps ConvertBits(16) MDegrainNL(MT=true, BLKSize=8, TR=2) Trim(1000,1999) What difference it makes to the degraining, I'll confess I haven't checked, as I rarely work with high bitdepth sources. If the above is any indication maybe as the block size decreases the speed increase decreases too. I couldn't tell you in file size, but I was degraining some noisy animation when I tried the YUV=full thing, and I thought it offered a slight improvement. Not anything you'd probably notice until you compared still frames, but I figured it's virtually free so I kept it. Last edited by hello_hello; 23rd January 2022 at 19:41. |
||
23rd January 2022, 21:17 | #28 | Link |
Registered User
Join Date: May 2018
Posts: 184
|
hello_hello
TrueMotion=false is 5.6% slower in my testings. But I'm testing with actual encodings and I'd recommend you do the same. On SearchBits, my CPU (Ryzen 9 3900x) still has plenty of room to spare even with Prefetch(12) and when encoding FFV1. I think that is why I don't see any speed difference from there. |
23rd January 2022, 23:21 | #29 | Link | |
Registered User
Join Date: Mar 2011
Posts: 4,829
|
Quote:
Yes, it sounds like FFV1 encoding is the bottleneck, but that's why it's better to test things individually. |
|
30th May 2022, 23:55 | #31 | Link |
Registered User
Join Date: May 2018
Posts: 184
|
Updated OP.
Did some more tests. EZdenoise is now literally twice as fast as BM3D_CPU all while retaining more details. Amazing. And for future reference, I will only ever test speed with real videos, using real encodings with FFMPEG. No more ColorBars etc. |
31st May 2022, 23:37 | #32 | Link |
Registered User
Join Date: Jul 2018
Posts: 1,070
|
"Chroma: I recommend you only enable this if your video has visible chroma noise. It is much slower if set to true."
It is good to separate chroma in MAnalyse from chroma in MDegrain. If some speedup is important and quality is not visibly degraded chroma may be disabled for MAnalyse. But if disabling chroma in MDegrain (it uses chroma from MSuper) is greatly reduce degraining. So it may be better to have 2 control params - chroma for analyse and chroma for degrain. For best quality - both enabled. For best speed - both disabled. Though they are not freely controlled. Valid is only 3 of 4 combinations: Chroma analyse false, chroma degrain false. Chroma analyse true, chroma degrain true. Chroma analyse false, chroma degrain true. Chroma analyse true, chroma degrain false. - invalid. |
1st June 2022, 01:20 | #33 | Link |
Registered User
Join Date: May 2018
Posts: 184
|
In my testings, using lossless FFV1, looking at single frames, there was no difference between Chroma=True/False.
So the only difference for me was speed. I also tested different true/false configurations of super & analyse and concluded, that having two settings instead of one wasn't worth it. Even if chroma=false in theory removes less noise (which I cannot see in my testings), using a lossy encoding removes noise too and so the challenge becomes to remove just enough noise and leave some for the video encoder or else it will not distribute enough bits for very fine details. Last edited by takla; 1st June 2022 at 01:24. |
1st June 2022, 07:30 | #37 | Link |
Registered User
Join Date: Jul 2018
Posts: 1,070
|
It looks internal default thSAD of 150 too low for medium noise SD footages. The old mvtools default is about 400. It is the main param that user must adjust for each given footage to get best ratio of denoise/blur. Unfortunately currently there is no auto-adjustment implemented.
|
1st June 2022, 08:27 | #38 | Link | |
Registered User
Join Date: May 2018
Posts: 184
|
Quote:
Denoised I used frame 72 as the screenshot. Exact parameters used: Code:
LWLibavVideoSource("C:\Users\Admin\Downloads\1234.ts") Crop(2, 4, -2, -0) Spline36Resize(720, 540) EZdenoise(thSAD=400, TR=4, Chroma=true) Prefetch(12, 48) Note: Images were taken with EZdenoise_v3 Last edited by takla; 1st June 2022 at 10:28. |
|
1st June 2022, 11:15 | #40 | Link |
Registered User
Join Date: Jul 2018
Posts: 1,070
|
One possible way to estimate initial thSAD value is to get MVs for single frame delta and add MShow(showsad=true) and run through footage a bit. It will show 2 numbers at the top left corner and first number is the mean SAD of blocks in frame. So initial thSAD for denoise should be as bit higher (like mean SAD * 1.2..1.5).
I typically use like this: Code:
super = MSuper(pel=1, mt=false) forward_vec1 = MAnalyse(super, isb = false, chroma=false, delta = 1, mt=false) MShow(super, showsad=true, forward_vec1, thSCD1=2000, thSCD2=2000) You may add it as service function MeasureSAD(). So typical workflow is: 1. Run MeasureSAD() function to look for mean SAD of footage. 2. Setup initial EZdenoize param of thSAD ~ mean SAD * 1.5 3. Adjust TR param to get initial required speed/denoise ratio. 4. Make recursive adjustments of thSAD and TR to finetune denoise/blur/speed ratios. For this test anime sample mean SAD is about 180..190 so the minimum working thSAD to start MDegrain working should be about 200..250+. Last edited by DTL; 1st June 2022 at 11:40. |
|
|