DGDenoise
Re: About DGDenoise
Is the YV12 a CUDA/Nvidia restriction? I am asking because I try to avoid colorspace conversion to YV12 because of the Chroma upsampling and Chroma Interlace Problem.
Re: About DGDenoise
What color space are you interested in support for? Typical script?
These filters are designed to be used with DGSource() so obviously I implemented only YV12. That could change, however.
These filters are designed to be used with DGSource() so obviously I implemented only YV12. That could change, however.
Re: About DGDenoise
My tape captures are normally YUV or YUY2, 4:2:0 or 4:2:2. Hmm, now I think to remember that lossless 4:2:2 is not supported by Nvidia .....
Script like:
AviSource(xxxx.avi) #typically interlaced YUY2 4:2:2
bob() #optional
Crop(....)
Resize(....) #optional
addborders(...) #optional
ConverttoYV12() #for DGfilters
DGDenoise().DGSharpen()
separatefields().selectevery(4,0,3).weave() #optional re-interlace - when bobbed before
Then encode with x264 interlaced
Edit:
I am aware that x264 will convert to YV12 anyway, however I thought it would be better - if possible - to keep YUY2 for all the editing and filtering until the last step.
Script like:
AviSource(xxxx.avi) #typically interlaced YUY2 4:2:2
bob() #optional
Crop(....)
Resize(....) #optional
addborders(...) #optional
ConverttoYV12() #for DGfilters
DGDenoise().DGSharpen()
separatefields().selectevery(4,0,3).weave() #optional re-interlace - when bobbed before
Then encode with x264 interlaced
Edit:
I am aware that x264 will convert to YV12 anyway, however I thought it would be better - if possible - to keep YUY2 for all the editing and filtering until the last step.
Re: About DGDenoise
If your source is interlaced then you have to tell all the following filters for proper handling. So telling DGDenoise() the same via either ConvertToYV12() or directly if I added a parameter would be necessary.
And I would of course have to convert internally if I were to support YUY2 input, and that's why I would need a parameter to tell if the source is interlaced.
So I don't really follow your thinking. You can't get away from telling filters if the source is interlaced/progressive, unless of course you rely on the defaults. But in that case won't ConvertToYV12 default too?
Finally, you have to deinterlace first anyway unless you want trash as output.
Please help me to understand what you ask for here and why, in light of the above. I don't always grok things straightaway.
And I would of course have to convert internally if I were to support YUY2 input, and that's why I would need a parameter to tell if the source is interlaced.
So I don't really follow your thinking. You can't get away from telling filters if the source is interlaced/progressive, unless of course you rely on the defaults. But in that case won't ConvertToYV12 default too?
Finally, you have to deinterlace first anyway unless you want trash as output.
Please help me to understand what you ask for here and why, in light of the above. I don't always grok things straightaway.
Re: About DGDenoise
I thought leaving the YUY2 4:2:2 colorspace untouched would a priori eliminate certain chroma problems. For example YV12 interlaced needs to be cropped mod4 vertically, whereas YUY2 would accept mod2 cropping without chroma damage, if I am not mistaken.
Maybe it's just a fart as I have to deinterlace or separate the fields anyway for applying most of the filters, and putting converttoYV12(interlaced=true) early in the script is the way to go.
Maybe it's just a fart as I have to deinterlace or separate the fields anyway for applying most of the filters, and putting converttoYV12(interlaced=true) early in the script is the way to go.
Re: About DGDenoise
Yes, Sharc, I agree. Let's keep things as is for now. You're right that 4:2:2 support would be useful and I'd certainly want to support it when CUVID does. People are hopeful for nVidia Video SDK 8.0, but it is still awaited. On the other hand, it is only a limitation of CUVID decoding. I could make CUDA 4:2:2 filters. Let's see what nVidia Video SDK 8.0 brings us.Sharc wrote:I have to deinterlace or separate the fields anyway for applying most of the filters, and putting converttoYV12(interlaced=true) early in the script is the way to go.
Re: About DGDenoise
The spirit of adventure and discovery shines. So blessed you are to know such people. I wish they were forum members.hydra3333 wrote: This wasn't me (it hung on the shack wall for 30 years) but it may as well have been https://drive.google.com/open?id=0B5RV2 ... WhpcjZnY3M
Oh why not, a relative of mine is in this one https://drive.google.com/open?id=0B5RV2 ... HRZYWtFbDQ
![Smile :)](./images/smilies/icon_e_smile.gif)
- Aleron Ives
- Posts: 126
- Joined: Fri May 31, 2013 8:36 pm
Re: About DGDenoise
This might be a dumb question, but since you're working on adding new filters, are there any prospects for replicating the functionality of Decomb this way? That's my most-used filter, and getting a CUDA speedup for it would be welcome. I'm not sure how closely related this would be to your recent work on DGBobIM or whether CUDA is even appropriate for this purpose... ![Confused :?](./images/smilies/icon_e_confused.gif)
![Confused :?](./images/smilies/icon_e_confused.gif)
Re: About DGDenoise
Great idea, Aleron! Sure, we could speed up field matching and decimation. Why didn't I think of these obvious things?
Thank you for the valuable suggestion.
DGBobIM was mostly a proof-of-concept for how screwed up the IMSDK API is. Not exciting to work on that stuff.
BTW, Aussies swim real good. We may have to keep an eye on them.
![Thinking :scratch:](./images/smilies/icon_scratch2.gif)
DGBobIM was mostly a proof-of-concept for how screwed up the IMSDK API is. Not exciting to work on that stuff.
BTW, Aussies swim real good. We may have to keep an eye on them.
Re: About DGDenoise
+1 for implementing Decomb (especially the FieldMatching/IVTC functionality of telecide() )Aleron Ives wrote:This might be a dumb question, but since you're working on adding new filters, are there any prospects for replicating the functionality of Decomb this way? That's my most-used filter, and getting a CUDA speedup for it would be welcome. I'm not sure how closely related this would be to your recent work on DGBobIM or whether CUDA is even appropriate for this purpose...
P.S.
I also like the show= and debug= options of FieldDeinterlace(), however speed is not critical for visual analysis.
Re: About DGDenoise
+1 as well
Re: About DGDenoise
Thank you, the new gpu based filters work nice.
OK, I did a test or two displaying an interleaved (source,result1,result2) clip in vsedit.
Reasonably clean, if blocky, 15Mb Source: https://drive.google.com/open?id=0B5RV2 ... Hk1UlA5c2c
Card: 750Ti, CPU: i3820 (due for replacement next year; likely a cheapie ryzen 1800X and 1050Ti, not a 1070 though given touted v2's of 1060 and 1080)
Confirming per some other posts eg viewtopic.php?f=8&t=506&start=170#p6074 that the default setting (strength=0.15) for DGDenoise seem to yield a more"softened" visual result compared to KNLMeansCL at defaults (d=1 temporal) at least on my test source. So, easy, use .06 or something.
Sometimes a really old movie can be a bit of a shocker with grain and whatnot and the best thing I've found to date has been the old MDegrain1/2/3 eg
video=MDegrain3i2(video,blksize=8,overlap=4,dct=0)
which I suppose does OK due to temporal processing ?
I haven't such a source to hand to try, so what would be your thoughts re DGDenoise / KNLMeansCL(d=3) / MDegrain for those types of sources ?
I see with interest you considered the possibility of temporal option viewtopic.php?f=8&t=506&start=210#p6137 and then some hesitation viewtopic.php?f=8&t=506&start=220#p6153 and then a possible position of sticking with spatial viewtopic.php?f=8&t=506&start=260#p6253
... I'm hoping the DG density matrix is flagging that gpu temporal denoising still has a significant possibility of a state of existance
... no plans for temporal ?
(google gives the words but unfortunately not the intellect to comprehend it).
Just came across the tips from this crowd, although I don't really know what their credentials are
http://www.cineticstudios.com/blog/2015 ... ction.html
vapoursynth x64 shouldn't make any difference, eg
[/size]
OK, I did a test or two displaying an interleaved (source,result1,result2) clip in vsedit.
Reasonably clean, if blocky, 15Mb Source: https://drive.google.com/open?id=0B5RV2 ... Hk1UlA5c2c
Card: 750Ti, CPU: i3820 (due for replacement next year; likely a cheapie ryzen 1800X and 1050Ti, not a 1070 though given touted v2's of 1060 and 1080)
Confirming per some other posts eg viewtopic.php?f=8&t=506&start=170#p6074 that the default setting (strength=0.15) for DGDenoise seem to yield a more"softened" visual result compared to KNLMeansCL at defaults (d=1 temporal) at least on my test source. So, easy, use .06 or something.
Sometimes a really old movie can be a bit of a shocker with grain and whatnot and the best thing I've found to date has been the old MDegrain1/2/3 eg
video=MDegrain3i2(video,blksize=8,overlap=4,dct=0)
which I suppose does OK due to temporal processing ?
I haven't such a source to hand to try, so what would be your thoughts re DGDenoise / KNLMeansCL(d=3) / MDegrain for those types of sources ?
I see with interest you considered the possibility of temporal option viewtopic.php?f=8&t=506&start=210#p6137 and then some hesitation viewtopic.php?f=8&t=506&start=220#p6153 and then a possible position of sticking with spatial viewtopic.php?f=8&t=506&start=260#p6253
... I'm hoping the DG density matrix is flagging that gpu temporal denoising still has a significant possibility of a state of existance
![Smile :)](./images/smilies/icon_e_smile.gif)
(google gives the words but unfortunately not the intellect to comprehend it).
Just came across the tips from this crowd, although I don't really know what their credentials are
http://www.cineticstudios.com/blog/2015 ... ction.html
vapoursynth x64 shouldn't make any difference, eg
Code: Select all
import vapoursynth as vs
##import havsfunc as haf # http://forum.doom9.org/showthread.php?t=166582
import havsfuncTS as haf # this version uses vanilla TemporalSoften instead of TemporalSoften2, as it will be "better" over time
import mvsfunc as mvs # http://forum.doom9.org/showthread.php?t=172564
import finesharp as finesharp # http://forum.doom9.org/showthread.php?p=1777815#post1777815 http://avisynth.nl/index.php/FineSharp
core = vs.get_core(accept_lowercase=True) # leave off threads=8 so it auto-detects threads
# the r'' indicates do not treat special characters and accept backslashes
core.std.LoadPlugin(r'C:\SOFTWARE\Vapoursynth-x64\vapoursynth64\plugins\dll-to-choose-from\KNLMeansCL.dll') # the r'' indicates do not treat special characters and accept backslashes
# LOAD 64 bit AVISYNTH plugins into the avs namespace
core.avs.LoadPlugin(r'C:\SOFTWARE\Vapoursynth-x64\DGIndex\DGDecodeNV.dll')
def main():
video = core.avs.DGSource(r'.\z.dgi',deinterlace=1,resize_w=720,resize_h=576) # deinterlace=1 means single rate deinterlacing
videooriginal = video
video1 = core.knlm.KNLMeansCL(video, device_type="gpu", d=1, a=2)
video2 = core.avs.DGDenoise(video,strength=0.06)
#video = core.avs.DGSharpen(video,strength=0.40) #
video = core.std.Interleave([core.text.Text(videooriginal, 'Source clip'), core.text.Text(video1, 'LNKMeansCL clip'), core.text.Text(video2, 'DGDenoise clip')])
video.set_output()
return True
main()
I really do like it here.
Re: About DGDenoise
It's not worth speculating about it in the absence of a clip. When you have one to share I would be happy to discuss comparative results.hydra3333 wrote:Sometimes a really old movie can be a bit of a shocker with grain and whatnot and the best thing I've found to date has been the old MDegrain1/2/3 eg
video=MDegrain3i2(video,blksize=8,overlap=4,dct=0)
which I suppose does OK due to temporal processing ?
I haven't such a source to hand to try, so what would be your thoughts re DGDenoise / KNLMeansCL(d=3) / MDegrain for those types of sources ?
I've asked several times for a clip that clearly shows the benefits of temporal processing, either alone or in conjunction with spatial processing. Do you have one? That is what I would need to find the motivation to do something temporally. Meanwhile, there is always TemporalSoften(). My personal perspective (which can be altered by evidence) is that ghosting is anathema that I would avoid like the plague in the absence of palpable overriding considerations. Yeah, yeah, scene change detection. But not every frame is a scene change while it can still be full of motion, and hence ghosting. Please refute my view with some evidence, i.e., a clip.I see with interest you considered the possibility of temporal option viewtopic.php?f=8&t=506&start=210#p6137 and then some hesitation viewtopic.php?f=8&t=506&start=220#p6153 and then a possible position of sticking with spatial viewtopic.php?f=8&t=506&start=260#p6253
... I'm hoping the DG density matrix is flagging that gpu temporal denoising still has a significant possibility of a state of existance... no plans for temporal ?
If you want to consider motion compensation to combat ghosting, that's perfectly valid. But that has to wait for my CUDA motion estimation stuff.
DG density matrix. That's clever. Not everyone will grok it, though, especially with negative off-diagonal terms.
It's just warmed-over wives' tales, aka, conventional "wisdom", justifying some commercial product recommendations. I can't take seriously an article that provides a tip on noise reduction that advises to add noise.Just came across the tips from this crowd, although I don't really know what their credentials are
http://www.cineticstudios.com/blog/2015 ... ction.html
![facepalm :facepalm:](./images/smilies/icon_facepalm.gif)
Monty Python video enhancement algorithm:
1. Remove noise.
2. Add noise.
That tip is there only to push some commercial tools. The tip to prefer temporal processing is also just a push for a commercial denoiser. They conveniently neglect to mention ghosting. And it's strange that not a single image is given to support anything they say.
Re: DGDenoise
I am getting ugly artefacts (broad diagonal color stripes) with chroma=true in DGDenoise.
My source is interlaced video. I separate the fields before applying the filter. Unless I am missing something you should be able to duplicate the issue with any source clip.
My source is interlaced video. I separate the fields before applying the filter. Unless I am missing something you should be able to duplicate the issue with any source clip.
Re: DGDenoise
Yikes! I'll get on it this morning. Thanks for the report.
Re: DGDenoise
All fixed. Thanks for reporting it.
Re: DGDenoise
Confirmed. It's working.
Re: DGDenoise
Cool, thanks again Sharc.
Re: DGDenoise
Does DGDenoiseNV handle what is on this sample, film grain or mosquito noise, I believe?
http://www.mediafire.com/file/1djsss779 ... sample.mkv
If not, can you recommend a x64 filter?
http://www.mediafire.com/file/1djsss779 ... sample.mkv
If not, can you recommend a x64 filter?
Re: DGDenoise
Something is broken. Investigating...
Re: DGDenoise
Oy, that last slipstream was brain-dead.
OK, I fixed the DGDenoise problem. Now I have one little issue in DGTelecide. Fixes coming soon...
Thanks for pointing this out, gonca.
![Embarrassed :oops:](./images/smilies/icon_redface.gif)
OK, I fixed the DGDenoise problem. Now I have one little issue in DGTelecide. Fixes coming soon...
Thanks for pointing this out, gonca.
Re: DGDenoise
Thanks for creating the filters
Re: DGDenoise
Thanks. Of course, it would be better if they worked properly.
I just slipstreamed the fix. Heading over to the binaries thread to announce it.
![Wink ;)](./images/smilies/icon_e_wink.gif)
I just slipstreamed the fix. Heading over to the binaries thread to announce it.
Re: DGDenoise
This works pretty good on your sample, gonca:
dgsource("sample.dgi")
dgdenoise(strength=2.0,searchw=9,chroma=true)
dgsharpen()
That's industrial strength. Reduce strength and/or searchw, or turn off chroma, if you like.
dgsource("sample.dgi")
dgdenoise(strength=2.0,searchw=9,chroma=true)
dgsharpen()
That's industrial strength. Reduce strength and/or searchw, or turn off chroma, if you like.
Re: DGDenoise
I have read the documentation but would you recommend searchw=9 or chroma+true over the defaults in general terms?