Align default Thumbnail resolutions with our clients' requirements

[rhafer]

Describe the bug

Currently we have this for the allowed thumbnail resolutions in the thumbnails service:

{"16x16", "32x32", "64x64", "128x128", "1080x1920", "1920x1080", "2160x3840", "3840x2160", "4320x7680", "7680x4320"}

AFAIK this doesn't really align with what the clients (web mainly, didn't check others yet) actually need.

For the the grid view web would benefit from a size between 128x128 and 1080x1920. Currently it seems to request a 1000x1000 thumbnail (of type fit). If I understood @kulmann correctly, it does so because if it requested a more reasonable size the thumbnailers "ClosestMatch" check would fall down to 128x128 which is too small for the grid view.

Also I think we should get rid of the huge 4k and 8k thumbnails in the default config. Who needs that in the preview app? If somebody really needs that, it can always be configured with THUMBNAILS_RESOLUTIONS manually.

Also I am not sure if we really need 16x16 in the default config.

@kulmann Can you come up with a list of thumbnail dimension that would be useful for web (for the list view, the grid view and the preview app ideally).

[kulmann]

Argh, sorry for the late response...

@rhafer we currently have the following use cases for previews:

• files in list view, square image (aspect ratio 1:1), 36x36px (the current 32x32px is fine for that)
• files in tiles view, aspect ratio 16:9, various sizes depending on a size step [1..6] and the actual browser window size. I think having 16:9 sizes of 250x140px, 500x280px and 1000x560px would be helpful.
• right sidebar "details" panel can show a preview of roughly 400px width, also 16:9 aspect ratio. The 500x280px size for the tiles view would be ok for that.
• the preview app can request any size depending on the browser window size

Based on that I'd propose the following resolutions: {"32x32", "128x128", "250x140", "140x250", "500x280", "280x500", "1000x560", "560x1000", "1080x1920", "1920x1080", "2160x3840", "3840x2160"}

I agree that 4k and 8k are not so much relevant in the default case... but do they hurt? If they're never requested (based on the browser window size) they don't cause compute and storage utilization.

[kulmann]

With regard to pre-generating previews in post-processing I think we'd benefit from 32x32, 500x280 and 560x1000 (for portrait mode images in a 16:9 container).