real.finder's Avisynth Stuff

[tormento]

Originally Posted by FranceBB

I'll wait for real.finder to comment, though, as perhaps my SMDegrain version is old and there's a new one which supports 16bit planar... I don't know...

Thanks for your help. I doubt we can mix n16 with lsb

[real.finder]

Originally Posted by tormento

@real.finder

I asked a similar question, some time ago, but this is bit different.

Hi have a Hi10P source (unfortunately x264 and so no hw decode support). My idea was to use a script like this:

SetMemoryMax(8000)
SetFilterMTMode("DEFAULT_MT_MODE", 2)
LoadPlugin("D:\eseguibili\media\MeGUI_x64\tools\lsmash\LSMASHSource.dll")
LoadPlugin("D:\eseguibili\media\MeGUI_x64\tools\avs\plugins\ConvertStacked.dll")
LWLibavVideoSource("E:\in\1_31 Tokyo godfathers\godfathers.lwi", format="YUV420P8")

SMDegrain (tr=4, thSAD=500, refinemotion=false, n16=true, mode=0, contrasharp=false, PreFilter=4, truemotion=false, plane=4, chroma=true)

Prefetch(6)

Instead of YUV420P8 space, I'd like to use YUV420P10 and let SMDegrain deal with better color space and final conversion to 8 bit. Is there any change I have to do to the script or SMDegrain parameters to feed it with 10 bit or higher bit material? As I told, I need 8 bit as output.

Thanks

just remove those with red color, and add convertbits(8,dither=0) or with dither=1 for Floyd-Steinberg before Prefetch(6)

Originally Posted by FranceBB

I don't know if there have been any updates for SMDegrain (i.e if it supports 16bit planar as well), but it definitely supports 16bit stacked, therefore (assuming you have Avisynth+):

#Indexing with 16bit planar output from 10bit planar source
LWLibavVideoSource("E:\in\1_31 Tokyo godfathers\godfathers.lwi", format="YUV420P16")

#From 16bit planar to 16bit stacked
ConverttoStacked()

#Denoise with high bit depth precision: 16bit stacked input, 8bit planar output with dither (Floyd-Steinberg error diffusion)
SMDegrain (tr=4, thSAD=500, refinemotion=false, n16=true, contrasharp=false, PreFilter=4, truemotion=false, plane=4, chroma=true, lsb_in=true, lsb_out=false, mode=6)

And that's it...
The changes I made to your parameters are:
lsb_in=true to tell SMDegrain "Hey, you're gonna get 16bit stacked input with MSB, LSB stacked one on the top of the other, not a weird aspect ratio yv12 8bit source, so deal with it properly!!"
lsb_out=false to tell SMDegrain "Hey, don't you dare outputting 16bit stacked with psychedelic garbage on the bottom, I want a nice clean regular 8bit planar as an output!"
mode=6 to tell SMDegrain to use DitherPost to dither down to 8bit the output in a proper way. There are 8 modes that you can use for dithering, but I generally use the Floyd-Steinberg Error Diffusion as it's somewhat a good compromise.
Anyway, feel free to use a different mode if you like:

-1 no dither, round to the closest value
0 8-bit ordered dither + noise.
1 1-bit dither
2 2-bit dither, light
3 2-bit dither, medium
4 2-bit dither, strong
5 2-bit dither, stronger
6 Serpentine Floyd-Steinberg error diffusion.
7 Stucki error diffusion.
8 Atkinson error diffusion.



I'll wait for real.finder to comment, though, as perhaps my SMDegrain version is old and there's a new one which supports 16bit planar... I don't know...

SMDegrain support HBD as input=output since years but not for all settings

as for now only MedianBlur2 missed the HBD, if it have HBD then SMDegrain will fully support HBD as input=output for all settings (still there are some mvtools2 functions not work with float clip)

[tormento]

Originally Posted by real.finder

as for now only MedianBlur2 missed the HBD, if it have HBD then SMDegrain will fully support HBD as input=output for all settings (still there are some mvtools2 functions not work with float clip)

SMDegrain with variable bit in and out would be a dream. It’s still early for me to deal with 4K HDR material as I don’t own the proper hardware but I am thinking that, one day, I will have to denoise it too.

Real.Finder, do you have a roadmap?

[real.finder]

Originally Posted by tormento

SMDegrain with variable bit in and out would be a dream. It’s still early for me to deal with 4K HDR material as I don’t own the proper hardware but I am thinking that, one day, I will have to denoise it too.

Real.Finder, do you have a roadmap?

MedianBlur2 is dll plugin so no, I asked days ago in avs+ Thread for add HBD and no one but pinterf volunteered to do it but I think he busy with another things in avs+ core

[tormento]

Originally Posted by real.finder

MedianBlur2 is dll plugin so no, I asked days ago in avs+ for add HBD and no one but pinterf volunteered to do it but I think he busy with another things in avs+ core

Thanks, anyway

[real.finder]

Originally Posted by tormento

Thanks, anyway

I see pinterf update MedianBlur2 githup for HBD so it's a good thing

anyway, aside from that, I maybe will be nice with 4:4:4 fans like dREV (cuz there is a friend who use these things 720 444 from 1080 420), but will not update Gradfun3mod, Instead there will be another new function that did what Gradfun3mod (maybe base on it) but with no deband

[tormento]

Originally Posted by real.finder

I see pinterf update MedianBlur2 githup for HBD so it's a good thing

/me happy

Waiting for variable bit depth SMDegrain!

[tormento]

Originally Posted by real.finder

just remove those with red color

LWLibavVideoSource("E:\in\1_31 Tokyo godfathers\godfathers.lwi")
error: KNLMeansCL: INT10 require 'channels = YUV'!

LWLibavVideoSource("E:\in\1_31 Tokyo godfathers\godfathers.lwi", format="YUV420P10")
error: KNLMeansCL: INT10 require 'channels = YUV'!

LWLibavVideoSource("E:\in\1_31 Tokyo godfathers\godfathers.lwi", format="YUV420P16")
Working and I got 4,86 fps instead of 6,71 fps on 8 bit chain.

[real.finder]

Originally Posted by tormento

LWLibavVideoSource("E:\in\1_31 Tokyo godfathers\godfathers.lwi")
error: KNLMeansCL: INT10 require 'channels = YUV'!

LWLibavVideoSource("E:\in\1_31 Tokyo godfathers\godfathers.lwi", format="YUV420P10")
error: KNLMeansCL: INT10 require 'channels = YUV'!

LWLibavVideoSource("E:\in\1_31 Tokyo godfathers\godfathers.lwi", format="YUV420P16")
Working

KNLMeansCL has problems with 10 bit clip https://github.com/Khanattila/KNLMea...ment-469839637

and I got 4,86 fps instead of 6,71 fps on 8 bit chain.

Thank God it's not half speed of the 8-bit

yes, more than 8 bit will be slower indeed

[tormento]

Originally Posted by real.finder

KNLMeansCL has problems with 10 bit clip https://github.com/Khanattila/KNLMea...ment-469839637

I saw there is a workaround setting YUV, is it possible to create a script variant for that specific case, as all the H.265 HDR material out there is 10 bit?

[real.finder]

Originally Posted by tormento

I saw there is a workaround setting YUV, is it possible to create a script variant for that specific case, as all the H.265 HDR material out there is 10 bit?

YUV in KNLMeansCL need 4:4:4 chroma, if your source is 444 then it should work with 10 bit, but in your case (4:2:0) 16 bit is better since going from 420 to 444 is not recommended

[tormento]

Originally Posted by real.finder

YUV in KNLMeansCL need 4:4:4 chroma, if your source is 444 then it should work with 10 bit, but in your case (4:2:0) 16 bit is better since going from 420 to 444 is not recommended

Thanks man!

So if the source is 444, SMDegrain should work?

[real.finder]

Originally Posted by tormento

Thanks man!

So if the source is 444, SMDegrain should work?

yes

[tormento]

Originally Posted by real.finder

YUV in KNLMeansCL need 4:4:4 chroma, if your source is 444 then it should work with 10 bit, but in your case (4:2:0) 16 bit is better since going from 420 to 444 is not recommended

Just a question arise to my mind: Hi10P is 10 bit. You tell me to use 16 bit BUT at the end I have to dither to go back to 10 bit again to encode as proper format. Isn't better to find a way to stay in 10 bit with no dithering at the end?

[real.finder]

Originally Posted by tormento

Just a question arise to my mind: Hi10P is 10 bit. You tell me to use 16 bit BUT at the end I have to dither to go back to 10 bit again to encode as proper format. Isn't better to find a way to stay in 10 bit with no dithering at the end?

more bits = better

anyway you can chose another prefilter other than 4 or ask KNLMeansCL developer to make it work with grayscale in any bit depth (seems he only against 420 with 10 bit which is not being used in SMDegrain)

[tormento]

Originally Posted by real.finder

more bits = better

Yes unless the standard for UHD is 10bit and you need to dither at the end

That's why I was asking for a solution to have 10 bit chain

[tormento]

@real.finder

Would you mind consider implementing DGDenoise() as additional prefilter? It is FAST (CUDA) and gives good results.

[ChaosKing]

Originally Posted by tormento

@real.finder

Would you mind consider implementing DGDenoise() as additional prefilter? It is FAST (CUDA) and gives good results.

prefilter also accepts a clip as input.

[tormento]

Originally Posted by ChaosKing

prefilter also accepts a clip as input.

I do know but if you look at the avsi, you will notice that even KNLMeansCL needs script processing to do the job correctly.

[real.finder]

Originally Posted by tormento

@real.finder

Would you mind consider implementing DGDenoise() as additional prefilter? It is FAST (CUDA) and gives good results.

I don't has CUDA

anyway as ChaosKing said, you can always feed any clip in prefilter