1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
|
Wide Thumbnail Managing Standard
================================
Přemysl Eric Janouch <p@janouch.name>
v0.1, 2021-12-29: Preliminary draft
:description: Wide-format thumbnail managment specification
Introduction
------------
This document is a follow-up to the
https://specifications.freedesktop.org/thumbnail-spec/thumbnail-spec-latest.html[Thumbnail Managing Standard],
in particular version 0.9.0. It extends the specification to cover wide-format
file thumbnails, providing a well-defined mechanism for sharing them amongst
different programs. It also addresses new needs that have arisen with
high-density, wide-gamut monitors.
Please contact the author of this document if you intend to use it.
Rationale
~~~~~~~~~
Photos tend to be in a 4:3 format. Yet, nearly all file browsers at the time
of this document's conception (end of year 2021) show previews in a rectangular
grid. This wastes a lot of display real estate with padding, and looks
subjectively awkward. The Web at large has long been moving off of this
concept, instead preferring freely flowing items of fixed height--notably on
such sites as DeviantArt and Google/Duck image search. The general Unix desktop
keeps lagging behind.
Scaling sub-nominal thumbnail sizes up, or larger sizes down is not a practical
solution: the former gives blurry images, while the latter may waste
a significant amount of disk space. Both require reprocessing. Seeing as these
issues have only become worse with the higher resolutions added to the 0.9.0
revision of the preceding standard, a new one is necessary.
Storage
-------
The base directory for thumbnails is the same as in the original specification.
The list of subdirectories is similar, but a `wide-` prefix is added,
turning `large` into `wide-large`, and so on. The `fail` directory does not
constitute an exception to this rule, and is also duplicated, if necessary.
The dimensions differ like so: the original _height_ for the respective sizes is
kept, but a factor of 2 is applied to the _width_:
- _$XDG_CACHE_HOME/thumbnails/wide-normal_ contains previews proportionally
scaled down to 256x128 pixels,
- _$XDG_CACHE_HOME/thumbnails/wide-large_ contains 512x256 pixel previews,
- _$XDG_CACHE_HOME/thumbnails/wide-x-large_ contains 1024x512 pixel previews,
- _$XDG_CACHE_HOME/thumbnails/wide-xx-large_ contains 2048x1024 pixel previews.
It is unspecified whether non-square pixels are scaled down accordingly, but it
is recommended to do so.
File format
~~~~~~~~~~~
To account for very large thumbnail sizes, this specification has chosen the
WebP codec, in its _extended file format_. Thumbnail files still derive their
name from the MD5 hash of input URIs, as in the original standard, because
this widespread algorithm shows surprisingly good results for this use case.
The filename, however, deviates in that it receives the appropriate _.webp_ file
extension.
Both lossy and lossless encodings may be used. Animations are assumed to be
representative samples, and their timing needn't be respected. No metadata
chunks are allowed other than _THUM_, which is described below. Any Exif
orientation changes need to be "baked-in" to the image.
Metadata
~~~~~~~~
Because WebP doesn't directly provide any means of storing simple key-value
pairs, thumbnail attributes are stored in a custom chunk named "THUM".
It consists of a stream of NUL-terminated pairs, using the UTF-8 encoding.
The last NUL byte may not be omitted. The behavior of repeated keys is
undefined.
All keys from the original specification are adopted, including the extension
mechanism, plus these additions:
.Additional fields
[cols="1,2"]
|===
| Key | Description
| `Thumb::ColorSpace` | The thumbnail's color space, if it is known.
|===
The color space field may only be included if the producing program has applied
color management to the input image, e.g., using any embedded ICC profiles,
so that the color space is now known and normalized. No rendering intent is
hereby suggested. It is permitted to assume sRGB for input images with
unspecified color spaces. The full list of allowed values is:
.Color spaces
[cols="1,2"]
|===
| Value | Description
| `sRGB` | IEC 61966-2-1
| `Display P3` | sRGB with DCI-P3 primaries, as used by Apple.
|===
Interactions
------------
Programs may fall back to picking up and rescaling a square-sized thumbnail if
they fail to find a wide one, preferrably one size above what they are looking
for. The wide-format thumbnail should then be automatically regenerated.
It should also be regenerated if the program supports color management, but it
has found a thumbnail without a color space field.
A _normal_-sized old-specification thumbnail may be produced alongside any
wide ones, but it is strongly suggested to avoid duplicating the larger sizes.
References
----------
- https://specifications.freedesktop.org/thumbnail-spec/thumbnail-spec-latest.html[Thumbnail Managing Standard];
- https://developers.google.com/speed/webp/docs/riff_container[WebP Container Specification];
- https://github.com/rurban/smhasher[smhasher -- Hash function quality and speed tests]
evaluates MD5 as an excellent non-cryptographic hash function;
- https://datatracker.ietf.org/doc/html/rfc3629[RFC 3629 -- UTF-8, a transformation format of ISO 10646];
- IEC 61966-2-1:1999 -- sRGB is "only" available commercially, but reduces to
https://www.color.org/chardata/rgb/srgb.xalter[these characteristics];
- https://developer.apple.com/documentation/coregraphics/cgcolorspace/1408916-displayp3[Apple's brief Display P3 definition]
and the corresponding
https://www.color.org/chardata/rgb/DCIP3.xalter[DCI-P3 characteristics].
Change history
--------------
v0.1, 2021-12-29, Přemysl Eric Janouch::
Preliminary draft.
|
