On 6/18/06, Brion Vibber <brion(a)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.