Page MenuHomePhabricator

Non-animated GIF files with transparent background lose quality and parts of foreground when downsized
Closed, InvalidPublicFeature

Description

List of steps to reproduce (step by step, including full links if applicable):

What happens?:

The generated thumbnail looks fine but down at the file history section where there is a smaller version it looks awful, the foreground is all messed up. On the first the text "Stolle & Heinz Consultants" is unrecognizable and one of the three lines is not rendered. On the second the text to the right is all gone.

What should have happened instead?:

It should look fine both on top and in the file history section. The text should be possible to be read and there should be three lines, not two.

Other information:

There are also more examples at https://en.wikipedia.org/wiki/User:Jonteemil/sandbox3#GIF_files_that_look_bad_in_file_history. It seems that this very problem already had a task, T15252, but it was closed a decade ago as resolved. Evidently the fix they came up with has been undone in the meantime.

Event Timeline

Aklapper triaged this task as Lowest priority.May 17 2022, 1:47 PM

@Aklapper You think that's related?

Don't know about Aklapper, but I don't. My guess is the limited color palette of GIF is preventing the thumbnails from looking decent. 120px-Shc_logo_ppt_rgb_urlogo_freigestellt.gif looks like crap but 120px-Shc_logo_ppt_rgb_urlogo_freigestellt.gif.png looks a bit better. Forcing PNG thumbnails for GIF files would probably be an improvement.

I agree with @AlexisJazz :

  • T282385 is about that you define the width, then the height has to be rounded to the next integer, therefore the aspect-ratio of the frame does not fit, this might be a serious issue with ultra-landscape-impages
  • However T308556 is about gif, different to png do not have an alpha channel.

GIF doesn't have an alpha channel like PNG, so you can't get smooth transparent edges. The alpha channel specifies how transparent each pixel is, so you could have half-transparent pixels for example. GIF on the other hand is limited to 8 bit colors and one of them is designated as the transparent color.

Some say GIFs should be generally replaced by PNGs, because of such issues, which is imho wrong, see e.g. https://commons.wikimedia.org/wiki/Commons_talk:Superseded_images_policy#Scaled_GIF_images_use_much_fewer_kilobytes_than_scaled_SVG/PNG_images by @Timeshifter . However many users do not understand the Differences between SVG, JPEG, PNG and GIF, that's why they sometimes use the wrong format, that's why especially transparent GIFs are very problematic, since most users are too unexperienced to choose the right format.

Let's compare the rendering with ImageMagick 6.9 using the command
convert Shc_logo_ppt_rgb_urlogo_freigestellt.gif -resize 120x120\> 120px-Shc_logo_ppt_rgb_urlogo_freigestellt.gif

Thumbor-Renderinglocal ImageMagick-Rendering
Shc_logo_ppt_rgb_urlogo_freigestellt.gif.gif (38×120 px, 1 KB)
120px-Shc_logo_ppt_rgb_urlogo_freigestellt.gif (38×120 px, 568 B)

This is not a Thumbor-issue, it is a issue of looking at 120px-thumbmails of a resized GIF with transpraency. GIF would be imho the wrong format if you would need to scale those logos.

@Aklapper I think we should close it as invalid.
Other options are to rename it to:

  1. "transparent GIFs should be converted to PNGs on rescaling"
  2. "transparent GIFs should be convertet to not transparent GIFs on rescaling"

Because the gif image format is 8-bit only. So gif images only scale to 8-bit versions. So they use a lot fewer kilobytes than scaled SVG/PNG images on MediaWiki.

Technically true but not an advantage of the GIF format. There are some potential savings to be had by restricting the color palette for PNG thumbnails with generally no perceivable quality loss, but, umm, nobody really cares. Whoever pays the server bills doesn't know and whoever could write a patch that does that doesn't pay the server bills. The biggest issue is probably the million edge cases to consider. But I did some quick tests a while back and there are savings possible.

Other options are to rename it to:

  1. "transparent GIFs should be converted to PNGs on rescaling"
  2. "transparent GIFs should be convertet to not transparent GIFs on rescaling"

Removing transparency wouldn't be acceptable so that leaves only one option.

There's another potential issue: I'm not sure animated GIFs can be detected/handled easily. Because you can't convert those to PNG. The parser would have to check while parsing.. Seems potentially problematic.

Edit: sorry, lazily copied the page title, it is indeed the talk page of the policy, not the policy.

Superseded images policy:

It is only a discussion, speaking imho a bit against the current policy. This discussion may only represent the opinion of some individuals.

There's another potential issue: I'm not sure animated GIFs can be detected/handled easily. Because you can't convert those to PNG. The parser would have to check while parsing.. Seems potentially problematic.

@AlexisJazz Converting animated GIFs to PNG, without losing the animation is possible if you convert it to APNG (*.png) instead. Basically all viewers can open the APNG as PNG, and all common browser can even view the animation of APNGs.

The advantage of APNGs compared to animated GIFs is that APNG does have an alpha-channel, see e.g. https://commons.wikimedia.org/wiki/File:Animated_PNG_example_bouncing_beach_ball.png

The gif2apng conversion is even available for debian: https://manpages.debian.org/jessie/gif2apng/gif2apng.1.en.html

I'm not sure if there is a Debian-packed program for resizing APNGs, but small APNGs are currently imho not scaled at all (large APNGs are scaled to a static PNG). The same applies to animated gifs, so I think Thumbor might know (=detect) which files are animated and which not.


I took the first animated GIF from https://en.wikipedia.org/wiki/GIF and conerted it to APNG, and then I rescaled the APNG to 120px width:

120-ezgif-3-cde9fe47c6.png (120×120 px, 312 KB)

If you don't see the animation try opening https://phab.wmfusercontent.org/file/data/g7ngmj2toe77h6ego5no/PHID-FILE-5bvdbavh75ke6eh7upu6/120-ezgif-3-cde9fe47c6.png directly in Firefox or in any Chromium-Based-Browser.

APNG are allowed in Wikiversum, however according to https://caniuse.com/apng Internet Explorer does not support APNGs, which might be a problem.

Okay, so to sum up, this is no Thumbor issue, but rather an issue with the GIF mimetype?

JoKalliauer changed the subtype of this task from "Bug Report" to "Feature Request".

Okay, so to sum up, this is no Thumbor issue, but rather an issue with the GIF mimetype?

Yes the question is this task:
A: An invalid request, since transparent GIF can't downscale better
or
B: A feature request to convert GIF to PNG on downscaling

I changed the Subtype and Status according to my personal opinion, feel free to change/undo.