Doom9's Forum - View Single Post

DTL · 31st May 2022, 12:06

Here is a test build for testing : (Updated )

It have optimizations disabled for 16bit (>8bit) SAD functions. Currently it is the only fast way to save from crash in release build. Debug build works but too slow and can not show the source of crash. May process slower. I hope no other (8bit) processing speed of MAnalyse is touched. It is fast but not perfect fix. Also as a bonus it have 2 C++ builds for SSE2 and AVX2 CPUs. May be AVX2 is a bit faster at AVX2 CPU.

If testing will be acceptable I will place next pre-release to github.

About not bit-exact results with old 2.7.45 - it may be one of many small changes to MDegrainN finally works a bit different to old release. Will try to look later.

Update: https://drive.google.com/file/d/1lkm...ew?usp=sharing

It is even more strange - the crash happens only with SSE2-targeted build inside SSE2 intrinsic-based function. With AVX2-targeted it looks working with all optimizations enabled. It may be some complex bug inside mvtools or in current used version of MSVS compiler ? So in updated archive link the SSE2 build is with optimizations for SAD >8 bit disabled and AVX2 build is 'normal'.

"thSAD2=thSAD/2"

I do not think it is good internal default. Typically thSAD should be 'just a small above noise level' . So setting thSAD2 too low by default you either lost many useful frames in tr-scope or force user to increase tr-value too high to have more neibour frames being covered with high enough thSAD near current frame (and it will cause slower speed processing). If user will raise thSAD high enough to get thSAD2 not too small - it may cause additional blurring or detail lost. I typically set thSAD2 manually just a few below thSAD. In float math it is about thSAD2=0.9*thSAD. I not test how it processed by AVS+ scripting. May be ToInt(0.9*thSAD) required if MDegrain will not accept float value or something else. Or let user to enter thSAD2 and thSADC2 too. I think the feature to allow lower thSAD at the edges of tr-range is mostly to decrease artifacts if artifacts happens. If not - the best for denoising and speed with current tr-value is thSAD2 close to thSAD.

31st May 2022, 12:06	#125 \| Link
DTL Registered User Join Date: Jul 2018 Posts: 1,057	Here is a test build for testing : (Updated ) It have optimizations disabled for 16bit (>8bit) SAD functions. Currently it is the only fast way to save from crash in release build. Debug build works but too slow and can not show the source of crash. May process slower. I hope no other (8bit) processing speed of MAnalyse is touched. It is fast but not perfect fix. Also as a bonus it have 2 C++ builds for SSE2 and AVX2 CPUs. May be AVX2 is a bit faster at AVX2 CPU. If testing will be acceptable I will place next pre-release to github. About not bit-exact results with old 2.7.45 - it may be one of many small changes to MDegrainN finally works a bit different to old release. Will try to look later. Update: https://drive.google.com/file/d/1lkm...ew?usp=sharing It is even more strange - the crash happens only with SSE2-targeted build inside SSE2 intrinsic-based function. With AVX2-targeted it looks working with all optimizations enabled. It may be some complex bug inside mvtools or in current used version of MSVS compiler ? So in updated archive link the SSE2 build is with optimizations for SAD >8 bit disabled and AVX2 build is 'normal'. "thSAD2=thSAD/2" I do not think it is good internal default. Typically thSAD should be 'just a small above noise level' . So setting thSAD2 too low by default you either lost many useful frames in tr-scope or force user to increase tr-value too high to have more neibour frames being covered with high enough thSAD near current frame (and it will cause slower speed processing). If user will raise thSAD high enough to get thSAD2 not too small - it may cause additional blurring or detail lost. I typically set thSAD2 manually just a few below thSAD. In float math it is about thSAD2=0.9thSAD. I not test how it processed by AVS+ scripting. May be ToInt(0.9thSAD) required if MDegrain will not accept float value or something else. Or let user to enter thSAD2 and thSADC2 too. I think the feature to allow lower thSAD at the edges of tr-range is mostly to decrease artifacts if artifacts happens. If not - the best for denoising and speed with current tr-value is thSAD2 close to thSAD. Last edited by DTL; 31st May 2022 at 13:48.