From kde-devel Fri Apr 25 15:25:15 2003 From: Mosfet Date: Fri, 25 Apr 2003 15:25:15 +0000 To: kde-devel Subject: Fwd: My problems with the thumb spec X-MARC-Message: https://marc.info/?l=kde-devel&m=105128553211397 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 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 <<