Even more files: https://commons.wikimedia.org/w/index.php?title=Special:Contributions&offset=20150128&contribs=user&target=YaCBot&newOnly=1

@Paladox: This task is about decoding.

Yes, confirmed to be working now. Thank you for fixing all the TMH bugs lately, I really appreciate that.

Why would it be useful?

It can be used to make templates more intelligent.

I am uploading GIF images. Another example:

In T48741#1621361, @matmarex wrote:

Is this still reproducible on Commons?

The "rename twice to restore" technique is apparently not working all the time: https://commons.wikimedia.org/w/index.php?title=Special:Log&page=File%3A%D0%94%D0%BD%D0%B5%D1%81%D1%82%D1%80%D0%BE%D0%B2%D1%81%D0%BA%D0%B8%D0%B9+%D0%B3%D0%BE%D1%80%D1%81%D0%BE%D0%B2%D0%B5%D1%82.jpg

Not sure what the devs prefer, but I can put them back in the general tracking bug anytime, if that's preferred?

The pipe for thumbnailing is a bit different for each file type, so a separate tracking ticket may be helpful.

In T56744#1290495, @McZusatz wrote:

Right now there are two files left [...]

Archive of one test case:

Archive of the linked thumbs:

$ convert -version
Version: ImageMagick 6.8.8-10 Q16 x86_64 2015-03-10 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2014 ImageMagick Studio LLC
Features: DPC Modules OpenMP
Delegates: bzlib cairo djvu fftw fontconfig freetype gslib jng jpeg lcms ltdl lzma openexr pangocairo png ps rsvg tiff webp wmf x xml zlib

Testing https://commons.wikimedia.org/wiki/File:J%C3%BCrgen_Alberts_-_pv_portrait_02-3.png in RGB, grey and indexed gives three slightly different results but all of them are greyscale thumbs.

$ for x in 20*; do convert -quality 95 -background white $x -thumbnail 300x215! -depth 8 -auto-orient 300px-$x; done 

In T106516#1470598, @Bawolff wrote:

I just tested on most recent image magick. Can confirm that upgrading image magick would fix the issue.

Indeed, the last change to https://github.com/wikimedia/mediawiki/blame/9c8f333eb87f128933dd754f4c7e4b26fa1cf514/includes/media/Bitmap.php#L160 was Jan 2014.

In T31659#318148, @brion wrote:

Ok I did a quick check resizing these versions of the Ping_deny.png image:
[...]
So the commands we're giving are exactly the same; ImageMagick itself is applying some slightly different behavior.

Tested:
Version: ImageMagick 6.6.2-6 2011-03-16 Q16 http://www.imagemagick.org

In T6947#94022, @brion wrote:

(In reply to comment #33)

Can we at least enable gzip Transfer-Encoding for plain SVG files?

That would be very logical yes! I've filed bug 54291

I suspect the upload function back in 2006 did not normalize like it does today. Could someone with a higher sql-foo than me shoot up a query to find more cases if they exist?

@fgiunchedi Would you mind hitting the ffmpeg command once again with another video like

If not, please add a blocking task for clarity.

I did a quick test with no flash/silverlight/java (people are actually still using those?) and could delete the test evercookie created by http://samy.pl/evercookie/ by simply deleting all firefox history; So before using evercookie in addition to the standard http cookie, someone should do a test with the most commonly used browsers on wiki* sites and see if evercookie may even yield substantial advantages.

In T106216#1462552, @MZMcBride wrote:

In T106216#1462541, @McZusatz wrote:

As soon as https://phabricator.wikimedia.org/T35186 is merged you can modify any upload client to request rotation of some of the uploaded files...

Yes, such as Special:Upload in MediaWiki core. And probably Special:UploadWizard as well (from the MediaWiki extension).

In T106216#1462451, @MZMcBride wrote:

ingest images and rotate them in the same interaction.

In T106216#1462206, @Tgr wrote:

Storing a different file than what the user uploaded is a problematic idea. Confusion, permanent data loss if there is an error in the transformation, no easy way to check the upload success via the sha1 hash.

In T106216#1462067, @MZMcBride wrote:

How can we fix the image orientation during the upload process?

Even if discussion was necessary, we already had one:

About the "find out whether there is already a rotation pending" problem:

@all @MarkTraceur Is there any progress with doing the refactoring and then applying the patch?

In T42193#1429735, @Wilfredor wrote:

You can upload the file here ...

(Solve edit conflict)

Note: Let's rather split the discussion from this bug report. I quickly created https://commons.wikimedia.org/wiki/Commons:Village_pump#Allow_WebP_upload

In T27397#1408367, @MZMcBride wrote:

Yes. Is there any reason not to do this these days?

@Anomie thanks for the feedback. But if there is no place where the behavior is documented, there is also no way to find out if there is a bug in the API?

In T100211#1406930, @brion wrote:

In T100211#1406858, @McZusatz wrote:

Also, I am wondering to what extend a unit test could avoid bugs in this TMH-area to pop up.

Yeah that'd help a lot. :)

So, the commit introducing this bug has been reverted and merged but what happens to all the transcodes that were reset in the meantime and are now gone? (You can not request a fresh transcode because there is no link to do so.)

Wikimedia Commons Village Pump sounds like a good place to ask the community whether anyone needs this.

If only there wasn't T63401, T49312 and T63713.

Translations always trigger two edits at the same time. Just now one of them failed with

Saving the translation failed: [42491262] Database query error

leaving the translation in some "undefined" state.

Is this a duplicate of T49312?

In T98694#1292720, @Bawolff wrote:

• It would probably be better to wait for VP9, and transcode 4k videos to VP9 instead of VP8.

Can someone please look into this, or at least confirm the bug? Imo this is important, because someone could just delete all transcodes off of commons and no one could stop them or revert their action.

No, the upstream fix ( http://www.imagemagick.org/discourse-server/viewtopic.php?f=3&t=20642#p82834 ) implies we can do better on the test case mentioned in comment #1 ( https://commons.wikimedia.org/wiki/File:%22What_a_Brilliant_Idea!%22_Barnstar.xcf )

Right now there are two files left in https://commons.wikimedia.org/wiki/Category:Images_that_will_not_render

In T97253#1260717, @Lupo wrote:

I think every "upstream" issue should have an upstream bug report, and mention it here, too.

Just a workaround: People could use something like

I saw about 30 of those between 1:27:26 PM GMT and 7:39:21 PM GMT.

In T96556#1223356, @85jesse wrote:

But yes, we do have a more 'narrow' URL path. Which is:
https://soundcloud.com/beeldengeluid

Actually I think for this one, it is the color profile which causes the incorrect colors.

In T24097#263825, @MZMcBride wrote:

While I thought that fixUserRegistration.php had been run on all Wikimedia wikis, [[wikitech:Server admin log/Archive 7#June 5]] indicates that it may have only been run on the English Wikipedia.

In T88783#1020647, @Anomie wrote:

these are far from "void data"; in fact, they all appear to be log entries from MediaWiki-extensions-GWToolset.