Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
27th April 2022, 11:40 | #922 | Link |
Registered User
Join Date: Dec 2007
Location: Enschede, NL
Posts: 301
|
Of course it does.
__________________
Roelofs Coaching |
11th June 2022, 16:35 | #923 | Link |
Registered User
Join Date: Apr 2013
Posts: 346
|
I am moving to 64-bit and have encountered errors when applying EZDenoise. It is throwing off error messages about “Zs_Rf_Shared.avsi, line 1619” and “QTGMC.avsi, line 799” (which refers to FFT3D). However, I have the current related dll’s for these filters in both SYSWOW and plugins64.
Without EZDenoise, QTGMC works fine. It also works, with EZDenoise, when I run QTGMC in Avisynth 32-bit. UPDATE: This seems to be caused by the fft3dfilter.dll (currently using v2.10). I suspect this because, when I remove the 32-bit version from the Avisynth 32-bit plugins folder, I get the same errors. It is as though the 64-bit fft3dfilter.dll does not exist in the plugins64 folder ...but it is there. I did try downloading it, again, to see if the first one was corrupted. Last edited by Danette; 11th June 2022 at 18:11. |
12th June 2022, 02:16 | #924 | Link |
Registered User
Join Date: Jan 2018
Posts: 2,156
|
fft3dfilter.dll 3.3.10 here
https://forum.doom9.org/showthread.p...37#post1965537 |
12th June 2022, 14:58 | #925 | Link | |
Registered User
Join Date: Apr 2013
Posts: 346
|
Quote:
You would think that the "AviSynth+ x64 plugins" page would reference the link that you posted, rather than the defective fftw-3.3.5-dll64.zip However, I found some behavior that contradicts instructions on the QTGMC wiki page for placement of the DLL's and am looking for confirmation that it is ok to do this: For 64-bit Avisynth, I found that renaming the 64-bit libfftw3f-3.dll to FFTW3.dll, as instructed, then placing that FFTW3.dll file in the plugins64 folder is necessary for 64-bit functionality. The libfftw3f-3.dll is not needed at all, although having libfftw3f-3.dll in SysWOW64 does not negatively affect 64-bit Avisynth. For 32-bit Avisynth, it is necessary to place the 32-bit libfftw3f-3.dll into either the System32 or SysWOW64 folders for 32-bit functionality, and the FFTW3.dll is not needed at all. Last edited by Danette; 12th June 2022 at 22:35. |
|
12th June 2022, 23:37 | #927 | Link | ||
Registered User
Join Date: Apr 2013
Posts: 346
|
Quote:
Quote:
So …as mentioned in the OP, this is for QTGMC functionality using EZDenoise. If I do what I pointed out works: FFTW3.dll (64-bit) in plugins64 and libfftw3f-3.dll (32-bit) in either sysWOW64 or System32, can you foresee any other difficulties with QTGMC behavior, when running either Avisynth+ 64-bit or Avisynth+ 32-bit? Last edited by Danette; 13th June 2022 at 00:20. |
||
13th June 2022, 01:56 | #928 | Link | |
Registered User
Join Date: Jan 2018
Posts: 2,156
|
Quote:
|
|
3rd August 2022, 14:27 | #931 | Link |
Registered User
Join Date: Mar 2007
Posts: 217
|
Hi, I have 2 questions ragarding restoration of badly deinterlaced video:
1. The documentation states that InputType=3 "complements field parity of the input", what does this mean in layman's terms? Is InputType=3 a bit slower than InputType=2 but possible more pleasing to the eye? 2. Is InputType=2/3 comparable in quality to InputType=0 with SelectEven()? InputType=2/3 only produces frames for half of the fields, but does it still use the "discarded" fields as information sources for the frames it produces? Or does it have less information to work with than InputType=0? Or is this question stupid and I have a wrong impression of how QTGMC works? |
3rd August 2022, 19:41 | #932 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,781
|
InputType=3 uses ComplementParity
|
18th September 2022, 12:00 | #933 | Link |
Registered User
Join Date: Jul 2018
Posts: 1,060
|
Some user tried use QTGMC https://raw.githubusercontent.com/re...0up/QTGMC.avsi for both deinterlacing and denoising but increasing TR2 for poor quality VHS recordings makes almost no result. So the recommendation was to increase ThSAD2 from default 4*8*8=256 to some higher (like 400 and more). But other user points to very small ThSCD1 default value of 180.
Typically setting of thSAD > thSCD1 for MDegrain makes almost no effect because low thSCD1 fail total frame as 'scene change' so it is not included in 'denoise' process. But I have idea may be too low ThSCD1 is also used for some other purposes inside QTGMC (not only denoise) so it is no good to raise ThSCD1 if noise level is high at input clip and increasing of TR2 and ThSAD2 make no help to denoising ? Or it is safe to increase ThSCD1 to any required value for denoise only and it will not harm other parts of deinterlacing ? Also why defaults of ThSCD1 of 180 is visibly lower of ThSAD2 of 256 ? In typical mvtools/MDegrain defaults thSCD1 is 400 and thSAD is 400. So thSCD1 is about equal to thSAD. |
20th September 2022, 01:37 | #934 | Link | |
Registered User
Join Date: Jan 2012
Location: Mesopotamia
Posts: 2,587
|
Quote:
__________________
See My Avisynth Stuff Last edited by real.finder; 20th September 2022 at 01:41. |
|
10th March 2023, 05:25 | #935 | Link |
Registered User
Join Date: Aug 2016
Posts: 609
|
It seems QTGMC has an issue with moire on high frequency patterns. This is stronger moire than you would get with just Bob() or bwdif(field=-2, thr=2)
A suggestion posted by Didee here was to do a lowpass filter beforehand. I've implemented something like this, but the issue I've run into is that it blends with pixel above+below which for interlaced video could be previous/next frame and so you end up with blended frames on motion. I am thinking there must be some way to apply a low pass filter to interlaced material without first deinterlacing it. Back in analogue days when they used deflicker filter for CRT's I don't think they are deinterlacing it first before applying the deflicker filter. So there must be some way to lowpass filter each field without resulting in blended frames in motion - can anyone advise? |
10th March 2023, 06:23 | #936 | Link | |
Registered User
Join Date: Sep 2007
Posts: 5,374
|
Quote:
ie. separatefields(), apply some lowpass (e.g. vertical blur) , weave() |
|
10th March 2023, 08:41 | #937 | Link | |
Registered User
Join Date: Aug 2016
Posts: 609
|
Quote:
Wow, how did I not think of that edit: ah yeah, it doesn't seem to work very well. Code:
SeparateFields() strength = 0.25 # 0.0=off, 0.25=mid, 0.5=max orig = last shift_up = PointResize(orig.width, orig.height, 0.0, 1.0, orig.width, orig.height) shift_down = PointResize(orig.width, orig.height, 0.0, -1.0, orig.width, orig.height) blend_up = Merge(orig, shift_down, strength) blend_down = Merge(orig, shift_up, strength) Merge(blend_up, blend_down, 0.50) AssumeFieldBased() Weave() Last edited by flossy_cake; 10th March 2023 at 08:58. |
|
10th March 2023, 10:58 | #938 | Link |
Registered User
Join Date: Aug 2016
Posts: 609
|
I see QTGMC has a ton of parameters that can be fine tuned - does anyone know which ones might affect moire? I'm talking about this sort of thing: https://imgsli.com/MTYxMTM3 (look at her left sleeve... it's more noticeable in motion)
Tried playing with some of the nnedi3 search radius params without success. Here is the source clip: https://drive.google.com/file/d/15UX...ew?usp=sharing |
10th March 2023, 12:34 | #939 | Link |
Registered User
Join Date: Aug 2017
Location: Italy
Posts: 114
|
I see the "moire effect" also on the original video, at least using FFMpeg2 as filter source: https://imgsli.com/MTYxMTYx
QTGMC extends it to more areas / frames
__________________
A channel on S-VHS / VHS capture and AviSynth restoration https://www.youtube.com/channel/UCMs...h1MmNAs7I8nu4g |
10th March 2023, 14:10 | #940 | Link | |
Registered User
Join Date: Aug 2016
Posts: 609
|
Quote:
And yes I do acknowledge that if we interpolate fields to progressive frames with Bob() or bwdif() there will be moire artefacts too, but they are a lot less intense than QTGMC. Probably because QTGMC is trying really hard to make these smooth antialiased lines everywhere so that just naturally results in more contiguous moire bands and I'm not sure there is any solution to that. Last edited by flossy_cake; 10th March 2023 at 14:23. |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|