| AlexisJazz | |
| May 9 2021, 2:59 PM |
| F35215535: 219xAspect_ratio_thumbnail_crop_test.png | |
| Jun 7 2022, 2:22 PM |
| F35215537: 220xAspect_ratio_thumbnail_crop_test.png | |
| Jun 7 2022, 2:22 PM |
| F35215528: 220output.png | |
| Jun 7 2022, 2:22 PM |
| F35215525: 219output.png | |
| Jun 7 2022, 2:22 PM |
| F34447784: 120px-Just_Group_logo.png.png | |
| May 9 2021, 2:59 PM |
| F34447782: 220px-Just_Group_logo.png | |
| May 9 2021, 2:59 PM |
| F34447780: Just Group logo.png | |
| May 9 2021, 2:59 PM |
https://en.wikipedia.org/wiki/File:Just_Group_logo.png
The original and 120px thumbnail are fine. In the 220px thumbnail about 1 pixel from the left and 1-2 pixels from the right seem to be cropped away. It's noticeable because the P isn't closed and the symmetry on the T is off.
Original:
220px thumbnail:
120px thumbnail:
Example to demonstrate the cropping more clearly: https://commons.wikimedia.beta.wmflabs.org/wiki/File:Aspect_ratio_thumbnail_crop_test.png
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T43371 Thumbnail/imagescaler (tracking) | |||
| Open | None | T108517 PNG thumbnails issues (tracking) | |||
| Open | None | T282385 Certain PNG thumbnail sizes get cropped (one or two pixels missing) |
Though less than ideal in this case, this is expected behavior.
# The ^ + gravity + extent trick is necessary to ensure that we get a thumbnail # of exactly the width we've requested. In some edge cases a tiny fraction # of the image might be cropped out. This is unavoidable with ImageMagick # See http://www.imagemagick.org/Usage/resize/ for details
This effect is most prominent in high aspect-ratio files at lower resolutions like this, because there is no way to fit the image into the requested size. Doing the math, height = 20 / 235 * 200 = 18.7. Can't have a .7 of a pixel, so we round to 19. However, there's no way to fit a 235x20 image in a 220x19 box without stretching, cropping, or changing the size of the box, and cropping usually produces the best result.
My advice would be to use the 235px version instead of the 220px version, or add padding to the image.
Defining the size in pixels is a bad idea because users have varying displays with various DPI values. Logos having zero padding is very common and even if the uploader sees no problem on desktop, a mobile user or someone with a different thumbnail size preference setting may get a cropped logo.
In your calculation, you mean "20 / 235 * 220 = 18.7". (you wrote 200) So the problem is a rounding error because the aspect ratio is different: 11.75:1 for the original vs. 11.58:1 for the thumbnail. (about 1.6% deviation)
Less than 15 pixels height means you won't get anything realistically useful other than a decorative line, and that's pushing it. With 15 pixels height, the maximum deviation would be if the real height was 15.501, resulting in a 3.2% deviation.
You will be severely disappointed when you find out how many people don't even notice (or just don't care) when an old 4:3 television broadcast is stretched to 16:9. (33% wider) So stretching the image for thumbnails is imperceptible in any realistic scenario, even for freaks like me who are absolutely anal about this.
Cropping on the other hand leads to issues like the one here. Complete removal of padding (if there ever was any) is very common. I've uploaded another example of what cropping does to https://commons.wikimedia.beta.wmflabs.org/wiki/File:Aspect_ratio_thumbnail_crop_test.png including what stretching does.
@Gilles your name appears a lot in imagemagick.py. Do you know why thumbnails are getting perceptibly (in some cases) cropped instead of imperceptibly stretched?
@AntiCompositeNumber pointed to the right comment. ImageMagick has limited options in that area. It's either a choice of always getting an exact width and a tiny percentage of the image being potentially cropped (what we do now) and always having the full picture but the width may vary by 1 pixel. Since the thumbnail width is expected to be a precise value in MediaWiki/wikitext, we decided to use the former.
If you know a technique that allows us to have the best of both worlds in ImageMagick, you're welcome to try and improve the current situation. But I believe that there will always be edge cases due to rounding floating number operations on resizing dimensions, it's an issue found in other image processing software as well.
-resize doesn't guarantee a 220 pixels wide image as output
The argument to the resize operator is the area into which the image should be fitted. This area is not the final size of the image but the maximum size of the area into which the image is to be fitted.
I can't reproduce this. And I loaded some very old version as I know you're not running the latest. I scaled https://commons.wikimedia.beta.wmflabs.org/wiki/File:Aspect_ratio_thumbnail_crop_test.png to everything from 1x to 500x. Now I have 500 thumbnails that differ exactly 1 pixel in width. I think you're mistaken. If you use -resize 100x100 on Aspect_ratio_thumbnail_crop_test.png the resulting image is 100x7. If you use -resize 100x5 it will scale the image to 71x5. But if you enter -resize 220x you get exactly that.
If you don't want Imagemagick to calculate the height for some reason, use -resize 220x16\! for a guaranteed width and height. (you'll have to calculate the height yourself in this case, but if this is what you need you'd already be doing that)
Thinking about it a year later, what "This area is not the final size of the image" actually only applies if you set both width and height. Since there's no reason to set height, there's no problem.
In light of this the decline reason doesn't seem valid, so reopening.
I used the commands:
convert landscape.png -resize 219x 219output.png convert landscape.png -resize 220x 220output.png
and the result was
| 219x15 |  |
| 220x16 |  |
you can see that ImageMagick changes the aspect ratio to fit into the image, however Wikimedia seems to keep the aspect ratio and trims part of the image:
| 219x15 |  |
| 220x16 |  |
As @AlexisJazz suggested I prefer distorting the image, than trimming the image.