Currently the file page provides a set of different image sizes for the
user to directly access. These sizes are usually width-based. However, for
tall images they are height-based. The thumbnail urls, which are used to
generate them pass only a width.
What this means is that tall images end up with arbitrary thumbnail widths
that don't follow the set of sizes meant for the file page. The end result
from an ops perspective is that we end up with very diverse widths for
thumbnails. Not a problem in itself, but the exposure of these random-ish
widths on the file page means that we can't set a different caching policy
for non-standard widths without affecting the images linked from the file
page.
I see two solutions to this problem, if we want to introduce different
caching tiers for thumbnail sizes that come from mediawiki and thumbnail
sizes that were requested by other things.
The first one would be to always keep the size progression on the file page
width-bound, even for soft-rotated images. The first drawback of this is
that for very skinny/very wide images the file size progression between the
sizes could become steep. The second drawback is that we'd often offer less
size options, because they'd be based on the smallest dimension.
The second option would be to change the syntax of the thumbnail urls in
order to allow height constraint. This is a pretty scary change.
If we don't do anything, it simply means that we'll have to apply the same
caching policy to every size smaller than 1280. We could already save quite
a bit of storage space by evicting non-standard sizes larger than that, but
sizes lower than 1280 would have to stay the way they are now.
Thoughts?