Hello!
I've gathered a few files at https://en.wikipedia.org/wiki/User:Jonteemil/sandbox3#WebP that are transparent in the thumbnail at the top but in the file history section they are opaque for some reason. I guess this is some kind of bug?
Edit: Seems to be what T198370 was to PNG files.
Reported upstream: https://github.com/ImageMagick/ImageMagick/issues/3772
I'll use https://commons.wikimedia.org/wiki/File:Bookbinder%27s_Logo.webp as a sample image.
And for https://en.wikipedia.org/wiki/File:Jewelpet_cover.webp
It's not limited to smaller files though, I also tried with https://commons.wikimedia.org/wiki/File:Logo-breakflip-transparent.webp
I don't know about you, but I can't find a correlation between those resolutions. Testing locally, I found that this is related to our use of -extent when resizing. On ImageMagick 6.9.7-4 it appears to only affect certain resolutions, but on ImageMagick 7.0.11-14 it affects every resolution as far as I can see.
Reported upstream https://github.com/ImageMagick/ImageMagick/issues/3772
@AntiCompositeNumber Thanks for looking further into this and reporting upstream. I also found https://sv.wiktionary.org/wiki/Fil:Wiki.png which possesses the same transparency error, but this file is a PNG, not WebP. https://commons.wikimedia.org/wiki/File:Logo-breakflip-transparent.webp seems to possess the inverse of the error - transparent in the file history but thumbnail is opaque. Intresting to say the least.
@AntiCompositeNumber You seem to have gotten a response over at GitHub. Do you know if it fixes the problem?
EXTENT? Not AGAIN! T282385 rears its ugly head again. I provided the solution and it was professionally ignored.
Now that "extent" is mentioned, I'll guess this happens when the extent actually triggers - which depends on the exact size. A comment by "snibgo" on the ticket also suggests this as they recommend putting "-background none" before -extent. I recommend, AGAIN, to bloody get rid of -extent because it's not needed. -resize 220x (or whatever desired size) is all you need.
Anyone is welcome to contribute a software patch. The (custom Wikimedia changes) repo seems to be operations/software/thumbor-plugins; the file wikimedia_thumbor/engine/imagemagick/imagemagick.py. See also https://wikitech.wikimedia.org/wiki/Thumbor#Updating_the_custom_Thumbor_plugins . (For completeness, https://gerrit.wikimedia.org/r/plugins/gitiles/operations/debs/python-thumbor-wikimedia/ would be the upstream Debian package.)
I'm not being paid. I spot a problem, I generously spend time to report it, generously spend time to get to the bottom of it, present the solution on a silver platter and you, a paid developer, are asking me to do more? Somebody pinch me..
operators += [
'-resize',
'%s^' % target_size,
'-gravity',
'center',
'-extent',
target_size
]I'm guessing it should be this, but I'm unfamiliar with this code and, in fact, not actually experienced with Python nor getting paid to take a course:
operators += [
'-resize',
int(width) % 'x',
]In the event of thumbnails with a specified width and height (like, you purposely need a 60x60 image that's padded/squeezed/cropped to be exactly 60x60) you would need something different, but I don't know if that even ever happens. Search thumbnails appear to use CSS cropping.
@AlexisJazz: I merely provided pointers that anyone interested in getting this issue closer to getting fixed could pick up if interested, as this ticket and our code bases are public. Please avoid assumptions and getting personal for no obvious reasons (for the records, I am not a "paid developer") and please use civility when we interact. Thanks for sticking to technical aspects in the issue tracker.
That surprises (and confuses) me. As there's no relation to the issue at hand I took this to https://en.wikipedia.org/wiki/User_talk:AKlapper_(WMF)#Not_paid?.
Edit: for the sake of completeness, Aklapper is paid but claims not to be a developer. This answers questions and raises many new ones all at the same time.