Cel Foreground filter : Denoiser for animation -- new pictures up

[mg262]

Here is a filter that @TBL and I wrote; it denoises foreground objects in animation:

http://people.pwf.cam.ac.uk/mg262/posts/Foreground/ForegroundA_2806.jpg

Filter (http://people.pwf.cam.ac.uk/mg262/posts/Foreground/CelForeground_08Sep05.dll)

Documentation (http://people.pwf.cam.ac.uk/mg262/posts/Foreground/Foreground.HTML)

You should start by reading the introduction (or at least the independence section, which is important) and basic denoising up to 'Thresholds'... then you should be ready to start playing with the filter.

We would recommend getting the hang of denoising before trying separation.
______________________________________________________

In case they are convenient...

Documentation in a thread (http://forum.doom9.org/showthread.php?t=99778)
Filter and Documentation in a ZIP file (http://people.pwf.cam.ac.uk/mg262/posts/Foreground/CelForeground_08Sep05.zip) (2 MB) [Open Foreground.html]

Edit: (Below) Thank you for prodding me to make the documentation more readable, Wilbert... HTML was a lot less painful than the last time I tried it [maybe because I'm not using notepad this time ;)].

[Wilbert]

Yo! Perhaps it's a good idea to package the docs with your plugin? That's much easier for people :)

[mg262]

^^ thank you.

I've left the material in a thread because I want it to be searchable... Doom9 search is the main way I've found filters.

[Pookie]

Hey MG, Congrats on releasing this. I know you were working on it for a while.
Well done :)

[mg262]

Thank you very much!

Edit: I've cleaned up the documentation!

[bill_baroud]

Just took a quick glance at the documentation thread .... wow !
If i understand correctly, you're using a sort of "watershed" technique, that's just crazy :D
I've thought about a filter like that for quite a long time, but i never got that far and that complex... Hat off.

[mg262]

:) thank you... we are not actually using watersheds because they are very slow, but we're using something very similar.

I've been tidying up the HTML, so there should be a decent version up in an hour or so. (Thank you for prodding me, Wilbert.)

[foxyshadis]

Most of it is neat, and definitely seems to have the potential to become the ultamite cartoon smoother.

But what really caught my eye and made me weep was the absorb filter. Oh, how often I've been stuck with trashed gradients, which I'd love to smooth out without hitting the smudge tool. How many times I've fixed up a scan and gone to save in a slim-sized tiff/png only to get ugly banding or dithering without greatly increasing the number of colors and filesize. (Obviously here I'm hoping for a photoshop filter someday, which probably won't happen. Ah well.)

[Mug Funky]

hey, this is cool! i'll have to read up on how this filter works.

one thing - just looking at the demo image, the brown jacket in the source image seems redder than in the output image (it's VERY subtle, perhaps just a rounding issue... all those years painting are paying off i guess). how is this filter determining which colour should "take over"?

i might be just seeing things though :)

very good stuff :thanks:

[mg262]

@foxyshadis,
No plans for a Photoshop plug-in, I'm afraid... although someone was vaguely thinking about writing a general converter (can't now remember who). Also, what the filter does is specifically aimed at restoring blocks of flat colour, as that is what was originally present in my sources... I think the kind of thing you mention may be possible but if I start discussing I'll take up pages!

@Mug Funky
You're completely right, although I'd never have seen it if you haven't pointed it out -- I checked by cutting out a square patch and applying a massive blur. The difference is about (4, 0, 0) in RGB, which is bigger than the .5 from rounding errors should cause. [Though I should adjust the rounding in the next version.]

The colour is just obtained as a simple average. That screenshot was generated using a very crude method (cf the more refined method at the end of Advanced Denoising in the docs), which results in some holes... I suspect the problem is that the flood fill avoids the red-most pixels, so they are excluded from the region.

You can see what the regions look like here [coloured at random, original showing through holes]:

http://people.pwf.cam.ac.uk/mg262/posts/Foreground/ForegroundA_2806regions_cropped.jpg

(Because of the chroma subsampling, the original chroma will only show through on 2x2 holes, so don't read too much into the red pixels.)

I'm very glad you're interested! I learnt to write filters specifically to try implementing this idea -- break animation up into background and foreground, stitch the background together to make a bitmap per scene (occasionally more), vectorise the foreground and represent it as blocks of solid colour. So I really want to make this approach work -- and any feedback is very much appreciated.

[Mug Funky]

it's a bloody good idea - especially the vectorization. this could make anime restoration a snip, and allow HDTV upsizing with practically no bad effects - backgrounds and textures can be resized with smooth bicubic or something similar, and cels can be splined...

could also form the basis of a very cool animation-only compression format (sort of like .swf).

considering i'm up to my eyeballs in really REALLY bad quality old anime, something like this is quite a cool thing. if it could be made to work flawlessly, even at 1 frame every few seconds, this could be an extremely useful tool for restoration.

and right now, a VERY large chunk of the DVD market is in re-releasing back catalogues (just from here in the last few months, we've seen Robotech/Macross, Kimba, Astroboy, Voltron, Starblazers, He-Man and Fat Albert all get a release, not counting the horrid DBZ remasters), so this could come at just the right time :)

[bill_baroud]

@mg262 : why not throw a dilatation/erosion (enclosure ?) to your mask ? that would fill the holes quite neatly.

[mg262]

@Mug Funky,

You've thought of every application except one: frame rate change ;) . If we ever get as far as compression, then the playback codec could render frames as fast as it was able to, rather as (I believe) many modern games do. Backgrounds and some foreground objects would be pan/zoom-interpolated, and the remaining foreground objects could be blended.

I'm not sure it could ever be flawless... but it may end up separate from AVISynth, with a GUI which lets you make changes quickly -- e.g. click somewhere in an object and have it flagged as foreground/background, both in the current frame and all other appropriate frames in the scene.

I don't know how long it will take to finish. TBL and I only had a brief time to work together, so we didn't manage to implement vectorisation -- but in some ways that's for the best as it's worth getting feedback and making the existing parts work really well so they can feed reliable data into the vectoriser. The Background filter has been mostly working since April, but needs *much* speeding up; and a TBC-like preprocessor wouldn't hurt (the combing visible in e.g. the hand at the bottom left translates to blurred backgrounds). Separation is the trickiest part, but I'm hopeful that a ping-pong method between Background and Foreground will work quite well...

@bill_baroud,

Its slightly more complex because it is a list of regions rather than a mask... but things like that can certainly be done. We've tried really hard to build the filters in such a way that this kind of change can be made simply by adjusting the script used... one way to reduce holes (better seeds clip) is in Advanced Denoising, section 7, and there are more suggestions in the Notes (especially under Postprocessing). [Those weren't used for that particular screenshot.]
____________

Incidentally, every function in this filter should be compatible with @tsp's multithreading in mode 1 (fastest mode).

[Zarxrax]

I'm not sure it could ever be flawless... but it may end up separate from AVISynth, with a GUI which lets you make changes quickly -- e.g. click somewhere in an object and have it flagged as foreground/background, both in the current frame and all other appropriate frames in the scene.

It's not necessary to separate it from avisynth to have a good gui.
Check out this plugin: http://forum.doom9.org/showthread.php?s=&threadid=92174&highlight=freeframe
It has a gui that you can adjust the properties in realtime as the video is playing!

[mg262]

Thank you, that's worth looking at. Although, in this case so much of the functionality would be separate from AVISynth that in the long run it might be better to create a separate program.
________________________

To illustrate my comments above, a few shots of the Background filter at work:

Input
http://people.pwf.cam.ac.uk/mg262/posts/Background/mountain_3650_small.jpg (http://people.pwf.cam.ac.uk/mg262/posts/Background/mountain_3650.jpg) http://people.pwf.cam.ac.uk/mg262/posts/Background/mountain_3700_small.jpg (http://people.pwf.cam.ac.uk/mg262/posts/Background/mountain_3700.jpg) http://people.pwf.cam.ac.uk/mg262/posts/Background/mountain_3750_small.jpg (http://people.pwf.cam.ac.uk/mg262/posts/Background/mountain_3750.jpg)
(and another 98 frames from this scene)

Output
http://people.pwf.cam.ac.uk/mg262/posts/Background/mountain_meld_10_small.jpg
(http://people.pwf.cam.ac.uk/mg262/posts/Background/mountain_meld_10.jpg)

Click on a picture to see the full-size version.

This particular source has a problem with h-sync drift -- i.e. scanlines don't quite line up with each other properly -- and this translates into some blurring in the output. (I need to adapt this very method to make a time-base correction type filter... ) The same method will also work with masked input -- I will illustrate this at a later date.

[FredThompson]

Wow. This is just the thing I've been looking for.

The reference thread mentions a faster version. Any progress on that?

[mg262]

No, I'm afraid not... TBL and myself being in different countries tends to slow this one down. It will definitely get done though -- unlike motion compensation, blend removal, etc., this one is actually something I'm going to use. (That's probably why it's rather complex on the script side... ) Sorry to make you wait.

[Arachnotron]

@mg262 the link in the top-post to the reference thread seems broken.

Thanks to you and @TBL for this great work!

<Walks off to settle on the couch for some serious reading>

[mg262]

Arachnotron,

It's good to see you here -- you have helped me many times in the Capturing forum, although it was sometime back so you might not remember it! Thank you for pointing out the link -- I have fixed it, but I would recommend sticking to the HTML version as it's much more readable. Let me also point you at this caveat...

http://forum.doom9.org/showthread.php?p=734096#post734096

In any case, hope you find it interesting reading!

(I thought I replied to this post, but it doesn't seem to have happened so I rereplied... sorry if somehow a double post happens.)

[SCIF]

Does this project is still under researching?

[FredThompson]

Sigh...apparently this is pretty dead. Darn.

[Revgen]

Sigh...apparently this is pretty dead. Darn.

Well, if you want any good news, I loaded Chainmax's simpsons test clip and my script in this thread (http://forum.doom9.org/showthread.php?p=771966#post771966) using TSP's SetMTmode filter and speed increased by 63% to about 3.16FPS. It ran at 1.93FPS with one core.

Hopefully with more opts, this filter can become faster.

[mg262]

Sorry, it's not dead... I was buried in other things over Christmas, so some replies will have slipped past (do remind me of any others).

I* am aware that it's not the simplest plug-in around. The thing is, it's the simplest one that works... I have three or four dead (unreleased) plug-ins on my hard disk as testament to that. You can also try the VirtualDub plug-in Maven's area smoother; it tries to do something similar but (in my experience) breaks down very quickly.

I'm going to go out on a limb and say that the underlying difficulty is that this problem can't be solved by looking at the video in the standard way, as a big grid of numbers. It needs you to look at the problem in a different way, a shift of representation, to look at the video as a collection of regions of flat colour. Switching representation is very standard in AI, but not something video people are used to... so it's confusing. I tried to put lots of pictures in the documentation to make it easier to understand, but obviously that hasn't been very successful... I'm certainly open to any suggestions on how to make it more comprehensible.

Further work is definitely on the cards... but development is slow for the main reason that we are normally based in different countries. It's also more mentally demanding to work on than e.g. motion compensation or suchlike. But it will definitely get sped up...

*TBL is based in another country, so I'm generally writing on my own; broad outlines probably reflect his opinions but specifics may not.

[Revgen]

One way to make it more understandable is to replace "seed" with "paintball". The "seed" effect as you describe it sounds more like a paintball hitting a target and flooding a target area. The settings can affect how large the paintball is and how many paintball targets are in a specific area. The color that the paintball floods would be determined by the area it hits. If a scene is very detailed it would be better to have a small paintball size and increase the amount of paintballs that are shot at the picture. A less detailed scene would benefit from less paintballs and a larger paintball size.

This might be more undestandable to people.

[Revgen]

I've got another suggestion (or request ;) ) as far as this filter goes. The "campfire effect" that I've been having using Chainmax's video (http://forum.doom9.org/showthread.php?t=105965) seems to be happening in still or non-moving areas. Sometimes it does happen in moving areas (Simpson family's car headlights), but not as much (or it's not noticeable). I think this effect could be lessened if some kind of motion compensation was involved. But I haven't seen any motion compensation routines suggested in the documentation.

[mg262]

That effect happens when areas are unstable from frame to frame... and actually you can notice this on your video: look for dark areas just above people's heads. When these areas are assimilated into the main background, the average colour of that background is dark; when they are not, it's bright. They belong in the background, i.e. they should always be assimilated... Choosing parameters to do this will reduce the flicker substantially or eliminate it... give me a bit to play with the settings. I might also look at how hard it would be to add a 'median' option which would be immune to flicker.

Edit: forgot to say, standard motion compensation doesn't work on animation, especially animation like this... it needs texture detail to grip on to. Global motion compensation definitely works, and that's what Cel Background does.

[FredThompson]

I'm not complaining about the complexity of the filter. Complexity is part of capability.

Frankly, a complete "sample" use of the filter would help a lot. The documentation thread contains detailed descriptions but putting all the pieces together to start playing with it is difficult.

[mg262]

Fred,

Sorry for the delay in replying. I've now spoken with TBL, and the rough plan is to

a) Speed up the filter is much as possible. As well as the obvious effect, this will hopefully simplify scripts by removing the need for some speed-workarounds.

b) Create a detailed example (probably using Chainmax's clip, if he doesn't mind) and put the script up somewhere, both in compact form as requested and expanded with lots of pictures.

It will be a bit because we can't work on this together this time (and I'm pretty busy at the moment), but it will be done... sorry for making you all wait.

[FredThompson]

Oh, believe me, I'm exstatic about the possibilities and incredibly thankful for what you two have done.

If you bebop over to my page you'll see I've been tinkering on a horrible film transfer from the 70s for quite a while. I've got the background looking great. The foreground characters still look dirty and your filter looks like the Holy Grail. One of the things I discovered was cleaning the background required a different approach than the foreground characters which matches your descriptions of painted vs. drawn portions of the source. I've also found cleaning makes compression artifacts VERY visible.

Now I just need to find a way to think like didee and get dehalo_alpha running faster.

[zilog jones]

...b) Create a detailed example (probably using Chainmax's clip, if he doesn't mind) and put the script up somewhere, both in compact form as requested and expanded with lots of pictures.
Are you sure The Simpsons would be the best example for this filter? The thing is the backgrounds are generally all cel-shaded too unlike most animations (especially anime) - though there appears to be some use of shading and gradients and stuff in the first (and maybe second) season, after that it's pretty much 100% cel-shaded. Would this not make it a lot harder for the filter to distinguish between background and cels, and use parameters/filtering that may potentially destroy normally painted backgrounds?

[Prettz]

This looks really damn interesting. I think I might start testing this on Akira. The noise and ringing in that movie is incredibly hard to remove without blurring the highly-detailed background art.

[guada 2]

@mg262

Hello,
Very interesting your job. :)

A Complex Script:

seeds1 = source.Blur(1).Blur(1).LocalMaxima.inflate.inflate.inflate.binarize(40, upper=false)
seeds2 = source.Blur(1).Blur(1).Blur(1).LocalMaxima.inflate.inflate.inflate.binarize(40, upper=false)
seeds = logic(seeds1, seeds2, "or") #uses MaskTools
graph = ConstructFloodGraph(source, seeds, 11, 30)
sizemask = black.ColourGraphBySize(graph, 0, 40)
#graph = graph.MaskGraph(sizemask) #uncomment for better, very slow, results
absorbedgraph = graph.AbsorbByColour(source, 6, 25, 400000)

sizemask = black.ColourGraphBySize(absorbedgraph, 0, 1500)
largegraph = absorbedgraph.MaskGraph(sizemask)
gradientabsorbedgraph = largegraph.AbsorbByTouchingColour(source, 2.5,5, 40, 400000)
source.ColourGraphByAverage(absorbedgraph, source)\
.ColourGraphByAverage(gradientabsorbedgraph, source) #remove bands
source.overlay(last, mask = seeds) #postprocessing

from this thread:
http://forum.doom9.org/showthread.php?t=99778

Is it possible to increase the speed of calculation?

:thanks:

[hartford]

@ Prettz

This _might_ interest you: http://forum.doom9.org/showthread.php?t=102121&highlight=akira

Not perfect, but not bad for "general purpose" on that anime.

I'm interested in your criticisms.

[Mug Funky]

This looks really damn interesting. I think I might start testing this on Akira. The noise and ringing in that movie is incredibly hard to remove without blurring the highly-detailed background art.

have you tried dehalo_alpha on it? the r4 one (only one i've seen) has halo from oversharpening. when you get rid of that denoising becomes a lot easier.

good movie though :)

[Revgen]

@mg262

So how is the work going so far?

The last I heard was that your computer was giving you problems.

[Backwoods]

Has there been any progress on this filter? It does an amazing job on cleaning up the cells but getting a right setting to leave the background alone is tough. I was just hoping you haven't forgotten about this project.

[Revgen]

Clouded hasn't been around for awhile. He got an illness awhile ago and never came back.

[Boulder]

He's been around but hasn't posted anywhere.

[juurek]

I want work with Cel Foreground to write another interpreter of Graph. How to interpret Graph(return by ConstructFloodGraph()) data type in my filter ?