Thumbnails

The thumbnails service provides methods to generate thumbnails for various files and resolutions based on requests. It retrieves the sources at the location where the user files are stored and saves the thumbnails where system files are stored. Those locations have defaults but can be manually defined via environment variables.

• File Locations Overview
• Thumbnail Location
• Thumbnail Source File Types
• Thumbnail Target File Types
• Thumbnail Query String Parameters
• Thumbnail Resolution
• Thumbnail Processors
• Deleting Thumbnails
• Memory Considerations
• Example Yaml Config

The relevant environment variables defining file locations are:

• (1) OCIS_BASE_DATA_PATH
• (2) STORAGE_USERS_OCIS_ROOT
• (3) THUMBNAILS_FILESYSTEMSTORAGE_ROOT

(1) … Having a default set by the Infinite Scale code, but if defined, used as base path for other services. (2) … Source files, defaults to (1) plus path component, but can be freely defined if required. (3) … Target files, defaults to (1) plus path component, but can be freely defined if required.

For details and defaults for these environment variables see the ocis admin documentation.

It may be beneficial to define the location of the thumbnails to be other than the default (with system files). This is due the fact that storing thumbnails can consume a lot of space over time which not necessarily needs to reside on the same partition or mount or expensive drives.

Thumbnails can be generated from the following source file types:

• png
• jpg
• gif
• tiff
• bmp
• txt

The thumbnail service retrieves source files using the information provided by the backend. The Linux backend identifies source files usually based on the extension.

If a file type was not properly assigned or the type identification failed, thumbnail generation will fail and an error will be logged.

Thumbnails can either be generated as png, jpg or gif files. These types are hardcoded and no other types can be requested. A requestor, like another service or a client, can request one of the available types to be generated. If more than one type is required, each type must be requested individually.

Clients can request thumbnail previews for files by adding ?preview=1 to the file URL. Requests for files with thumbnail availabe respond with HTTP status 404.

The following query parameters are supported:

Various resolutions can be defined via THUMBNAILS_RESOLUTIONS. A requestor can request any arbitrary resolution and the thumbnail service will use the one closest to the requested resolution. If more than one resolution is required, each resolution must be requested individually.

Example:

Requested: 18x12
Available: 30x20, 15x10, 9x6
Returned: 15x10

Normally, an image might get cropped when creating a preview, depending on the aspect ratio of the original image. This can have negative impacts on previews as only a part of the image will be shown. When using an optional processor in the request, cropping can be avoided by defining on how the preview image generation will be done. The following processors are available:

• resize resizes the image to the specified width and height and returns the transformed image. If one of width or height is 0, the image aspect ratio is preserved.
• fit scales down the image to fit the specified maximum width and height and returns the transformed image.
• fill: creates an image with the specified dimensions and fills it with the scaled source image. To achieve the correct aspect ratio without stretching, the source image will be cropped.
• thumbnail scales the image up or down, crops it to the specified width and hight and returns the transformed image.

To apply one of those, a query parameter has to be added to the request, like ?processor=fit. If no query parameter or processor is added, the default behaviour applies which is resize for gif’s and thumbnail for all others.

As of now, there is no automated thumbnail deletion. This is especially true when a source file gets deleted or moved. This situation will be solved at a later stage. For the time being, if you run short on physical thumbnails space, you have to manually delete the thumbnail store to free space. Thumbnails will then be recreated on request.

Since source files need to be loaded into memory when generating thumbnails, large source files could potentially crash this service if there is insufficient memory available. For bigger instances when using container orchestration deployment methods, this service can be dedicated to its own server(s) with more memory.

 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

# Autogenerated
# Filename: thumbnails-config-example.yaml

tracing:
  enabled: false
  type: ""
  endpoint: ""
  collector: ""
log:
  level: ""
  pretty: false
  color: false
  file: ""
debug:
  addr: 127.0.0.1:9189
  token: ""
  pprof: false
  zpages: false
grpc:
  addr: 127.0.0.1:9185
  tls: null
http:
  addr: 127.0.0.1:9186
  tls:
    enabled: false
    cert: ""
    key: ""
  root: /thumbnails
grpc_client_tls: null
thumbnail:
  resolutions:
  - 16x16
  - 32x32
  - 64x64
  - 128x128
  - 1080x1920
  - 1920x1080
  - 2160x3840
  - 3840x2160
  - 4320x7680
  - 7680x4320
  filesystem_storage:
    root_directory: /var/lib/ocis/thumbnails
  webdav_allow_insecure: false
  cs3_allow_insecure: false
  reva_gateway: com.owncloud.api.gateway
  font_map_file: ""
  transfer_secret: ""
  data_endpoint: http://127.0.0.1:9186/thumbnails/data