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

[Robert Krüger]

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.