[Clipart] thumbnails size

[Jonadab the Unsightly One]

Bryce Harrington <bryce at bryceharrington.com> writes:

> Erf, I don't think that'd produce very good results...  E.g. if the
> giraffe thumbnail cut off its head and feet, then I think people would
> assume the svg was busted and wouldn't download it.

Agreed; cropping (unless we want to have a human do it intelligently)
is probably not the way to go.

> A better algorithm would calculate the expected height and width prior
> to rendering, then 
>    if height > 80 and height x width > 80 x 80, use -h 80
>    else use -w 80
> Or something like that (maybe we could fudge to allow height up to 100
> before limiting it.

That's fairly similar to what I was going to suggest -- scale so that
the larger dimension is some fixed constant number of pixels,
maintaining the aspect ratio.

>> Can inkscape do this when converting instead?
>
> No, inkscape's export function is pretty basic.

Another option:  Export it with a width of 80 and with a height of 80,
and take whichever image is smaller.

>> By the way, the thumbnails take up about 13MB of space. Can they be
>> compressed or made lower quality too?

[Does some checking...]

It is theoretically possible, yes, even without loss of quality.  The
aforementioned giraffe's thumbnail (the one shown on the browse
interface) is 3118 bytes.  I opened it in Gimp and did a save-as,
saved it as a PNG, setting the compression to 9 (the max value), and
the resulting image is 2802 bytes.  This is without any loss of image
quality.  It's not a big savings, but it demonstrates that the
existing thumbnails are not maximally compressed.

Then I changed the image mode from RGB to indexed (with a 256-color
palette, which I let Gimp generate automatically) and saved *that* as
a PNG with max compression, and the resulting image is 512 bytes.
Figuring that the giraffe, being a silhouette, is probably atypical
for colorspace reduction, I also did another image like this, the
thumbnail of Aki's blue whale, bluewhale-md.png.  It went from 3153
bytes to 2056 bytes, less of a reduction than the giraffe but clearly
more than just the lossless compression.

Whether we want to shoehorn the thumbnails into a reduced colorspace
is an open question, but it's an option to consider.  The difference
is quite noticeable (visually, I mean; in some places the blue whale
gets speckles reminiscent of dithering -- the colorspace reduction was
not noticeable on the giraffe, since it had so few colors in the first
place), but the resulting thumbnail still looks better than a JPEG and
in any case definitely conveys a good general idea of what the image
looks like, which is the basic idea of a thumbnail.  Then again, the
unreduced true color version (of the whale, not the giraffe) does
definitely look better.  So it's a tradeoff.

There's still the small matter, however, of finding a practical way to
perform the compression (and/or indexing) on all of them, either as
they're generated or in a periodically-performed batch operation.  I
know next to nothing about automating image operations, so at this
point (having established roughly how much could be gained by further
compression) I'll shut up and let someone else talk.

-- 
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}}
split//,"ten.thgirb\@badanoj$/ --";$\=$ ;-> ();print$/