My problems with the thumb spec
kai.wetzel1 at freenet.de
Sun May 18 03:45:32 EEST 2003
On Tuesday 29 April 2003 16:14, Jens Finke wrote:
> On Mon, 28 Apr 2003, Mosfet wrote:
> > This is a pretty confusing email.
> I have the feeling you just don't _want_ to understand my points, the
> points of the spec or the points in any other mail in this thread.
> I will stop reading your mails on this topic, because I have better things
> to do. Implement what you want, actually I don't care.
It would be cool to have ONE standard instead of two, though :(
...sorry for joining the discussion so late. I've re-read some of the
earlier threads on the TMS in my mailbox and I'll comment on some
of those suggestions but I'll focus on the latest debate.
#1 Configuration options related to thumbnails should _not_ be
stored inside the ~/.thumbnails/ directory: it is a cache
only, "rm ~/.thumbnails/* -Rf" must not delete valuable non-redundant
I don't recall how freedesktop configuration information are
stored in general, but probably morelike this:
XDG_THUMBNAIL_SIZES=normal,large (environment variable)
#2 Does TMS 0.6.1 define sizes or does it provide "examples" only ?
I think it defines exact sizes, "more or less":
"Programs which need smaller resolutions SHOULD read and write
the 128x128 thumbnails and downscale them afterwards to the
desired dimension." (emphasis added by me)
But it could indeed be more clear - on the next page it becomes
pretty fuzzy : is it reasonable to save smaller thumbnails ?
I read it as follows:
Applications SHOULD store thumbnails that fit into sizes "normal"
and "large" exactly, maintaining aspect ratio.
Application MUST NOT rely on thumbnails to have the recommended
size since it's only a SHOULD, not a MUST.
While I'd even prefer a MUST here, I think the practical
consequences are nottoo bad:
- All existing implementations actually store 128x128 (right ?)
- All reasonably applications would do the same in the future, unless
I read the stadard wrong.
- If some application does indeed store smaller-then-suggested
thumbnails it can be detected easily and will only cause (a minor)
performance hit compared to the fact that the thumbnails have to
be regenerated if the application needs them larger, anyway.
- the whole situation becomes even more relaxed IF other sizes (like
"small" are going to be added to the standard.
No matter what the decision will be:
1. try to find a even clearer wording then now
2. the sections mentioning thumbnails sizes should not be
spread across different pages.
#3 Should the standard be extended to cover "local" thumbnails, like
in the .xvpics case ?
I was basically agreed upon that rules for _generating_ "local"
thumbnails would have to be horribly complicated, likely to
leave some security issues open and should thus not be included
in the TMS. (Unless someone has a really bright plan how to do it).
It seems to have been consensus, too, that specifying rules for
where and how local thumbnails should be _stored_ is very useful,
e.g. for public ftp image archives, image collections on CD and
things like /usr/share/backgrounds.
If the standard was extended in this way, it would make a lot
of sense to use a similar scheme as in the ~./thumbnails/
case for consistency where it makes sense, e.g. regarding naming
I suggest to call these relative thumbnail directories ".thumbs"
Or any other name as long as it is NOT ".thumbnails".
#4 Should other thumbnail sizes, like 64x64 and/or 96x96 be added ?
If this was done, a configuration key should be defined
which lets an advanced user (or the site's admin) specify what
sizes application should actually generate inside ~/.thumbnails/
(and thus what sizes not to generate), like:
XDG_THUMBNAILS_SIZES="small,normal,large", or "normal,large".
I think that sizes in addition to normal (128x128) and large (256x256),
especially at least small 64x64 _should_ be added to the TMS:
- If an application generated 128x128 thumbnails for a directory after
which the user switches size to 64x64 and visits said directory
regularly the 128x128 thumbnails are likely to stay there "forever"
_even_though_ 64x64 is all that's wanted, wasting (some) time each time
the directory is visited (and wasting some space, too). [a scenario]
- Because with multiple directories a seperate access time is available
for small and normal sizes, a thumbnails managing application
can purge the thumbnails directory in a smarter way, resulting
in a higher "cache hit rate"
- Because of this, adding multiple sizes only increases disk
usage if alternating sizes are requested regularly, e.g. because
the user like Nautilus as well as PixiePlus.
- A thumbnail management app _could_ clean up by removing
one of the thumbnails sizes if space is really tight.
- If an application uses 64x64 thumbnails (or 96x96) loading the
128x128 ones wastes time loading and smooth-scaling the images,
each time again.
- If only 64x64 thumbnails are needed, significantly more (more then
twice as many) PNG thumbnails can be cached in memory then otherwise
(by mmap or by the application directly depending on it's
- Applications that prefer to save/load 128x128 always are not
effected by this addition at all, and a user may set
XDG_THUMBNAIL_SIZES="normal" if she perfers.
- The TMS defines those sizes closer to those that are actually
used by applications.
- speed for thumbnail loading and smoothscaling alone may not be an
issue but things could add up to the difference between "instantly"
and "with a small lag"!
- having more, closer-matching sizes is good for "local"
.thumbs directories and _allowing_ them for both cases is
more consistent =)
But of course there are some good reasons to stick to the current
solution as well:
- instant "zoom-in" previews on mouse-over
- it's actually a little easier to implement
- doesn't need a smart thumbnail manager to save space.
- less stat() calls required if you wanted 64x64: No double-checks
in normal and, say, "small".
- Applications wanting 90x90, not 96x96, will use 128x128 for
reference to get better smoothscaling results, anyway. [example]
An implementation note regarding a scenario given earlier (I think
in the december thread):
A user visits a directory in 64x64 mode, there is a 20MG image (e.g.
a high-res scan) and scales it down to 64x64. The next application
visits this dir in 128x128 and does it again, wasting a lot of time!
An application scaling it down to 64x64 would likely save a 128x128
version as well (maybe even a 256x256 version, too) IF "normal" is
in the user's wanted sizes in this extreme case. It will get just
garbage-collected if nobady requests it:
- smart thumbnail manager removes atime==mtime thumbnails before
others (negative bonus for only accessed once).
- said manager removes thumbnails with a high original/thumbnail
size ratio later then others (bonus for saving time to regenerate).
#5 file:/ vs. file:///
Resolved, file:/// it is :^) But XDND problems regarding host
in file-scheme URIs should be adressed ...
#6 UNIX mtime vs. MTime attribute in PNG thumbnail file
This decision should be explained more clearly in the standard
or else it will come up again and again. The reason given
is that basically a younger mtime of an invalid thumbnail could
result if the image is replaced with an older one,I think. (Hmm)
Saving the MTime in a PNG chunk and checking for _equality_
makes the whole check much more _reliable_:
- above case as an example
- mtime would work reasonable for file: scheme, but:
- clock skew may occur for some reason
- other scheme's are more likely not to be in sync
with the local time.
- The mtime returned by the scheme is stored (e.g. ftp:) not
the local file systems mtime.
- sub-case: time zone handling may be screwed up
mosfet: please consider this, even though it adds a performance hit:
- most images will have the right mtime, especially for typical
"large number of files in one directory" cases.
- if the mtime check is sucessful, no time is wasted.
- if it fails, re-generating thethumb-nail is what wastes time.
It should be added to the TMS, though most encoders are likely
to do it already:
- The MTime attribute (and the other meta-data tEXt chunks SHOULD
appear as early as possible in the PNG file, most definitely
before the image data chunk(s).
#6 One large folder with MD5 for each file vs. MD5 directories &
individual files without MD5
Unfortunately, few _facts_ have been presented about this issue.
The case about one large directory has been backed off with readings
for NFS but I don't understand why it's actually faster (must be
some weird NFS implemetation detail). A few points:
- Having one directory per URI-directory allows quick-checking
if there are ANY thumbnails for a given directory.
- Having one dir per URI-dir works for people with few thumbnails
and is likely to scale better. (But the soft limits about files
per directory are going to fade, I admit)
- watching a dir for changes needs less re-reading in the
case of one dir per URI-dir.
- (this) also allows easier thumbnail-reuse in case of a directory
relink. (relink "now" and conservingly update the PNG thumbnails
I'd prefer to have it with directories (no surprise if you noticed
I didn't give many arguments for the current scheme).
Considering there are so little facts about this particular
point and only time will tell which issues are going to
becomenon-issues by improvements in underlying technologies
I think it is even better to specify BOTH schemes then to
have TWO standards to chose from. Both schemes may make
sense in different real-world scenarios.
"All sizes define just a rectangle area where the thumbnail must
fit in. Don't scale every image to a rectangular thumbnail but
preserve the ratio instead!"
To make the point about ratio even more clear I suggest to
replace "rectangle", "rectangular" by "square".
temporary file naming should be specified in a way that makes
it easy to check for left-overs from dying apps. (not essential
but it should be more explicite in the TMS.)
#8 Proposal for thumbnail sizes:
The new TMS, and ultimately version 1.0 should _define_ and _allow_
the following directorys and sizes for use in ~/.thumbnails and
relative thumbnails directories (.thumbs) as well:
name: alternative: size bounds:
xs small 64x64
m normal 128x128
xl large 256x256
If no configuration key is set, default "sizes to be used" should
be defined to "small,normal,large" (or the same: "xs,m,xl") or
mosfet's list: "xs,s,m".
The above list joins the old list with mosfet's list and
adds the definition of "l" for symmetry (remember: only used if
This scheme is extensible (in the future), (like most things
starting with an X nowadays): from "xxxxxxxxxxxxxs" (2x2) to
as big as you want x...xl ! (Disclaimer: only the very last
paragraph is not quite serious!)
I can help with concrete changes in the SGML if it helps to
have a common standard again!
More information about the xdg