Removegrain(1) or (2) [Archive]

Oline 61

27th January 2006, 01:59

How it works

RemoveGrain is a purely spatial denoiser for Avisynth. However, in combination with Clense and the Repair plugin more powerful spatio-temporal denoisers and Deinterlacers can be built as Avisynth functions (see the examples below). Modes 1-10,17,18 are for truely progressive input only, while modes 13-16 are primarilarily for interlaced input and are used for constructing deinterlacers. While modes 1-10,17,18 can be used for interlaced and telecined material as well by applying it to the separated fields, the quality is inferior, because the adjacent pixels have twice the vertical distance, which clearly has a negative impact on quality. With RemoveGrain one can't remove big spots or scratches from a clip. Rather it was designed for the very small spots - not much larger than a pixel. Although the changes made by RemoveGrain are hardly visable the impact on compression may be quite substantial. In modes 1-10,17,18 the value of the center pixel is replaced by the value of one of its eight neighbours. This applies to the luma and the chroma liekwise. More precisley, for a given pixel x RemoveGrain looks at the eight spatial neigbours of that pixel and chooses two of these neighbours, say, a,b for minmax clipping, i.e. x is replaced by min(max(x, min(a,b)), max(a,b)). The choice of a,b depends strongly on the mode variable. If 1 <= mode <= 4 a minmax clipping is done at a(mode), a(9-mode), where a(1) <= a(2) <= a(3) <= a(4) <= a(5) <= a(6) <= a(7) <= a(8) is the sequence of neighbours ordered by the luma. Thus, if the number of neighbours with luma >= x is greater than the value of the mode variable and if the number of neighbours with luma <= x is greater than mode as well, then the luma of this pixel is left unchanged. Clearly this method only makes sense for 1 <= mode <= 4. If mode=1, then RemoveGrain(mode=1) is identical with trbarry's Undot (even the speed of the SSE version is nearly identical to that of Undot, but the SSE2 and especially the SSE3 versions are significantly faster). The chroma values are treated similarily, but instead of the mode variable, the variable modeU is used for the U plane and modeV is used for the V plane. However, the value of the mode variable is the default value for the modeU variable and the value of the modeU variable is the default value for the modeV variable. Let us look at an example: assume that the pixel has the luma value 32 and that the eight neighbours have the luma values 21, 122, 77, 25, 56, 200, 133, 45. If mode <= 2, then the pixel remains unchanged, because there are two neighbours with smaller luma and six with larger luma. If mode=3, then the luma of the pixel is increased to 45. Finally, if mode=4, then the luma is increased to 56. With mode=1,2 the filter is fairly artifact free. Thin lines are preserved by these modes including the two end points. If mode=3 or 4, then thin lines may be destroyed by RemoveGrain. Thus RemoveGrain(mode=3 or mode=4) may only be used with some caution. The fairly risk free mode=2 is the default value. It still does significantly more denoising than Undot, i.e. mode= 1. The larger the value of mode (between 1 and 4 only), the softer the look of the output and the higher the compression ratio. The smart mode 17, introduced in version 0.8, is of special importance. It is a variant of modes 4. However, unlike mode 4, it preserves thin lines, although the pixels at the two ends of a thin line may get lost. Whenever mode= 4 doesn't destroy thin lines through a pixel, then mode 17 handles a pixel just like mode 4, otherwise a mode slightly more aggressive than mode 2 is used. Unlike the modes <= 4 the modes between 5-9,17,18 are edge sensitive . While in mode <= 4 any pair of neighbours is a possible choice for minmax clipping, in modes 5-9,18 only line pairs are used. There are four such pairs: firstly the horizontal pair consisting of the left and the right neighbour of the pixel, secondly the vertical pair consisting of the top and bottom neighbour, thirdly the diagonal pair consisting of the bottom left and the top right neighbour and finally the diagonal pair consisting of top left and the bottom right neighbour. If mode=9, then we choose simply that line pair (a,b) for minmax clipping, for which |a - b| is minimal (as usual |y| = max(y,-y) denotes the absolute value of a number y) . Thus RemoveGrain(mode= 9) is just a purely spatial variant of trbarry's ST Median filter. If mode=5, then that line pair (a,b) is chosen for minmax clipping, for which |x - y| is minimal (here x is the original luma value of the pixel and y=min(max(x, min(a,b)), max(a,b)) is the value obtained by minmax clipping). The modes 6,7,8 are intermediate modes between mode=5 and mode=9. mode=6 is closer to mode=5 while mode=8 is closer to mode=9 and mode=7 is right in the middle between mode=5 and mode =9. Mode 5 preserves thin lines including the two end points. Mode 6-8 also preserve thin lines, but end points may get lost (the likelyhood of such a loss increases with the mode number). Fizick has extended mode 5-9 to the temporal domain in his plugin DeGrainMedian. Because there are now 26 instead of 8 neighbour pixels, these extension are necessarily slower. Nevertheless the temporal extension makes a lot of sense. Mode 18 (added in version 0.9) has preserves thin lines often also with the two end points, but it should be clearly inferior to mode 17 as far as compression is concerned.

Beginning with version 0.6 we have also added a fast implementation of the most important 3x3 convolution as mode 11. If y(i,j) denotes the luma of the pixel with coordinates i,j, then mode 11 replaces y(i,j) by (4*c(i,j) + 2*(c(i-1,j) + c(i+1,j) + c(i,j-1) + c(i,j+1)) + (c(i-1,j-1) + c(i-1,j+1) + c(i+1,j-1) + c(i+1,j+1)) + 8)/16 (+8 is necessary for proper rounding). Thus the all pixels are blurred vertically and horizontally with a (1/4,1/2,1/4) kernel. The builtin Blur(1) claims to do the same, but it really doesn't. Mode 12 (added in version 0.7) is a significantly faster version of mode 11, which is slightly less precise (the difference between both is always <=1). Thus, unless you are pedantic, you should always use mode 12 instead of 11. In version 0.7 the two bob modes 13 and 14 have been added. Mode 13 leaves the bottom field unchanged and interpolates the top field. Mode 14 leaves the top field unchanged and interpolates the bottom field. The interpolation in mode 13, 14 is similar to Trbarry's weird bob, which is part of Trbarry's Tomsmocomp. However, instead of optimising over 5 line pairs we optimise only over 3 line pairs. More precisely, c(i,j) is replaced either by (c(i-1,j-1) + c(i +1,j+1)+1)/2 or (c(i-1,j+1) + c(i +1,j-1)+1)/2 or (c(i,j-1) + c(i,j+1)+1)/2, depending on which of the three distances |c(i-1,j-1) - c(i +1,j+1)|, |c(i-1,j+1) - c(i +1,j-1)|, |c(i,j-1) - c(i,j+1)| is minimal. In Trbarry's weird bob (c(i-2,j-2) + c(i +2,j+2)+1)/2 and (c(i-2,j+2) + c(i +2,j-2)+1)/2 are possible interpolation values as well. Thus weird bob is more edge sensitve, but also the likelihood of smart edge artifacts is higher and of course it is slower. Taking only 3 line pairs seems to be the best compromise to us. Together with the filter TemporalRepair, described below, it may be used for builting motion adaptive deinterlacers. Beginning with version 0.8 we have added modes 15, 16. They have the same edge sensitivity as modes 13,14 but the quality is somewhat higher and the speed somewhat lower.

Which mode is the best for denoising? As far as compression is concerned, my benchmarks so far give the following mode ranking: 4,17,9,8,3,7,6,2,5,1, but modes 4 and 17 really stand out. As far as artifacts are concerned, we have unfortunately almost the reverse mode ranking: 1,5,2,18,6,7,8,17,3,4,9. Modes= 1,5,2 are the risk free modes, the modes 18,6,7,8,17 show low to moderate artifact risk (usually some softness) and modes 3,4,9 have severe problems with thin lines. Mode 9 has less artifacts than mode 4, but when they occur they look a lot more ugly. Mode 17 is my clear personal favorite. As far as compression is concerned it is fairly close to the leader, mode 4, and I have only seen some softness but hardly any visable artifacts. The frame width of the input clip must be > 36 (SSE version) or > 68 (SSE2 version).
Optimal Usage

1. As already mentioned, RemoveGrain cannot change border pixels. To get rid of these, cropping should be done after RemoveGrain. On the other hand, for RemoveDirt cropping should be done before such that DCT blocks and RemoveDirt blocks are the same. Thus, if RemoveGrain is combined with RemoveDirt cropping should be done at best between RemoveGrain and Removedirt.

2. Although RemoveGrain always makes a lot of unaligned memory access aligning frames nevertheless has a positive performance impact. Thus crop with align=true, if you need to crop before RemoveGrain.

3. If mode=0 (resp. modeU=0, resp. modeV=0), then the Y plane (resp. the U plane, resp. the V plane) is simply copied from input to output. If even mode < 0 (resp. modeU < 0, resp. modeV < 0) then for the respective planes nothing is done at all (not even a copy operation). This may be used for faster processing of black&white clips. For instance RemoveGrain(mode=8, modeU= -1).RemoveDirt(grey= true) is the fasted way to process a black&white clip by the RemoveGrain/RemoveDirt combo. Because modeV inherits the value -1 from modeU, RemoveGrain doesn't process the chroma planes and RemoveDirt subsequently sets the chroma planes uniformly to 128. If you use modeU=-1, you must add a chroma later through the builtin filters MergeChroma or GreyScale.

4. RemoveGrain is fairly fast. It makes perfect sense to iterate it for better denoising. For instance, RemoveGrain(mode=2). RemoveGrain(mode=2) is still a fairly defensive denoiser, which doesn't destroy thin lines.

5. If grain is too crude, RemoveGrain can only partially remove it or cannot remove it at all. Because in such a case the source is quite poor anyway, it is a good idea to shrink. Then also the grain gets smaller and RemoveGrain may be able to erase it. In general, downsizing should be done before RemoveGrain while upsizing should be done after RemoveGrain.

6. As described above, some modes, especially mode 3,4,9, have a thin line problem. Now YUY2 and especially YV12 have a buitlin thin line problem for the chroma, because several pixels share one chroma value. This problem is amplified if RemoveGrain is applied to the chroma. It should be kept in mind, that RemoveGrain has roughly four times the strength, if it is applied to the YV12 chroma rather than the luma. This is the main reason for edge softness caused by the more conservative modes 18,6,7,8,17. Thus to avoid compounding the thin line problem, it is a good idea to use modes without a thin line problem for the chroma even if mode 3,4,9 is used for the luma. For instance RemoveGrain(mode=4, modeU=2) uses the high compression mode 4 for the luma and the low artifact mode 2 for the chroma. On the other hand the chroma is often particularily noisy (especially if the clip originates from a video tape), which speaks against applying a more conservative mode for the chroma.

From the readme.