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. |
8th March 2008, 23:10 | #301 | Link |
Registered User
Join Date: Sep 2006
Posts: 72
|
Didée, Thankyou. Great explanation.
You see, I'm always still learning, and I get frustrated when I can't see a solution that you see straight away. All I need is a brief explanation, and a possible script demo, and I learn from that. Once again, thankyou. |
9th March 2008, 20:27 | #302 | Link | |
Registered User
Join Date: Oct 2007
Location: Forest of the Trufulas
Posts: 37
|
Quote:
TemporalDegrain is awesome, but I have to check the TV guide before I invoke it to see if there is anything else I wanted to capture in the next day or so before I begin encoding. |
|
10th March 2008, 17:51 | #303 | Link | |
Guest
Posts: n/a
|
Quote:
What I do know is that when I would call TemporalDegrain, it would take about 30sec to generate a frame, whereas mine took maybe a few seconds. In retrospect, I've found it to blur fast motion stuff a bit too much for what I intended to use it for, but I'm still trying to run with the idea of using the median aspects of Clense with mo-comp'd frames. -G |
|
21st April 2008, 23:55 | #304 | Link |
Registered User
Join Date: Jun 2002
Location: Greece
Posts: 242
|
I think that there is a mistake in Didée's post #33.
Code:
o = last f = o.MinBlur(1,2).MinBlur(2,2).RemoveGrain(11,-1) f.FluxSmoothT(7).mt_AddDiff(mt_MakeDiff(o,f,U=1,V=1),U=4,V=4) # eventually, limit the maximum pixel change to +/- 2 : mt_LutXY(last,o,"x 2 + y < x 2 + x 2 - y > x 2 - x ? ?",U=2,V=2) That is pixel change = 5 In my opinion the right syntax is: Code:
o = last f = o.MinBlur(1,2).MinBlur(2,2).RemoveGrain(11,-1) f.FluxSmoothT(7).mt_AddDiff(mt_MakeDiff(o,f,U=1,V=1),U=4,V=4) # eventually, limit the maximum pixel change to +/- 2 : mt_LutXY(o,last,"x 2 + y < x 2 + x 2 - y > x 2 - y ? ?",U=2,V=2)
__________________
Greece PAL User... |
22nd April 2008, 12:06 | #305 | Link |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 5,389
|
@Nikos: Exactly like you said, that LUT expression was wrong. Well spotted, thanks for noting!
Also, there's something strange with >> mt_AddDiff(mt_MakeDiff(o,f,U=1,V=1),U=4,V=4) UV=4 means copy chroma from 2nd clip argument. The 2nd clip argument is mt_MakeDiff(o,f,U=1,V=1), which has chroma in an undefined state. Funny that this seems to output correct chroma nonetheless ... LUT and chroma issues are in the script of post#33 are fixed now.
__________________
- 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!) |
22nd April 2008, 14:13 | #306 | Link |
Registered User
Join Date: Jun 2002
Location: Greece
Posts: 242
|
Thanks Didée for the correction and for all your work.
From my tests on a very problematic HD movie the results from the script was great. The dirty dancing effect reduced with almost no smoothing. I had tried many other filters without success. Now the usual questions 1. In masktools Round(1.5)=2 or 1. 2. Why in mt_makediff with identical clips, the difference is 128 and not 0 like maths. In general i don't understand well the meaning of 128 3. It's a good idea to use the motion compensate ML3DexGPU for prefiltering in my MC-denoise scripts? I tried your script with the ML3DexGPU and the result happens to be sufficient and pleasant. This prefilter combo is able to cut down the dirty dancing noise almost completely with minimal blurriness. Thanks again!!!
__________________
Greece PAL User... |
23rd April 2008, 12:14 | #307 | Link |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 5,389
|
1. It should follow the usual convention for rounding, .5 is rounded upwards. (It appears to be so ... but don't nail me on that it does so in each possible case. I'm not the coder of MaskTools.)
2. A pixel can't have a negative value, only 0-255. In order to handle "negative" differences, the range -127..0..127 is offsetted to 0..128..255. 3. You tell, I don't know. The exact operation of ML3Dex isn't fully clear to me (have been a bit lazy when looking through that pdf) ... however in practice, it doesn't impress me too much. The temporal artefacts in motion areas (resp. areas with erroneous motion compensation) are pretty much the same as those of plain temporal median, so there's no benefit in that respect. In areas without motion (resp. in areas with correct motion compensation), it does remove a bit more signal spikes, no matter whether it's noise or detail. Thus, for me ML3Dex isn't a interesting option. And ML3DexGPU isn't because I don't have GPU acceleration. If it works sufficient for you, then you answered your own question.
__________________
- 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!) |
23rd April 2008, 15:09 | #308 | Link | |
Registered User
Join Date: Jun 2002
Location: Greece
Posts: 242
|
Quote:
I suppose that clip them to +/- 127. Thanks again!!!
__________________
Greece PAL User... |
|
30th April 2008, 07:21 | #309 | Link |
Registered User
Join Date: Feb 2003
Location: Russia, Moscow
Posts: 854
|
Hi folks!
Simple idea. I very frequently use MVDegrain3 for denoising VHS cassette capture. I use big thSAD 800 for luma and 1200 for chroma for many parts video this work very good, but for frame with big scan I see ghosting, may be will be useful use mask with motion estimation (vector length). Separate all frame to three types slow motion, medium motion and fast motion (depending from value motion vector) and use three MVDegrain3 and after use mask. yup. |
11th October 2009, 07:46 | #310 | Link |
Registered User
Join Date: Mar 2008
Posts: 25
|
Hi to all, I'm encoding Matrix Revolutions from my HDDVD and i wanted to clean the flickering on the background (minimizing detail loss) that's sometimes there fro compressibility purpose. I've checked the first pages of the thread and tried this script from Didée. The script doesn't give me any error nor when I load it nor when I'm encoding but the results are very strange with some frames getting more accelerated than the others.
Samples http://www.megaupload.com/?d=J6ISVCM3 - Encoded http://www.megaupload.com/?d=VAOBD7FL - Source Watch the logo, this effect is repeated across all the movie making it unwatchable. If I use only dss and crop the video is perfect, how can I solve??? Last edited by Snake91; 11th October 2009 at 07:49. |
11th October 2009, 15:00 | #311 | Link | |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 5,389
|
Quote:
Do not use DSS. DSS is not frame accurate on seeking. With a script that's so ressource hungry as the one you're referring to, it is very likely that frames will be requested out-of-(linear)-order, and that's where DSS may and will cause problems. Also, I don't know the HD version of that movie, only the SD one ... and that one is not extraordinarily noisy. I'd suspect that you don't need such a complex denoising strategy for this movie, and that a simple MDegrain2|3 should be sufficient. (In particular, it's the act of MDegraining an already-MDegrain'ed clip that is eating ressources for breakfast. Such should not be done when poking in the blue, but only on well-aimed intention.)
__________________
- 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!) |
|
11th October 2009, 19:30 | #312 | Link | ||
Registered User
Join Date: Mar 2008
Posts: 25
|
Quote:
Thanks a lot!!! Quote:
|
||
26th June 2010, 20:38 | #314 | Link |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 5,389
|
That script is based on FluxSmooth and MedianBlur. Unfortunately, neither of them has been ported to x64 yet.
It would be possible to construct something similar. MedianBlur can be done via mt_luts(). FluxSmooth could be approximated with a combination of Clense and TemporalSoften. But no, seems that Clense is not included in the current compilation of RemoveGrain_x64. (Not Joshy's compilation. And kassandro's 64bit compilation is said to not work at all)(?) - So it would need to be built by a 3-fold mt_logic() combination. Workarounds for workarounds for workarounds. The result would probably run 5 to 10 times slower than the 32bit script. That's not really worth the effort. Much better choice: - Instead of challenging me to script that, challenge the plugin guys to port FluxSmooth and MedianBlur to 64bit. Possibly also Clense. - For bonus points, someone write a plain Temporal-Median Filter that is actually usable. (MedianBlurT is not, if radius>2.)
__________________
- 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!) |
26th June 2010, 22:22 | #315 | Link |
Acid fr0g
Join Date: May 2002
Location: Italy
Posts: 2,537
|
Didée you are right and I apologise for threatening your patience My disappoint comes from the impossibility to run MCTD in x64. After some frames in MT it just plain crashes.
I have some very difficulties to encode BD (Save private Ryan to tell one) and using higher CRF to fit a DVD9 is not an option as quality would suffer too much. I am currently trying TemporalDegrain or MC Degrain3, however believe me or not the result are always over 10 GB. MCTD_x64 could be a solution. It's a pity it does not exist =)
__________________
@turment on Telegram |
13th January 2011, 15:56 | #316 | Link |
Registered User
Join Date: Oct 2009
Posts: 212
|
Didée thank you for the script.
Really calms down that "naasty dance effect of grain". I was wondering could that script be modified to have stronger effect? In some of my Dvd sources it doesn't calm down grain fully, and Mdegrain after isn't really effective and produces smearing in those areas where that dancing effect is stronger mostly in the CGI elements of some movies that I tried on. Thanks Last edited by SilaSurfer; 13th January 2011 at 16:01. |
13th January 2011, 16:36 | #317 | Link |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 5,389
|
This thread has 16 pages, 300+ posts, and quite a few scrpts have been posted. Which script exactly are you speaking of?
If it's the initial denoising script I had posted - meanwhile converted to "TemporalDegrain" by Sagekilla - that one is basically performing source.MDegrain3().MDegrain3() ... ... so yes, you are right: using MDegrain after that isn't really effective. Why should it, after all. But maybe we're talking past each other. Please specify.
__________________
- 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!) |
14th January 2011, 13:30 | #319 | Link | |||
Registered User
Join Date: Oct 2009
Posts: 212
|
Quote:
Quote:
Quote:
This one o = last f = o.MinBlur(1,2).MinBlur(2,2).RemoveGrain(11,-1) f.FluxSmoothT(7).mt_AddDiff(mt_MakeDiff(o,f,U=2,V=2),U=4,V=4) # eventually, limit the maximum pixel change to +/- 2 : # mt_LutXY(o,last,"x 2 + y < x 2 + x 2 - y > x 2 - y ? ?",U=2,V=2) # to compare: stackvertical(o,last) #interleave(o,last) return(last) To modify it to have more stronger effect or am I mixing apples with oranges? Thank you |
|||
14th January 2011, 14:08 | #320 | Link |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 5,389
|
The Question is - what are the apples, and what are the oranges?
In which way should it be stronger? Is it that FluxSmooth isn't strong enough (is there still residual flicker of low spatial frequencies)? Or is it that too much grain is in the output? If it's the latter - the whole purpose of this script is to not touch grain at all, and to calm down only the low spatial frequencies.
__________________
- 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!) |
Thread Tools | Search this Thread |
Display Modes | |
|
|