This document helps to explain what ImageWorsener’s -intclamp option does.
Consider this little test image:
| in.png |
|---|
![]() |
Here it is, magnified:

Notice in particular that it is perfectly symmetric about a diagonal line from the lower-left to the upper-right:

Now I’m going to enlarge it using ImageMagick, a popular image processing application (I used version 6.6.6-5).
Note: Like most copies of ImageMagick, the one I used was compiled without the “High Dynamic Range Imaging” option. When HDRI is enabled, ImageMagick does not exhibit the problem shown here.
convert in.png -filter lanczos -resize 250x out.png
| out.png |
|---|
![]() |
Look closely, and you can see that the enlarged image does not have the symmetry of the original. There are some vertical streaks in it, but no corresponding horizontal streaks. Why would enlarging a symmetric image make it asymmetric?
Here is a graph of the resampling filter I used:

Like many (but not all) such filters, there are places where it goes below zero. There’s a reason it does this, but it can have some strange effects. It’s what causes the resized image to contain colors that are darker and bluer than any colors present in the original image.
This filter has the property that it is separable, which means that it can be applied in two passes. If you first resize the image in one dimension, and then in the other dimension, you will get the same result as if you had done it in a single pass, or if you had resized the dimensions in the opposite order.
ImageMagick (I’m speculating) takes advantage of this by resizing the image in two stages. In the first stage, it enlarges it horizontally, yielding an intermediate image that would look like this:

Remember those negative regions in the graph above? They can cause the samples to have values that are outside of the range that is normally possible. For example, if white is encoded as 255, you could actually get a value like 270: whiter than white. When that happens, an application might (or might not) deal with it by “clamping” the value: changing it to the nearest supported value, which in this example would be 255.
The problem is, adding this clamping operation to your processing makes it non-separable. So, doing the resize in two stages will affect the output, and it will make a difference which dimension you resize first.
Ideally, you should not do any any clamping until after the whole resizing operation is complete. That means your intermediate image format must be able to support sample values outside the usual range. The copy of ImageMagick that I used did not support such values, and that’s why this problem occurred.
Based on my limited testing of imaging applications, there are many applications that clamp the intermediate samples, but there are also many that do not. If you don’t clamp the intermediate samples, you get a perfectly symmetric image:

In real-world images, this issue is not much of a problem. You’ll probably never notice whether your image scaling application does it right or not, and doing it right could hurt performance or have other disadvantages.
Note: The image processing on this page was done without proper gamma correction. It made the issue more visible, and it has no fundamental effect on the results.