On 6/18/06, Brion Vibber brion@pobox.com wrote:
When the primary file storage is migrated to the hash-based filestore, that will decouple physical filenames from logical filenames and make that feasible.
I do want to make sure it's done before the end of the year, but it's not a top priority (and we want to be damn sure migration will work correctly when it happens; we'll have near half a terabyte of data to migrate when the time comes!) so it won't be tomorrow.
Brion,
When you work on the hash store for primary storage you'll have to address thumbnails. When you do this, please keep in mind the ability to create thumbs with multiple parameters beyond size, I'm not suggesting that such extensions need be implemented today, I just want us to avoid a redesign should we decide to implement them in the future.
Here are three examples where additional parameters would be very useful: 1) Cropping. Right now there are cases where people will upload multiple cropped versions of an image to place parts at reasonable sizes throughout the article. This complicates tagging and copyright matters, is generally wasteful, and can not be fluidly edited. A syntax such as [[Image:foo.jpg|crop:100x100+20+80|50px]] would solve this. Cropping should be possible without loading the entire image in memory, but imagemagick doesn't currently do this as far as I can tell. 2) Sharpening. Many images lose too much [[accutance]] when downsampled with quality filtering, and appear blurry as a result. This has caused some cases of people uploading thumbed and sharpened images rather than using mediawiki syntax. Syntax would be something like [[Image:foo.jpg|thumb|sharpen_high]]. Sharpening should be possible without completely loading the image in memory, but imagemagick doesn't do this as far as I can tell. 3) SVG parameters. For translations and other applications it would be useful to do basic variable replacement in SVGs, for example [[Image:heart.svg|250px|options=title:The human heart,la:Left auricular,rv:Right ventricle]]. Perhaps positioning issues will make that non-useful without a full XSLT engine (which can be done in bound memory and cpu...) but that would be a much larger issue.
I hope you can see from these examples that it is possible that someday we will decide that having more options offsets the additional storage and missrate of having more thumbnail flavors.
It's also possible that some would like to provide a jpeg quality switch, because our current setting create visible artifacts on some images... but I think this would be better solved by increasing our jpeg quality setting globally.