Topic on Talk:Requests for comment/Standardized thumbnails sizes

Hi there,

We've been struggling with a similar issue in the Multimedia team. If we want Extension:MultimediaViewer to scale properly, we should probably bucket our requests for thumbnails to a specified list of sizes. This may be a way to test different solutions to this problem without necessarily figuring out a canonical solution in core.

Basically the idea would be to try bucketing the thumbnail requests to a set of 10-20 predetermined sizes, then either requesting the nearest one above the ideal size and scaling down on the client, or requesting the nearest one below and showing the image in a container with a frame.

If we can be of any use in testing possible solutions, we'd love suggestions as to implementation details.

Let's start by just devising some buckets and using them explicitly in MultimediaViewer, then if we find that successful we can start building it into the backend?

The traditional default selectable File: page display sizes appear to be some classic full-screen sizes:

• 320x240
• 640x480
• 800x600 (default)
• 1024x768
• 1280x1024 (slightly different aspect ratio)

Some things to consider:

• do these fit default aspect ratios well?
• do we also need to bucket display density variants?
• what about dealing with panoramic images? (very long or tall aspect ratios, work best when requesting a larger total size in the longer dimension and allowing some kind of scroll/panning) Should we set size by the long dimension, or the short dimension ('show horizontal panoramas at 600px high, however wide they are' or 'show vertical panoramas at 800px wide, however tall they are)?

I'll probably add 1920x1080 just to make sure we're supporting everyone, and use the full-size image for anything above that.

When it comes to panoramic images, I guess we'll need to determine that based on the aspect ratio of the thumbnail on the page - AFAIK it's guaranteed to preserve the original ratio, so that should be OK, but we'll determine whether the ratio is e.g. 3 or 1/3, and if so, use the height or width as the only limiting factor, then enable scrolling.

Good plan :)

Be very, very careful about using "full-size" image. Sometimes that's a 4MP or 8MP photo, but sometimes it's a 100MB TIFF file. And of course sometimes it requires rotation for display in browser, or transformation to a JPG, PNG, etc. Generally... never EVER use the original file as anything but a download link, unless the API happens to return you the original file when you ask for a rendered thumbnail...

I mean, the only time that would happen is if the screen size were bigger than 1920x1080. And that's...unlikely.

I could add one more size that's double that, I guess. Maybe two more (one double, one quadruple) just to be safe.

Not that unlikely; I have one of those monitors at home, and yes, I do use it full-screen in 1:1 resolution. :-)

You'll have people with non-retina screens in the 2560x1440 range running those big 27-30" monitors.

You'll also have people with retina screens where the screen density bumps you up from 1280x800 or 1440x900 CSS pixels to 2560x1600 or 2880x1800.

Common densities are going to be in the 1.0, 1.5, and 2.0 ranges, but others may appear (especially if you have a funny zoom, etc)