to get the infobox into some kind of row in the column

Well I feared that something like that is used so it's not so simple to change this in the code which is why I first went to the talk page of the infobox to propose alternatives. However, none of these seem to get implemented or be easier to implement plus changing this in the code would be the proper (instead of workaround) way.

I do not know the policies of the Commons community to hand out permissions to accounts. Best to ask the Commons community on Commons.

Can account Uwelir get that mass-upload permission?

I fear this isn’t possible (but I’d be happy to be proven wrong!): the subcategories use CSS columns, and in my experience elements with columns never wrap floated elements that are outside of the columns element. (I couldn’t find any standard or anything else supporting this, though, it’s just my experience.{{citation needed}})

Hi, maxUploads was increased to 500 for users who have mass-upload permissions in T135085. I don't see reasons provided in this ticket why to change this.
For future reference, please provide clear steps to reproduce something somewhere, and use the templates - thanks a lot!

Recently I've made the tool able to not reject images that just had size improvement with https://commons.wikimedia.org/w/index.php?title=MediaWiki:Gadget-ImageAnnotator.js&diff=prev&oldid=887093691 and noow I see this issue, I'm not sure how that's related to my changes or how I can share the logic.

Let's say someone is autoconfirmed at English Wikipedia, but not on Commons. Would you want them to be allowed to upload or not? And vice versa?

Shouldn't be just autoconfirmed (or perhaps a new permission specific to upload dialog) on Commons? That would be more straightforward and make more sense to me.

Let's say someone is autoconfirmed at English Wikipedia, but not on Commons. Would you want them to be allowed to upload or not? And vice versa?

Also purposed as a Community Wishlist https://meta.wikimedia.org/wiki/Community_Wishlist/Wishes/Hosting_of_free_fonts_in_Commons

Im going to close this bug. Its a little hard to know, as it seems like different people are experiencing issues on different files that other people aren't, so its possible there are additional unknown issues. If anyone else experiences anything, please reopen the task.

Since this discussion , I do not have anymore issues. To me there are no more issues.

I am now down a rabbit hole updating someone's BRISQUE, PIQE and NIQE code. It mostly now seems to work, but I don't have an NVidia card to test the BRISQUE code on.

Sorry, bad example it was probably because the category was new and it takes a while for it to work with a new category. It does exclude the file at my side as well now. It was just an example, it also didn't work in many other cases. However, there the problem is the "A warning has occurred while searching: Deep category search timed out". I think it's best if I edit the issue to make it about this particular cause of it often not working (currently it's only in a comment), if I notice it failing on a non-new category with another error I'll add it, I think sometimes it didn't work but also didn't show this error but only whitespace. I shouldn't have only put this error in a comment but added it to the issue right away.

@Nikki Thanks for the very helpful context, based on that I've created a RfC to see what Commons community also think about it. https://commons.wikimedia.org/wiki/Commons:Requests_for_comment/Hosting_of_free_fonts_in_Commons

I compiled libavif from https://github.com/AOMediaCodec/libavif

In T367644#9895757, @Aklapper wrote:

Allowing local wiki to use free web fonts where they need, maybe site wide (which may is covered by ULS

AFAIU this exists, see https://www.mediawiki.org/wiki/Universal_Language_Selector/WebFonts

I can't reproduce with the given example in the description, File:Nut_Grab.jpg (page id 29851242) is properly excluded when searching pageid:29851242 -deepcategory:"Animals with nuts". So I suspect that the problem might have been caused by the issues we had with dumps recently. @Prototyperspective could you confirm or possibly provide another example file that does not comply with the search query.
For reference (when writing this comment) the list of categories identified by deepcategory:"Animals with nuts" is:

• Animals with nuts
• Animals eating nuts
• Animals eating peanuts
• Curculio (larval damage)
• Animals eating hazelnuts
• Animals eating walnuts
• Birds eating nuts
• Sciurus vulgaris eating walnuts
• Sciurus vulgaris eating hazelnuts
• Sciuridae eating peanuts
• Birds eating peanuts
• Sciurus carolinensis eating walnuts
• Curculio nucum (larva)
• Tamias striatus eating peanuts
• Sciurus vulgaris eating peanuts
• Sciurus carolinensis eating peanuts
• Tamias striatus fed by hand (EIC)

Can people retest to see if recent fix fixed the issue?

I guess we should verify if other image scaling methods round the same way

In T257652#9993075, @Trougnouf wrote:

WebP is 8-bit only, right? (The reason I need a modern codec like AVIF/HEIC/JPEG XL is higher color bit depth.)

In T257652#9993064, @Jonathanischoice wrote:

Also, it might be fun to compare HDR images with higher bits (10 or 12 per element, e.g. RAW) which is where the newer WebP and AVIF codecs do a better job

That is very cool :) My only nit-pick might be that starting with a JPEG source image might bias or throw off the lossy compression, since it will already have minor block and ring artifacts (especially if you're measuring SSIM or PSNR). Might be better to find an uncompressed TIFF or RAW image. Also, it might be fun to compare HDR images with higher bits (10 or 12 per element, e.g. RAW) which is where the newer WebP and AVIF codecs do a better job; and I'd like to dig into things like PIQE or BRISQUE measurements if I get time (unlikely!) since SSIM is a bit blunt.

Note: it also only shows "Connecting..." for the other buttons in that dropdown, I would find the two buttons "In this category and in..." very useful but in practice on has to go to petscan which most readers don't know about. The alternative of using the deepcategory search operator for that usually also doesn't work. Maybe this problem is caused by that, the issue is T369808

The result is 457.7614537px (800px*(2960px/5173px)), that seems to rounded and results in 458.

Possibly related, but i think different - this is about MW being consistent about the thumbnail's dimensions, whatever they are

Potential dup or related to T282385 ?

In my testing, seems to be an issue on images where the height gets rounded down by 1 pixel (or at least one of the cases seemed to be that

In T257652#9989027, @Jonathanischoice wrote:

Apologies - for what it's worth, using an arbitrarily chosen but reasonable quality of 80% for both conversions: