Right now we switch from using the big thumbnails to the full size render at 400 pixels. That's the size of the large thumbnail.
But the large thumbnail quality isn't the best so maybe we could try using 300 pixels next build.
Please test and let us know what you think. Thanks.
Thank you for answering.
I do think I know what the problem is. The 400px cutoff value you are talking about is about the rendered
width of a cover art in the view. At least that is what my tests confirm.
Edit: It is actually min(render with, render height). So the problem appears on landscape cover art as well.
However, as far as I understand the thumbnailing process, the larger side is always 400px. For series cover art that have a 2:3 aspect ratio that means the large thumbnails are of size 267 x 400.
So the view shows a cover art rendered at 400x600 using a thumbnail of size 267x400, which is why it looks blurry. If that is indeed the problem, the cutoff value should be left at 400, but compared to max(render width, render height) instead of just the render width. Of course this needs to be applied to all thumbnail levels. This would fix the problem for all aspect ratios at all size slider positions.
It might also be a good idea to the let the user decide the jpeg compression level of thumbnails. This setting would not affect old thumbnails, only new ones. Through the "Erase all thumbnails..." and "Build missing thumbnails..." options users could still update already created ones. Should also be implementable quite easily.
I personally don't care if I have 1 or 10GBs of thumbnails lying around, but other users might. Parametrizing allows for both. High quality thumbnails or low disk usage.
Even, if you only suceed in fixing the cutoff problem, that would still improve quality substantially.