My problems with the thumb spec

[Kai Wetzel]

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.

Hi,
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
   information.

   I don't recall how freedesktop configuration information are
   stored in general, but probably morelike this:
   /etc/freedesktop/thumbnails.conf (defaults)
   ~/.freedesktop/thumbnails.conf   (user-overrides)
   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
   the subdirectories.

   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
     caching scheme.
   - 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
     "when idle").
   - 
   
   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.

#7 Details:

  "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
   s                   96x96
   m    normal         128x128
   l                   192x192
   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
   actually requested).
   
   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!

Best regards,
kai