View Full Version : Dogway's Filters Packs
Boulder
2nd April 2023, 14:11
The default SetMemoryMax plays it too safe. 4K processing can easily require over 10GB of cache :D
Guest
2nd April 2023, 14:21
You probably have to. 16GB is not very much for more complex filtering of 4k content.
Change of subject...
Is there a way to add .srt subtitles with AVS, and edit font size.
poisondeathray
2nd April 2023, 14:43
Change of subject...
Is there a way to add .srt subtitles with AVS, and edit font size.
Nothing to do with this thread. You should post somewhere else or start a new one
You can convert to .ass and specify font size there
Guest
2nd April 2023, 14:50
Nothing to do with this thread. You should post somewhere else or start a new one
You can convert to .ass and specify font size there
Well, you never know what Dogway may have hidden in amongst all his scripts / filters.
coolgit
2nd April 2023, 15:46
Put .srt sub with same filename as video in same folder and your player will load it and use player to change font size.
Guest
2nd April 2023, 17:08
Put .srt sub with same filename as video in same folder and your player will load it and use player to change font size.
I do that most of the time, but I want to hardcode them for a series, before editing out lengthy intros, etc.
Emulgator
2nd April 2023, 17:33
SubtitleEdit is your friend. Go to thread
https://forum.doom9.org/showthread.php?t=162721
Dogway
2nd April 2023, 22:16
Simply used:
Code:
pre=ex_Median(mode="IQMST",thres=255)
STTWM(sw=50,tw=50,aw=100,sthres=5,tthres=5)
SMDegrain(tr=2,thSAD=200,thSADC=100,contrasharp=true,prefilter=pre,str=1.2,refinemotion=true)
FrameRateConverterMIX(FrameDouble=true)
in AvsPmod, and I think without Prefetch() even as I only use it when encoding.
You might need to review your workflow, use avs+ test 9, setmemorymax to an appropiate value, and load the mt-modes.avsi. Also test with other source loaders.
I think I might have figured out what's going on...
What type (resolution) video did you test this script on ?
I am trying to use FrameConverter on 4K HDR10 content, and I think the combination is just too much for it, 'cause it seems to be ok, but slow, on lesser resolution's.
4K changes it all. Look at the script, 4 temporal filters, that requires a lot out of order access. Unless you have a lot of cache or/and use your highest RAM it's going to run very slow, and I'm not sure even if AVS+ is ok for smooth 4K workflows. You might improve it using RequestLinear(2*24) just before FrameRateConverter.
Also being HDR10 you need to supply SMDegrain (and ideally FrameRateConverter) an SDR prefilter, as suggested in the docs or at the top of the SMDegrain script.
Should these two be identical in output?
Code:
PRE=ex_Median(mode="IQMST", UV=3,thres=255)
Code:
PRE0=ex_Median(mode="IQMST", UV=3,thres=255)
PRE=ex_blend(PRE0,"blend",opacity=1)
Since opacity is clamped between 0,1 in ex_blend
-output with opacity=0 seems identical with the last clip, as it should.
-output with opacity=1 seems not identical with the blend clip, which I would've expected.
Also I noticed some flickering in the output when opacity is used with anything but 0.
Quite subtle but noticeable in some backgrounds when you're very susceptible to flicker. Could these be rounding errors from the blending process by any chance?
Sorry I missed this post, I thought you were referring to the SceneStats issue. Yes this is a bug, only when opacity is 1 in 'blend' mode for TV range sources. It's fixed now.
As for the flicker, are you sure about that? it's a basic 2 clips blends, I forgot to say but you could also do Merge(clip1,clip2,0.5), output should be similar, that means it should not show flicker either.
coolgit
3rd April 2023, 00:01
I do that most of the time, but I want to hardcode them for a series, before editing out lengthy intros, etc.
Don't hardcode them. What if there is a spelling mistake, missing word, lines etc. With subtitleedit you can fix them easily. With hardcode you will have to fix the subs and compress the files all over again.
Hardcode subs are a very bad idea.
Guest
3rd April 2023, 01:05
Don't hardcode them. What if there is a spelling mistake, missing word, lines etc. With subtitleedit you can fix them easily. With hardcode you will have to fix the subs and compress the files all over again.
Hardcode subs are a very bad idea.
I find it interesting how many continuing comments you can get with an off topic subject :(
This will be the last comment I make about subtitles here, as it is WAY off the thread's topic....kinda wish I hadn't brought it up, here.
I know hard coded has all those issues, but when you want to edit, cut, trim, the video & audio, (for example the first 2 minutes of every Game of Throne episode), you'd have to separately re-time the subtitles to suit the new running time, whereas if the video is hard coded (and double checked for typo's etc), then the trimming will take care of the subtitles :)
@ Emulgator
And I know that "SubtitleEdit is your friend", I have been using it for years, but I don't think you can change the font size for .srt's.
If you want to reply, please send me a PM, not on here.
Guest
3rd April 2023, 01:08
4K changes it all. Look at the script, 4 temporal filters, that requires a lot out of order access. Unless you have a lot of cache or/and use your highest RAM it's going to run very slow, and I'm not sure even if AVS+ is ok for smooth 4K workflows. You might improve it using RequestLinear(2*24) just before FrameRateConverter.
Also being HDR10 you need to supply SMDegrain (and ideally FrameRateConverter) an SDR prefilter, as suggested in the docs or at the top of the SMDegrain script.
Sorry about the subtitles stuff :scared:
Yes, I will be changing a few things with the info I've got about this, I'm glad I mentioned the 4K HDR10 thing.
But as for the SDR pre-filter, if that is to change the HDR to SDR, I don't want to do that!!
:thanks:
UPDATE:-
OK, I've had some success :cool:
Added TIVTC, so as to use RequestLinear(2*24), and modified the script.
Now using
SetCacheMode()
SetMemoryMax(20480)
I found that using SetCacheMode(0) was a little slower.
And going from SetMemoryMax 16384 (16Gb) to 20480 (20Gb) was a nice little bump, however, going up to 24576 (24Gb), it basically maxed out my 32G of DD5 and didn't really even want to start :(
So if there's anyone else out there that's silly enough to want to use FrameRateConverter on 4K, you need to add all this to the script :cool:
I'm sure that if I upped the system RAM to 64Gb or beyond it would process even faster. but DDR5 RAM is a bit too much $. :devil:
coolgit
3rd April 2023, 01:19
I find it interesting how many continuing comments you can get with an off topic subject :(
This will be the last comment I make about subtitles here, as it is WAY off the thread's topic....kinda wish I hadn't brought it up, here.
I know hard coded has all those issues, but when you want to edit, cut, trim, the video & audio, (for example the first 2 minutes of every Game of Throne episode), you'd have to separately re-time the subtitles to suit the new running time, whereas if the video is hard coded (and double checked for typo's etc), then the trimming will take care of the subtitles :)
Actually it isn't off topic as Dogway does have a sub filter SwipeSubs https://github.com/Dogway/Avisynth-Scripts/tree/master/EX%20mods therefore your query and hope Well, you never know what Dogway may have hidden in amongst all his scripts / filters. was valid within the realm of this thread even though it not what you wanted.
Re timing the srt files is easy and quicker, 10 seconds per file. I have been doing this for 2 decades. Trust me if you hardcode them you will create more problems and waste more time.
Up to you.
Guest
3rd April 2023, 01:40
Actually it isn't off topic as Dogway does have a sub filter SwipeSubs https://github.com/Dogway/Avisynth-Scripts/tree/master/EX%20mods therefore your query and hope was valid within the realm of this thread even though it not what you wanted.
Re timing the srt files is easy and quicker, 10 seconds per file. I have been doing this for 2 decades. Trust me if you hardcode them you will create more problems and waste more time.
Up to you.
Well, all right then :)
Yes, it's not really what I'm after, so maybe Dogway might come up with a solution to my situation. :eek:
I know that re-timing would be reasonably easy with just a trim at the start, but when you're chopping out bits throughout the video, makes it pretty difficult.
I've done hard with a few series, and the only issue I have is the font size.
LeXXuz
3rd April 2023, 10:30
But as for the SDR pre-filter, if that is to change the HDR to SDR, I don't want to do that!!
Not at all. It is just for the prefiltering process before handing the prefiltered clip to mvtools. Since mvtools does not support HDR, you need to change your HDR content to SDR with an additional prefilter like DGHDRtoSDR().
If not, mvtools "sees" the prefilter-clip like you would on a SDR screen, with heavily compressed luma and chroma range. Which reduces the accuracy of the motion estimation quite a lot.
Sorry I missed this post, I thought you were referring to the SceneStats issue. Yes this is a bug, only when opacity is 1 in 'blend' mode for TV range sources. It's fixed now.
As for the flicker, are you sure about that? it's a basic 2 clips blends, I forgot to say but you could also do Merge(clip1,clip2,0.5), output should be similar, that means it should not show flicker either.
Thanks Dogway. :)
Well, since you ask me that way, no, I'm not 100% sure anymore. :D
I'll do some more testing on different sources with the fixed ex_blend() and compare it with merge().
Guest
3rd April 2023, 12:34
Not at all. It is just for the prefiltering process before handing the prefiltered clip to mvtools. Since mvtools does not support HDR, you need to change your HDR content to SDR with an additional prefilter like DGHDRtoSDR().
If not, mvtools "sees" the prefilter-clip like you would on a SDR screen, with heavily compressed luma and chroma range. Which reduces the accuracy of the motion estimation quite a lot.
OK, thanks for the explanation, would you be so kind to provide a example of a call for DGHDRtoSDR() as a pre-filter ??
Wait, what, I think I found it here:-
DGHDRtoSDR as pre filter (https://forum.doom9.org/showthread.php?p=1984264#post1984264)
Something like this :-
pre=DGHDRtoSDR(mode="pq",white=112)
pre2=ex_Median(mode="IQMST",thres=255) or pre2=pre.ex_Median(mode="IQMST", UV=3, thres=255)
STTWM(sw=50,tw=50,aw=100,sthres=5,tthres=5)
SMDegrain(tr=2,thSAD=200,thSADC=100,contrasharp=true,prefilter=pre,prefilter=pre2,str=1.2,refinemotion=true)
RequestLinear(2*24)
FrameRateConverterMIX(FrameDouble=true)
coolgit
3rd April 2023, 17:42
Well, all right then :)
Yes, it's not really what I'm after, so maybe Dogway might come up with a solution to my situation. :eek:
I know that re-timing would be reasonably easy with just a trim at the start, but when you're chopping out bits throughout the video, makes it pretty difficult.
I've done hard with a few series, and the only issue I have is the font size.
If you must use .srt instead of .ass then you can use
assrender("filepath and name.srt", scale=1.2, srt_font="verdana")
Scale adjust size of font.
Or use subtitleedit and load srt file and use <font size="10px">Hello World</font>. For each line.
I surmised assrender would be easier.
Guest
4th April 2023, 03:24
If you must use .srt instead of .ass then you can use
assrender("filepath and name.srt", scale=1.2, srt_font="verdana")
Scale adjust size of font.
Or use subtitleedit and load srt file and use <font size="10px">Hello World</font>. For each line.
I surmised assrender would be easier.
:thanks::thanks::thanks::thanks: It works a treat ;)
The only problem is you'd have to change the script's subtitle path for EVERY episode, so you could end up with MANY scripts :(
LeXXuz
4th April 2023, 06:34
Something like this :-
pre=DGHDRtoSDR(mode="pq",white=112)
pre2=ex_Median(mode="IQMST",thres=255) or pre2=pre.ex_Median(mode="IQMST", UV=3, thres=255)
STTWM(sw=50,tw=50,aw=100,sthres=5,tthres=5)
SMDegrain(tr=2,thSAD=200,thSADC=100,contrasharp=true,prefilter=pre,prefilter=pre2,str=1.2,refinemotion=true)
RequestLinear(2*24)
FrameRateConverterMIX(FrameDouble=true)
You can only set one prefilter in SMDegrain and the white point is pretty low. Use 400 and adjust from there. That really depends on the source. Str of 1.2 is also quite below recommended default of 5.0.
Try:
pre=ex_Median(mode="IQMST",thres=255).DGHDRtoSDR(mode="pq",white=400)
STTWM(sw=50,tw=50,aw=100,sthres=5,tthres=5)
SMDegrain(tr=2,thSAD=200,thSADC=100,contrasharp=true,prefilter=pre,str=1.2,refinemotion=true)
RequestLinear(2*24)
FrameRateConverterMIX(FrameDouble=true)
Guest
4th April 2023, 07:33
You can only set one prefilter in SMDegrain and the white point is pretty low. Use 400 and adjust from there. That really depends on the source. Str of 1.2 is also quite below recommended default of 5.0.
Try:
pre=ex_Median(mode="IQMST",thres=255).DGHDRtoSDR(mode="pq",white=400)
STTWM(sw=50,tw=50,aw=100,sthres=5,tthres=5)
SMDegrain(tr=2,thSAD=200,thSADC=100,contrasharp=true,prefilter=pre,str=1.2,refinemotion=true)
RequestLinear(2*24)
FrameRateConverterMIX(FrameDouble=true)
Hi LeXXuz,
Yes, I found that out the hard way, but I think I might have got it going, but I removed the DGHDR call, tho, afterwards.
I tried this, not sure if it worked, tho...
pre=DGHDRtoSDR(mode="pq",white=112)
pre2=ex_Median(mode="IQMST",thres=255)
STTWM(sw=50,tw=50,aw=100,sthres=5,tthres=5)
SMDegrain(tr=2,thSAD=200,thSADC=100,contrasharp=true,prefilter=pre,str=1.2,refinemotion=true)
SMDegrain(prefilter=pre2)
RequestLinear(2*24)
FrameRateConverterMIX(FrameDouble=true)
But I will definitely try your script suggestion...
:thanks:
Quick Update:-
Just ran your script (only as a quick preview test), but it worked :)
Next thing I'm curious about is, FrameConverter doubles the original FPS, but is there a script/filter that you can enter the FPS you want ???
There probably is, I just haven't found it yet, or forgotten.
LeXXuz
4th April 2023, 10:35
Hi LeXXuz,
Yes, I found that out the hard way, but I think I might have got it going, but I removed the DGHDR call, tho, afterwards.
I tried this, not sure if it worked, tho...
pre=DGHDRtoSDR(mode="pq",white=112)
pre2=ex_Median(mode="IQMST",thres=255)
STTWM(sw=50,tw=50,aw=100,sthres=5,tthres=5)
SMDegrain(tr=2,thSAD=200,thSADC=100,contrasharp=true,prefilter=pre,str=1.2,refinemotion=true)
SMDegrain(prefilter=pre2)
RequestLinear(2*24)
FrameRateConverterMIX(FrameDouble=true)
That way you would run SMDegrain twice. And the 2nd time with default settings and no HDR to SDR conversion for the prefilter either which would make your first call with those subtle settings pretty much useless.
Also you have quite low thresholds for 4k but use a pretty strong prefilter with IQMST mode of ex_Median.
You may want to balance that a little more. Your low thresholds plus extra refinement will do you no good to preserve fine details if your prefilter is too strong and kills them in the first place.
Guest
4th April 2023, 10:50
That way you would run SMDegrain twice. And the 2nd time with default settings and no HDR to SDR conversion for the prefilter either which would make your first call with those subtle settings pretty much useless.
Also you have quite low thresholds for 4k but use a pretty strong prefilter with IQMST mode of ex_Median.
You may want to balance that a little more. Your low thresholds plus extra refinement will do you no good to preserve fine details if your prefilter is too strong and kills them in the first place.
I'm still learning, and open to suggestions :)
Dogway
4th April 2023, 19:47
FilmGrain+ (https://github.com/Dogway/Avisynth-Scripts/blob/master/FilmGrain+.avsi)
I've been working on a new filter, that it's not so new. As you know I've been chasing down a good grain filter for some time. First I modded GrainFactory3, later optimized it only to discover ugly artifacts, so I refactored into what got called FilmGrain. It was like trying to fix what was broken as a whole, so I made a new grain filter from the ground up, new concept with 3 goals, good quality, intuitive/easy to use, and performance. Unless you are on UHD for which is slow I would say I achieved what had planned.
It's the first version, and still need to revise a few things here and there, but try to give it a try and give back some feedback. I still need to add a preset system, with more modes than those listed.
The idea is to finally remove the old filters from the repo.
kedautinh12
5th April 2023, 00:22
Hope filmgrain+ don't upsize file too much like grainfactory3
Guest
5th April 2023, 00:52
So just a quick question about DGHDRtoSDR, as with a lot of DG's stuff, it requires a CUDA device, so that must mean that a user that only has Intel or AMD GPU's can't use it to its full potential ??
impl="sw" - Software mode (very slow).
Is there an alternative ??
LeXXuz
5th April 2023, 08:45
Hope filmgrain+ don't upsize file too much like grainfactory3
Depends on the settings I'd say. Most important is imho it survives later compression by the encoder and not only in parts which looks very ugly as a result.
So just a quick question about DGHDRtoSDR, as with a lot of DG's stuff, it requires a CUDA device, so that must mean that a user that only has Intel or AMD GPU's can't use it to its full potential ??
impl="sw" - Software mode (very slow).
Is there an alternative ??
I remember Donald did a thing with z_convert before creating DGHDRtoSDR() but that required quite a lot of trial and error tweaking and is surely not maintained anymore since he released his filter. Don't really know anything else which gives decent results. And I can't recall that software mode was that slow to be honest.
Dogway
5th April 2023, 09:16
FilmGrain+ is not for compressibility but for remaster purposes, to regrain ugly sources after a denoising and then encoding at a higher bitrate. Grain can also mask banding and increase perceptual sharpness.
I just updated v1.1 with a benchmark on first page. It's not that bad performance wise, given that it's so more intuitive to use and has higher quality. With PTH=true it reduces speed greatly so something to be aware.
I still need to port a few more presets.
So just a quick question about DGHDRtoSDR, as with a lot of DG's stuff, it requires a CUDA device, so that must mean that a user that only has Intel or AMD GPU's can't use it to its full potential ??
It's a suggestion for a quick tonemap. You can use CPU tonemappers like those in fmtconv or maybe the ones in TransformsPack - Transfers, but they will be considerably slower.
Guest
5th April 2023, 10:43
@ LeXXuz & Dogway,
Thanks for your explanations, but there is still an unanswered question...
With FrameConverter, it "only" does double the original frame rate, but is there another option (or possible option for FrameConverter) to be able to process to a user set frame rate ?? eg:- 50, 60 or even higher.
It would be nice to have a "fast" FrameConverter that just does a UHD standard of 60FPS...
:thanks:
kedautinh12
5th April 2023, 11:14
Info about DGHDRtoSDR here:
http://avisynth.nl/index.php/DGHDRtoSDR
Guest
5th April 2023, 11:51
Info about DGHDRtoSDR here:
http://avisynth.nl/index.php/DGHDRtoSDR
Thanks, I guess that means its nVidia or bust...
Dogway
5th April 2023, 17:33
With FrameConverter, it "only" does double the original frame rate(...)
Just curious, why do you spread falseness? Read the script, it supports any target fps.
Guest
5th April 2023, 19:10
Just curious, why do you spread falseness? Read the script, it supports any target fps.
I'm so so sorry Dogway... i only noticed the double rate.
Please realise, this is all new to me.
How do I specify what fps I want..eg:- 60fps ?
Dogway
5th April 2023, 20:07
Just read a little (https://github.com/Dogway/Avisynth-Scripts/blob/23086eeab07979898024f7eb4143d8084e62d333/MIX%20mods/FrameRateConverterMIX.avsi#L53).
NewNum=60000,NewDen=1000 for your case.
Guest
6th April 2023, 01:21
Just read a little (https://github.com/Dogway/Avisynth-Scripts/blob/23086eeab07979898024f7eb4143d8084e62d333/MIX%20mods/FrameRateConverterMIX.avsi#L53).
NewNum=60000,NewDen=1000 for your case.
Hi Dogway, I do read a lot, however, if it's not "staring me in the face", and obvious, then I have no idea what I'm looking for.
If it's any consolation, I sort of thought it might have been that..
Surely you have to realise that to a large % of ppl would just see a sea of numbers, letters & characters when looking at a filter script, but ppl like yourself that kind of "live & breathe" this stuff, it's just second nature.
I know it can be frustrating when having to explain things that you know, "like the back of your hand", to someone that really hasn't got a clue, unless it's really obvious.
That's why I have to ask.
I'm sure there are things that I know, and have learned to do, that you wouldn't have clue where to start...and it's that, that makes everything work.
We're all different.... different skills, knowledge, experience, etc, etc.
Respect!
EDIT:-
Unfortunately, I have run into another annoying issue, that clearly has nothing to do with FrameConverter, it will work for me with FrameDouble=true, but not NewNum=60000,NewDen=1000 :(
LeXXuz
6th April 2023, 07:30
Just a fair bit of warning to everyone using DGHDRtoSDR() for the prefilter chain of SMDegrain.
ALWAYS check the whitepoint manually of the prefilter clip with show=true parameter of SMDegrain. The default value of 400 was way too low for 10 out of 10 different HDR films I tested this with.
And with white=112 what I had seen here on some samples the prefilter clip was always almost black. Which means motion estimation is pretty useless as mvtools is only seeing a somewhat "blank" clip.
For all 10 of my tests I ended up with a whitepoint between 1200 and 1800. And I remember the old default value was ~1500. I have no idea why it is set to 400 now.
Guest
6th April 2023, 07:57
Just a fair bit of warning to everyone using DGHDRtoSDR() for the prefilter chain of SMDegrain.
ALWAYS check the whitepoint manually of the prefilter clip with show=true parameter of SMDegrain. The default value of 400 was way too low for 10 out of 10 different HDR films I tested this with.
And with white=112 what I had seen here on some samples the prefilter clip was always almost black. Which means motion estimation is pretty useless as mvtools is only seeing a somewhat "blank" clip.
For all 10 of my tests I ended up with a whitepoint between 1200 and 1800. And I remember the old default value was ~1500. I have no idea why it is set to 400 now.
Well, when I was first introduced the DGHDRtoSDR (just the other day), I did a couple of tests with 112, and it seemed OK, but then 400 was suggested, and that was, I thought, even better.
I have been using a Tweak function to reduce the color & increasing the brightness a little, but I think I can do away with that now :)
I will give that show=true parameter a try, and see how I go.
LeXXuz
6th April 2023, 09:40
Thanks, I guess that means its nVidia or bust...
You can try DGToneMap to see if it is any faster for you.
http://avisynth.nl/index.php/DGTonemap
It is the older filter I spoke about. But read the docs carefully. It needs more adjustment to your needs than DGHDRtoSDR.
Guest
6th April 2023, 10:20
You can try DGToneMap to see if it is any faster for you.
http://avisynth.nl/index.php/DGTonemap
It is the older filter I spoke about. But read the docs carefully. It needs more adjustment to your needs than DGHDRtoSDR.
I was just confirming that DGHDRtoSDR was optimised for nVidia (as most of DG's stuff is), fortunately, I mostly have nVidia's, so it's not an issue for me :)
Boulder
6th April 2023, 13:30
Just a fair bit of warning to everyone using DGHDRtoSDR() for the prefilter chain of SMDegrain.
ALWAYS check the whitepoint manually of the prefilter clip with show=true parameter of SMDegrain. The default value of 400 was way too low for 10 out of 10 different HDR films I tested this with.
And with white=112 what I had seen here on some samples the prefilter clip was always almost black. Which means motion estimation is pretty useless as mvtools is only seeing a somewhat "blank" clip.
For all 10 of my tests I ended up with a whitepoint between 1200 and 1800. And I remember the old default value was ~1500. I have no idea why it is set to 400 now.
I've used the filter default, which is 2000. The Avisynth wiki doesn't seem to have the latest information (v1.15-based) updated.
anton_foy
7th April 2023, 08:58
Thanks for Filmgrain+!
If you like I can provide to you 3k scans from various filmstocks in 10-bit dpx. format if you want to mimic the grain. They are just color charts but maybe I have some real life images too. It seems many of the filmstocks grain is less in the red channel. Maybe because the focus when developing the filmtypes was on clean skin tones and textures.
Dogway
7th April 2023, 09:36
So what would be a "safe" default to recommend in SMDegrain for DGHDRtoSDR? I set 59 because it worked for one or two cases (around 100 also) but now I'm not sure. Maybe the filter was asking for the reference white and not peak white?
Thanks for Filmgrain+!
If you like I can provide to you 3k scans from various filmstocks in 10-bit dpx. format if you want to mimic the grain. They are just color charts but maybe I have some real life images too. It seems many of the filmstocks grain is less in the red channel. Maybe because the focus when developing the filmtypes was on clean skin tones and textures.
Thanks! Just in time, next update will be re-matching the presets I've done and do the new ones. I prefer plates over grey background because I can study the amplitude and some other aspects better, but ultimately I will cross check with actual film content, so I guess color charts are perfect.
It's not only the film "brand" but within it there are several ISO so my concern is to mimic the shape of the grain, while ISO can be replicated with strength ('str' arg). Next week I will post an example for regraining a clip on scene basis. Instead of adding the filter inside ScriptClip I will add 4 examples at different strengths outside, and depending on a denoise metric, choose either one within ScriptClip.
I need a few frames at least for each stock to appreciate the temporal perception of grain, not only static grain shape. Specially the rarer Kodak ones and also some digital ones, like digital RED, GoPro, Alexa, whatever... Positive film prints also welcome.
anton_foy
7th April 2023, 11:30
Thanks! Just in time, next update will be re-matching the presets I've done and do the new ones. I prefer plates over grey background because I can study the amplitude and some other aspects better, but ultimately I will cross check with actual film content, so I guess color charts are perfect.
It's not only the film "brand" but within it there are several ISO so my concern is to mimic the shape of the grain, while ISO can be replicated with strength ('str' arg). Next week I will post an example for regraining a clip on scene basis. Instead of adding the filter inside ScriptClip I will add 4 examples at different strengths outside, and depending on a denoise metric, choose either one within ScriptClip.
I need a few frames at least for each stock to appreciate the temporal perception of grain, not only static grain shape. Specially the rarer Kodak ones and also some digital ones, like digital RED, GoPro, Alexa, whatever... Positive film prints also welcome.
Yes I believe there are a few frames in sequence but Im not sure how large the patches are on the color chart. Have to dig out the harddrive and sort the files out first. I think I have red epic footage aswell if lucky. Kodak 5219, 5213, 5217, 5207, fuji 8543, 8546, 8588, 8552 and more I think but let me see so I have them all in the same place or I need to search some more.
Edit: when I experimented to mimic the filmgrain I found that temporal movement got close to the real thing when generating it in about 8k size and then downsize and adding blur then sharpen. But this is tedious and time consuming for a script. Your solution looks much more efficient.
Dogway
7th April 2023, 11:51
Thank you! Yes 5213 is one of the rarer just like 5201. Also the Fuji I think, have no experience with them. You can PM me as I have one PM slot still.
LeXXuz
7th April 2023, 12:27
So what would be a "safe" default to recommend in SMDegrain for DGHDRtoSDR? I set 59 because it worked for one or two cases (around 100 also) but now I'm not sure. Maybe the filter was asking for the reference white and not peak white?
Difficult to set a default value I think. Highly depends on how the source was mastered. I tested this with this UHD Blu-ray just yesterday. Film is just mastered in SMPTE ST2086 HDR-10.
from Mediainfo:
Color range : Limited
Color primaries : BT.2020
Transfer characteristics : PQ
Matrix coefficients : BT.2020 non-constant
Mastering display color primaries : Display P3
Mastering display luminance : min: 0.0050 cd/m2, max: 1000 cd/m2
from DGIndex:
DEPTH 10
CHROMA_LOCATION 2
ASPECT 1 1
COLORIMETRY 9 16 9
IS_444 0
MASTERING 13250 34500 7500 3000 34000 16000 15635 16450 10000000 50
If I run DGHDRtoSDR() with white=400 on this one, the prefilter clip is very dark with no more details in the blacks. With white=100 and below it's almost entirely black.
I set it to 1500 which showed me a good balance between fine nuances still visible in deepest blacks and highest whites. My desk monitors are calibrated with SpyderX.
So far I did not come across anything outside of 1200-1800 range. That doesn't mean the next one could be outside that range, of course. :D
anton_foy
7th April 2023, 16:31
Thank you! Yes 5213 is one of the rarer just like 5201. Also the Fuji I think, have no experience with them. You can PM me as I have one PM slot still.
I found some files! I actually have from 5201 too but only in 2k. And the ones in 3k are only photographed with a still camera som the grain size is not accurate to super35 then. But I will send you it is 4.5gb in size. Any suggesion for uploading service that is free? Maybe I can buy extra for my google drive otherwise but that will be in a few days then.
Dogway
7th April 2023, 16:45
Difficult to set a default value I think. Highly depends on how the source was mastered.
It's only as a loose guidance, as 59 seemed to be way off... I guess 1500 will do right?
I found some files! I actually have from 5201 too but only in 2k. And the ones in 3k are only photographed with a still camera som the grain size is not accurate to super35 then. But I will send you it is 4.5gb in size. Any suggesion for uploading service that is free? Maybe I can buy extra for my google drive otherwise but that will be in a few days then.
Anything helps, I will also do some hunting and guess from everything I check. I have some gizmos (addons) in Nuke but for some reason they look horrible, more like salt & pepper noise than actually grain and by the looks of it I think grain is better applied in an opponent color model like YCbCr.
Maybe send me one of the 3K shots first, because being photographed instead of scanned might not be sufficient. You can upload to Drive if you have an unused account, OneDrive, Mega... Mediafire has 1Gb upload limit for no accounts.
anton_foy
7th April 2023, 17:28
It's only as a loose guidance, as 59 seemed to be way off... I guess 1500 will do right?
Anything helps, I will also do some hunting and guess from everything I check. I have some gizmos (addons) in Nuke but for some reason they look horrible, more like salt & pepper noise than actually grain and by the looks of it I think grain is better applied in an opponent color model like YCbCr.
Maybe send me one of the 3K shots first, because being photographed instead of scanned might not be sufficient. You can upload to Drive if you have an unused account, OneDrive, Mega... Mediafire has 1Gb upload limit for no accounts.
No all of them are scanned by Scanity scanner but only the 2k ones are filmed by a 35mm film camera while the 3k ones are from film stocks used in a analog still photography camera. So all of them are scanned but the area from the still camera negative differs in area and therefor resolution from the film camera ones are only 2k.
Edit: to clarify, all of them are scanned with the Scanity scanner. And some I realized are in 16bt rather than 10 bit.
Edit 2: I found also grey plates with grain in 4k that I bought but mostly bad compression artifacts yet I can send you these too.
Dogway
7th April 2023, 18:51
Well maybe, I think there's more value in 4K than 2K if it's not severely harmed because downscaling (or sampling at 1080) changes the grain structure. Anyway I don't need the full loop, one second or maybe less is enough, if it's intra only you can trim them. As for analog still photography film stock, for the time being I'm not going to work on them, have many thing piled to do on many fronts so want to finish this filter ASAP.
anton_foy
7th April 2023, 19:09
Well maybe, I think there's more value in 4K than 2K if it's not severely harmed because downscaling (or sampling at 1080) changes the grain structure. Anyway I don't need the full loop, one second or maybe less is enough, if it's intra only you can trim them. As for analog still photography film stock, for the time being I'm not going to work on them, have many thing piled to do on many fronts so want to finish this filter ASAP.
This was scanned 9 years ago so 2k was the only alternative then. The film stock from still photography is actually the motion picture film stocks just using a still camera instead of a motion picture camera. Just to clarify. No still film stocks used at all.
Edit: sorry about the confusion, the "analog still camera" scans that are 3k and the "film camera" scans in 2k. Only "motion picture film stocks used" for both cameras.
LeXXuz
8th April 2023, 06:14
It's only as a loose guidance, as 59 seemed to be way off... I guess 1500 will do right?
I think that'll be okay as a starting point. Maybe add this as a global parameter and the hint that it should be controlled via the prefilter preview and adjusted for best results?
Guest
10th April 2023, 03:59
I'm sure this has been asked before, but what's the different between the (similarly named) filters in the EX mods & MIX mods ?
Another question, what's the difference or advantages/disadvantages (if any) between using ConvertFPS(), to FrameRateConverter() ?
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.