View Full Version : Dogway's Filters Packs
kedautinh12
10th April 2023, 05:45
Ex mods mean Dogway trans to use Ex_functions complete and mix mods mean Dogway almost trans to use ex_finction (not complete)
Dogway
10th April 2023, 23:07
EX mods use minimum dependency plugins and try to use EX functions where possible, this makes it more compatible with other OSes and you can edit or fix the functions if you want.
MIX mods use a mix of EX functions and external plugins to maximize speed so they are about 15%-20% faster than EX mods, but have more plugin dependencies.
I don't remember much about ConvertFPS() but I think it simply blend frames whereas FrameRateConverter() interpolates (generates) new frames. Asd-g ported RIFE to avs+ so now you can also use RIFEwrap to interpolate frames with higher quality.
Guest
11th April 2023, 01:11
EX mods use minimum dependency plugins and try to use EX functions where possible, this makes it more compatible with other OSes and you can edit or fix the functions if you want.
MIX mods use a mix of EX functions and external plugins to maximize speed so they are about 15%-20% faster than EX mods, but have more plugin dependencies.
I don't remember much about ConvertFPS() but I think it simply blend frames whereas FrameRateConverter() interpolates (generates) new frames. Asd-g ported RIFE to avs+ so now you can also use RIFEwrap to interpolate frames with higher quality.
Thankyou for the great explanation(s).
So that would explain why ConvertFPS() is somewhat faster than FrameConverter()...and I've heard that RIFE functions can be slow, too :(
The RIFEWrap() calls are VERY similar to FrameConverter() calls...
You probably don't want to hear this, but Handbrake does pretty good frame conversions, but being a "closed" app, there's no way to know exactly what its process is :(
UPDATE:-
I tried a RIFEWrap script, and I got some strange errors:-
vkAllocateMemory failed -2
vkQueueSubmit failed -4
I'd suggest that these have something to do with Vulkan.
I'm using a RTX 3060, with "normal" current drivers...
I changed the gpuid from 0 to -1 in Resizers.avsi, but didn't make any difference.
I tried RIFEWrap another way, and only got a black screen with audio and a VERY low video bitrate.
poisondeathray
11th April 2023, 01:36
You probably don't want to hear this, but Handbrake does pretty good frame conversions, but being a "closed" app, there's no way to know exactly what its process is :(
Handbrake is open source
https://github.com/HandBrake
HB drops and duplicates frames to achieve the desired framerate for it's framerate conversions
In avisynth lingo - it uses a "ChangeFPS" style conversion. Ie. ChangeFPS(numerator, denominator)
Guest
11th April 2023, 03:12
Handbrake is open source
https://github.com/HandBrake
HB drops and duplicates frames to achieve the desired framerate for it's framerate conversions
In avisynth lingo - it uses a "ChangeFPS" style conversion. Ie. ChangeFPS(numerator, denominator)
Well by "closed" I meant that afaik you can't access, edit or preview ANY of the filters or scripts...
Correct me if I'm wrong....I don't use it regularly.
I just tested, it's actually ChangeFPS(60000,1000), doesn't need the num & den, it seems.
But then ConvertFPS(60)
poisondeathray
11th April 2023, 03:26
Well by "closed" I meant that afaik you can't access, edit or preview ANY of the filters or scripts...
Correct me if I'm wrong....I don't use it regularly.
I don't really use it either. I just tested HandBrakeCLI to assess the claim "Handbrake does pretty good frame conversions".
Guest
11th April 2023, 03:34
I don't really use it either. I just tested HandBrakeCLI to assess the claim "Handbrake does pretty good frame conversions".
OK, I use the GUI, I "hate" CLI :(
poisondeathray
11th April 2023, 03:46
I just tested, it's actually ChangeFPS(60000,1000), doesn't need the num & den, it seems.
But then ConvertFPS(60)
You can use ChangeFPS(60) ... if you meant 60/1 . 60 is the numerator, 1 is the denominator (den can be omitted in that case, because the default value for den is 1) . When you have "59.94" , it's actually an abbreviation of the real number. It's really ChangeFPS(60000,1001), and you do need to specify both
OK, I use the GUI, I "hate" CLI :(
AFAIK, there is no "live" preview in the GUI either
poisondeathray
11th April 2023, 03:57
UPDATE:-
I tried a RIFEWrap script, and I got some strange errors:-
vkAllocateMemory failed -2
vkQueueSubmit failed -4
I'd suggest that these have something to do with Vulkan.
I'm using a RTX 3060, with "normal" current drivers...
I changed the gpuid from 0 to -1 in Resizers.avsi, but didn't make any difference.
I tried RIFEWrap another way, and only got a black screen with audio and a VERY low video bitrate.
Those are likely out of memory errors. What were your source video dimensions ? Try a small test on a SD video. If it "works", you have your answer
Guest
11th April 2023, 04:13
Those are likely out of memory errors. What were your source video dimensions ? Try a small test on a SD video. If it "works", you have your answer
Will do, but I was using 4K HDR10...
UPDATE:-
Well, you were right :)
So, would it be system memory, or GPU memory ??
I've got 32Gb DDR5, and 8Gb GPU....
Shame that changing the gpuid didn't help :(
poisondeathray
11th April 2023, 04:32
Will do, but I was using 4K HDR10...
UPDATE:-
Well, you were right :)
So, would it be system memory, or GPU memory ??
I've got 32Gb DDR5, and 8Gb GPU....
Shame that changing the gpuid didn't help :(
GPU memory, but 8GB should be enough for UHD. Make sure you're not consuming GPU memory in other processes
RIFE also has a UHD mode (uhd=true) which reduces memory usage, but I don't think it's implemented in Dogway's wrapper version
Guest
11th April 2023, 04:48
GPU memory, but 8GB should be enough for UHD. Make sure you're not consuming GPU memory in other processes
RIFE also has a UHD mode (uhd=true) which reduces memory usage, but I don't think it's implemented in Dogway's wrapper version
Interesting, hopefully Dogway will read this :)
Thanks for your help :)
UPDATE:-
Was just looking thru the RIFE docs, and there is indeed a UHD model...it's #2.
I added it to the call, but it still has those same memory errors :(
RIFEwrap(model=2,FrameNum=60000,FrameDen=1000)
RIFE Wiki (http://www.avisynth.nl/index.php/RIFE)
### Usage:
```
RIFE(clip input, int "model", int "factor_num", int "factor_den", int "fps_num", int "fps_den", string "model_path", int "gpu_id", int "gpu_thread", bool "tta", bool "uhd", bool "sc", float "sc_threshold", bool "skip", float "skip_threshold", bool "list_gpu")
```
### Parameters:
- input\
A clip to process.\
It must be in RGB 32-bit planar format.
- model\
Model to use.\
`models` must be located in the same folder as RIFE.dll.\
Some of the models have two versions: speed oriented (ensemble=False / fast=True) and quality oriented (ensemble=True / fast=False).\
0: rife\
1: rife-HD\
2: rife-UHD\
3: rife-anime\
4: rife-v2\
5: rife-v2.3\
6: rife-v2.4\
7: rife-v3.0\
8: rife-v3.1\
9: rife-v4 (ensemble=False / fast=True)\
10: rife-v4 (ensemble=True / fast=False)\
11: rife-v4.1 (ensemble=False / fast=True)\
12: rife-v4.1 (ensemble=True / fast=False)\
13: rife-v4.2 (ensemble=False / fast=True)\
14: rife-v4.2 (ensemble=True / fast=False)\
15: rife-v4.3 (ensemble=False / fast=True)\
16: rife-v4.3 (ensemble=True / fast=False)\
17: rife-v4.4 (ensemble=False / fast=True)\
18: rife-v4.4 (ensemble=True / fast=False)\
19: rife-v4.5 (ensemble=False)\
20: rife-v4.5 (ensemble=True)\
21: rife-v4.6 (ensemble=False)\
22: rife-v4.6 (ensemble=True)\
23: sudo_rife4 (ensemble=False / fast=True) (custom model)\
24: sudo_rife4 (ensemble=True / fast=False) (custom model)\
25: sudo_rife4 (ensemble=True / fast=True) (custom model)\
Default: 5.
- factor_num, factor_den\
Factor of target frame rate.\
For example `factor_num=5, factor_den=2` will multiply input clip FPS by 2.5.\
Only rife-v4 model supports custom frame rate.\
Default: 2, 1.
- fps_num, fps_den\
Target frame rate.\
Only rife-v4 model supports custom frame rate.\
Supersedes `factor_num`/`factor_den` parameter if specified.\
Default: Not specified.
- model_path\
RIFE model path.\
Supersedes `model` parameter if specified.\
Default: Not specified.
- gpu_id\
GPU device to use.\
By default the default device is selected.
- gpu_thread\
Thread count for interpolation.\
Using larger values may increase GPU usage and consume more GPU memory. If you find that your GPU is hungry, try increasing thread count to achieve faster processing.\
Default: 2.
- tta\
Enable TTA(Test-Time Augmentation) mode.\
Default: False.
- uhd\
Enable UHD mode.\
Default: False.
- sc\
Avoid interpolating frames over scene changes.\
Default: False.
- sc_threshold\
Threshold to determine whether the current frame and the next one are end/beginning of scene.\
Must be between 0.0..1.0.\
Default: 0.12.
- skip\
Skip interpolating static frames.\
Requires [VMAF](https://github.com/Asd-g/AviSynth-VMAF) plugin.\
Default: False.
- skip_threshold\
PSNR threshold to determine whether the current frame and the next one are static.\
Must be between 0.0..60.0.\
Default: 60.0.
- list_gpu\
Simply print a list of available GPU devices on the frame and does no interpolation.\
Default: False.
Dogway
12th April 2023, 11:34
@FTLOY: Added support for UHD in RIFEwrap (link (https://github.com/Dogway/Avisynth-Scripts/blob/master/ResizersPack.avsi)), anyway whatever issues you ever have while working with UHD, blame first the resolution because avisynth tools and hardware (8Gb VRAM mostly) are not ready for this.
Guest
12th April 2023, 12:00
@FTLOY: Added support for UHD in RIFEwrap (link (https://github.com/Dogway/Avisynth-Scripts/blob/master/ResizersPack.avsi)), anyway whatever issues you ever have while working with UHD, blame first the resolution because avisynth tools and hardware (8Gb VRAM mostly) are not ready for this.
Thankyou very much, I will see how I go, and maybe I'll have to get a better GPU, but that all depends on the "performance", I guess.
Guest
12th April 2023, 12:35
I hope this isn't off thread topic...
Just curious about what these scripts actually do...
z_ConvertFormat(colorspace_op="709:709:709:full=>2020:2020:2020:full")
Does this "just" change the picture characteristics (meaning what it looks like), as they don't seem to change the info shown in MediaInfo.
I have noticed that using the above script, that the clip is still shown to be BT709.
There's also Colormatrix scripts, and some LUT's, but they again, only seem to change what the video "looks like".
Is there a specific script or filter that will actually change the BTxxxx info ?
Dogway
12th April 2023, 12:46
Yes, it's a bit offtopic, ask them directly. I made ConvertFormat() because z_ConvertFormat() is intelligible to me, they use strange naming conventions and has some limits.
Sometimes if I urge performance for a project I do some research to find the correct call but for the day to day I use TransformsPack.
Guest
12th April 2023, 13:15
Yes, it's a bit offtopic, ask them directly. I made ConvertFormat() because z_ConvertFormat() is intelligible to me, they use strange naming conventions and has some limits.
Sometimes if I urge performance for a project I do some research to find the correct call but for the day to day I use TransformsPack.
I have quickly (using search) read thru all the TransFormsPacks, and can't see a particular reference to a BT709 to BT2020 conversion.
I would doubt that a z_convertformat script would work with yours.
Any suggestions ??
DTL
12th April 2023, 13:47
Is there a specific script or filter that will actually change the BTxxxx info ?
MediaInfo only display manually defined metadata in some container (or may be some more RAW stream somehow formatted). The data encoding numbers itself are 'virtual' math objects and not have any application-specific properties itself. So using only RAW image encoding dataset it is not possible to found encoding rules. And also what essence do this dataset encodes too.
User must keep in mind image encoding rules when processing in AVS scripting at each step.
You typically set metadata in the MPEG-encoder input settings to define some specific metadata in standard fields for MPEG-formatted stream.
Dogway
12th April 2023, 14:25
I haven't made docs for ConvertFormat but arguments seem self-explanatory enough.
ConvertFormat(cs_in="709",cs_out="2020")
This will rewrite frameprops, not sure about Mediainfo, that has more to do with x264 or the encoder you use.
DTL
12th April 2023, 14:28
2020 may use cl and non-cl matrix. non-cl typically larger used in broadcasting ? What matrix expected in ConvertFormat(cs_out="2020") ?
"z_ConvertFormat(colorspace_op="709:709:709:full=>2020:2020:2020:full")"
It converts colour image encoding rules from 709 transfer/matrix/primaries to 2020 transfer/matrix/primaries using non-cl matrix. Because 2020 for matrix is naming alias to 2020ncl. Also 2020-transfer is sort of non-exist item - it is about same as 709/sRGB transfer. So in z_ConvertFormat 2020-transfer is alias to 2010_10 - may be simple convert anything to 10bit 709/sRGB transfer ? So if you need some HDR you need to define some other transfer. BT.2020 is about WCG mostly.
So pure 2020-system is WCG SDR. May be very rarely used.
poisondeathray
12th April 2023, 15:13
RIFE with SDR UHD test src works ok for me (Rifewrap works ok too) , and GPU-z shows ~2.5 - 3 GB GPU mem consumption during preview or avsmeter script.avs -gpu . Different models take slightly more or less , but it should be easily "doable" with 8GB GPU mem. Check that other processes are not concurrently consuming GPU memory.
If you use RIFE(list_gpu=true), it will tell you the id numbers. Or you can check with GPU-z while running the test RIFE SD script that works to see if the correct GPU is being used by that id, maybe something is mapped incorrectly in your system
I would doubt that a z_convertformat script would work with yours.
It works . It changes both the avs props and the actual video values. If you use ffmpeg libx265 , it will pass the props directly to the encode instead of you having to manually set them in the encoder
Dogway
12th April 2023, 15:30
2020 is a shorthand for 2020NCL which is the most common one used, but you can explicitly define 2020CL or 2020NCL. Anyhow I haven't implemented model conversion yet so I think CL is not currently possible from ConvertFormat. You still have the function in TransformsPack - Models. You can see what's going on with show=true panel.
The concept of "matrix" is ill-formed, it was born when most of the model conversions could be done via a matrix transform, like between YCbCr/YPbPr and RGB, or YUV, or YIQ, etc. Now this is not the case, you can't convert to YcCbcCrc with a single 3x3 matrix, and the same applies to IPT, OkLab, and if I'm not wrong to YCoCg nor YUVr.
Also you don't want 709 transfer if working with delivery formats, for example if you are working with a Bluray source you want 1886 transfer which is the same 2020 uses as standard.
DTL
12th April 2023, 15:44
"you can't convert to YcCbcCrc with a single 3x3 matrix,"
Matrix of output is required param for decoder to de-matrix data into RGB for display (typically for non-RGB and chroma-subsampled systems). The way format converter perform conversion between input image encoding rules to required target may be very complex (like converting first to some 'generic colour space' like XYZ ? ).
The real only point of having any metadata with image compressed/encoded dataset is only to instruct display/decoder to show proper physical image. Or may be next format converter. Matrix not required for 4:4:4 RGB or other direct primary encoded datasets and 'transfer' sort of non-required for linear transfer systems. Mostly required is 'primaries' as the only physical conversion from math values to viewer-oriented colours.
Dogway
12th April 2023, 18:24
So today I added a few options to FilmGrain+, a skin mask to lower the effect on faces, and emulsion artifact which happens on the U channel as yellow stains.
Here is a comparison, it also shows 'bump' and Path to White:
FilmGrainPlus(str=1.2,size=1.0,sharpness=0.4,mode="log",bump=0.1,skin=0.7)
http://i.imgur.com/kJbde9yl.png (https://i.imgur.com/kJbde9y.png)
http://i.imgur.com/MkkyUXvl.png (https://i.imgur.com/MkkyUXv.png)
Guest
13th April 2023, 02:31
@FTLOY: Added support for UHD in RIFEwrap (link (https://github.com/Dogway/Avisynth-Scripts/blob/master/ResizersPack.avsi)), anyway whatever issues you ever have while working with UHD, blame first the resolution because avisynth tools and hardware (8Gb VRAM mostly) are not ready for this.
I tried the "new" RIFEWrap, and it works OK with anything up to, and including 1080p, but I think like you said, maybe it's not ready for UHD HDR10.
I'm still getting these errors that pdr suggested were GPU memory issues..
vkAllocateMemory failed -2
vkQueueSubmit failed -4
However, I'm wondering if its an issue with the Ryzen 7950X having an iGPU, and maybe it's using that instead of the RTX 3060.
Is this call all I need ? :-
RIFEwrap(model=2,FrameNum=60000,FrameDen=1000)
Would adding this be of any benefit ??
- gpu_thread\
Thread count for interpolation.\
Using larger values may increase GPU usage and consume more GPU memory. If you find that your GPU is hungry, try increasing thread count to achieve faster processing.\
Default: 2.
poisondeathray
13th April 2023, 03:05
I tried the "new" RIFEWrap, and it works OK with anything up to, and including 1080p, but I think like you said, maybe it's not ready for UHD HDR10.
I'm still getting these errors that pdr suggested were GPU memory issues..
vkAllocateMemory failed -2
vkQueueSubmit failed -4
However, I'm wondering if its an issue with the Ryzen 7950X having an iGPU, and maybe it's using that instead of the RTX 3060.
Is this call all I need ? :-
RIFEwrap(model=2,FrameNum=60000,FrameDen=1000)
Try gpuid=1
RIFEwrap(model=2,FrameNum=60000,FrameDen=1000,gpuid=1)
Guest
13th April 2023, 03:26
I haven't made docs for ConvertFormat but arguments seem self-explanatory enough.
ConvertFormat(cs_in="709",cs_out="2020")
This will rewrite frameprops, not sure about Mediainfo, that has more to do with x264 or the encoder you use.
I also tried this, and not sure of the results, and MediaInfo still showed the BT709 of the test clip.
But strangely enough, I ran it thru Handbrake, and chose the Colourspace setting of BT2020, and MediaInfo then showed it to be BT2020...
Some basic info from the log of HB:-
"Settings": {
"desat": "0",
"matrix": "bt2020ncl",
"primaries": "bt2020",
"tonemap": "hable",
"transfer": "bt2020-10"
}
Guest
13th April 2023, 03:46
Try gpuid=1
RIFEwrap(model=2,FrameNum=60000,FrameDen=1000,gpuid=1)
Unfortunately, I get this error:-
RIFE:invalid GPU device
and referring to Resizers Pack Line 633 (https://github.com/Dogway/Avisynth-Scripts/blob/master/ResizersPack.avsi#L633)
LeXXuz
13th April 2023, 07:21
You should easily be able to spot which GPU is used by watching VRAM usage in task manager. Even if your script won't start because it can't allocate enough mem, should be able to see which GPU mem gets used up. Either your RTX or your iGPU.
And if you want to play it safe and don't need the iGPU you can disable it in the BIOS of any AM5 board. :)
DTL
13th April 2023, 11:52
"I'm still getting these errors that pdr suggested were GPU memory issues..
vkAllocateMemory failed -2
vkQueueSubmit failed -4"
You need to start from 1 AVS thread only - set Prefetch(1) as the global script param (end of script) and check if no other scripts (includes ?) uses more threads.
Dogway
13th April 2023, 11:53
I also tried this, and not sure of the results, and MediaInfo still showed the BT709 of the test clip.
As I said before, it's an encoder thing. Whether it supports frameprops or not, or if it's overriding what's stated in frameprops.
If you don't have control of the whole pipeline you get things like this where it would be most useful to ask to HandBrake devs.
anton_foy
13th April 2023, 12:14
So today I added a few options to FilmGrain+, a skin mask to lower the effect on faces, and emulsion artifact which happens on the U channel as yellow stains.
Here is a comparison, it also shows 'bump' and Path to White:
FilmGrainPlus(str=3.2,size=1.0,sharpness=0.4,mode="log",bump=0.1,skin=0.7)
http://i.imgur.com/kJbde9yl.png (https://i.imgur.com/kJbde9y.png)
http://i.imgur.com/MkkyUXvl.png (https://i.imgur.com/MkkyUXv.png)
Very good I like it alot! But why is the grained image so much softer/blurrier than the original?
Dogway
13th April 2023, 12:39
Yes, I knew this would come up :D
Grain is detail, and depending on the amount of grain it defines the detail of the image. I've doing my research and did a reparametrization of the blur depending on several factors like 'sharpness' and 'str' but also resolution. In the last version since I knew many would argue I converted 'preblur' to a float type, so you can type 0.5 for half the blur effect, just mind you, it would look unnatural.
Have a look at this video (https://youtu.be/Vv7lB7n1Fak?t=391).
Also reading some studios apply different grain strength to faces, so I added a quick skin mask and you can lower the effect on faces with the 'skin' arg. Also looks like the red channel has typically the less grain so I added a bit more blur to the V plane.
I will now complete the presets I have samples of. I also want to optimize the LMH code block (lo, mid, hi) but kinda don't want headaches right now.
Also refactored Vignette() in GradePack, so it goes well with this for a vintage look.
anton_foy
13th April 2023, 13:29
Yes, I knew this would come up :D
Grain is detail, and depending on the amount of grain it defines the detail of the image. I've doing my research and did a reparametrization of the blur depending on several factors like 'sharpness' and 'str' but also resolution. In the last version since I knew many would argue I converted 'preblur' to a float type, so you can type 0.5 for half the blur effect, just mind you, it would look unnatural.
Have a look at this video (https://youtu.be/Vv7lB7n1Fak?t=391).
Also reading some studios apply different grain strength to faces, so I added a quick skin mask and you can lower the effect on faces with the 'skin' arg. Also looks like the red channel has typically the less grain so I added a bit more blur to the V plane.
I will now complete the presets I have samples of. I also want to optimize the LMH code block (lo, mid, hi) but kinda don't want headaches right now.
Also refactored Vignette() in GradePack, so it goes well with this for a vintage look.
Oh yes I am with you. This video is the Dehancer plugin, I have tried it and it is ok but some things (halation and softening mostly) is not correct IMHO. I made a script for the softening effect here in Avisynth which mimics without actually sacrificing the details. Merely softens instead of blur them away. Can post it for demonstration.
Been scanning 35 and 16mm film for years and there is usually more details than what is shown in the dehancer video but it depends on the scanner alot. Used first Spirit 2k then Scanity (up to 4k+).
Edit: btw. up and running again so tonight I will upload the grain-scans to you.
Guest
13th April 2023, 13:32
@ Dogway,
Can you please comment to my earlier question (in the Red text)
post1985770 (https://forum.doom9.org/showthread.php?p=1985770#post1985770)
Dogway
13th April 2023, 13:54
Would adding this be of any benefit ??
- gpu_thread\
Thread count for interpolation.\
Using larger values may increase GPU usage and consume more GPU memory. If you find that your GPU is hungry, try increasing thread count to achieve faster processing.\
Default: 2.
You can try several things if you look into the original plugin repo (https://github.com/Asd-g/AviSynthPlus-RIFE).
For example skip=true, but as it says it requires the VMFA plugin, and maybe raising gpu_thread, default for HD is 4, maybe try with 6 or 8 but I don't recall it making a change...
I made a script for the softening effect here in Avisynth which mimics without actually sacrificing the details. Merely softens instead of blur them away. Can post it for demonstration.
Yes please, I have no hands on experience on this, just digital. I could use ex_unsharp to blur other frequencies so it has more like a dreamy look and not a plain blur as you state. Maybe, I'm not sure, I could try to calculate standard deviation of the grain and then pass that to the blur so it's more accurate so to speak instead of a visual setting.
Guest
13th April 2023, 14:09
You can try several things if you look into the original plugin repo (https://github.com/Asd-g/AviSynthPlus-RIFE).
For example skip=true, but as it says it requires the VMFA plugin, and maybe raising gpu_thread, default for HD is 4, maybe try with 6 or 8 but I don't recall it making a change...
OK, but is gpu_thread something that might need to be enabled in your wrapper, like the rife-UHD the other day ??
I added it the call, and it said it could find it...
Dogway
13th April 2023, 14:48
gpu_thread is not exposed, I'm not sure what it does exactly because I didn't get better performance for HD above 4 threads on my card, so YMMV, that's why.
Try different values and see what works for you.
Guest
13th April 2023, 14:57
gpu_thread is not exposed, I'm not sure what it does exactly because I didn't get better performance for HD above 4 threads on my card, so YMMV, that's why.
Try different values and see what works for you.
I'm confused, how do I use it then ??
Were you using 4K video, and your GTX 1070 probably hasn't got much vram (unless you've updated recently)
Dogway
13th April 2023, 15:20
The 1070 has 8Gb, it's ngreedia who hasn't updated recently, well yeah, you can get a 4070 for the price of a xx80.
I meant it's not exposed in RIFEwrap, but simply look into the function and edit the argument and change here (https://github.com/Dogway/Avisynth-Scripts/blob/02981ad98eecfc4014932f9be51e0b9d5648a3ff/ResizersPack.avsi#L633) the gpu threads you want.
Guest
13th April 2023, 15:33
The 1070 has 8Gb, it's ngreedia who hasn't updated recently, well yeah, you can get a 4070 for the price of a xx80.
I meant it's not exposed in RIFEwrap, but simply look into the function and edit the argument and change here (https://github.com/Dogway/Avisynth-Scripts/blob/02981ad98eecfc4014932f9be51e0b9d5648a3ff/ResizersPack.avsi#L633) the gpu threads you want.
Wouldn't have a clue what to do with this...
gpu_thread=isHD ? 4 : 2
Would it be gpu_thread=2 (or 4) ??
I think I might have mentioned this before, I just don't understand "code", it's just letters & numbers to me :(
anton_foy
13th April 2023, 21:27
I must say that you made an amazing effort and the results are GREAT with filmgrain+! Trying to figure out your script as I go home from work here on the subway, how is vstcanny actually meant to be used here? The red channel may be faster reduced by just a simple merge call? Just a thought. It is very realistic looking and a very thougth through script. Await one hour and I will upload the scans:)
Dogway
13th April 2023, 21:56
I'm currently dealing with the blue/red channel and trying a few things.
I already ported 5248 which is/was a famous stock and also 5279.
What happens is what's described in the charts but at a higher level, blue channel (U plane roughly in this case) is VERY noisy while the red channel is remnant, barely noisy.
Doing things now by plane complicates matters and I'm not sure the results are quite there since we are working in YUV and more importantly, the grain is now decorrelated so we lose the nice white spots/grains.
I think I will leave chroma grain as it is, unless you are inspecting on a grey plate chroma grain is barely noticeable, less so with path to white.
On the vstcanny line, I use it for gaussian blur, the filter was designed for TCanny edge detection but its mode=-1 (gaussian blur) is actually the more performant gaussian blur you can find in AVS+ if you omit removegrain(12) for a gaussian blur of 0.707 and ex_gaussianblur() for big sigmas. The expression in it is only layered expressions, it's not a multi-regression or anything, I tried to plot it in 3D yesterday without success.
The core concept of the filter is replicating grain behaviour on the visual system, by integrating it, that is the lower the 'size' the higher resolution the original grain plate is, then I downscale. Probably this, along 'log' space and the Path to White is what makes it work, preblurring also though.
I'll have a look at your samples tomorrow and implement them.
anton_foy
14th April 2023, 00:27
Here is my soft "hack", it may be tweaked for different resolutions etc. but a base of what I use.
u=last
#Soften
blr = ex_expand(mode="disk",thres=120).removegrain(20).ex_levels(0,0.96,255)
merge(u.sharpen(0.2),blr, 0.52)
interleave(u,last)
Edit: I could not find the script I used before that was much more complex so hacked this together yesterday from memory. Also did you get my PM Dogway? A little bit of a mess of files but maybe first look into "imsc" folder.
Guest
14th April 2023, 01:01
Could someone recommend a good filter to remove color banding.?
For removing (or improving at least) the banding you get in foggy, dark or some underwater scenes.
Dogway
14th April 2023, 12:26
Edit: I could not find the script I used before that was much more complex so hacked this together yesterday from memory. Also did you get my PM Dogway? A little bit of a mess of files but maybe first look into "imsc" folder.
Yes thank you! Just downloaded and was sorting the names. Only checked a few of thems but I think you got 2 "Eterna Vivid 8543 160T" samples and 2 "Eterna 8563 250D" samples (the one called ET250D_GR), I see they are samples for shooting with an exposure fade, so only a few frames are useful where exposure is balanced, also there's a big cast to green, so not sure I can pull chroma grain detail from there but I think it will come useful anyways. Most are Fuji and among the Kodaks all are already done except 5201 and 5212, 5205 is not in my list maybe cause it was short lived or something.
I liked your soften example, but maybe I don't know it starts to get into the dilation realm, which is not bad at all but it pertains more into compositing rather than restoration, as denoised movies already have all the camera and lens flaws.
It can be approximated without the dilation with:
ex_unsharp(-0.4,Fc=width()/1.5)
And with the dilation, it's the same but in one call, presumibly faster but in reality slower, not sure why:
ex_luts(mode="max",pixels=ex_shape(1,mode="disk"),exprf=" dup x - abs 5 > swap range_max / 1.05 ^ range_max * x ?").removegrain(20)
@FTLOY: Try GradFun3plus/SmoothGradPlus
anton_foy
14th April 2023, 12:49
Yes thank you! Just downloaded and was sorting the names. Only checked a few of thems but I think you got 2 "Eterna Vivid 8543 160T" samples and 2 "Eterna 8563 250D" samples (the one called ET250D_GR), I see they are samples for shooting with an exposure fade, so only a few frames are useful where exposure is balanced, also there's a big cast to green, so not sure I can pull chroma grain detail from there but I think it will come useful anyways. Most are Fuji and among the Kodaks all are already done except 5201 and 5212, 5205 is not in my list maybe cause it was short lived or something.
I liked your soften example, but maybe I don't know it starts to get into the dilation realm, which is not bad at all but it pertains more into compositing rather than restoration, as denoised movies already have all the camera and lens flaws.
It can be approximated without the dilation with:
ex_unsharp(-0.4,Fc=width()/1.5)
And with the dilation, it's the same but in one call, presumibly faster but in reality slower, not sure why:
ex_luts(mode="max",pixels=ex_shape(1,mode="disk"),exprf=" dup x - abs 5 > swap range_max / 1.05 ^ range_max * x ?").removegrain(20)
@FTLOY: Try GradFun3plus/SmoothGradPlus
Great! Yes the exposure fade was due to the lack of film I only got short cuts for free :) Or if you mean the dark ones they are shot with a still camera but with the motion picture stocks.
As for the dilation it was originally meant for my digital footage to look like film so your script will be better for denoised film.
Balling
14th April 2023, 14:34
2020 is a shorthand for 2020NCL which is the most common one used, but you can explicitly define 2020CL or 2020NCL. Anyhow I haven't implemented model conversion yet so I think CL is not currently possible from ConvertFormat. You still have the function in TransformsPack - Models. You can see what's going on with show=true panel.
The concept of "matrix" is ill-formed, it was born when most of the model conversions could be done via a matrix transform, like between YCbCr/YPbPr and RGB, or YUV, or YIQ, etc. Now this is not the case, you can't convert to YcCbcCrc with a single 3x3 matrix, and the same applies to IPT, OkLab, and if I'm not wrong to YCoCg nor YUVr.
Also you don't want 709 transfer if working with delivery formats, for example if you are working with a Bluray source you want 1886 transfer which is the same 2020 uses as standard.
Correct with 2020CL. Indeed, it tries to make constant luminance which is by definition making Y' as close to Y of XYZ as possible. To do that it applies part of matrix first on linear values and only then applies nonlinearity and finishes the matrix using Y'.
anton_foy
15th April 2023, 19:36
Dogway your inbox is full. Did you also want me to send you the grey card grain plates?
Dogway
16th April 2023, 01:38
Yes sorry, I forgot to delete the PM, deleted just as I got the warning so try when you can. Will be filling the presets for next updates, I think that's all is left for FilmGrain+.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.