[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Fwd: My problems with the thumb spec
From:       Mosfet <dan.duley () verizon ! net>
Date:       2003-04-25 15:25:15
[Download RAW message or body]

Okay, I don't know if you all on kde-devel are interested in this but since I 
got a few individual responses I figured I would post the mail I sent to the 
xdg list.

----------  Forwarded Message  ----------

Subject: My problems with the thumb spec
Date: Friday 25 April 2003 10:21 am
From: Mosfet <dan.duley@verizon.net>
To: xdg-list@freedesktop.org

Okay, I was going to implement the thumbnail spec for PixiePlus but have some
serious issues with it. Here they are:

1) The thumbnail sizes. While the spec says they are undefined, (not good
itself), it seems people are using 128x128 for normal and 256x256 for large
since that is what is used as example sizes. Of course, the spec says you
don't *have* to use those sizes. You can make them smaller or larger and it's
up to the app to scale them as required. But then you'd have a situation
where larger thumbnails created in one application would have to be scaled
down in another - making it more inefficent, or would be smaller than it
needs and not look as good as thumbnails created natively. Or perhaps the app
would just recreate a larger thumbnail, again making it more inefficent for
the apps that use smaller ones. Then perhaps the app that uses smaller ones
would recreate them again! You'd be much better off with defined sizes, and
some smaller ones.

So let's say I use 128x128 since that is what other people are using and I
want to avoid the above problems. If people are using the common size of
64x64 in PixiePlus it would waste almost twice as much space and of course
requires smoothscaling. The smoothscaling isn't too much of a problem but is
additional overhead when before I could just save the icon in the proper
size. This is something I consider when I spent a lot of time optimizing
everything else. The bigger problem is space. If you have a couple hundred or
thousand images this is not insignificant and it gains my users nothing to
have thumbnails larger than what is displayed.

I can see one advantage of using a big-a** thumbnail size, and that would be
that your assured the same thumbnail can be used everywhere, but I don't
consider the overhead acceptable if my users are using 64x64 pixel
thumbnails.

The spec really needs to define sizes, and it needs to define smaller ones
 for use in browsers and not apps like the Gimp - the only place where
 128x128 and 256x256 really make sense. My suggestion would be 64x64 and
 90x90.

A thumbnail specification that doesn't define the sizes of the thumbnails
isn't really a specification.

2) I'm really not getting saving the modification date as PNG comment text.
This is a lot more inefficent without any real benefit. The spec says this is
needed, but I don't think so. If you copy or move a file of course you need
to update the thumbnail to mark it as still valid, you need to do this if
your going off of timestamps or PNG comment text. Same goes for if you modify
metadata like comments. Saving the modification date as PNG comment text in
the thumbnail doesn't give you any benefit. It does make things a much bigger
pain in the butt and inefficent tho, since you have to actually open the PNG
file instead of using standard Unix timestamps.

PixiePlus has been using modification timestamps forever and can copy or move
images, touch files to make them the oldest or newest in a folder, modify
comments and other metadata, etc... while keeping the thumbnail valid. If I
use the spec I have to actually open them up. Screwy. This is not needed at
all.

3) I'm not convinced throwing all the thumbnails the user has on the system
 in one folder is a good decision - actually I think it will slow things
 down, not speed it up. My users regularly have 1000+ images in a folder,
 sometimes multiple folders with that many images. Currently I can calculate
 the thumbnail path once when a folder is entered then just check for
 filenames and timestamps. Using the method in the spec I have to calculate a
 md5 sum for every file. I'm not going to do this. Throwing them all in one
 folder seems aimed at optimizing directory access but the only time this is
 relevent is when first calculating the directory. Otherwise it's worse.

I'm not saying md5 sums is bad - KDE3.1 used them very effectively. I think
they should be used for determining the path for the thumbnails based on the
URI of the folder. Individual files should not be md5 encoded. So basically I
feel thumbnails can be stored in the home directory or /var/xxx and use a
directory heirarchy based on the md5 sum of the URI for the path. Individual
files should not be encoded. And what's with file:///blah ? Gnome needs to
fix that - file://blah is what everyone uses these days ;-)

Anyways, this is why I will not support the spec as it stands. If people are
interested in making a spec that:

1) Defines sizes, and sizes useful for thumbnail browsers. My suggestion is
128x128, 90x90, and 64x64. 48x48 and 256x256 can be considered, althougth
creating a 64x64 thumbnail when your viewing them 48x48 wastes a lot less
space than 128x128 ;-)
2) Uses md5 sums for URI's to create a path for thumbnails but doesn't encode
individual files, (this is very similiar to KDE3.1), and doesn't throw them
all in one folder.
3) Uses standard Unix timestamps for modification checking like everything
else in the world ;-)

then feel free to contact me and maybe we can make something happen.

-------------------------------------------------------

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]