Template talk:BadGIF

Reasons why some still upload GIF images

Commons:Village pump 2006

{{BadGIF}}

Our rules say: "GIF should only be used for animated images." The non-animated GIFs must be tagged witk this tamplate. Sanbec ✉ 22:52, 14 June 2006 (UTC)

Unfortunately, PNG thumbnailing currently sucks for images of certain types, especially those 8-bit greyscale or palette color images which are not derived from a computer-generated diagrammatic source. For example, Image:1812-neoclassical-Young-Ladies-at-Home.png is 111,929 bytes at its original 943x681 dimensions, while the 800x578 alleged "thumbnail" [1] is actually 1,112,034 bytes long -- or in fact, almost exactly ten times bigger!

I had to go through a whole long rigamarole at English Wikipedia village pump (technical) to get the generation of new PNG thumbnails which were in 48-bit format (i.e. RGB 16-colors per channel) stopped, and it's apparently beyond reasonably hoping for that old 48-bit "thumbnails" (which are often LARGER in size than a completely uncompressed BMP would be!) would be purged, or that thumbnails of PNG images which are in 8-bit greyscale or palette color format could be generated simply according to EXACTLY THE SAME algorithm which is currently used to generate GIF thumbnails. (This GIF thumbnailing algorithm isn't perfect, but it's a lot better than the current PNG thumbnailing algorithm, which has absolutely no special handling of 8-bit greyscale or palette color input PNGs whatever.)

So as long as PNG thumbnailing isn't fixed, people will try to get around the problems by uploading GIFs (especially for large 8-bit greyscale or palette color images which are not derived from a computer-generated diagrammatic source). I've been thinking of re-uploading Image:1812-neoclassical-Young-Ladies-at-Home.png (and a few other of my early greyscale PNG uploads) in GIF format, and requesting that the PNGs be deleted... Churchh 18:17, 25 June 2006 (UTC)

Use ?action=purge on the image page to purge the old thumbnails; this system has been in place for at least several weeks.

There are certainly still improvements that can be made to the thumbnailing system; for instance if we can reliably detect opaque files we can output to JPEG, which while lossy will often compress better on images other than extremely simple line art. A quick test with the file you mention above appears to produce acceptable results for inline display while being smaller than the original source file. --brion 20:44, 25 June 2006 (UTC)

Thanks for telling me about ?action=purge -- that enabled me to get rid of a few of the more annoying cases of the old 48-bit color pseudo-thumbnail nonsense. However, the "thumbnail" of Image:1812-neoclassical-Young-Ladies-at-Home.png is still FIVE times larger than the original "high-resolution" version, so that this is only a very limited partial solution to the long-standing problem.

And unfortunately, when I tried to purge on Image:1742-1794-fashion-silhouette-contrast.png, then the new 800px-wide "thumbnail" was now BIGGER than before -- it went from being a uselessly 24-bit RGB color image (when a GIF thumbnail of this very same picture would probably contain only 64 palette colors, and be a lot smaller) to now being a 32-bit RGBA image -- i.e. not only with useless color, but now also with useless alpha channel(!), for an increase in filesize from 383,215 bytes to 435,031 bytes (when the original large "high-resolution" image is only 265,815 bytes in the first place).

Trying to selectively compress PNGs as JPEGs is a horrendous hack which will involve the software trying to guess which PNGs are diagrammatic or cartoony and which are non-diagrammatic and non-cartoony -- and almost inevitably guessing wrong in some cases, giving rise to a whole new set of problems. I really don't understand why you can't just use the EXACT SAME thumbnailing algorithm which is currently used for GIF images, and also apply it to 8-bit greyscale and pallette color input PNG images. That would be the right thing to do -- as opposed to trying to evade the issue of necessary special treatment for color-reduced images by jumping off into a whole new unexplored area of trying to guess which PNGs are JPEG-able. Churchh 23:12, 25 June 2006 (UTC)

That of course requires being able to find out enough about the image to guess how it should be rendered and whether it might look ok that way. GIF is rather simplified by not having all those extra colors; it's *always* 8-bit. ;) --brion 03:41, 26 June 2006 (UTC)

You only have to look at the first 37 bytes of a PNG file (i.e. the info contained in the IHDR chunk) to see whether it contains 8-bits (or fewer) data per pixel, in a completely deterministic manner. If the "Color Type" byte has the values 0 or 3 (and the "Bit-Depth" byte does not have the value 16), then you know that the image data contained within a PNG can be thumbnailed in the same way that the image data contained within a GIF would be thumbnailed. By contrast, I could easily create a PNG which is guaranteed to look extremely crappy as JPEG thumbnail, and your program would basically need artificial intelligence to tell this PNG apart from other PNGs which would look fine as JPEG thumnails.

I really don't understand this apparent rigid insistence on creating uniformly 24-bit RGB thumbnails (or formerly uniformly 48-bit RGB thumbnails, and recently apparently uniformly 32-bit RGBA thumbnails), when there are a large number of images which could perfectly well be handled with 8-bit PNG thumbnails (i.e. PNG thumbnails where the "Color Type" byte in the IHDR chunk has the values 0 or 3, and the "Bit-Depth" byte does not have the value 16). This would sure save a heck of a lot of bandwidth too -- and avoid the absurdity of "thumbnails" which are five or ten times larger than the original unthumbnailed image (an absurdity which drives some people, including me, to still upload certain types of non-animated images in GIF). Churchh 19:45, 26 June 2006 (UTC)

Is there any hope of rendering SVGs with 256 or fewer colors and no alpha-transparency as 8-bit PNGs? That would be a tremendous improvement. —Lifeisunfair 20:51, 25 June 2006 (UTC)

Can anybody update Commons:Images for cleanup to explain how to change gif to png or svg format? Sanbec ✉ 22:57, 14 June 2006 (UTC)

From en.wikipedia Village pump (technical), Feb. 2006

PNG thumbnailing is not just merely bad, but actively horribly sucks

I didn't realize how bad PNG thumbnailing was until I uploaded some greyscale PNG images yesterday, and found (among other things), that the WikiMedia software always makes thumbnails as 48-bit color images(!!), even when the input source image is an 8-bit greyscale PNG or reduced-color indexed PNG. For example, the image Image:1913-Dictates-of-Fashion-Calvert-Life-cartoon.png which I uploaded for article "Fashion" is 155,878 bytes long, but the 280px-wide so-called "thumbnail" displayed in Fashion is 167,988 bytes long, despite being much smaller. To be precise, the source image has 155878 bytes / 553610 pixels (830 x 667) for a ratio of 0.2816 bytes per pixel, while the "thumbnail" has 167988 bytes / 63000 pixels (280 x 225) for a ration of 2.6665 bytes per pixel -- or almost ten times worse...

A simple 280 x 225 256-color uncompressed BMP would be only 64,078 bytes long, so the alleged "compressed" thumbnail http://upload.wikimedia.org/wikipedia/en/thumb/1/1a/1913-Dictates-of-Fashion-Calvert-Life-cartoon.png/280px-1913-Dictates-of-Fashion-Calvert-Life-cartoon.png is actually almost three times as large as an UNCOMPRESSED image would be!

I don't know how difficult it would be to implement in programming, but if the following rules could be followed, it would improve the situation dramatically:

1) NEVER use 48-bit color or 16-bit greyscale (i.e. 16 bits per color channel) in PNG thumbnails.

2) If the input image is a greyscale, the output image should always be a greyscale.

3) If the input image is indexed color, then the output image should also be indexed color (and so will contain no more than 256 colors).

Also, I notice that JPEG thumbnails have an IJG quality setting of 85, when 75 is more or less the "standard" default setting, and the majority of small thumbnail images will give reasonable results with a quality setting of 55 or even lower.

If these thumbnailing problems could be fixed, then that would lessen wasted bandwidth. Churchh 16:34, 3 February 2006 (UTC)

Yes, there seem to be a bug in the handling of grayscale images. Color images get scaled down just fine, but grayscale images become 48-bit RGB. I've no idea what causes this, though. In the mean time, I suppose you could partially work around the problem by reuploading a version saved as RGB... —Ilmari Karonen (talk) 21:33, 3 February 2006 (UTC)

Actually, I was thinking of reuploading a version saved as a GIF... Churchh 15:18, 4 February 2006 (UTC)

If the input image is indexed color, then the output image should also be indexed color (and so will contain no more than 256 colors). This isn't a good idea. Here's an extreme example: a black-and-white image of 2000 x 1500 pixels reduced to 100 x 75 would look like crap reduced to black-and-white, but looks quite nice at 32-bit and wouldn't be bad with an 8 or 16 colour palette. I think it's more reasonable to give the contributor explicit control over the number of colours to reduce to. A temporary workaround for these issues is to upload a properly reduced version for use in articles, put a big scary note on it that it's a temporary measure with a link to the bug (great place for a template), and interlink the big and small versions. Deco 03:33, 4 February 2006 (UTC)

I didn't mean that an indexed-color thumbnail would have the same colors as an indexed-color source -- there could be dithering to an appropriate 256-color palette. Churchh 15:18, 4 February 2006 (UTC)

"Here's an extreme example: a black-and-white image of 2000 x 1500 pixels reduced to 100 x 75 would look like crap reduced to black-and-white"

Yes thats why we need manual control over the process, Judgements about what color depth a scaled version needs to stay looking decent can only be made by humans. Plugwash 13:53, 4 February 2006 (UTC)

I'd say the following ruleset would be better:

1. Never use more than 8 bits per channel in thumbnails.
2. Never use indexed color.
3. Make the thumbnail grayscale if the original is a) grayscale or b) indexed with only grays in the palette.

That's also more or less what my usual method for doing this at home (pngtopnm | pnmscale | pnmtopng) does, except maybe for part 3b. —Ilmari Karonen (talk) 12:37, 4 February 2006 (UTC)

I mentioned the possibility of indexed-color output PNGs because exactly the SAME color pixel data will generally compress much better as an indexed=color image than if put into 24-bit RGB format. This same issue is seen in the Image:1913-Dictates-of-Fashion-Calvert-Life-cartoon.png example, where putting 8-bit greyscale data into a 48-bit RGB color format image greatly hinders compressibility. Churchh 15:18, 4 February 2006 (UTC)

Though your "3b" idea (if an indexed-color image only contains greys, make the output be greyscale) is also good... Churchh 15:41, 4 February 2006 (UTC)

I strongly disagree with prohibiting indexed colour. I've created many images with 32 or 16 colours that were visually indistinguishable from 32-bit colour and were 10 times smaller. Let's give the modem users a break here. Deco 23:49, 4 February 2006 (UTC)

If the image syntax was amended to allow specifying the color depth, that would be fine. But as long as thumbnailing is a one-size-fits-all process, quality should be given priority over compression. That's particularly true since there's no easy way to determine how many colors a thumbnail needs based on the number of colors in the original: as an extreme example, I can take any full-color photograph, scale it up 16-fold and quantize it to 8 colors without any loss of detail. Calculating an optimal palette for an indexed color image also requires an extra pass over the raw image data, which can be costly for large images; scaling down to RGB or grayscale, on the other hand, is a one-pass process that doesn't require keeping the entire image in memory. Finally, if you really need to optimize a particular thumbnail, you can always scale it down yourself and reupload it with a different name. Then just include a link to the original. —Ilmari Karonen (talk) 11:58, 5 February 2006 (UTC)

Oh, okay. I agree with all that. Deco 23:55, 6 February 2006 (UTC)

---

The 16-bit channel issue is fixed now, both by specifying -depth 8 on the command line and by switching to a Q8 version of ImageMagick. As far as I could tell, ImageMagick was not adding channels, 8-bit greyscale images were being converted to 16-bit greyscale images, not 48-bit colour images. Doing anything intelligent with indexed-colour images is difficult, without writing our own scaling routines. Converting them all to RGB is at least robust. -- Tim Starling 06:18, 7 February 2006 (UTC)

It isn't fixed, as far as I can tell. I looked at page Fashion again (trying also from a completely different account to try to get around any caching), and the image http://upload.wikimedia.org/wikipedia/en/thumb/1/1a/1913-Dictates-of-Fashion-Calvert-Life-cartoon.png/280px-1913-Dictates-of-Fashion-Calvert-Life-cartoon.png is still 167,988 bytes long, and pngcheck produces the following report:

File: 280px-~1.png (167988 bytes)
  chunk IHDR at offset 0x0000c, length 13
    280 x 225 image, 48-bit RGB, non-interlaced
  chunk pHYs at offset 0x00025, length 9: 72x72 pixels/unit
  chunk vpAg at offset 0x0003a, length 9
    unknown private, ancillary, safe-to-copy chunk
  chunk IDAT at offset 0x0004f, length 32768
    zlib:  deflated, 32K window, maximum compression
  chunk IDAT at offset 0x0805b, length 32768
  chunk IDAT at offset 0x10067, length 32768
  chunk IDAT at offset 0x18073, length 32768
  chunk IDAT at offset 0x2007f, length 32768
  chunk IDAT at offset 0x2808b, length 3989
  chunk IEND at offset 0x2902c, length 0
No errors detected in 280px-~1.png (55.6% compression).

I did a preview edit with "280px" changed to "250px" to try to get around any Wikipedia-internal caching, and the resulting image 250px-1913-Dictates-of-Fashion-Calvert-Life-cartoon.png was 136,764 bytes long (or about the same compression ratio per pixel, only a tiny bit better), and still shows up as 48-bit color in PNGCheck. Churchh 20:14, 9 February 2006 (UTC)

Try reuploading the image or using an odd size that noones likely to have used before. afaict once a thumbnail is generated it is never regenerated unless a new version of the image is uploaded. Plugwash 21:24, 9 February 2006 (UTC)

Thumbnails are only ever generated once. I've been thinking about wiping them all out (or at least the PNGs) and allowing them to be regenerated, to take advantage of the software change, but I haven't done so yet. Churchh's attempt to get around this caching failed, the 280px thumbnail was created a week ago. -- Tim Starling 22:58, 9 February 2006 (UTC)

Ok, 250px didn't work but 279px did. At least, 279px-1913-Dictates-of-Fashion-Calvert-Life-cartoon.png is not 48-bit color, and is actually slightly smaller than a corresponding uncompressed 8-bit BMP would be (not almost three times longer, as 280px was). I still think that thumbnailing greyscale PNGs as greyscales and thumbnailing indexed color PNGs as indexed color would be a great improvement, but this is obviously as good as it's going to get right now...

For the record, the problem did NOT affect just greyscale PNGs -- for example, Image:1850-g-cruikshank-crinoline-parody.png is an indexed color image (with just 13 colors), yet http://upload.wikimedia.org/wikipedia/commons/thumb/3/37/1850-g-cruikshank-crinoline-parody.png/200px-1850-g-cruikshank-crinoline-parody.png is a 48-bit RGB color image , while Image:1816-neuestenmode-couple.png is a 24bit RGB color image, yet the image description page "thumbnail" http://upload.wikimedia.org/wikipedia/commons/thumb/b/b7/1816-neuestenmode-couple.png/422px-1816-neuestenmode-couple.png is also a (quite huge) 48-bit RGB color image. Churchh 02:44, 11 February 2006 (UTC)

Haabet PNG Gamma example

This is the same image but by different Gamma Haabet

Rewording reverted

The problem with the GIF format is not the artifacts (it's lossless), but the supremacy of PNG (and some MediaWiki problems with scaling). See Commons:File types for more information. Conscious 21:42, 14 February 2007 (UTC)

Images with less than 256 colors

There is no need to convert GIF graphics with less than 256 colors to PNG. It may be useful to convert some of them to SVG, but not to PNG.

Also, PNG is terrible for clickable image maps in most cases because of the previously-discussed PNG scaling problem with the MediaWiki software. An unscaled clickable PNG image map may work out fine. But a scaled clickable PNG image map can be much higher in kilobytes. As in 100 kilobytes versus 500 kilobytes. In that case it may actually be better to create a GIF version of the map for this particular use. Even if less colors are used. --Timeshifter 21:36, 12 May 2008 (UTC)

The reason to use, or not use, the template BadGIF (and {{Convert to PNG}}) is being discussed at Commons:Village pump#Policy PNG vs. GIF which is also cross-linked to the related English Wikipedia en:Template talk:ShouldBePNG#PNG vs. GIF. --Perhelion (talk) 10:29, 23 September 2010 (UTC)

There are many reasons not to convert GIF images to PNG images. Besides the reasons listed here people can read more reasons on this English Wikipedia talk page:

en:Template talk:BadGIF --Timeshifter (talk) 08:53, 24 September 2010 (UTC)

What we can do now? Everyone in the Village pump has argues for the GIF. So can you make a list of arguments, pro and contra? Than we can use it to stop this policy? --Perhelion (talk) 19:02, 5 October 2010 (UTC)

Due to all the talk pages most people ignore most demands to change GIF images to other formats. The most important thing is that the GIF images aren't deleted. People can convert them to other formats, but as long as they don't delete the GIF images, I am not worried. --Timeshifter (talk) 22:59, 6 October 2010 (UTC)

I echo Timeshifter's point that it is important we do not delete the original image file. Because "deletion of superseded images has been suspended indefinitely" (see Commons talk:Superseded images policy) it should no longer matter whether an image has a {{Superseded}} template attached. PS: the above Village pump link isnow archived at Commons:Village_pump/Archive/2010Sep#Policy PNG vs. GIF -84user (talk) 17:15, 7 October 2010 (UTC)

But this all is not necessary cleanup tagging, we all know here are too few people to support commons for more important things. Look here Commons_talk:Media_for_cleanup#Problems_with_.7B.7BBadGIF.7D.7D_template. There is no support and no policy for this template (from a single user). The time is overdue to delete this template. Please make a detailed list of significant for the delete nominating. There also other unpreferred image formats (like tiff) there are also not such policy for cleanup. --Perhelion (talk) 20:16, 18 October 2010 (UTC)

CONTRA GIF (PRO PNG)

• Some GIF cause problems with thumbnails?
• GIF compression is lower than PNG (from 0-9 zip compression), but only if the PNG is also saved with lower (indexed) color depth (the thumb is always larger?)
• Scaled GIF are unsharper than PNG in truecolor^[2]
• GIF transparency has lower quality, especially if scaled (no alpha transparency)

-- Perhelion (talk) 21:07, 18 October 2010 (UTC)

CONTRA PNG (PRO GIF)

Remove this template from superseded images?

Hi all. I've been doing some conversion of inappropriate GIFs to more appropriate formats, and I was wondering---when I place the {{superseded}} template on the inappropriate GIF page, should I remove the {{badGIF}} template? On the one hand, removing the template removes the image from Category:Images with inappropriate GIF format, meaning users looking to fix up bad GIFs don't have to wade through already-fixed ones. But on the other hand, the template serves as a good warning to people that a GIF shouldn't have been used in that scenario. Any thoughts? (In the meantime, I'll keep removing them.) MithrandirMage (talk) 01:16, 31 May 2009 (UTC)

It would be better if they would fix PNG resampling (see the just-uploaded example File:1885_Punch_three-volume-novel-parody_Priestman-Atkinson.png, where a 189 KB image is resampled down to a 395 KB 800 × 558 pixel image), instead of just turning off GIF resizing. Churchh (talk) 08:49, 1 June 2009 (UTC)

Why hasn't GIF resizing been turned back on? I thought they had found a solution to the animated gif resizing problem.

When I save the resampled 800 × 558 pixel image as a GIF file it is only 151 kilobytes. It is illogical to ask people to upload these type of grayscale or black-and-white images as PNG images. GIF images avoid all these PNG scaling problems.

This illogical bias against GIF images needs to stop. It is now a completely free lossless 256-color image format which is fine for graphics or cartoons that use less than 256 colors. The GIF image format is no longer under any patents or copyrights. --Timeshifter (talk) 12:51, 3 June 2009 (UTC)

template protection

{{editprotected}} After the recent vandal attack it would be nice if an admin protects this template. --Denniss (talk) 15:33, 14 July 2009 (UTC)

 Done Protected as a widely used template. --Mormegil (talk) 15:46, 14 July 2009 (UTC)

Making an update more user friendly.

You have a couple of options as newbies dont know how to do some things,

1. link to the newbie list of steps...
2. perhaps modify the message "After doing so, please tag the JPEG version with ((Superseded|NewImage.ext)), and remove this tag." so TAG is clikable because as far as i can guess, the process is as follows: upload a new image by clicking "upload a new version of this file" with the text "((Superseded|NewImage.ext)), and remove this tag" in it and as the text in "file changes" text box - which seems incorrect.
3. alternatively place "Upload a new version of this as another filetype" near "Upload a new version of this file" which could do all that is required automatically. — Preceding unsigned comment added by Charlieb000 (talk • contribs) 05:22, 13 January 2014‎ (UTC)