RemoveDirt - Revision history

Pinterf: /* SCSelect */ mention YUY2 unsupport, cache hints

2025-01-09T07:20:19Z

‎SCSelect: mention YUY2 unsupport, cache hints

Pinterf: /* RestoreMotionBlocks */ YUY2 planar not supported

2025-01-09T07:18:23Z

‎RestoreMotionBlocks: YUY2 planar not supported

Pinterf: New version 1.1

2025-01-09T07:14:58Z

New version 1.1

Pinterf: /* Description */

2025-01-09T07:11:57Z

‎Description

Reel.Deal: /* Change Log */

2020-06-28T22:30:25Z

‎Change Log

Reel.Deal: add Deep_color_tools category

2020-06-25T17:27:19Z

add Deep_color_tools category

Reel.Deal: /* Requirements */

2020-06-25T04:43:14Z

‎Requirements

Reel.Deal: cosmetics, link updates

2020-06-25T04:31:00Z

cosmetics, link updates

Reel.Deal: add x64 category

2020-03-16T19:40:13Z

add x64 category

Pinterf: /* RestoreMotionBlocks */ explain pthreshold/cthreshold for 10+ bits

2019-05-21T07:17:45Z

‎RestoreMotionBlocks: explain pthreshold/cthreshold for 10+ bits

@@ Line 162: / Line 162: @@
 <br>
 ::{{Par2|planar|bool|false}}
-:::If you use planar YUY2 then you have to set "planar=true" (false is the default value).
+:::If you use planar YUY2 then you have to set "planar=true" (false is the default value). The parameter is ineffective from v1.0 since YUY2 is no longer supported.
 <br>
 ::{{Par2|cache|int|2}}
 ::{{Par2|gcache|int|0}}
-:::Undocumented parameters.
+:::Undocumented parameters, meant to add Avisynth video cache hints (up to Avisynth 2.6).
 <br>

@@ Line 38: / Line 38: @@
 <br>
 ::{{Par2|planar|bool|false}}
-:::If you use planar YUY2 then you have to set "planar=true" (false is the default value).
+:::If you use planar YUY2 then you have to set "planar=true" (false is the default value). The parameter is ineffective from v1.0 since YUY2 is no longer supported.
 <br>
 ::{{Par2|show|bool|false}}

@@ Line 2: / Line 2: @@
 {{Filter3
 | {{Author/kassandro}}, {{Author/pinterf}}
-| v0.9.2
+| v1.1
-| [http://github.com/pinterf/RemoveDirt/releases RemoveDirt-0.9.2.7z]
+| [http://github.com/pinterf/RemoveDirt/releases RemoveDirt-1.1.7z]
 | Luma Equalization
 | [http://www.gnu.org/licenses/gpl-2.0.txt GPLv2]
@@ Line 205: / Line 205: @@
 <br>
 == Change Log ==
 * v0.9.2 (20190324)

@@ Line 9: / Line 9: @@
 == Description ==
-RemoveDirt is a temporal cleaner for AviSynth 2.6 and [[AviSynth+]]. It has now become a script function which involves RestoreMotionBlocks and various filters from the [[RgTools|RemoveGrain]] package.
+RemoveDirt is a temporal cleaner for AviSynth 2.6, [[AviSynth+]] and VapourSynth. It has now become a script function which involves RestoreMotionBlocks and various filters from the [[RgTools|RemoveGrain]] package.
 <br>
 <br>
@@ Line 16: / Line 16: @@
 *[[#SCSelect|SCSelect]] is a scence change detention filter meant to be use with RestoreMotionBlocks.
 <br>
 == Requirements ==
 * [x86]: [[AviSynth+]] or [https://sourceforge.net/projects/avisynth2/ AviSynth 2.6]

@@ Line 225: / Line 225: @@
    - Fix: SCSelect: Old v0.9 SSE2 code omitted difference checking for every second 8 columns
    - Removed MMX code, now requires SSE2
-   - Reports MT Modes for Avisynth+: MT_SERIALIZED for SCSelect
+   - Reports MT Modes for Avisynth+: [[MT_SERIALIZED]] for SCSelect
-   - Reports MT Modes for Avisynth+: MT_MULTI_INSTANCE for RestoreMotionBlocks (may not be any faster)
+   - Reports MT Modes for Avisynth+: [[MT_MULTI_INSTANCE]] for RestoreMotionBlocks (may not be any faster)
    - Added Y, YV16 and YV24 support besides existing YV12 and planar-hacked-YUY2
 * v0.9 (20050507)
 <br>
 == Archived Downloads ==
 {| class="wikitable" border="1"; width="100%"

@@ Line 1: / Line 1: @@
-{{FilterCat5|External_filters|Plugins|Plugins_x64|Restoration_filters|Luma_equalization}}
+{{FilterCat6|External_filters|Plugins|Plugins_x64|Restoration_filters|Luma_equalization|Deep_color_tools}}
 {{Filter3
 | {{Author/kassandro}}, {{Author/pinterf}}

@@ Line 20: / Line 20: @@
 * [x64]: [[AviSynth+]]
 * Supported color formats: [[Y8]], [[YV12]], [[YV16]], [[YV24]]
-**AviSynth+: All [[planar]]  Y and YUV formats (8/10/12/14/16-bit). [[#SCSelect|SCSelect]] also supports 32-bit float and planar RGB.
+**AviSynth+: All [[planar]]  Y and YUV formats (8/10/12/14/16-bit) are supported. [[#SCSelect|SCSelect]] also supports 32-bit float and planar RGB.
 <br>

@@ Line 6: / Line 6: @@
 | Luma Equalization
 | [http://www.gnu.org/licenses/gpl-2.0.txt GPLv2]
-|6=[http://forum.doom9.org/showthread.php?t=70856 Doom9 Thread], [http://forum.doom9.org/showthread.php?t=176199 Doom9 Forum (original thread)]}}
+|6=[http://forum.doom9.org/showthread.php?t=70856 Doom9 Thread (original)], [http://forum.doom9.org/showthread.php?t=176199 Doom9 Thread (update)]}}
 == Description ==
 RemoveDirt is a temporal cleaner for AviSynth 2.6 and [[AviSynth+]]. It has now become a script function which involves RestoreMotionBlocks and various filters from the [[RgTools|RemoveGrain]] package.
 The plugin contains 2 filters:
-*RestoreMotionBlocks which is the main function used in the RemoveDirt script.
+*[[#RestoreMotionBlocks|RestoreMotionBlocks]] which is the main function used in the [[#RemoveDirt Script|RemoveDirt script]].
-*SCSelect is a scence change detention filter meant to be use with RestoreMotionBlocks.
+*[[#SCSelect|SCSelect]] is a scence change detention filter meant to be use with RestoreMotionBlocks.
-<br>
 <br>
 == Requirements ==
-* [http://sourceforge.net/projects/avisynth2/ AviSynth 2.6] or [[AviSynth+]] (x86 / x64)
+* [x86]: [[AviSynth+]] or [https://sourceforge.net/projects/avisynth2/ AviSynth 2.6]
-* Supported color formats: [[Y8]], [[YV12]], [[YV16]], [[YV24]], plus all 8-16 bit Y and YUV color spaces with Avisynth+
+* [x64]: [[AviSynth+]]
-<br>
+* Supported color formats: [[Y8]], [[YV12]], [[YV16]], [[YV24]]
+**AviSynth+: All [[planar]]  Y and YUV formats (8/10/12/14/16-bit). [[#SCSelect|SCSelect]] also supports 32-bit float and planar RGB.
-* 0.9.1 and up is statically linked, does not have VC redistributable dependency
-* 0.9 required [http://www.microsoft.com/en-us/download/details.aspx?id=8328 Microsoft Visual C++ 2010 Redistributable Package (x86)]
 <br>
@@ Line 113: / Line 112: @@
 <br>
 <br>
 ----
@@ Line 131: / Line 131: @@
 ::{{Par2|debug|bool|false}}
 :::If debug=true, then SCSelect sends output of the following type to the [http://technet.microsoft.com/en-us/library/bb896647.aspx DebugView]  utility:
 <pre>
 [3416] [67865] SCSelect: global motion
@@ Line 156: / Line 157: @@
 [3416] [72165] SCSelect: global motion
 </pre>
 :::To describe the basic idea  behind SCSelect let SAD(n)  be the SAD difference between the frames input(n) and input(n+1). Now, if SAD(n) > dfactor * SAD(n-1), then SCSelect recognizes a scene end and pulls the frame from the clip scene_end. If SAD(n-1) > dfactor * SAD(n), then SCSelect recognizes a scene begin and pulls the frame from the clip scene_begin. If both SAD(n) <= dfactor * SAD(n-1) and SAD(n-1) <= dfactor * SAD(n), then SCSelect recognizes a global motion and pulls the frame from the clip global_motion. From this description it is clear that dfactor must be > 1 for getting reasonable results. The above algorithm is optimized such that often only one and not two SADs are calculated for one requested frame. However, there are certain shortcomings. If a scene ends with global motion, then SCSelect often can't detect the scene end. If a scene begins with global motion, then SCSelect often can't detect the scene begin. These two effects are usually responsible if lonely scene begins and scene ends are detected by SCSelected, otherwise each scene begin should be preceded by a scene end. By refining the above algorithm we could avoid lonely scene begins and scene ends, but there is one situation, where even such a refinement fails. Namely if the scene ends with global motion and the new scene starts with global motion. Then a sharp scene switch can only be detected reliably with a good motion analysis, which would result in an extreme slow down of the filter.
 <br>
@@ Line 203: / Line 205: @@
 == Change Log ==
 * v0.9.2 (20190324)
    - RestoreMotionBlocks: 10-16 bit support. Relevant threshold and noise parameters are bit depth independent.
@@ Line 229: / Line 230: @@
 * v0.9 (20050507)
+<br>
 == Archived Downloads ==
 {| class="wikitable" border="1"; width="100%"
@@ Line 241: / Line 242: @@
 !v0.9
 |[http://xhmikosr.1f0.de/_old/avisynth/plugins/RemoveDirt_0.9.zip RemoveDirt_0.9.zip]
-|[http://web.archive.org/web/20150405173333/http://xhmikosr.1f0.de/_old/avisynth/plugins/RemoveDirt_0.9.zip RemoveDirt_0.9.zip]
+|[https://web.archive.org/web/20150405173333if_/http://xhmikosr.1f0.de/_old/avisynth/plugins/RemoveDirt_0.9.zip RemoveDirt_0.9.zip]
 |includes statically and dynamically linked [[SSE2]] binaries compiled with MSVC2010. Dynamically linked binaries requires the [http://www.microsoft.com/en-us/download/details.aspx?id=8328 Microsoft Visual C++ 2010 Redistributable Package (x86)] to be installed.
 |Included with the binaries.
 |-
 !v0.9
-|<strike>[http://home.arcor.de/kassandro/RemoveDirt/RemoveDirt.zip ReduceDirt.zip]</strike>
+|<strike>[https://web.archive.org/web/20140723074402if_/http://home.arcor.de/kassandro/RemoveDirt/RemoveDirt.zip ReduceDirt.zip]</strike>
-|<strike>[http://web.archive.org/web/20140723074402/http://home.arcor.de/kassandro/RemoveDirt/RemoveDirt.zip ReduceDirt.zip]</strike>
 |includes 3 binaries: one statically linked (<tt>RemoveDirtS.dll</tt>) and two dynamically linked (<tt>RemoveDirt.dll, RemoveDirtSSE2.dll</tt>).
 SSE2 version is recommended but unfortunately it requires the <tt>Msvcr71.dll</tt> runtime component from the very ancient Microsoft Visual C++ .NET 2003. For this reason this package is considered deprecated!
-|[http://home.arcor.de/kassandro/RemoveDirt/RemoveDirt-src.zip ReduceDirt-src.zip]
+|[https://web.archive.org/web/20141121054131if_/http://home.arcor.de/kassandro/RemoveDirt/RemoveDirt-src.zip  ReduceDirt-src.zip]
 |-
 !v0.6.1
-|[http://web.archive.org/web/20050215121957fw_/http://home.pages.at/kassandro/RemoveDirt/RemoveDirt.zip RemoveDirt.zip]
+|[https://web.archive.org/web/20050215121957if_/http://home.pages.at/kassandro/RemoveDirt/RemoveDirt.zip RemoveDirt.zip]
+|
-|Old archived documentation: [http://web.archive.org/web/20050311122626/http://www.removedirt.de.tf www.removedirt.de.tf]
+|Old archived documentation: [https://web.archive.org/web/20050311122626/http://www.removedirt.de.tf www.removedirt.de.tf]
 |}
 <br>
 == External Links ==
-*[http://home.arcor.de/kassandro/RemoveDirt/RemoveDirt.htm RemoveDirt.htm] | [ RemoveDirt.htm] - official documentation.
+*[https://web.archive.org/web/20160610102940/http://home.arcor.de/kassandro/RemoveDirt/RemoveDirt.htm RemoveDirt.htm] - official v0.9 documentation.
 *http://forum.doom9.org/showthread.php?p=641337#post641337
 *http://forum.doom9.org/showthread.php?p=1560013&highlight=scselect#post1560013

@@ Line 67: / Line 67: @@
 ::{{Par2|pthreshold|int|10}}
 ::{{Par2|cthreshold|int|pthreshold}}
-:::For postprocessing RestoreMotionBlocks uses the variable pthreshold and cthreshold. If the total luma difference of the two adjacent border line increases by more than pthreshold, then cleaning of the block is undone by RestoreMotionBlocks. Similarily cleaning is undone, if the chroma difference exceedes cthreshold. The maximal difference of 8 pixels is 8*255. If cthreshold is larger than this value, then chroma postprocessing is disabled. If both, pthreshold and cthreshold,  are larger than the maximal value, then postprocessing is completely disabled. pthreshold=10 is the default value and if nothing else is specified cthreshold has the same value as pthreshold. Clearly luma postprocessing is much more important than chroma postprocessing. If cthreshold and especially pthreshold, then rather unpleasant blocky artifacts become visible. These are much more likely in areas with very flat contrast. Of course, there must be motion as well to get such artifacts. If you see these typical blocky artifacts, you should lower the thresholds. Postprocessing should only be disabled if all the cleaned frames are checked for artifacts. By the very nature of the algorithm no postprocessing will occur if all blocks were cleaned. There must be at least one block, which has not been cleaned to trigger postprocessing. The postprocessing algorithm loops through all the blocks as long as it can find blocks to be restored, nevertheless it is quite efficient. It is the basic philosophy of RestoreMotionBlocks, that motion detection needs only detect at least one but not all blocks of a moving object. The rest is then taken care by postprocessing.
+:::Parameters "pthreshold" and "cthreshold" are thresholds for luma and chroma, respectively. For 10-16 bits (where actual pixel values and thus SAD values are larger) the parameter is automatically normalized internally. You can keep it the same across different formats for the same effect.<br>For postprocessing RestoreMotionBlocks uses the variable pthreshold and cthreshold. If the total luma difference of the two adjacent border line increases by more than pthreshold, then cleaning of the block is undone by RestoreMotionBlocks. Similarily cleaning is undone, if the chroma difference exceedes cthreshold. The maximal difference of 8 pixels is 8*255. If cthreshold is larger than this value, then chroma postprocessing is disabled. If both, pthreshold and cthreshold,  are larger than the maximal value, then postprocessing is completely disabled. pthreshold=10 is the default value and if nothing else is specified cthreshold has the same value as pthreshold. Clearly luma postprocessing is much more important than chroma postprocessing. If cthreshold and especially pthreshold, then rather unpleasant blocky artifacts become visible. These are much more likely in areas with very flat contrast. Of course, there must be motion as well to get such artifacts. If you see these typical blocky artifacts, you should lower the thresholds. Postprocessing should only be disabled if all the cleaned frames are checked for artifacts. By the very nature of the algorithm no postprocessing will occur if all blocks were cleaned. There must be at least one block, which has not been cleaned to trigger postprocessing. The postprocessing algorithm loops through all the blocks as long as it can find blocks to be restored, nevertheless it is quite efficient. It is the basic philosophy of RestoreMotionBlocks, that motion detection needs only detect at least one but not all blocks of a moving object. The rest is then taken care by postprocessing.
 :::Negative values are allowed for pthreshold and cthreshold, but are not very reasonable.