6

Can anyone clarify if the GDI StretchBlt function for the workstation Win32 API performs bilinear interpolation for scaling to both larger and smaller images for 24/32-bit color images? And if not, is there a GDI (not GDI+) function that does this?

The SetStretchBltMode fn has a setting HALFTONE which is documented as follows:

HALFTONE Maps pixels from the source rectangle into blocks of pixels in the destination rectangle. The average color over the destination block of pixels approximates the color of the source pixels.

I've seen references (see follow-up to first answer) that this performs bilinear interpolation when scaling down an image, but no clear answer of what happens when scaling up.

I have noticed that the Windows Mobile CE SDK does support a BILINEAR flag - which is documented exactly opposite of the HALFTONE comments (only works for scaling up).

Note that for the scope of this question, I'm not interested in pursuing GDI+ (which has numerous interpolation options), OpenGL, DirectX, etc. as alternatives, so please don't bother with follow-ups regarding these other APIs or alternate image libraries.

What I'm really hoping to find is some definitive MS/MSDN or other high-quality documentation that clearly documents this behavior of the Win32 (desktop) GDI behavior.

Meanwhile, I'll try some experiments comparing GDI vs. Direct2D (which does have an explicit flag to control this) and post my findings.

Thanks!

Community
  • 1
  • 1
holtavolt
  • 4,378
  • 1
  • 26
  • 40
  • What happens when you tried using both features to render to a surface with low bit depth, ie a 1 bit surface? – SingleNegationElimination Nov 22 '10 at 22:25
  • I'll try that, too. My initial tests on scaling up using HALFTONE certainly appear to be averaging the pixels. – holtavolt Nov 22 '10 at 22:51
  • And clearly COLORONCOLOR shows the expected nearest-neighbor pixelization when zooming up on the same test image. – holtavolt Nov 22 '10 at 23:19
  • Not sure how useful this is but I've found GDI only takes the SetStretchBltMode as a suggestion. With certain images it will ignore it and always do nearest-neighbour. It seems to use a heuristic to do this and seems more likely to use nearest-neighbour in simple images with few colours. (I use it in a simple animation player and, as a result, when zooming it sometimes turns the bilinear filtering on/off for different frames because the slightly different source images do/don't trigger it, which is quite odd.) What happens may depend on graphics drivers as well, I suppose. – Leo Davidson Nov 23 '10 at 00:01
  • @Leo, my experience is that nearest neighbor is always used when the source is a paletted image. I don't know how an animation would use different algorithms for different frames. – Mark Ransom Nov 23 '10 at 05:40
  • @Mark Ransom, here's an example of what I mean: http://www.pretentiousname.com/gifanim/images/coloroncolor_heuristic.png -- That's an Animated GIF viewer I wrote, showing all frames from a GIF zoomed 400%. Each frame is decoded to a separate 24-bit bitmap, then they're drawn individually via GDI using identical settings. As you can see, some of the frames were scaled differently to others. (In this case the first 2 vs the last 3, but other anims show it on different frames, not always partitioned like that.) – Leo Davidson Nov 23 '10 at 06:47

2 Answers2

8

I've been looking into this same problem for the past couple of weeks.

As far as I can tell, there does not exist any definitive documentation on this behaviour from Microsoft.

However, I've run some tests myself, to try and establish the degree to which StretchBlt can be trusted to perform consistently with respect to up- and down-scaling images in halftone mode.

My findings are:

1) StretchBlt does produce adequate quality up- and down-scaled images. It might be a touch below Photoshop quality, but probably OK for most practical purposes.

2) It seems to depend upon hardware acceleration, whenever it's available. I haven't been able to confirm this, but I have a slight fear that this may lead to different outputs on different types of hardware. However, on the 5 or 6 different systems I've tried it on, old and new, the performance has been consistent and fast.

3) If you use the call on a 16-bit color device, or lower, StretchBlt will automatically dither your image. If you run it on a 24-bit color device, it will not dither.

4) If you use it to scale small images (smaller than 150x150px), it will randomly fall back to nearest neighbour interpolation. This can be remedied in your own software, by padding the bitmap before scaling, doing StretchBlt on it, and then removing the padding afterwards. Kind of a hack, but it works.

bjaastad_e
  • 691
  • 6
  • 10
0

HALFTONE mode performs a very blocky halftone dithering on the image, based on varying the conversion thresholds over a defined square. I have never seen a situation where it would be considered the best choice.

COLORONCOLOR is the best mode for color images, but as you've seen it doesn't give great results.

GDI does not support a bilinear mode (except in Windows Mobile CE as you discovered). The naive implementation of bilinear does not do very well when shrinking an image, as it simply tries to interpolate between two adjacent input pixels without trying to draw from a larger area.

Mark Ransom
  • 299,747
  • 42
  • 398
  • 622
  • 2
    In my case, the source and target are both 24-bit color, and the image is a grayscale image. In my experiment with scaling up a region of such an image using HALFTONE, the result appears to be bilinear interp (as COLORONCOLOR on the same image is clearly nearest neighbor) and there's no signs of dithering. That said, I don't want to rely on undocumented behaviors, so I'll find another solution if I can't count on this behavior being consistent. – holtavolt Nov 23 '10 at 15:10
  • @holtavolt, that's very interesting information about HALFTONE, too bad about it being undocumented. My experience with it is very old and probably not relevant to 24-to-24 copies. I'm guessing it still doesn't deliver very good results when shrinking, you didn't mention if you had tried it or not. – Mark Ransom Nov 23 '10 at 16:44
  • Actually, it looks OK on shrinking for 24-bit greyscale as well (likely bilinear, but may be nearest - would have to use something like ImageMagick to be sure). – holtavolt Nov 23 '10 at 20:29
  • @holtavolt, now I'm going to have to do my own experiments, you have me curious. – Mark Ransom Nov 23 '10 at 23:16