I purged the first two files useing ?action=purge, and they rendered quite differently (one imho worse, one imho better, but mostly different), and in both of them even the full-size-preview was imho before purging was awefull (not as described in the bug-descripiton).

I overwrited the first tiff-file using gimp, which solved the issue, however for the first two files (did not try the others) gimp reported:

So I assume it is a file-issue, and another strange thing is https://commons.wikimedia.org/wiki/File:Sc_cmyk_pos_claim.tif was 2,7MB large, and resaving the tiff uncompressed was only 475KB, (The bitmap (*.bmp) is uncompressed 426kB, and the PNG can be lossless compressed with pngout to 9,6kB.) So the 2,7MB looks strange to me (maybe hidden data?).

Since gimp renders it correct I assume it is related to a wrong/different error-handling.

I consider the reported jpg in https://en.wikipedia.org/wiki/User:Jonteemil/sandbox3#Bad_quality_in_file_history_and_Special:Search as correct.

@JoKalliauer Thanks for looking into this. https://commons.wikimedia.org/wiki/File:Sc_cmyk_pos_claim.tif looks good now but I think you accidently changed the metadata 'image title' to the URL of this Phabricator task :).

Regarding https://commons.wikimedia.org/wiki/File:Logo_SKH_300dpi.jpg, on my computer it looks the same in the thumbnail as in the file history section. You see the gray lines behind the text. However when you click on it and get to https://upload.wikimedia.org/wikipedia/commons/8/88/Logo_SKH_300dpi.jpg the lines have disappeared. It is this lineless image that is in the thumbnail on my phone where in the file history the lines appear again. So there must be some rendering issue going on there as well.

I agree that perhaps good in the thumbnail was an exaggeration, https://commons.wikimedia.org/wiki/File:AQS_Logo_yellow_grey_.tif (and a few more) doesn't look good, but at least better compared to the version showed in the file history section. Regarding the more technical stuff you mentioned, whether the issue lies with the individual file or with the Mediawiki software, whether there was hidden data that made the file so large etc. I won't really be the best sounding board to you b/c of my limited knowledge of what goes on beyond the computer screen :).

@Jonteemil : Regardin JPEG-Preview of the *jpg: I just compared full-size-preview with 120px-preview (not the raw file), thanks that is strange and might be a different issue.

@Aklapper : Do you know why *.tiff are previewed as *.jpg not as *.png. *.tiff s are imho often scans so jpg might make sense. But imho most *.tiff (but imho not all?) are uncompressed or lossless compressed (e.g. ZIP, LZW), so maybe a converting to png would make more sence?

It looks to me like this is a CMYK problem. When you passed File:Sc cmyk pos claim.tif through Gimp, you exported it as RGB. Filesize savings aren't unexpected converting from unoptomized CMYK[A] to sRGB[A] with a colormap.

Testing locally, it appears that this is just T272364: Overly blurry JPG thumbnail for certain JPG and TIFF images due to chroma-subsampling not working in CMYK. TIFFs don't get conditional sharpening, even when thumbnailing to jpg, but they do get the same sampling factor.

With sampling-factor:

https://commons.wikimedia.org/wiki/File:Logo_SKH_300dpi.jpg was mostly fixed with a purge, but is still affected by T272364.

As far as jpg vs png, that's a PagedTiffHandler decision, see https://www.mediawiki.org/wiki/Extension:PagedTiffHandler. Thumbor is capable of outputting either (or a lossy or lossless webp), and you can choose lossy or lossless anywhere but the file page. I'm guessing the choice of lossy-by-default was just due to filesize considerations.

@AntiCompositeNumber Okay, thanks for your digging!
(I hope this doesn't reopen the task...)