Commons:Bots/Requests/GifTagger

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search

GifTagger (talk · contribs)

Operator: McZusatz (talk · contributions · Statistics · Recent activity · block log · User rights log · uploads · Global account information)

Bot's tasks for which permission is being sought:

  1. Converting problematic[1] static GIFs to PNG
  2. Uploading the PNG
  3. Tagging the source-GIF with the appropriate templates
  4. Posting the replacement to Commons Delinker

[1] Problematic are:

  • GIFs using transparency
  • GIFs using color
  • GIFs using color & transparency

Unproblematic are:

  • Opaque GIFs in greyscale
  • Animated GIFs

Automatic or manually assisted: Automatic

Edit type (e.g. Continuous, daily, one time run): one time run

Maximum edit rate (e.g. edits per minute): less than 12

Bot flag requested: (Y/N): Would be helpful, I guess.

Admin flag requested: (Y/N): Y

Programming language(s): Java

McZusatz (talk) 17:01, 27 January 2014 (UTC)[reply]

Discussion

Is there a community consensus for doing this? Should we really tag each and every gif with a message that requests a re-upload as PNG? I'd think that only a tiny fraction of GIFs would benefit from this (if any). I don't think there is much benefit of just converting a GIF to a PNG. The big PNG feature - alpha transparency - will be unused, unless the image is recreated from scratch (or from a source that has alpha transparency). Maybe I'm missing something... --Dschwen (talk) 17:19, 27 January 2014 (UTC)[reply]

The thumbnail of this gif is useless as it only shows some random black pixels. Sadly it is used in two articles.
Much smoother thumb
There are some reasons which favor PNG:
  1. Better thumbnails
    C.f. thumb on the right; GIF thumbnails are often pixelated due to transparency (Only a single transparency index is supported). Also PNG thumbnails support 24-bit RGB in contrast to a maximum of 256 colors in GIF (thumbnail) files.
  2. Smaller size
    GIF files tend to be larger than PNG
  3. Easier editing/"Lossless" editing
    Someone may want to edit those files. Surely the editor prefers a 24-bit palette over the 8-bit GIF-palette without uploading a new PNG derivative file before or after his edit by fiddling with (partly) broken tools such as UpWiz or DerivativeFX. Also you can not apply most filters to indexed palettes which results in a lossy process: Palette -> 24 bit -> Apply filter -> another? Palette
    However, the conversion from GIF to PNG is lossless and also the transparency, if present, does not get lost. (PNG supports 8-bit transparency in contrast to GIF's 1-bit transparency.)
--McZusatz (talk) 18:09, 27 January 2014 (UTC)[reply]
Ok, thanks for the detailed response. I was not aware that the GIFs thumbnail so terribly (why doesn't MW just generate PNG thumbs?). --Dschwen (talk) 18:39, 27 January 2014 (UTC)[reply]

How hard would it be for a bot to do the conversion, upload the png, link them in other_versions, (and bonus points: replace mainspace usage)? (rather than just tagging) --99of9 (talk) 03:49, 28 January 2014 (UTC)[reply]

I don't think it would be too hard. Mainspace usage replacement could be delegated to existing bots and upload and conversion should only take marginally longer than an edit to the file page. --Dschwen (talk) 03:56, 28 January 2014 (UTC)[reply]
Sorry for the delay... Feedback about my three test edits is welcome. --McZusatz (talk) 15:29, 31 March 2014 (UTC)[reply]
I had a brief look and they looked fine apart from the old "reason it's superseded: a png is now available" should be changed to "a color version is now available". Can you do some more test edits to give us a better overview? Thanks. --99of9 (talk) 23:32, 31 March 2014 (UTC)[reply]
Some more test edits are here: (Always in batches of three edits: Uploading, Tagging as dupe, Posting to COMdel)
(I can do more test if you want. If there are specific files you want me to tackle, just send me a list of the file names.)
However, I have still a question left: As you can see, I am posting the replacement to Commons Delinker which is only allowed to be done by administrators. Should I use my main account to run the bot or does my bot get additional administrative rights? --McZusatz (talk) 11:50, 1 April 2014 (UTC)[reply]
@McZusatz, @99of9: Thanks, the tests look fine to me. I'd prefer if the edits were made from the bot's account rather than your own; we can easily make the bot a sysop to enable it to edit the CommonsDelinker page; there's precedent for that, and I believe there shouldn't be any problems about it. odder (talk) 14:35, 9 April 2014 (UTC)[reply]

I think this looks very good right now, but I have one further suggestion. Could you wikilink the "superior" to a small page listing the advantages of PNG vs. GIF (like the ones you listed above). Otherwise I fear some uploaders might be bummed to hear that they uploaded an inferior file :-). --Dschwen (talk) 15:27, 9 April 2014 (UTC)[reply]

✓ Done (The link looks like this) . --McZusatz (talk) 18:29, 9 April 2014 (UTC)[reply]
Ok, from my side this looks fine now. I also have no reservations against giving the bot an admin flag, as long as the operator account does have one as well. If you ever loose the bit on your main account it should be removed from the bot account as well. --Dschwen (talk) 19:40, 9 April 2014 (UTC)[reply]
Agreed. --99of9 (talk) 22:07, 9 April 2014 (UTC)[reply]
Issues with greyscale and transparency

McZusatz -- unfortunately you did not understand the real reason why the GIF thumbnail is problematic, and your edit to "Commons:File types" was inaccurate. The reason the rescaled GIF doesn't look good is because it has a transparent background, and when GIFs with a transparent background are rescaled here, the transparent area eats away at the non-transparent area. If the GIF was changed to be fully opaque, then its thumbnail would look perfectly fine. Until two or three years ago, GIF thumbnailing was in fact better than PNG thumbnailing in some respects... AnonMoos (talk) 06:21, 10 April 2014 (UTC)[reply]

A 1-bit palette is still a palette (at least in my mind). My wording was not perfect and I have to thank you for making the section clearer.
Also considering your argument that "thumbnails of fully opaque GIFs would look perfectly fine" in the context of this Bot request, I am not sure if this is a supporting or opposing argument. (Maybe neither.) However, wiping the alpha channel of affected GIF files is obviously not an option because we'd loose the transparency which is needed on backgrounds other than white. Even if we did, we are still left with the limited color palette of GIF files which makes editing and applying image-filters impossible or unhandy as well as the limited color palette of the thumbnails which are GIF, too. --McZusatz (talk) 16:14, 10 April 2014 (UTC)[reply]
First off, GIF has palette-based transparency, not "1-bit alpha channel". If it had a 1-bit alpha channel, then any color could be specified as either transparent or opaque, but that's not the case -- only one color in a GIF image can specified as transparent, while all other colors are always opaque.
Secondly, there's no problem whatsoever with an opaque grayscale GIF; there's a palette of 256 shades of black/gray/white to work with, so that PNG doesn't have anything that GIF doesn't have in this particular case. In fact, for many years (from at least 2005-2011, and probably during part of 2012 also), the GIF thumbnailing algorithm on Wikimedia did a better job of resizing opaque grayscale images than the PNG thumbnailing algorithm, which was why some people preferred to upload lossless grayscale opaque raster images in GIF format (see File:1900_census_Still.gif etc.).
Third, I really don't see what real purpose transparency serves in File:(R)-3-phenyl-cyclohanone.gif; by far the simplest way to fix that file would be to upload an opaque version (saved as GIF87), which I could do in two minutes or less... AnonMoos (talk) 17:56, 10 April 2014 (UTC)[reply]
Letting the bot replace the gifs with pngs costs contributors even less (if the bot just does it). I see no compelling reason to cling to gif as a format, just because there are certain limited cases where gif is "just as good" as png, or bacause thumbnailing of certain types of gifs "used to be" better than the thumbnailing of pngs. --Dschwen (talk) 18:11, 10 April 2014 (UTC)[reply]
That might be the case if PNG resizing could be trusted to never regress, but past developments don't give great confidence on that point. Nothing was done to fix known and complained about flaws in PNG resizing for six years or more, and if I hadn't offered the comments at Commons:Village_pump/Archive/2013/07#problem_with_new_thumbnailer (incorporated as Bugzilla bug 51298), some of the old flaws might have been reintroduced. In the future, I might not be able to make such comments, or might not be listened to if I do make them, and everything might be thrown back to square one again. There doesn't seem to be any on-staff salaried Wikimedia developer who has direct responsibility and expertise in image resizing issues -- or if there is one now, his position would appear to be of rather recent date. AnonMoos (talk) 07:50, 11 April 2014 (UTC)[reply]
There is no reason to believe that GIF thumbnailing will never be changed and that it is more stable than PNG thumbnailing. (c.f. bugzilla:52043, ...). Moreover I think that it should not be a problem to teach the bot to skip Grayscale GIF images. --McZusatz (talk) 12:59, 16 April 2014 (UTC)[reply]
Sorry I didn't see your remark until now, but in fact GIF thumbnailing has been the same since 2005 (same strengths, same weaknesses), while PNG thumbnailing has gone through a series of gyrations, by no means always in a positive forward direction. It's true that significant flaws in PNG thumbnailing were simply ignored from at least 2005-2011, if you want to call that "stability"... AnonMoos (talk) 14:24, 1 May 2014 (UTC)[reply]
@McZusatz, @AnonMoos: This request appears to have stalled. While I did not participate in your discussion, I have been watching it develop. Is there anything in particular that's blocking this request from moving forward? odder (talk) 14:12, 1 May 2014 (UTC)[reply]
It would be fine to auto-convert all GIFs with transparent pixels to PNG, since such GIFs have always had problems. However, I would strongly suggest and request that opaque grayscale GIFs not be converted to PNGs, since there GIF resizing was better than PNG thumbnailing for more than six years (at least), and I don't know that I have great confidence that PNG thumbnailing of this type of image won't regress again in future (as it probably already would have regressed if I hadn't been around to raise issues at Commons:Village_pump/Archive/2013/07#problem_with_new_thumbnailer... -- AnonMoos (talk) 14:24, 1 May 2014 (UTC)[reply]
P.S. The fact that the proposed bot operator (User:McZusatz) appears to have a very limited understanding of certain issues involved with the GIF format doesn't necessarily fill me with confidence... AnonMoos (talk) 14:28, 1 May 2014 (UTC)[reply]
I already implemented grayscale GIFs to be skipped. (Btw. The image above you linked to above is not a grayscale GIF but an indexed one only containing grayscale values.) --McZusatz (talk) 15:20, 1 May 2014 (UTC)[reply]
There is no special coding of greyscaleness in the GIF image format. A greyscale GIF is exactly and only a GIF, all of whose RGB color values happen to have R=G=B. There is no other definition. Unfortunately, this kind of thing is what I meant when I referred to a "limited understanding of certain issues involved with the GIF format"... AnonMoos (talk) 16:09, 1 May 2014 (UTC)[reply]
As there is "no other definition", why does GIMP choose to name a palette with limited grayscale values different than a full one? --McZusatz (talk) 19:44, 1 May 2014 (UTC)[reply]
It seems we could continue this discussion about vocabulary forever but this bot request is not really the best place to do so. This discussion should rather help to define the bot task and make clear what should be done by the bot and what should not be done by the bot. Lastly, the bot operator is completely irrelevant (given a minimum amount of trust he/she won't misuse the flag) when it comes to approving a request. The only thing relevant is the actual task. I'd be happy to adjust the behaviour of the bot to whatever is considered useful but I will not waste further time about discussing each others understanding of internal GIF specific features irrelevant to the symptoms observed in the GIF thumbnails produced by mediawiki software. --McZusatz (talk) 19:44, 1 May 2014 (UTC)[reply]

McZusatz -- Some image editing programs, when you go into greyscale editing mode, and then chose "Save as GIF", save a file with a palette of 256 sorted monochrome shades; and when they read in a GIF file with 256 sorted monochrome shades, they automatically set the image editing mode as greyscale. However, that's merely a convenience for the program user, so that they won't have to set the image editing mode manually so often. It is not a formal definition of anything. The only functional and useful definition of a greyscale GIF is one all of whose RGB colors individually have the property R=G=B. Having a palette of 256 sorted monochrome shades is not required, since that's nothing more than an image-editing program convenience, and has no other status whatsoever.
Frankly, the more this discussion reveals gaps and deficiencies in your knowledge of the GIF format, the more my doubts as to whether you're the one to run this bot increase. I would strongly suggest and request that you read the official Compuserve GIF89a specification attentively all the way through at least once, since you seem to have a lot of loose or unexamined assumptions which are unfortunately not factual. AnonMoos (talk) 04:52, 2 May 2014 (UTC)[reply]

 Comment I read through spec-gif89a.txt yesterday. --McZusatz (talk) 07:36, 7 May 2014 (UTC)[reply]
Sorry for the delay in replying (I never actually added this page to my watchlist).
Notice how transparency can only specified for a single palette color (so that there's no general alpha-channel mechanism), and there's no mention of grayscale images (the words "gray" or "grey" do not appear in the document), and the only mention of sorted color tables refers to tables sorted by the importance of colors to a particular image (for systems with less than 256 display colors available).
I will support this bot request as long as you guarantee that the bot run will not apply to all GIF images where R=G=B for every individual color, and where there is no transparency set. Otherwise, it seems to me to have problematic features... AnonMoos (talk) 14:35, 9 May 2014 (UTC)[reply]
Yes, the most relevant part of the spec for this bot task is probably the "Transparency Flag - Indicates whether a transparency index is given in the Transparent Index field."
I have added section headings for easier reading if you don't mind. Refer to the next section to see my response --McZusatz (talk) 22:04, 9 May 2014 (UTC)[reply]
Sum up

I changed the upload summary to reflect which of the three possible problems the GIF suffered (e.g. Transparency, Transparency & non-greyscale color table, non-greyscale color table) --McZusatz (talk) 22:04, 9 May 2014 (UTC)[reply]


@Dschwen: @99of9: @Odder: @AnonMoos: Is there anything I can do to improve this Bot? Are there any concerns left or questions overlooked by me? --McZusatz (talk) 11:31, 31 May 2014 (UTC)[reply]

As long as opaque greyscale GIFs (where R=G=B for each color, and no transparency is defined) are left alone this time around (at least), I don't care too much about the others -- fire when ready, Gridley... AnonMoos (talk) 22:40, 31 May 2014 (UTC)[reply]

Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Bots/Requests/GifTagger&oldid=126685482"