Discourse loses the top/bottom pixels when generating thumbnails

Feature
1

When you attach images to a post, Discourse resizes them to make thumbnails suitable for display.

There seems to be a bug when it does this which causes it to consistently lose the top and bottom rows of pixels.

This isn’t a huge deal but makes things with thin borders look weird. (e.g. Most Windows 10 software screenshots look wrong because the bottom edge of the window isn’t there.)

Observations:

  • It doesn’t seem due to aspect ratio, so I don’t think it’s the intentional cropping of very wide/tall images; it seems like a bug.

  • I’ve checked that pixels are missing in the actual thumbnail image resource. So it’s happening when the thumbnail is generated on the backend, not when it’s displayed by the browser.

  • Edit: I’ve just noticed that the top/bottom pixels are not gone completely, but they are so blended/faded that they may as well be. Maybe something to do with how the edges of the image are handled by the resize algorithm? It doesn’t ever seem to happen to the left and right edges, e.g. with portrait aspect screenshots.

  • When you click for the full-size image, that is displayed correctly, at least.

Hopefully this example image will reproduce the problem here on the Discourse forum:

1px_red_border
1px_red_border1416×946 757 Bytes

That should be a white image with a 1 pixel red border on all sides. If the problem happens here, you’ll only see the left and right borders until you click for the full-size image.

(Edit: It does indeed seem to happen here.)

In case it doesn’t happen, this is the result I see on my own forum:

example
example1624×1429 55.1 KB

When testing this, you have to wait a little while after posting (and sometimes refresh the thread) for it to happen, since it takes a few seconds after posting for the thumbnail to be generated server-side.

4 Likes
2

Yes, I’ve noticed this too for quite a while. Not sure what can be done about it.

1 Like
3

Interesting, I see the top, left, and right, but not the bottom.

chrome://gpu
Chrome version Chrome/87.0.4280.141
Operating system Windows NT 10.0.19042
GL_RENDERER ANGLE (Intel(R) HD Graphics 620 Direct3D11 vs_5_0 ps_5_0)
1 Like
4

I wonder if it depends on screen size, with different assets being served to different clients.

Having a quick look at the post/image above via F12, I found two assets, plus the original image:

  • Original image (1416 x 946) /original/3X/e/2/e2c5f032e18fa374c0593af71cf25d3499826289.png, which is untouched. Direct URL

  • Smaller version (1380 x 920) optimized/3X/e/2/e2c5f032e18fa374c0593af71cf25d3499826289_2_1380x920.png, which has (almost) invisible top and bottom edges. Direct URL

  • Even smaller version (640x460) optimized/3X/e/2/e2c5f032e18fa374c0593af71cf25d3499826289_2_690x460.png, which has no bottom border at all, but has the left, top and right borders. Direct URL

There might be some ImageMagick arguments to tweak the scaling algorithm and how it handles pixels at the edges, although any change could of course make other situations worse while improving this one.

1 Like
5

Yeah, that’s my thought as well. It’s a scaling algorithm issue. As long as the original version is preserved, I’m not seeing a serious problem here, so I’m moving it to feature request.

4 Likes