non-ringing Lanczos scaling

[madshi]

Hey guys,

anyone interested in non-ringing Lanczos4 scaling? :D

Unfortunately I'm not an Avisynth developer, so I can only describe the algorithm, maybe someone else experienced with Avisynth can implement it.

(Caution: The following explanation is targeted at developers who know how Lanczos scaling works inside.)

---------------

First of all the contributors need to be sorted. The contributor which is nearest to the "center" (usually gets the highest weight) should be first in the list etc. The list should be sorted for distance to the center and not for weight. The sorted contributor list makes it easy to apply special processing to the "main contributors".

upscaling:
main contributors = first 2 contributors in the sorted list

downscaling:
main contributors = first "trunc(scale ratio) + 1" contribs

E.g. for 1.9x downscaling the main contributors are the first 2 contributors in the sorted list. For 2.0x downscaling the first 3.

Now calculate each destination value by using the usual Lanczos4 scaling, but additionally calculate the lowest and highest values of the main contributors. If the calculated destination value lies outside of the main contributors' value range, make sure that the destination value is modified to fit into range.

That is the main concept of the algorithm. Unfortunately it's not as easy as it sounds right now, because if you do this separately for X and Y scaling, there are sometimes some artifacts. Some of these can be avoided by keeping track (throughout the whole X + Y scaling process!) of the highest/lowest values of all main contributors which are used to calculate a destination value/pixel and to correct the destination pixels only after X + Y scaling is fully completed.

Here are some samples (scaled up 4x) with normal vs. anti-ringing Lanczos4 scaling:

http://madshi.net/lanczos/bad1.pnghttp://madshi.net/lanczos/good1.png

http://madshi.net/lanczos/bad2.pnghttp://madshi.net/lanczos/good2.png

http://madshi.net/lanczos/goodbw.pnghttp://madshi.net/lanczos/badbw.png

Unfortunately the algorithm isn't perfect. Look at the "out of order" text, it looks better without the anti-ringing extra processing. Maybe someone has an idea on how to further improve the algorithm? But I think it's working quite well already as it is...

Here is a bigger picture:

http://madshi.net/lanczos/lanczos.rar

[Guest]

What's your source for this material?

How is this different from LimitedSharpenFaster?

[Didée]

It's the concept of LimitedSharpenFaster. The difference is that LSF first does its supersampling/resizing stuff with a standard lanczos or spline resizer, and the limiting comes after that. So, where the standard resizers do ring, there LSF will ring, too.

A basic resizer by the same method:

LanczosResize(dest_x,dest_y).Repair(Gaussresize(dest_x,dest_y,p=100),1)

[madshi]

What's your source for this material?
The original photos used for testing were downloaded somewhere from the internet.

A basic resizer by the same method:

LanczosResize(dest_x,dest_y).Repair(Gaussresize(dest_x,dest_y,p=100),1)
Hmmmmm... I didn't know the "Repair" filter. Seems that it uses the same concept, but it's not as well optimized for the specific case, I think. E.g. from what I've just read, "Repair" always compares 3x3 pixels. From my tests that's a good general purpose solution, but maybe not the best solution specifically for scaling. For upscaling I'm only comparing 2x2 pixels (those which are nearer to the "center"). For downscaling it can be more than 3x3 pixels, depending on the scale factor.

Or in short: The algorithm I described is custom tailored to "contributor" based resampling algorithms, by making use of the information in the contributor list. I think this should result in slightly superior quality because exactly those pixels are compared which are the main contributors to the final destination pixel. If we compare too many or not enough pixels, the algorithm should get a bit less effective (e.g. miss some ringing or misdetect ringing).

Maybe we should do some comparison tests?

One thing I'm wondering about: "LanczosResize.Repair" does appear to be rather similar to my suggestion. So why is it (seemingly) used rather rarely? At least from what I've read in the forums, many people complain about Lanczos ringing and I haven't ever seen "LanczosResize.Repair" being mentioned as a possible workaround.

[Guest]

The original photos used for testing were downloaded somewhere from the internet. Can't you remember where? I want to read more about the algorithm.

Also, where do I find the Repair filter?

[madshi]

Can't you remember where?
The black&white image is from here:

http://compression.ru/video/resampling/index_en.html

The other two crops are from a photo I downloaded from a digicam review site, so not related in itself to scaling in any way. The original photo I used for testing is contained in the RAR linked in the first post.

I want to read more about the algorithm.
Do you mean the general Lanczos algorithm? In that case you can check out either AviSynth's source code or "swscale.c/h" (libav).

Or do you mean the algorithm I described here? I've "invented" that algorithm myself. So there's no website I can point you to. But if you know how Lanczos works then the description in the first post of this thread should be easy enough to understand. If you have any questions, just let me know...

But it seems that the basic concept of my algorithm was already used by "Repair" und "LimitedSharpenFaster" before. So I didn't really find anything new. Maybe a little quality optimization of what already existed.

Also, where do I find the Repair filter?
It's part of the AviSynth package "RemoveGrain". If you download "RemoveGrain", there's a HTML documentation inside which explains how "Repair" works.

[Didée]

The repair() method is pretty basic, yes. However, the main problem is one step deeper. The approach with clipping to not go beyond the limits of a given neighborhood has downsides. It prevents ringing/overshooting in those places where you don't want such. Yes. But it also prevents ringing/overshooting in those places where you do want it. Ouch#1. In both cases, the output signal is not smooth anymore, due to the possible clipping of the signal peaks. Ouch#2.
Rule of thumb: you don't want overshoot on one-step gradients, but you do want overshoot on the center of two-step gradients.

[Guest]

Unfortunately I'm not an Avisynth developer, so I can only describe the algorithm, maybe someone else experienced with Avisynth can implement it.

How did you make screenshots of your algorithm if you could not implement it? You're really confusing me.

[Fizick]

neuron2,
he may be not Avisynth but for example Gimp developer...

[madshi]

The repair() method is pretty basic, yes. However, the main problem is one step deeper. The approach with clipping to not go beyond the limits of a given neighborhood has downsides. It prevents ringing/overshooting in those places where you don't want such. Yes. But it also prevents ringing/overshooting in those places where you do want it. Ouch#1. In both cases, the output signal is not smooth anymore, due to the possible clipping of the signal peaks. Ouch#2.
Yeah, I see the problems, they do show as artifacts.

Rule of thumb: you don't want overshoot on one-step gradients, but you do want overshoot on the center of two-step gradients.
That makes sense. The problem for me is that the pixel right next to an edge usually fails the "is this part of a gradient?" check - because the edge is right next to it. And this pixel is in danger of ringing. I've tried to detect gradients, but all I tried looked worse than the rather simple "clip any out of range values" approach.

How did you make screenshots of your algorithm if you could not implement it? You're really confusing me.
Sorry about the confusion. I've my own Delphi based scaling implementation. I came up with an IMHO ok looking workaround for the ringing problem so although I can't offer an AviSynth solution I thought I'd at least share the exact algorithm I'm using, in case one of the AviSynth devs is interested...

[tetsuo55]

This looks very interesting.

Although the nr-lancsoz has some artifacting i find this less disturbing than the ringing caused by normal lanczos.
I also find the words easier to read.

So we actually have 3 problems right?

*Ringing introduced by lanczos
*Artifacting introduced by Ringing fix
*Inability to handle gradients correctly.

Would it be possible/doable to use some kind of 2 pass approach?

1. Analyse image (filter out gradients)
2. Prepass NR-Lancsoz
3. Prepass "gradient-lanczos" ?
4. Merge result
5. Compare to original image to fix artifacting

Some expert could probably put all of this into 1 single pass...

[madshi]

*Ringing introduced by lanczos
*Artifacting introduced by Ringing fix
Yes.

*Inability to handle gradients correctly.
Huh?

[tetsuo55]

Huh?Your post earlier:That makes sense. The problem for me is that the pixel right next to an edge usually fails the "is this part of a gradient?" check - because the edge is right next to it. And this pixel is in danger of ringing. I've tried to detect gradients, but all I tried looked worse than the rather simple "clip any out of range values" approach.

[madshi]

Your post earlier:
This falls into the category "Artifacting introduced by Ringing fix". It's not a 3rd extra thing.

[tetsuo55]

This falls into the category "Artifacting introduced by Ringing fix". It's not a 3rd extra thing.

Ahh i guess i misunderstood that a separate problem

[unix_sansei]

add more lobes to reduce ringing or program up the mitchell or catrom.

[madshi]

add more lobes to reduce ringing
What!? Adding more lobes *increases* ringing.

or program up the mitchell or catrom.
That's not the point of this thread. Mitchell is noticeable softer than Lanczos. And Catmull-Rom has a lot more aliasing than Lanczos.

[Gavino]

Furthermore, Mitchell and Catmull-Rom are already available through BicubicResize.

[unix_sansei]

What!? Adding more lobes *increases* ringing.


That's not the point of this thread. Mitchell is noticeable softer than Lanczos. And Catmull-Rom has a lot more aliasing than Lanczos.


that's what i say What?

the infinite sync or besselj(arg)/arg are mathematically ideal for sampling.

when you window them, chop off lobes, you get ringing. the ringing is because your weights are relatively large negative if you have a very limited number of lobes. the more lobes you have the less significant the ringing as the negative coefficients are much smaller.

Mitchell are softer but generally they don't ring. so balance whether the softer is better overall or ringing.

[madshi]

the infinite sync or besselj(arg)/arg are mathematically ideal for sampling.

when you window them, chop off lobes, you get ringing. the ringing is because your weights are relatively large negative if you have a very limited number of lobes. the more lobes you have the less significant the ringing as the negative coefficients are much smaller.
That goes contrary to anything I've read and seen. See here:

http://audio.rightmark.org/lukin/graphics/lhouse_more.htm

You will notice that the "Sinc filter" has more ringing than anything else. The "Sinc filter" may be theoretically ideal, but it still has the most ringing compared to any other filter. If you think that this is not true, why don't you post a comparison screenshot between Lanczos and infinite Sinc filtering? I'd love to see infinite Sinc filtering without ringing!

Mitchell are softer but generally they don't ring. so balance whether the softer is better overall or ringing.
You seem to misunderstand the purpose of this thread. I didn't start this thread to get help in finding a filter which doesn't ring. The purpose of this thread is to discuss a specific algorithm I've found which allows to do Lanczos filtering without getting ringing. So talking about Mitchell is out of topic here...

[Manao]

Sinc filter won't ring if the input signal isn't aliased (but, alas, non-aliased input signal will already look too soft...)

[madshi]

Sinc filter won't ring if the input signal isn't aliased (but, alas, non-aliased input signal will already look too soft...)
Are you sure about that? It is my understanding that ringing is produced by "contributors" that are more than 1 pixel away from the center and which fall on contrasty edges. I don't see what aliasing has to do with it.

In the screenshot here:

http://audio.rightmark.org/lukin/graphics/lhouse_more.htm

... you can see that the Sinc filter shows very strong ringing for both aliased and non-aliased edges.

[Manao]

http://en.wikipedia.org/wiki/Whittaker%E2%80%93Shannon_interpolation_formula

Basically, if the signal isn't aliased, the limiting conditions are met, thus the sampling theorem states you can reconstruct the signal exactly.

[madshi]

http://en.wikipedia.org/wiki/Whittaker%E2%80%93Shannon_interpolation_formula

Basically, if the signal isn't aliased, the limiting conditions are met, thus the sampling theorem states you can reconstruct the signal exactly.
I read that wikipedia article differently. It lists two limiting conditions which must apply so that we can reconstruct exactly. These conditions are some funny math stuff. E.g. "The sampling rate, fs, must exceed twice the bandwidth". I don't even understand what this means for image resampling. Anyway, the wikipedia article does not list "non-aliased input" as one of the limiting conditions (which you stated in your previous post). Instead wikipedia says that the *output* of the Sinc filter will be aliased if those two limiting conditions are not met.

Anyway, do we agree that the Sinc filter rings more than Lanczos does?

[Manao]

Then check out aliasing's definition : http://en.wikipedia.org/wiki/Aliasing

[*.mp4 guy]

Manao is correct, also, perfectly band limited signals "never happen". If you created a reasonable imitation of a perfectly band limited signal using the imperfect tools available, it would look quite bad, and you would have a lower S/N/Resolution ratio then if you used more standard resampling methods.

[madshi]

I have to admit that I'm far from a math guy. So most of the discussion in the wikipedia articles is over my head. But anyway, I'm not really interested in things like "under specific theoretical circumstances the Sinc filter doesn't ring", if these circumstances usually do not apply to real world image/video content.

So can I get a straight answer out of you math gurus, please? :) Does the Sinc filter ring with typical real world image/video content? Does it ring more or less compared to e.g. Lanczos4?

Thanks!

[Manao]

On aliased images, it will ring more, because it isn't windowed.

[madshi]

Thanks.

[NicolasRobidoux]

...
... or besselj(arg)/arg are mathematically ideal for sampling.
...

Do you have references for this statement? (Besides Andreas Gustafsson's 1993 Helsinki UT Masters thesis and the fact that it's implemented in ImageMagick?)

[NicolasRobidoux]

I tried something related in this thread on the ImageMagick Forums (http://imagemagick.org/discourse-server/viewtopic.php?f=22&t=18458). (I was unaware that there were precedents.)

[NicolasRobidoux]

...
You seem to misunderstand the purpose of this thread. I didn't start this thread to get help in finding a filter which doesn't ring. The purpose of this thread is to discuss a specific algorithm I've found which allows to do Lanczos filtering without getting ringing. So talking about Mitchell is out of topic here...

(Possibly out of topic) LBB-Nohalo (LBB stands for "Locally Bounded Bicubic"; Nohalo stands for, well, "no halo", that is, no ringing), which is implemented in the
VIPS library: https://github.com/jcupitt/libvips/blob/master/libvips/resample/nohalo.cpp (https://github.com/jcupitt/libvips/blob/master/libvips/resample/nohalo.cpp), which is accessible via the NIP2 (http://www.vips.ecs.soton.ac.uk/index.php?title=Nip2) image resize tool (which, currently, does not align images "correctly" but otherwise works fine), and which is also found in the "samplers" git branch of the GEGL library (in a version, called lohalo, which does not use memory efficiently yet), is a method suitable for resampling and upsampling (but not downsampling) which introduces no ringing and which is pretty sharp and smooth (although it is more suited for non-noisy natural images than, say, binary images or noisy images).

[NicolasRobidoux]

I have to admit that I'm far from a math guy. So most of the discussion in the wikipedia articles is over my head. But anyway, I'm not really interested in things like "under specific theoretical circumstances the Sinc filter doesn't ring", if these circumstances usually do not apply to real world image/video content.

So can I get a straight answer out of you math gurus, please? :) Does the Sinc filter ring with typical real world image/video content? Does it ring more or less compared to e.g. Lanczos4?

Thanks!

Don Munsil (heard of him?) is of the opinion that frequency response is irrelevant w.r.t. image resizing. For example, search for "Don Munsil" in the ImageMagick Forums. (http://imagemagick.org/discourse-server/search.php?keywords=Don+Munsil&terms=all&author=&sc=1&sf=all&sr=posts&sk=t&sd=d&st=0&ch=300&t=0&submit=Search)

Needless to say, not everybody agrees.

My personal opinion is that frequency response matters, but that other things matter as well. What matters depends on what you're doing, and what kind of image you have.

P.S. I forgot to make the link to your query explicit: Basing a filter on the Sinc can only (pretty much) be justified with frequency response considerations.

[*.mp4 guy]

Frequency response matters, but so does impulse response. You get screwed if you blindly optimize for either one. People tend to get around this by using different filters on different types of content; the inevitable arguments over what the best filter is become more clearly pointless when you understand that none of them really work without a human deciding which is appropriate to the situation.

[unix_sansei]

Do you have references for this statement? (Besides Andreas Gustafsson's 1993 Helsinki UT Masters thesis and the fact that it's implemented in ImageMagick?)

you must be kidding this thread over 2 years old...

my own master's thesis dealt with computational electromagnetic fields and optics of lenses. the bessel function arguments are suited because of linear or differential recursion when integrated with a green's function or whatever your basis function is, they are numerically stable where other routines will break down, say on the shadow boundary of a lens. especially when you get in lomel and hankel functions of fractional order or spherical harmonics.

i wrote freakingly fast code in fortran in 32bits on solaris/sparc/dec alpha, back in 1992 that could compute coefficients faster than fft's and were orders of magnitude more accurate. in my case, i blew up and destroyed more professional fft libraries than anyone.

[madshi]

I tried something related in this thread on the ImageMagick Forums (http://imagemagick.org/discourse-server/viewtopic.php?f=22&t=18458). (I was unaware that there were precedents.)
Haha, I was 2 years faster... :)

But really, the credit belongs to Didée, he had a similar idea years before me for his LimitedSharpenFaster Avisynth script.

Don Munsil (heard of him?) is of the opinion that frequency response is irrelevant w.r.t. image resizing. For example, search for "Don Munsil" in the ImageMagick Forums. (http://imagemagick.org/discourse-server/search.php?keywords=Don+Munsil&terms=all&author=&sc=1&sf=all&sr=posts&sk=t&sd=d&st=0&ch=300&t=0&submit=Search)

Needless to say, not everybody agrees.

My personal opinion is that frequency response matters, but that other things matter as well. What matters depends on what you're doing, and what kind of image you have.
I've had some discussions with Don on AVSForum. He believes that more than 2 taps make no sense. But then based on his own arguments I asked him why using 2 taps at all, and why using negative lobes (he prefers Catmull-Rom), with his argumentation he should be using 1 tap. After that question he stopped responding... :p

BTW, what is your opinion about scaling in linear light? Don Munsil and Stacey Spears think it's all good. But recently I heard someone else say that it's good mainly for downscaling but not for upscaling.

[NicolasRobidoux]

...
BTW, what is your opinion about scaling in linear light? Don Munsil and Stacey Spears think it's all good. But recently I heard someone else say that it's good mainly for downscaling but not for upscaling.

Quick and dirty answer: If I had to make a bet, I'd put my money on linear light. But I don't like to gamble.

Less quick: It is reasonable, from a physical viewpoint, to see it as "obvious" that one should resample in linear light. However, when you are dealing with human perception, I'm not totally sure that "reasonable" always applies. This being said, people who compare the results of resampling in linear light (with careful convertion in and out of, say, sRGB) to "straight" appear to generally prefer the "through linear light" results. But I'm not sure the difference jumps at you.

Bottom line: I wish I had more experience/research results/forum threads/... to throw at you, but I don't. And this is not something I've given much thought to: I've always assumed that linear light is better, but I've also believed that it is not, generally, a huge deal. This being said, Oyvind Kolas, whose opinion I generally respect, set up the GEGL library (future GIMP engine) so it does everything in linear light. Anybody wants to place a wager?

(Now, maybe I should read the Doom9 and ImageMagick threads touching the topic... What you're getting is my "top of the hat" opinion, for what it's worth.)

Plausible is not the same as true.

[NicolasRobidoux]

By the way, when I read Don Munsil's statements RE: the irrelevance of frequency response, I went "Yes!"

This being said, the best all purpose filter I put together is the Clamped EWA Jinc Lanczos 3-lobes (in "straight" or "sharpened" versions) which one gets with "convert -filter lanczos (or lanczossharp) -distort resize" in ImageMagick (recent ImageMagick).

The construction of the non-sharpened version of this filter is motivated by a frequency response argument.

Just to say that reality has a way of disagreeing with opinions.

[NicolasRobidoux]

...
Maybe someone has an idea on how to further improve the algorithm? But I think it's working quite well already as it is...

It is working quite well indeed.

Suggestion #1: Don't try to eliminate all haloing. Try to have the "limiter" have a "soffter knee:" Let some haloing through, and consider yourself lucky that you can make the worst of it mostly disappear. Figure out how to set the "limiter" so as to leave things mostly alone when the haloing is "mild", and so that some of it is left when the haloing is "bad."

That is: Don't go for "perfect." Go for "better."

Suggestion #2: Use a scheme that has less haloing and jagginess from the get go like... Clamped EWA Jinc Lanczos 3-lobes.

[NicolasRobidoux]

For sake of comparison, here are the results obtained with five methods developed by my collaborators and me, on the "bull's eye" test image used by madshi in the original post of this thread: http://web.cs.laurentian.ca/nrobidoux/misc/halodemo/bullseye/

Three halo-free methods implemented in NIP2, and two EWA methods implemented in ImageMagick.

imagemagickewalanczossharp.png uses "sharpened" Clamped EWA Jinc Lanczos 3, a linear method which I highly recommend (note how it has basically no visible halo even though it is a linear method with negative lobes);

imagemagickewarobidoux.png uses Clamped EWA Robidoux bicubic, a linear method (the default ImageMagick EWA method);

nip2lbb.png uses LBB (Locally Bounded Bicubic), a nonlinear method;

nip2lbbnohalo.png uses LBB-Nohalo, a nonlinear method which I highly recommend ("Nohalo" image subdivision with LBB finish);

nip2vsqbs.png uses VSQBS (Vertex Split with Quadratic B-Spline finish), an extremely cheap linear method;

original.png is the original used to produce the enlargements.

[madshi]

Interesting. Looking at these results alone, I like "sharpened EWA Jinc Lanczos 3" and maybe "LBB". "LBB-Nohalo" looks pretty soft to me. But then, this is such an artifical test image. Without at least one good quality photo for comparison I can't really judge these algorithms properly.

FWIW, here are a couple comparisons:

standard Lanczos4: http://madshi.net/bwLanczos4.png
non-ringing Lanczos4: http://madshi.net/bwNonRingingLanczos4.png
modified ICBI: http://madshi.net/bwICBI.png
Progressive Refinement: http://madshi.net/bwPR.png
NNEDI3: http://madshi.net/bwNNEDI3.png
Imagiris: http://madshi.net/bwImagiris.png

Now let's do at least one good quality photo. If possible three or four.

[NicolasRobidoux]

...
Interesting. Looking at these results alone, I like "sharpened EWA Jinc Lanczos 3" and maybe "LBB". "LBB-Nohalo" looks pretty soft to me.
...

Warning: LBB-Nohalo is really meant for natural images. When used with a binary image, the slope limiting is so strong that there is no "sharpening", and LBB-Nohalo boils down to doubling the density with bilinear and then interpolating the double density result with LBB. The softness comes from the bilinear step.

Expect some more results (using your "parkmeter") soon.

[madshi]

Ok, here are the parkmeter results:

standard Lanczos4: http://madshi.net/parkingLanczos4.png
non-ringing Lanczos4: http://madshi.net/parkingNonRingingLanczos4.png
modified ICBI: http://madshi.net/parkingICBI.png
Progressive Refinement: http://madshi.net/parkingPR.png
NNEDI3: http://madshi.net/parkingNNEDI3.png
Imagiris: http://madshi.net/parkingImagiris.png

[*.mp4 guy]

For natural images, this comparison (http://www.general-cathexis.com/interpolation/index.html) is obligatory.

[madshi]

Yes, that's a good one, I've had that in my bookmarks for a long time. I also like to use the clown image for testing.

[NicolasRobidoux]

Ok, here are the parkmeter results:
...
standard Lanczos4: http://madshi.net/parkingLanczos4.png
non-ringing Lanczos4: http://madshi.net/parkingNonRingingLanczos4.png
modified ICBI: http://madshi.net/parkingICBI.png
Progressive Refinement: http://madshi.net/parkingPR.png
Imagiris: http://madshi.net/parkingImagiris.png
Here are mine:
http://web.cs.laurentian.ca/nrobidoux/misc/halodemo/parking

[NicolasRobidoux]

For natural images, this comparison (http://www.general-cathexis.com/interpolation/index.html) is obligatory.
I'm happy to do the "clown" and/or the "lighthouse," but I'd like to point out that the "original" images on the site are produced by downsampling with (orthogonal) Lanczos 3, and consequently they have a fairly unusual combination of quality features and artifacts.

In particular, the "small original images" have noticeable haloing to start with. The lighthouse has obvious moire to boot.

[*.mp4 guy]

I'm happy to do the "clown" and/or the "lighthouse," but I'd like to point out that the "original" images on the site are produced by downsampling with (orthogonal) Lanczos 3, and consequently they have a fairly unusual combination of quality features and artifacts.

In particular, the "small original images" have noticeable haloing to start with. The lighthouse has obvious moire to boot.
If you don't want to work with those images that's fine, but the clown image is of above average quality, and contains no glaring defects. It is generally what should be expected of competent linear interpolation.

The parking meter image also contains defects, it appears to have been box downsampled, which provides insufficient protection from aliasing, which is manifest quite clearly in the results of interpolating it. I bring this up only to indicate that most source images that are available will contain defects.

The moire in the lighthouse image is not severe and is almost completely removed by even basic linear interpolation. It represents a tractable and non-pathological test for ability to avoid/correct minor more when interpolating.

[NicolasRobidoux]

Here are the clown enlargements: http://web.cs.laurentian.ca/nrobidoux/misc/halodemo/clown/

[NicolasRobidoux]

Here are the lighthouse enlargements: http://web.cs.laurentian.ca/nrobidoux/misc/halodemo/lighthouse/