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. |
25th May 2011, 11:56 | #701 | Link | |
Registered User
Join Date: Jan 2011
Posts: 121
|
Quote:
A thought just came to me though: The temporal smooths in QTGMC might GREATLY benefit from "gamma-corrected" smoothing, when it comes to thin horizontal details. See here to get an idea of what I'm talking about. The basic idea is that at ordinary gammas, any kind of smoothing or averaging ends up reducing the overall luminosity of areas (the softened grill of the car has been darkened excessively). To correct for this, you would reduce the gamma, perform your operations, and increase the gamma again. As a quick test to see if it might help, you could try sandwiching your QTGMC call between with two calls to levels or LaTo's Smoothlevels (the first reducing gamma and the second increasing it again). The optimal solution requires 10+ bit processing in Avisynth, but if the Smoothlevels solution makes the picture look better in the meantime, why not? If time is no object, you could even repair very subtle detail (least significant bits) lost in the gamma shifts by doing the following:
Last edited by Mini-Me; 25th May 2011 at 12:10. |
|
25th May 2011, 12:04 | #702 | Link |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 5,391
|
Regarding 'gamma correction' -- generally a good idea. But a simple un-gamma before QTGMC + re-gamma afterwards probably is no good idea. Besides of the 8bit problem, I assume that MVTools' motion search will not react very gracefully if ME is performed on a clip with linear gamma. If at all, then the motion search should be done on the normal input, and the gamma operations be done only in the parallel processing path ('super' clip & separate base clip for rendering).
__________________
- We´re at the beginning of the end of mankind´s childhood - My little flickr gallery. (Yes indeed, I do have hobbies other than digital video!) |
25th May 2011, 12:14 | #703 | Link | |
Registered User
Join Date: Jan 2011
Posts: 121
|
Quote:
Actually, by the same token, would motion search possibly be better if performed on a clip with higher-than-usual gamma? Last edited by Mini-Me; 25th May 2011 at 12:18. |
|
25th May 2011, 12:15 | #704 | Link |
Registered User
Join Date: Mar 2011
Posts: 48
|
Hi. According to this, the RemoveGrainSSE3.dll bug has been fixed. What is the official QTGMC author's stance on this? Can we revert to RemoveGrainSSE3 or should we still continue to use RemoveGrainSSE2.dll?
And I do not wish to step on any toes or insult anyone, but I have downloaded pretty much every free filter/plugin from MSU. Even though Mounir talks about a payware filter, if their freeware is any measure, I can safely say that their quality cannot match anything the high-performance plugins avisynth can throw at them. The demo pictures they show on their website are nothing more than demo pictures, not real-life applications. Believe me, I've tried Boolet, FieldsKit, Topaz Enhance et al, and QTGMC leaves them far behind. Your particular case is, as others have already mentioned quite difficult for any deinterlacer. |
25th May 2011, 13:30 | #705 | Link |
Registered User
Join Date: Jul 2010
Posts: 448
|
The fixed version of RemoveGrain has some changed and undocumented functionality. It comes with no source code. So it can't be recommended. In the last version with source code there is exactly one line of difference between SSE2 and SSE3 versions. It won't make a difference.
I tend to agree regarding the MSU plugins. Whilst the guys seem to know what they're doing, the plugins they do release are not very special. Their Video Quality Measurement tool is quite handy though. |
25th May 2011, 17:24 | #706 | Link | |
Registered User
Join Date: Apr 2009
Posts: 478
|
Quote:
|
|
29th May 2011, 21:36 | #708 | Link |
Anime addict
Join Date: Feb 2009
Location: Spain
Posts: 673
|
Update doc plugin in spanish. Link: http://www.mediafire.com/?1h1r5tf2t9t8rq1
__________________
Intel i7-6700K + Noctua NH-D15 + Z170A XPower G. Titanium + Kingston HyperX Savage DDR4 2x8GB + Radeon RX580 8GB DDR5 + ADATA SX8200 Pro 1 TB + Antec EDG750 80 Plus Gold Mod + Corsair 780T Graphite |
30th May 2011, 10:48 | #709 | Link |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 4,926
|
Hehe because without hard facts it's hard and these samples are known once schumacher and flag people here on doom9 are confronted with situations most test sequences shown their don't reproduce
And if you want to test the base of their algorithm you can do that http://www.yuvsoft.com/download/dein...ing/index.html And well it's Didée (nothing to add)
__________________
all my compares are riddles so please try to decipher them yourselves :) It is about Time Join the Revolution NOW before it is to Late ! http://forum.doom9.org/showthread.php?t=168004 Last edited by CruNcher; 30th May 2011 at 10:56. |
6th June 2011, 03:54 | #710 | Link |
zj262144
Join Date: Sep 2010
Posts: 105
|
First I'm new to QTGMC here...
A question maybe stupid for others but confused for me Could QTGMC use FFT3Dgpu instead of FFT3Dfilter? How?
__________________
MPC-HC 1.7.8 / LAV Filters 0.64+ (tMod) / XySubFilter 3.1.0.705 / madVR 0.87.14 Direct264 Mod (src & win32 builds): code.google.com/p/direct264umod (maybe outdated) |
6th June 2011, 20:08 | #711 | Link |
Registered User
Join Date: Jul 2010
Posts: 448
|
I guess you could replace the single call to FFT3DFilter in the script.
I have never done so because FFT3Dgpu is unstable for me. I believe it is also unstable generally with SetMTMode, which many people use with QTGMC. I don't think it would give a great speed up because denoising is only a small part of the processing (and not enabled by default anyway). |
7th June 2011, 01:01 | #713 | Link |
zj262144
Join Date: Sep 2010
Posts: 105
|
@ -Vit-
Thanks for the reply!
__________________
MPC-HC 1.7.8 / LAV Filters 0.64+ (tMod) / XySubFilter 3.1.0.705 / madVR 0.87.14 Direct264 Mod (src & win32 builds): code.google.com/p/direct264umod (maybe outdated) |
16th June 2011, 16:34 | #717 | Link | |
Registered User
Join Date: Jul 2010
Posts: 448
|
Quote:
Have you tried the various ideas from the first post? Particularly different versions of Avisynth MT and my modded plugins? Also try running MT at less than full load, that can help whilst still being faster. ____ On a related point, I recommend updating to nnedi3 0.94, it gives a nice speed-up (thanks tritical!). Last edited by -Vit-; 16th June 2011 at 16:38. |
|
16th June 2011, 21:58 | #718 | Link |
Registered User
Join Date: Nov 2004
Location: Poland
Posts: 2,843
|
I tried new plugins, all versions of avisynth and on HD sources and my 24core machine it crashes until I limit it to <4 cores. Even this sometimes crashes- only not using mt gives stable results, but 2fps is way to slow
It's a bit hopeless Quality is better than anything I've seen including big K$ solutions. Andrew Last edited by kolak; 16th June 2011 at 22:02. |
17th June 2011, 00:40 | #719 | Link |
Registered User
Join Date: Jul 2010
Posts: 448
|
Well, you can safely use a faster preset with HD material, e.g.
QTGMC( "Faster" ) Also, you should usually output to a lossless intermediate file when using QTGMC on HD. Then encode that lossless file to x264 or whatever. Otherwise Avisynth will run out of memory (it's still a 32-bit app, so limited to 2Gb). |
17th June 2011, 22:04 | #720 | Link | |
Registered User
Join Date: Nov 2004
Location: Poland
Posts: 2,843
|
Quote:
I have to try again 64bit, but last time I had no luck. Couldn't make it working at all Andrew |
|
|
|