A Standard for Thumbnailers

[Stanislav Brabec]

Benedikt Meurer wrote:
> Stanislav Brabec wrote:
> > - Image files in public directories are thumbnailed many times:
> >   once for each accessing user.
> 
> Sharing thumbnails might be a security problem.

Not bigger problem than sharing any other images - any image loader must
be written as a secure code. Thumbnail loader must be written as a
secure code, too. Additional security problems I can imagine:
- Anybody who has permission to change image can also upload false
  thumbnail.
- It local thumbnail directory does not exist, it's easy to DoS it by
  using bad permissions for mkdir.

Note that creating of false thumbnails is already possible in Nautilus
by playing with time stamps.

> > - Thumbnails on removable media are thumbnailed many times: once for
> >   each machine, where medium is accessed
> 
> IIRC the standard already covers this, tho it's not implemented in Xfce
> and GNOME.

Yes, shared thumbnails are part of the spec. But if they are not present
on the medium, it has another problem:

Depending on OS, it may generate thumbnails again and again for each
drive to which medium is inserted and vice versa it can overwrite cached
thumbnails from one medium by thumbnails for another medium:
Imagine following schema:
One medium has:
/mnt/cdrom0/pict0001.jpg
In the different drive it's thumbnailed as a different file:
/mnt/cdrom1/pict0001.jpg
Another medium has pict0001.jpg, too:
/mnt/cdrom0/pict0001.jpg
After inserting to the drive, it will invalidate thumbnails of the
previous medium.

>> - Thumbnail files are often larger than images itself, especially for
>>   jpeg images below 20kB in size.
>
>The software can detect this and load the JPEG directly.

Yes. This information can be cached to not try to thumbnail it again.
The same is valid for images with embedded thumbnails.

> > - There is a very small chance to detect deleted images and delete
> >   corresponding thumbnail.
> 
> The file manager should clean up the thumbnails when deleting files.

Not only file manager is allowed to delete files. Using rm or viewing
temporary images ends with orphan thumbnail. Cleaning them requires to
check the whole cache (or file system) and can potentially delete all
thumbnails of not inserted removable media. Well, in this case inode
concept does not work well, too. Only local thumbnails or xattr
thumbnails can perform better.

> > Use unique inode_number/volume_id instead of file_path.
> 
> This will not work with certain FUSE file systems, that generate unique
> inodes on-demand, because it's likely that the inodes will be different
> each time the file system is mounted.

But there is still a chance to detect it and fall back to file names on
such file systems. For example ISO 9660 does not allow to detect hard
links and some file systems may return different inode numbers for
different OSes.

> > Haw widely used desktop-neutral thumbnailing library understanding many
> > embedded thumbnails and providing thumbnailing for images without
> > embedded thumbnail.
> 
> I think external thumbnailer as used by Thunar/Nautilus are better,
> because it's more flexible and avoids loading various libraries required
> to generate thumbnails for different formats into the processes.

External binary thumbnailer has to initialize and load needed libraries
again and again for each image. If you will have library, you can manage
this better by using shared modules. For example you can load them on
demand and unload after finishing of thumbnailing of the directory.

For typical small and simple thumbnailer it saves only few milliseconds
per image, for thumbnailers preloading larger libraries it may be more.

> Using .desktop files to register thumbnailers instead of GConf should be
> fine for desktop-neutral usage.

I agree. Additionally GConf has no way to solve more-thumbnailes-per-
MIME-type problem (later wins), desktop files can solve it (by mechanism
of choosing defaults).

> > Allow jpeg thumbnails.
> 
> Aside from maybe a few bytes saved per thumbnail, why would you want to
> do this?
Few gigabytes saved per whole file system.

Imagine data on my hard disk. I have about 4000 images in the photo
library. Each image has 10 hard links depending on sorting criteria (by
topic, by place, by date, by topic & place, by topic & date,...). The
archive directory is accessible by two paths (direct, using symlink from
Desktop), each image is viewed by at least 2 users.
It may result with 10 x 2 x 2 x 20kB = 800kB of thumbnails per single
image!

> > Thumbnails can use file system extended attributes.
> 
> Not every file system supports that. What would be stored in the
> extended attributes anyway?

If file system has extended attributes, maybe you can use them to store
thumbnail. I am not sure about xattr limitations, but Apple's HFS uses
something similar called resources to store thumbnails.
If file system does not support it, the fall back to other methods.

-- 
Best Regards / S pozdravem,

Stanislav Brabec
software developer
---------------------------------------------------------------------
SUSE LINUX, s. r. o.                          e-mail: sbrabec at suse.cz
Lihovarská 1060/12                            tel: +420 284 028 966
190 00 Praha 9                                fax: +420 284 028 951
Czech Republic                                http://www.suse.cz/