Suggestion: Save resampled thumbnail artwork

[GoCubs]

I'm not sure if this has been covered before, but it seems that when browsing artwork by thumbnails (many per page), the orginal tagged artwork is sent to the browser for resizing.

Wouldn't it make sense to have SlimServer save a resized small thumbnail in the database for multiple album browsing along with the original for single album viewing? I'd think this would allow the page to load faster, especially for viewing on devices like a PSP or Nokia 770.

-Greg

[kdf]

Quoting GoCubs <GoCubs.1w50wd (AT) no-mx (DOT) forums.slimdevices.com>:

>
> I'm not sure if this has been covered before, but it seems that when
> browsing artwork by thumbnails (many per page), the orginal tagged
> artwork is sent to the browser for resizing.
>
that is true, but you could have a thumb.jpg in teh same folder if you wanted,
and that would be picked up isntead for the smaller artwork.
-kdf

[GoCubs]

that is true, but you could have a thumb.jpg in teh same folder if you wanted,
and that would be picked up isntead for the smaller artwork.
-kdf

That's a work-around, but it assumes that people have their files in separate directories by album. I personally do not (just by artist) and I'm sure I'm not alone. It also pushes thumbnail creation on the user, who may not be tech-savy enough to do this. SlimServer has a nice database, why not use it? It'd also be pretty slick if there were a user option on the exact size/resolution of the thumbnails so that they could choose one that best fits their viewing environment.

[kdf]

On 30-Sep-05, at 8:40 AM, GoCubs wrote:

>
> kdf Wrote:
>>
>> that is true, but you could have a thumb.jpg in teh same folder if you
>> wanted,
>> and that would be picked up isntead for the smaller artwork.
>> -kdf
>
> That's a work-around,

no. that's the design.

> but it assumes that people have their files in
> separate directories by album. I personally do not (just by artist)
> and I'm sure I'm not alone. It also pushes thumbnail creation on the
> user, who may not be tech-savy enough to do this. SlimServer has a
> nice database, why not use it?

memory footprint
-k

[GoCubs]

no. that's the design.

It may be the design, but it requires the user to do something that the average non-technical user would not know to do.

memory footprint

A well written database will handle memory allocation automatically and wouldn't load all of the thumbnails into memory at once. I suppose you could also have the server create the thumbnails on the fly.

Sending thumbnails would decrease network bandwidth use, client-side processing, and client-side disk cache requirements. On one of my album art pages there are 56 images, ranging from 12k to 185k. This ends up being several megabytes of image data per page. Resized thumbnails would probably be just a few k each, totaling just a couple hundred k of image data.

Without the thumb.jpg files the browse artwork pages take a while to load (even loaded locally on a fast computer). Since the average user will not have these files, I personally think something should be done to speed up this process and enhance the average user experiance.

[kdf]

Quoting GoCubs <GoCubs.1w6mrn (AT) no-mx (DOT) forums.slimdevices.com>:

>
> kdf Wrote:
> >
> > no. that's the design.
> >
> It may be the design, but it requires the user to do something that the
> average non-technical user would not know to do.

actually, there are already tools made available to grab 3 sizes of images for
given album data.

> kdf Wrote:
> >
> > memory footprint
> >
> A well written database will handle memory allocation automatically and
> wouldn't load all of the thumbnails into memory at once. I suppose you
> could also have the server create the thumbnails on the fly.

after adding an image manipulation engine to an audio playback server, sure.

> Sending thumbnails would decrease network bandwidth use, client-side
> processing, and client-side disk cache requirements.

no one is disputing that.

>
> Without the thumb.jpg files the browse artwork pages take a while to
> load (even loaded locally on a fast computer). Since the average user
> will not have these files, I personally think something should be done
> to speed up this process and enhance the average user experiance.

except for the period of time that the server is busy copying and shrinking
images on every rescan (w/ clear library selected). There is also an issue of
what size. Too small, and those who like large thumbnails get an ugly image.
Too large and you waste bandwidth again. Forcing the user to rescan any time
they want to alter the size isn't going to be met with much joy either. I
realise you are just tossing out ideas for improvement, and that's cool.If you
feel strongly about it, great. If you feel strongly enough to submit a patch,
even better. Just be aware of the hurdles facing such an effort. Please don't
be upset just because I've pointed out difficulties. One way or another,
someone ends up having to deal with them.

-k

[GoCubs]

actually, there are already tools made available to grab 3 sizes of images for given album data.

I know, I just wouldn't expect the average user to think- "Hey how can I speed up this album page?". Figure out that thumb.jpg files would do the trick. Then organize their files by album and find an application to create the image files.

after adding an image manipulation engine to an audio playback server, sure.

I wouldn't be surprised if there are some free perl libraries out there that scale images.

except for the period of time that the server is busy copying and shrinking
images on every rescan (w/ clear library selected). There is also an issue of
what size. Too small, and those who like large thumbnails get an ugly image.
Too large and you waste bandwidth again. Forcing the user to rescan any time
they want to alter the size isn't going to be met with much joy either. I
realise you are just tossing out ideas for improvement, and that's cool.If you
feel strongly about it, great. If you feel strongly enough to submit a patch,
even better. Just be aware of the hurdles facing such an effort. Please don't
be upset just because I've pointed out difficulties. One way or another,
someone ends up having to deal with them.

I know... It's just an idea on how to make a great product even better. I personally don't browse by album art that often, but my friends love the feature and the speed is noticeable. I envision with the advent of devices like the Nokia 770 and PSP, that the pre-scaled thumbnails will be even more desired.

Yes, it was just a suggestion and I understand it's not the most exciting technical enhancement. If I have time I'll look into what scaling libraries are available and what it would take to make a patch, but so far I've concentrated my coding efforts on plug-ins and not the server code. Unfortunately in this case, since I do not have much expereince with the SlimServer code, it may be easier for me to re-org my music and create the thumbs. This however, does not enhance SlimSever for the masses.

-Greg

[kdf]

Quoting GoCubs <GoCubs.1w6w0z (AT) no-mx (DOT) forums.slimdevices.com>:


> I know... It's just an idea on how to make a great product even
> better. I personally don't browse by album art that often, but my
> friends love the feature and the speed is noticeable. I envision with
> the advent of devices like the Nokia 770 and PSP, that the pre-scaled
> thumbnails will be even more desired.

I agree with you completely there. However, I expect it will still be some time
before the average user is going to have either device to use with slimserver.
A great many are still at the 'wow, cool, I can get artwork on this' stage

but, point well-taken.

-k

[GoCubs]

I agree with you completely there. However, I expect it will still be some time
before the average user is going to have either device to use with slimserver.
A great many are still at the 'wow, cool, I can get artwork on this' stage

but, point well-taken.

Very true...
Also- A quick google search found two popular free perl-friendly image resizer:

http://www.imagemagick.org/script/index.php
http://www.imagemagick.org/script/perl-magick.php
http://ungwe.org/blog/2005/06/10/16:23/
http://www.enlightenment.org/Libraries/Epeg.html

I know I'm a pain

-Greg

[kefa]

I love the browse by artwork feature with all the albums on one page (rather than having to step through page by page). That way I can see all my music in one go, much like a traditional CD rack.

I too have the problem that the browser is slowed down if you have 400+ high res cover images that are scaled in the browser. I fixed this by renaming all the originals to source.jpg, then running a script (below) to resize copies down to 100 pixels. Browser now much faster... :-)

linux script (must be possible to do something similar in M$)

find /home/kefa/music -type f -name source.jpg -print | while read path
do
echo "$path"
folder=`dirname "$path"`
cd "$folder"
djpeg source.jpg | pamscale -xsize 100 -ysize 100 | cjpeg -outfile cover.jpg
done