[FFmpeg-devel] Idea for a better filter that reduces noise

Robert Kr├╝ger krueger at lesspain.de
Fri Oct 30 10:26:05 CET 2015


On Fri, Oct 30, 2015 at 2:14 AM, P. van Gaans <w3ird_n3rd at gmx.net> wrote:

> On 10/29/2015 09:42 AM, Paul B Mahol wrote:
>
>> On 10/29/15, P. van Gaans <w3ird_n3rd at gmx.net> wrote:
>>
>>> You all know the CSI episodes where they read a license plate by
>>> "enhancing" some super-grainy security footage. Nonsense, right? Well,
>>> maybe not.. If the car was parked. And it seems what I found doesn't
>>> exist yet. (but perhaps I overlooked it)
>>>
>>> If you quickly want to know what I'm on about, take a look at these
>>> images:
>>>
>>> http://members.ziggo.nl/sinaasappel/images/1_original.jpg (original)
>>> http://members.ziggo.nl/sinaasappel/images/2_40framewind.jpg (40f WIND)
>>> http://members.ziggo.nl/sinaasappel/images/3_wind_hqdn3d.jpg (comparison
>>> with hqdn3d and pp=tn)
>>>
>>> All have limited jpeg compression, but I can deliver PNG files and an
>>> XCF to experiment for yourself if desired.
>>>
>>> So what is WIND? It's what you see if you forget/fail to do motion
>>> detection. (like I did in the images) Also, Wind Is Not a Denoiser. ;-)
>>> It's a way to increase the exposure time of the camera used to shoot a
>>> movie after it's been shot. For the images, I took a 2-second somewhat
>>> grainy clip of a building with nearly no motion. I output the frames to
>>> PNG and load them as layers in The GIMP. I set the opacity for the
>>> bottom layer to 100. The layer above that 50. (100/2) Above that 33.3.
>>> (100/3) 25, 20, 16.7 and so on. Every image with noise is "wrong", some
>>> too dark and some too light. On average, they are spot-on. The
>>> advantage: improved quality and better compression.
>>>
>>> To make this into a proper useable filter, it would need to do this:
>>>
>>> 1. Deshake/stabilize the image.
>>> 2. Divide image in blocks. (e.g. 8x8 pixels)
>>> 3. Figure out it the average color of an 8x8 block is changing during
>>> the next X frames. If not, it's probably not moving and you can average
>>> the values. If it is or is about to, it should be averaged over fewer
>>> frames or not at all. Any area that is about to move will gradually pick
>>> up noise so it doesn't look too unnatural.
>>> 4. Reshake the image.
>>>
>>> Will I do this myself? Maybe, but don't hold your breath. I'm just
>>> sharing this in case somebody finds it interesting and to make sure
>>> nobody can patent it. (assuming it hasn't been done already)
>>>
>>
>> See atadenoise.
>>
>>
>>> Best regards,
>>>
>>> P. van Gaans
>>> _______________________________________________
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel at ffmpeg.org
>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>>
>>> _______________________________________________
>> ffmpeg-devel mailing list
>> ffmpeg-devel at ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>>
> Thanks Paul! I think I scrolled past atadenoise in the docs a while ago
> but had otherwise never heard of it. While searching for it there is little
> to find besides the docs and source code. (i.e. no forum threads or
> mentions in guides or anything) My ffmpeg doesn't even have it so I guess
> it's quite a new thing. I'll first compile a fresh one and get testing. I
> hope atadenoise also performs the deshaking internally as I described since
> I noticed the camera is usually not fixed, without deshaking it won't be
> able to match much.
>
> I still think WIND would have been a funnier name than atadenoise, but I
> don't complain. This will be great if it works as well as my pictures. :-)
>
> afaik it does not deshake but try it anyway. You can read the paper it's
based on, if you're interested in more details. It's mentioned in the
source code.


More information about the ffmpeg-devel mailing list