Dogway's Filters Packs [Archive] - Page 50

DTL

4th May 2023, 11:22

What about setting limit=255? Does it improve denoising? I defaulted limit for !UHDHalf to 2 due to some issues.

Decreasing 'limit' to 2 close of disable degraining at all. It only will process (output denoised) samples of difference about 2 (denoised frame from current frame ?) at 8bit encoding. All other samples of input current frame will be passed to output unchanged (so no denoise for medium and high noise values).

May be decreasing limit to 2 only work somehow good for very low noised 10bit sources. Also setting limit to no-default (255) make performance slower (it is additional post-processing).

LeXXuz

4th May 2023, 12:13

Decreasing 'limit' to 2 close of disable degraining at all. It only will process (output denoised) samples of difference about 2 (denoised frame from current frame ?) at 8bit encoding. All other samples of input current frame will be passed to output unchanged (so no denoise for medium and high noise values).

May be decreasing limit to 2 only work somehow good for very low noised 10bit sources. Also setting limit to no-default (255) make performance slower (it is additional post-processing).

So that's why it keeps much better detail with !uhdhalf, and why my entire screen is red with the mfilter expression, because the setting is way too subtle and it denoises "almost" nothing, hence passing the entire frame over to mfilter.

Dogway

4th May 2023, 12:33

LeXXuz

4th May 2023, 13:22

I think the default in mvtools is 255. What I want you to check is how it behaves for UHD sources (with UHDHalf=false) as I encountered some issues back then. If everything looks fine to you I change it back to 255 as dedault.

I haven't done much with UHD yet. Just tested this because I was curious about more detail preservation anton_foy talked about. I think anton_foy has more experience to tell if this is troublesome or not.

Since we are talking about this. DTL made a lot of interesting commits to mvtools over the past couple of month in his versions. I admit I don't understand a lot of the technical background, but it looks like some good improvements. And the GPU based stuff is interesting of course. Is it a lot of work to get these versions to run with SMDegrain to benefit from their additions?

anton_foy

4th May 2023, 19:05

@Dogway
Wow great params I just replaced smdegrain from 23 feb to the new update. Now experimenting time and I found already alot of nifty tweaks.

@LeXXuz
Regarding DTL's commits they are amazing.
I just would like to get into action with it in HBD and the block overlap that I had problems with causing severe blockiness in higher motion areas. Maybe DTL solved this recently but I must see.

DTL

4th May 2023, 23:22

Since we are talking about this. DTL made a lot of interesting commits to mvtools over the past couple of month in his versions. I admit I don't understand a lot of the technical background, but it looks like some good improvements. And the GPU based stuff is interesting of course. Is it a lot of work to get these versions to run with SMDegrain to benefit from their additions?

My version is mostly working (tested) with 8x8 blocksize and 8bit YV12. Most of other block sizes and bitdepth may not work at all or slow (no SIMD versions of processing).

It is again looks as the very beginning of mvtools of 200x years and it may take more one decade to fix possible crash-bugs and cover some generally used block sizes and bitdepths at least (not all possible with mvtools). But it looks the civilization is dying very quickly and expecting no any developers in 202x may make this. So we possibly will no more have as good freeware developers as were for develop original mvtools to version 2.7.45 in 200x..2020 years.

At mid of 2023 it looks we have about 2..3 users of mvtools and 0 to 1 developers of new features. To the total planet Earth of about 8e9 people. The complexity of MAnalyse+MDegrainN is now may be comparable or approaching to some simple MPEG encoder (like MPEG1 or MPEG2) and having about 0 to 1 developer to the total planet looks like not very promising for nice all-features stable versions releases and quick bugfixes. For the residuals of current dying civilization we have examples of ffmpeg and x26x developing communities (>1 active developers and may be >10) so the users of ffmpeg and x26x encoders may still get good enough stable updates from time to time. For mvtools I not see good enough team of developers to make comparable progress.

The only somehow quick solution to work with original 2.7.45 by pinterf (old features but stable and most block size and bitdepth covered) and 2.7.45+ is to rename all filters in 2.7.45+ like _a (alpha-state) and it will possible to load both 2.7.45 and next builds in same AVS environment (also may be new MDegrainN_a can use old and more stable MAnalyse). Some new features in MDegrainN are not depend on block size and bitdepth.

anton_foy

5th May 2023, 10:17

My version is mostly working (tested) with 8x8 blocksize and 8bit YV12. Most of other block sizes and bitdepth may not work at all or slow (no SIMD versions of processing).

It is again looks as the very beginning of mvtools of 200x years and it may take more one decade to fix possible crash-bugs and cover some generally used block sizes and bitdepths at least (not all possible with mvtools). But it looks the civilization is dying very quickly and expecting no any developers in 202x may make this. So we possibly will no more have as good freeware developers as were for develop original mvtools to version 2.7.45 in 200x..2020 years.

At mid of 2023 it looks we have about 2..3 users of mvtools and 0 to 1 developers of new features. To the total planet Earth of about 8e9 people. The complexity of MAnalyse+MDegrainN is now may be comparable or approaching to some simple MPEG encoder (like MPEG1 or MPEG2) and having about 0 to 1 developer to the total planet looks like not very promising for nice all-features stable versions releases and quick bugfixes. For the residuals of current dying civilization we have examples of ffmpeg and x26x developing communities (>1 active developers and may be >10) so the users of ffmpeg and x26x encoders may still get good enough stable updates from time to time. For mvtools I not see good enough team of developers to make comparable progress.

The only somehow quick solution to work with original 2.7.45 by pinterf (old features but stable and most block size and bitdepth covered) and 2.7.45+ is to rename all filters in 2.7.45+ like _a (alpha-state) and it will possible to load both 2.7.45 and next builds in same AVS environment (also may be new MDegrainN_a can use old and more stable MAnalyse). Some new features in MDegrainN are not depend on block size and bitdepth.

Nevermind the majority, mind the passion. This is going to have impact regardless. But do you think it will take years to bugfix?

EDIT: by the way there are many people using mvtools especially when you count those who use QTGMC and denoising /degraining is not only bound to doom9 forums audience. Part of the pinnacle of denoising is in mvtools IMHO

DTL

5th May 2023, 16:12

" But do you think it will take years to bugfix?"

To find source of crashbug (possibly somewhere in MAnalyse) it may take even minutes if some experienced developer will look into it (also with good debug toolset). But we need >0 developer for it anyway. The pinterf is now busy with AVS core and may not have any time. And as the years going on I not see any more developers interested in mvtools.

But supporting of more blocksizes and bitdepths anyway need to design lots of new SIMD functions and it need time.

So currently we actually have 2 different branches of mvtools - the old all-blocksizes and bitdepths 2.7.45 by pinterf and some post-2.7.45 builds with lots of new features but it work mostly as tech-demo for 8x8 blocksize and 8bit YV12. The list of new features after 2.7.45 somehow implemented and planned is about 45..46 items now. Some are general new ways of processing (MVLPF/MPB/MEL) and may be expanded to many more sub-features. MAnalyse also have some complex planning on SIMD AVX2/AVX512 better performance multi-block processing functions but complex in developing and debugging. But my time for development is limited and my experience in C and C++ programming is poor.

So I understand why Dogway not like to touch such non-stable and no-warranty branch until some 'stable' release.

" there are many people using mvtools especially when you count those who use QTGMC and denoising /degraining is not only bound to doom9 forums audience. "

As I understand they are generally happy with old features of 201x and older and also total home-video creation and processing hype looks like died already at 201x season (today we have close to zero end-users handheld and shoulder-mount video cameras on market) - most end-users are busy with other more important things as the time going on. I also partially busy with development of simple med-ages medicine to be prepared to new 'dark ages' and to keep lives from diseases. Also I got second hit of COVID-19 this spring and need to spend more time on fresh air and money for food to restore health. So it makes even less time for programming at home.

anton_foy

5th May 2023, 16:24

As I understand they are generally happy with old features of 201x and older and also total home-video creation and processing hype looks like died already at 201x season (today we have close to zero end-users handheld and shoulder-mount video cameras on market) - most end-users are busy with other more important things as the time going on. I also partially busy with development of simple med-ages medicine to be prepared to new 'dark ages' and to keep lives from diseases. Also I got second hit of COVID-19 this spring and need to spend more time on fresh air and money for food to restore health. So it makes even less time for programming at home.

Two things; new people are coming on to the Avs+ scene and since AI whilst not sufficient mvtools is and does the job greatly although slow.
Secondly dont get any covoid shot it will damage you. Sorry just had to mention it. Hope I dont get banned.

LeXXuz

5th May 2023, 17:03

Sorry no it is just crazytown. Risk is ONLY getting the shots IMHO. Lost alot of friends over here because of it. But if your DNA is fit it is ok. Im not blaming anybodys choices here but I will NEVER take any of that.

I will NOT jump on this pro/con waggon. But please stop discussing Covid shots. This absolutely does NOT belong here.

anton_foy

5th May 2023, 17:14

I will NOT jump on this pro/con waggon. But please stop discussing Covid shots. This absolutely does NOT belong here.

Very sorry, correctly! I Just found out that the latest update
of smdegrain has indeed improved detail alot but also degraining/denoising is lower. Tweaked some params now to make it more suitable for my fizzy noised footage in UHD :)

Edit: seems like the flat parts are getting less denoised and trying to figure out what params make this.

madey83

5th May 2023, 18:40

Very sorry, correctly! I Just found out that the latest update
of smdegrain has indeed improved detail alot but also degraining/denoising is lower. Tweaked some params now to make it more suitable for my fizzy noised footage in UHD :)

Edit: seems like the flat parts are getting less denoised and trying to figure out what params make this.

hi,

Could you please share your smdegrain call with newbie?

I'm very curious your tweaks...

anton_foy

5th May 2023, 18:44

hi,

Could you please share your smdegrain call with newbie?

I'm very curious your tweaks...

But It its all in the code, see Dogway's github where smdegrain resides.

DTL

5th May 2023, 20:58

Two things; new people are coming on to the Avs+ scene and since AI whilst not sufficient mvtools is and does the job greatly although slow.

I see some still running progress in image processing science in Asian region - so may be some developers from that region may take mvtools and expand support of new features to more blocksizes and bitdepths and fix crashbugs. But may be we need to wait more. I think the European and US part of civilization already left the image processing development (at least as I see with AVS core and plugins development).

Guest

6th May 2023, 05:02

Delete Irrelevant

If you want to delete that post, simply go into "Edit", and choose "Delete", then "Delete Message" (bottom left corner, then the bottom right corner).

Done.

I haven't had any Covid shots....https://www.cosgan.de/images/midi/muede/p0045.gif

Guest

6th May 2023, 07:43

So I updated quite a few filters the other day, and now most scripts that used to work, now have errors, or should I say, "asking" for more "instructions."

Like "bicubic_coeffs", referencing some lines in both Resizers Pack, & SMDegrain.

And "I don't know what 'Lum' means"....

Clearly something has changed. https://www.cosgan.de/images/smilie/konfus/p020.gif

Dogway

6th May 2023, 08:52

Update TransformsPack and ResizersPack.

I finished already my AVS+ updates for the most part unless bugs arise. There's an update for SVM in SimilarityMetrics that I have to revise, and obviously fill more presets in FilmGrain+, aside from that I'm done (and TransformsPack).
We are at a point where AviSynth+ is mature, from the top of my head only the plugins need updates like TIVTC for frameprop support, a TemporalGauss version of TemporalSoften, a performant Hysteresis filter and maybe turn SceneStats into a plugin for a performance increase. Also AvsPmod might see improvements on the sliders side, and the wiki needs a deep update/clean up.

anton_foy

6th May 2023, 09:36

If you want to delete that post, simply go into "Edit", and choose "Delete", then "Delete Message" (bottom left corner, then the bottom right corner).

Done.

I haven't had any Covid shots....https://www.cosgan.de/images/midi/muede/p0045.gif

Done, thanks!

TemporalGauss version of TemporalSoften

Isn't the ex_blur3d(0,0,tr,"weighted",uv=3) that?

DTL

6th May 2023, 10:14

"We are at a point where AviSynth+ is mature,"

For quality processing (up to broadcast/premium) it still very far from. It only about good (stable) for simple non-demandable home-video (may be nowdays poor smartphones-shot). Many core processing and design still use very beginning of digital computers pixel-based imaging solutions. Not sample-based pro-video solutions.

It may look a shame I need to ask developers in 2023 to implement simplest new created transients shaping/conditioning for typical sinc-based channel and as civilization degrades very quiclky only a few persons already can understand why it is required - https://github.com/AviSynth/AviSynthPlus/issues/339 https://github.com/Asd-g/AviSynth-FillBorders/issues/3 .

About mvtools quality at processing non-4:4:4 sources - the precision for subsampled planes data fetching also still not perfect (even in by builds the error only centered but requied 1/2 more shift still not implemented).

Guest

6th May 2023, 10:25

madey83

6th May 2023, 11:16

But It its all in the code, see Dogway's github where smdegrain resides.

i was wondered yours tweaks, not defaults provided by Dogway.

But of course if you would like to not share, fine. :)

anton_foy

6th May 2023, 11:31

i was wondered yours tweaks, not defaults provided by Dogway.

But of course if you would like to not share, fine. :)

Sure I can share it just need some more testing first.

Boulder

6th May 2023, 12:01

In my over 20 years of Avisynth, I would never ever have thought that our biggest problem is the degradation of civilization :D

Honestly, we don't even have commercial 4:4:4 sources to work on so I really don't see the point of complaining that nothing is being developed. After all, Avisynth is mostly an amateur's toolkit. I've seen the early ages of normal Avisynth and the almost 100% working MT branch and we are already very, very far from there.

DTL

6th May 2023, 13:12

Honestly, we don't even have commercial 4:4:4 sources to work on so I really don't see the point of complaining that nothing is being developed.

It mean when current 2.7.45 mvtools run with typical mass-avaialble 4:2:0 content it creates more distorted result (more details degradation and less MPEG-fiendly output). Because spatial precision on fetching chroma planes blocks have both math design errors (error not centered and side-shifted so can reach about double amplitude of possibe in case of centering) and not enough precision (4:2:0 chroma require pel=2 for chroma at pel=1 for luma and luma of pel=4 require pel=8 for chroma). General users very rare see it - but after several years we finally got one perfectionist user and he open issue at github.

The only current workaround possible is to convert 4:2:0 to 4:4:4 and process with mvtools. But that conversion also not lossless and will add distortions.

Additional spatial errors on fetching chroma planes blocks cause more details blurring and also disturb MPEG encoder with qpel precision analysis with more spatial to temporal noise (false motion) to encode.

It is not very complex issue to fix in mvtools but pel=8 better require runtime subshifting and it require design separate SIMD processing functions for each blocksize+bitdepth combination required.

It is general issue of mvtools design so affect all motion-compensated filters members (MDegrain, MCompensate and so on). So generally used QTGMC script also affected.

"our biggest problem is the degradation of civilization"

When we have left about 2 still alive programmers for AVS core and plugins for 8e9 people at the planet to 2023 it looks somehow not very nice. It was expected with progress of computers the number of good programmers will be increase too. The activity on developing of new plugins or expanding features and quality of existed is sort of died too in compare with 200x years season.

LeXXuz

6th May 2023, 13:57

The only current workaround possible is to convert 4:2:0 to 4:4:4 and process with mvtools. But that conversion also not lossless and will add distortions.

Hm. Interesting.
So it would be beneficial to convert to 4:4:4 before filtering with SMDegrain and possibly even encode to 10bit 4:4:4 IF the playback device can handle that format?

And if the playback device can't handle 4:4:4, would a back convert to 4:2:0 before feeding the clip to the encoder 'destroy' all benefits from 4:4:4 processing before?

DTL

6th May 2023, 14:39

"it would be beneficial to convert to 4:4:4 before filtering with SMDegrain and possibly even encode to 10bit 4:4:4 IF the playback device can handle that format?"

Yes.

" would a back convert to 4:2:0 before feeding the clip to the encoder 'destroy' all benefits from 4:4:4 processing before?"

No. The only disadvantage is lower performance (fps) and higher RAM usage. Also may be scaleCSAD need different tweaking for RGB or YUV 4:4:4 processing.

It was already at this thread. https://github.com/pinterf/mvtools/issues/59

anton_foy

6th May 2023, 16:00

https://github.com/AviSynth/AviSynthPlus/blob/master/avs_core/filters/focus.cpp

Here is the TemporalSoften code but someone who knows this maybe can be able to add the TemporalGauss mode to it?

Dogway

6th May 2023, 16:32

Isn't the ex_blur3d(0,0,tr,"weighted",uv=3) that?
Yes, but the lack of SC limits its use.

About processing clips in 444, it would also be interesting in also converting to YCoCg (444) and see the possible benefits. I think this is better done outside with the TransformsPack filters instead of black-boxing it inside SMDegrain.

scaleCSAD in SMDegrain adapts to chroma subsampling and source resolution.

On the topic of AviSynth health it is more used than the four we chat here, people simply don't post or use Staxrip or other frontends. Also from my experience AVS helped me view TheFoundry Nuke in AviSynth eyes and while some things can't be done outside it (like tracking, roto, 3D layering) everything concerning filtering AVS is superior.

For ringing I don't know how feasible it is to use a frequency adapted filter for scaling, like say triangular/hermite for hard edges (255 gradient) and going down to sinc with several taps for low frequencies. It looks like the scaling kernels are always static and not content dependent (aside from NN ones)

Another useful update would be to implement avsresize (or zimg) as the backend for the ConvertTo calls, as shown here (https://forum.doom9.org/showthread.php?p=1979592) its speed is average and could be further improved.

DTL

6th May 2023, 17:59

For ringing I don't know how feasible it is to use a frequency adapted filter for scaling, like say triangular/hermite for hard edges (255 gradient) and going down to sinc with several taps for low frequencies. It looks like the scaling kernels are always static and not content dependent (aside from NN ones)

Simple Gauss kernel for simplest possible shaping/conditioning work nice enough - https://github.com/DTL2020/AviSynth-FillBorders/releases/tag/v_1.1.2_a01 . Though not as sharp as possible with more 'professional' kernels like SinPow/UserDefined2 .

Yes - the performance of equal to ConvertToRGB32 (in planar form) of avsresize is about 2 times better in compare with AVS internal ConvertToRGB32.

LeXXuz

6th May 2023, 20:37

Don't want to get OT, but for anyone interested:

KNLMeansCL runs great on Intel ARC. Got my A770 Limited just today and I'm very happy with its performance so far.

Beyond anything I could achieve with my RTX30x0 boards, thanks to 16GB VRAM and 256bit Membus with ReBAR support. :D

Finally I can run more complex SMDegrain scripts with quite high settings for KNLMeansCL (a=4,d=4,s=8) @ 32 threads, now fully saturating a 5950x CPU.

https://abload.de/thumb/2023-05-06mwe8z.png (https://abload.de/image.php?img=2023-05-06mwe8z.png)

I'm glad I gave it a try and bought one. So, if you use KNLMeansCL very often as prefilter and need a new GPU mostly for video processing and computing, consider an ARC. :)

DTL

6th May 2023, 21:52

Intel cards may be more useful if intel will finally implement support for DX12-ME (possibly with better quality on noised sources in compare with NVIDIA) and with better performance (more pairs frames per second search).

Special ASIC typically significantly outperforms 'universal programming language' implementation via universal programming API.

Also as I see AMD buy Xilinx and start to make some video-accelerators for PC-bus (like PCIe) specific for MPEG encoding - if they finally make support in chip+driver for DX12-ME for Windows it may have very nice performance in MAnalyse task. Alveo MA35D board announced - but still no news about DX12-ME support.

https://www.xilinx.com/applications/data-center/video-imaging/alveo-ma35d.html

Card provide at least 32 1080p60 AV1 stream realtime encoding (16 for 264/265) - it is sort of 2000 frames pairs search per second minimum for FullHD size. Also 8K max res allow to process with lower-pel precision if even main engine provide qpel only. Current old NVIDIA only run at 4096x4096 max. And only 35W passive cooling. The GTX1060 card running much lower DX12-ME performance (about 100 pairs frames search per second) takes about 60W.

Guest

7th May 2023, 04:15

Originally Posted by Dogway
Update TransformsPack and ResizersPack.

I ended up re-updating, all the Transformers, SMDegrain & Resizers, AGAIN, however, I then had to add NNEDI3CL (which had an update of it's own, recently) https://www.cosgan.de/images/smilie/froehlich/a020.gif

And due to whatever has changed, I now have to change/update ALL the scripts I use. https://www.cosgan.de/images/smilie/traurig/a045.gif

LeXXuz

9th May 2023, 10:05

I think the default in mvtools is 255. What I want you to check is how it behaves for UHD sources (with UHDHalf=false) as I encountered some issues back then. If everything looks fine to you I change it back to 255 as dedault.

I'd like to jump back to this for a second.
You mean this limit, right?
limit = Default( limit, md!="MDegrain" ? 255 : isUHD ? 2 : 255 ) # auto-scaled

What exactly does this limit do?
That's a huge gap between 2 and 255. Why so very low and what is meant with automatically scaled?

I'd like to do some more testing with UHDHalf=false one some sources to see how much benefit it may have.

Dogway

9th May 2023, 10:51

DTL

9th May 2023, 11:37

Limiting is post-processing designed to fight some possible artifacts of 'unlimited' denoising. If these artifacts present and visible. It not designed to control denoise-power. So if user see some artifacts and can not remove by other settings - it can enable limiting post-processing (set limit value to < 255).

LeXXuz

9th May 2023, 12:28

It does limit changes larger than a difference of 2. Auto-scaled means the difference will be auto-scaled to working bitdepth.
I was probably working around an issue with excessive denoising for UHD, so try with limit=255 with and without UHDHalf, and then compared to 1080p to check if you see something strange.

Okay. I did some testing with Ridley Scott's Prometheus UHD Blu-ray which is an act of balancing. It has some fine detail but also lots of nasty noise in the blacks. It's not really film grain, but some artificially added noise because of stupidity... eh... pardon me, I meant stylistic reasons of course. :rolleyes:

Anyhow, I uploaded 3 screenshots showing the filtered clip and two with unsuccesfull motion areas enhanced via Expr(). Middle one with UHDHalf=true (SMdegrain default) and the right one with UHDHalf=false, limit=255.
Quite a difference but it shouldn't be overrated, as it just shows that more mv areas have been found in context to the parameters I've used for this test.

https://abload.de/thumb/4k_filtered6ff7h.png (https://abload.de/image.php?img=4k_filtered6ff7h.png) https://abload.de/thumb/4k_mfilter_uhdhalf-tr49ig0.png (https://abload.de/image.php?img=4k_mfilter_uhdhalf-tr49ig0.png) https://abload.de/thumb/4k_mfilter_uhdhalf-fajeflc.png (https://abload.de/image.php?img=4k_mfilter_uhdhalf-fajeflc.png)

Script used:
#
ConvertBits(16)
ConverttoYUV444()
#
Stage=04
#
PRE1 = ConverttoYUV420().DGHDRtoSDR(mode="pq", white=1500, fulldepth=true).ConverttoYUV444().ex_unsharp(-min(0.5,(Stage/30.)))
PRE2 = PRE1.ex_Median(mode="IQMST",Y=3,UV=3).ex_sbr(r=2,UV=3)
PREv = PRE1.Merge(PRE2,(Stage/10.)).ex_unsharp(min(0.5,(Stage/30.)), Fc=width()/1.5).Levels(0,1.2,255*256,(Stage*1.5*256),max(128*256,(278-(Stage*24))*256))
#
SMDegrain(mode="MDegrain", tr=12, DCT=5, thSAD=(Stage*60), thSADc=(Stage*40), thSCD1=(200+(Stage*60)), Str=2.0, contrasharp=true, LFR=(Stage*40), DCTFlicker=true, refinemotion=true, truemotion=false, blksize=16, search=5, pel=2, subpixel=3, mfilter=Expr("81","90","250",scale_inputs="int"), prefilter=PREv, chroma=true, plane=4, gpuid=-1, interlaced=false, UHDHalf=false, limit=255)
#
ex_unsharp(min(0.5,(Stage/30.)), Fc=width()/1.5)
FilmGrainPlus(sharpness=0.5, size=0.05, str=0.05, strc=0)
#
ConverttoYUV420()
Prefetch(32)
Return(Last)

I'm still not sure about that 4:4:4 processing.
I can hardly see any differences and the file sizes are merely the same. Comparing frame by frame you can spot some subtle differences but those differences almost vanish when watching and comparing the clips side by side.
Considering it needs quite more processing power, as expected of course, I'll probably stay with 4:2:0. The tradeoff with encoding speed is not really worth it.

anton_foy

9th May 2023, 14:36

@LeXXuz
444 is mainly for the colors as with full RGB (correct me if Im wrong) but probably there will be very little gain in this case. Luma will be fully processed anyway.

LeXXuz

9th May 2023, 14:38

@LeXXuz
444 is mainly for the colors as with full RGB (correct me if Im wrong) but probably there will be very little gain in this case. Luma will be fully processed anyway.

I know. It might help on some old sources with more unstable colour planes. For this here it's overkill, but I left it in for the test anyway. :)

DTL

9th May 2023, 16:21

" not sure about that 4:4:4 processing.
I can hardly see any differences and the file sizes are merely the same. "

Yes - it is mostly for Die-Hard perfectionists.

LeXXuz

11th May 2023, 09:14

I think the default in mvtools is 255. What I want you to check is how it behaves for UHD sources (with UHDHalf=false) as I encountered some issues back then. If everything looks fine to you I change it back to 255 as dedault.

I've encoded the entire film now with limit=255 and UHDHalf=false. At first glance I can already say anton_foy was right. :)
The filtering quality is way better than with UHDhalf=true. Especially darker and/or low SAD areas have a lot more detail retention while even having more overall noise removal since the filze size got smaller than before.
If I have time, I will watch the entire film tonight.

Anything particular to look out for?

Dogway

11th May 2023, 13:09

I've encoded the entire film now with limit=255 and UHDHalf=false. At first glance I can already say anton_foy was right. :)
The filtering quality is way better than with UHDhalf=true.

Yes, that's a given, the problem was actually limit=255 while keeping the UHDHalf setting. I will run a few tests today and see how it behaves.

EDIT: Ok, this is what's going on. Specially when using UHDHalf=true, and also specially when paired with mode!=MDegrain (although it also shows with mode="MDegrain"), there's some detail warping.
I guess that to minimize this effect I chose to limit changes to no bigger than 2. It still warps details but it's not as exaggerated.
SMDegrain(tr=2, thSAD=400, mode="IQMT", limit=255, UHDHalf=true, prefilter=1, refinemotion=true) # prefilter=2 for UHDHalf=false

Source (3x zoom)
https://i.imgur.com/gec0fjqm.png (https://i.imgur.com/gec0fjq.png)

UHDHalf=false
https://i.imgur.com/F1FW4F6m.png (https://i.imgur.com/F1FW4F6.png)

UHDHalf=true
https://i.imgur.com/mv2qCGAm.png (https://i.imgur.com/mv2qCGA.png)

UHDHalf=true, Limit=2
https://i.imgur.com/l1rNqhRm.png (https://i.imgur.com/l1rNqhR.png)

Guest

12th May 2023, 04:45

SMDegrain(tr=2, thSAD=400, mode="IQMT", limit=255, UHDHalf=true, prefilter=1, refinemotion=true) # prefilter=2 for UHDHalf=false

To my eye's, it's hard to tell them apart...maybe the bottom one...

With the above call, where would be the best line to add them to, in my call, below ?

pre=ex_Median(mode="IQMST",thres=255).DGHDRtoSDR(mode="pq",white=2000)
STTWM(sw=50,tw=50,aw=100,sthres=5,tthres=5)
SMDegrain(tr=2,thSAD=200,thSADC=100,contrasharp=true,prefilter=pre,str=5.0,refinemotion=true)

:thanks:

anton_foy

12th May 2023, 07:23

@Dogway
Great find but I cannot see any images? I tried in two different browsers yet all I see is text.

@LeXXuz
Glad to be of help! Thanks for testing. :)

anton_foy

12th May 2023, 08:14

@FTLOY
Thanks but all I got was this:
https://tinypic.host/i/Screenshot-20230512-091027-Brave.o4eIHh

Btw. Those links are broken for me shows only a "broken image"-symbol. Nevermind.

LeXXuz

12th May 2023, 08:41

Yes, that's a given, the problem was actually limit=255 while keeping the UHDHalf setting. I will run a few tests today and see how it behaves.

EDIT: Ok, this is what's going on. Specially when using UHDHalf=true, and also specially when paired with mode!=MDegrain (although it also shows with mode="MDegrain"), there's some detail warping.
I guess that to minimize this effect I chose to limit changes to no bigger than 2. It still warps details but it's not as exaggerated.

The pictures are working for me and the difference is quite clear to see, I think.

Ah now I get it. Just to be clear, 'cause I think I mixed both modes up a little.

The DEFAULT is UHDHalf=true AND limit=2, right?
UHDHalf was added for performance reasons I guess, but there where some problems with details warping, so you chose to reduce limit to 2.

This does NOT apply to UHDhalf=false, which works fine with the limit of 255, but needs significantly more processing time of course.

But why is the limit still set to 2 with UHDHalf=false? Shouldn't it be set back to 255 automatically when user sets UHDHalf to false?

Personally I don't mind the speed penalty, I just set UHDHalf=false & the default limit=255 (unless it's too strong for some scenarios and I have to reduce it manually) from now on, as the result speaks for itself.

LeXXuz

12th May 2023, 08:50

To my eye's, it's hard to tell them apart...maybe the bottom one...

With the above call, where would be the best line to add them to, in my call, below ?

pre=ex_Median(mode="IQMST",thres=255).DGHDRtoSDR(mode="pq",white=2000)
STTWM(sw=50,tw=50,aw=100,sthres=5,tthres=5)
SMDegrain(tr=2,thSAD=200,thSADC=100,contrasharp=true,prefilter=pre,str=5.0,refinemotion=true)

:thanks:

You don't have to change anything in your script regarding UHDHalf unless you want more quality at the cost of a hefty speed penalty. Then you'll have to add UHDHalf=false, limit=255 to your SMDegrain call.

Btw. I would do the tone mapping first with DGHDRtoSDR before filtering the prefilter clip with ex_Median.
pre=DGHDRtoSDR(mode="pq",white=2000).ex_Median(mode="IQMST",thres=255)