On Fri, Oct 30, 2015 at 2:14 AM, P. van Gaans <w3ird_n...@gmx.net> wrote:
> On 10/29/2015 09:42 AM, Paul B Mahol wrote: > >> On 10/29/15, P. van Gaans <w3ird_n...@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@ffmpeg.org >>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >>> >>> _______________________________________________ >> ffmpeg-devel mailing list >> ffmpeg-devel@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. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
