Accuracy of resize filters

Thank you for bringing this to my attention. I must admit that I never really thought about it as I have focused most on the upsampling algorithms where I think that the Wiener filtering methods are some of the best that exist.

The current reduce algorithm is fairly simple and something I did many years ago. For scaling 50%-100% it uses simple bilinear resampling, and below 50% it just computes the average of the pixels that are removed. This works fairly well for reducing by an integer factor as you say, but it will produce artefacts for other values. This is also true when the Wiener methods are selected because the Wiener filtering is only used when enlarging.
Do you know of any good reduce algorithms? I will definetely look at Lanczos if you say it works better. If it is not too complicated to implement I will include it in the next version.

I'm afraid it is not of much use (i think you both know more about images then i do...) but perhaps a little information.
http://home.hccnet.nl/david.dirkse/math … esize.html a bitmap resize algorithm
http://www.americaswonderlands.com/digi … lation.htm Digital Photo Interpolation Review
http://graphics32.org/wiki/
http://freeimage.sourceforge.net/
http://www.cpr.demon.nl/prog_wega2.html a viewer with also 7 filters, this is what i use to (batch) make pictures smaller for use in a wiki or e-mail.

Oops I missed these replies.

For some reason I can't access meesoft.com to get the beta?

I did a bit more experimentation, and it seems to confirm my recent discovery that very few photo processing apps do any form of real downsampling. I don't think IrfanView Lancosz works either (unless it's using a "Lancosz1" filter). For years I have just assumed that when an app says it's using a filter for downsampling that it actually is, because the need is stronger for downsampling (aliasing etc). Now I can understand why it is generally not done, but it's been a bit of an eye-opener.

This is based on the zone plate 'workflow' described above, where the downsized result is heavily gamma adjusted or just thresholded to bring out the 'envelope' of the frequency response, which should be a clearly visible square or circle extending halfway to the edge even if the processing isn't gamma-correct. So far only PolyView and XnView so far have given the correct result (but gamma incorrect). When pre then post corrected for gamma, some of the results from these working Lancosz filters are amazing. This new Analyzer beta might do the first "correct" image resize I've seen in modern times!

Here's my wish-list of image resize features of photo apps:
- Emphasis put on the real resampling based methods, with choice from the best filters (Lancosz 2 and 3 seem to be the most popular). Ideally with a variable frequency response because sometimes textbook bandlimiting doesn't look best, eg capturing the sparkle coming off fine bubbles - where no antialias filtering filtering at all (nearest neighbour) can look best. Also a choice of square (2 * 1D) and circular (2D) filter kernels.
- Most effort focussed on best looking downsize (decimation) results (web, email, digicam images into reports).
- Curve-correct, or at least gamma corrected processing. Most digicams compress the top end (whites) to prevent sudden white-outs and loss of colour (creating an "S" shaped gamma curve), so applying a straight gamma correction can make jaggies worse. Also sRGB is actually gamma 2.4 with a linear section at the low end, so some sort of support for curve mapping makes sense.
- At least 16 bit (ie 48 bit colour) processing with preservation of undershoots (negative values) and overshoots until final rendering to 8 bit. With the option to dither.
- Ability to lock resize to an integer multiple. Many photo apps let you put in 50% or something, but often they are slightly out (and 33% will never work), or resample with an inconsistent phase. Such integer resizes introduce minimum artifacts, are easier and faster to compute, and are more predictable (eg when resizing a graph with a 1-pixel grid it won't blur every 3rd line or something).
- Integration of rotation and resize to reduce processing steps that would each introduce artifacts.
- Fast or even real-time view, to allow experiments. Now that CPUs are capable of well in excess of 10 billion operations per sec, raw processing power shouldn't be the bottleneck (even if programming it is!).
- While I'm at it, some sort of jpeg save optimisation. Mentioned because it relates to any "region of interest" variable filtering that could be applied eg to the bubbles mentioned above; unfiltered image detail often looks ok with a lot of compresison noise added, while sharp edges on flat surfaces cause problems - so this is kind of related to filtering. At least the filtering always affects jpeg size, and size is usually the only reason for downsampling images these days.

Well, I think that should be enough for now!

The download should be working again now.

Just a note on integer resizing: If you use the bilinear method it will replace each block of 2x2 pixels with their average in one pixel. With Lanczos the scaling is computed a bit differently which might explain the effect you see:
When scaling from e.g. a width of 1024 to 512 the position of the last pixel goes from 1023 to 511 because the first pixel is at position 0. This means that the internal pixel mapping factor is actually 511/1023 = 0.4995.

If you make your image with a white pixel every 4 H and V at 1023x1023 and resize it to 512x512 using Lanczos then you will get the result you expect because the internal scaling factor is 511/1022 = 0.5.

Tip: You can make IA generate such an image if you select File | New and set the parameters 1023, 1023, 8 bit grayscale, I(x,y) = ((x%4)+(y%4)=0)*255.

New, related question.

I'm just trying the batch processor, and don't know how to get the new Lancosz resize methods to work. I've tried variations on Resize(800,600,Lancosz) - and it just says "invalid resampling method". Maybe not implemented yet, but thought I'd ask!

I since realised batches are processed by a separate executable so my question was rather silly.

The new ver will be great - looking forward to it.