The image format for thumbnails is the PNG format (http://www.w3.org/TR/REC-png), regardless in which format the original file was saved. To be more specific it must be a 8bit, non-interlaced PNG image with full alpha transparency (means 255 possible alpha values). However, every program should use the best possible quality when creating the thumbnail. The exact meaning of this is left to the specific program but it should consider applying antialiasing.

If the original file contains metadata affecting the interpretation of the image, it should be respected as much as possible. In particular, metadata specifying the orientation of the original image data should always be respected. The image data should be transformed as specified by the metadata before generating the thumbnail. JPEG files commonly have Exif orientation tags. TIFF files may also have Exif orientation tags, although this is less common. It is less critical, but still desirable, to respect other image metadata, such as white balance information.

Beside the storage of the raw graphic data its often useful to provide further information about a file in its thumbnail. Especially file size, image dimension or image type are often used in graphic programs. If the thumbnail provides such information it avoids any need to access the original file and thus makes the loading faster.

The PNG format provides a mechanism to store arbitrary text strings together with the image. It uses a simple key/value scheme, where some keys are already predefined like Title, Author and so on (see section 4.2.7 (http://www.w3.org/TR/REC-png#C.tEXt) of the PNG standard). This mechanism is used to store additional thumbnail attributes.

Beside the png format there is another internet standard which is important in this context: the URI mechanism (https://www.ietf.org/rfc/rfc2396.txt). It is used to specify the location of the original file. For the global thumbnail repository, canonical absolute URIs (including the scheme) are used to determine the original uniquely. In shared thumbnail repositories, URIs are relative to the repository used.

The following keys and their appropriate values are used with this standard. All the keys are defined in the "Thumb::" namespace or if already defined by the PNG standard without any namespace.

If it's not possible to obtain the modification time of the original then you shouldn't store a global thumbnail for it at all, but may use a shared thumbnail if it does not have a Thumb::MTime attribute. The mtime is needed to check if the thumbnail is valid yet (see Detect modifications). Otherwise we can't guarantee the content corresponds to the original and must regenerate a thumb every time anyway.

There are surely some situations where further information are desired. Eg. the Gimp could save the number of layers an image has or something like this. So if an application wants to save more information it is free to do so. It should use a key in its own namespace (to avoid clashes) prefixed by X- to indicate that this is an extension. Eg. Gimp could save the layer info in the key X-GIMP::Layers.

However, regarding to the filetype there are some keys which are generally useful. If a program can obtain information for the following keys it should provide them.

With this approach a program doesn't have the guarantee that certain keys are stored in a thumbnail, because it may have been created by another application. If possible, a program should cope with the lack of information in such a case instead of recreating the thumbnail and the missing information.

As already mentionend in the Thumbnail Directory section there exists four suggested sizes you can use for your thumbnails: 128x128, 256x256, 512x512, 1024x1024 pixel. The idea is that if a program uses another size for it's previews it loads one of the two versions and scales them down to the desired size. Similar, when creating a thumbnail it scales the file down to 128x128 first (or 256x256, 512x512, or 1024x1024), saves it to disk and then reduce the size further. This mechanism enables all programs to obtain their desired previews in an easy and fast way.

However, these are suggestions. Implementations should cope also with images that are smaller than the suggested size for the normal, large and extra large subdirectories. Depending on the difference between the actual and the desired size, they can either use the smaller one found in the cache and scale it down or recreate a thumbnail with the proposed size for this directory.

If a program needs a thumbnail for an image file which is smaller than 128x128 pixel it doesn't need to save it at all.

Note

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!