Picture Service

NOTE: This API and its documentation are NOT provided or supported by Linden Lab. Linden Lab does not guarantee that this API works as described or works at all. Use at your own risk!

Second Life APIs

• Registration API

• Map API

• Inventory API
• Live Data Feeds
• Media Plugin API

• Marketplace API for Viewers

Unofficial APIs

• Search API
• Snapshot API
• World API
• Picture Service

Description

The picture service is a little-known Web service which retrieves any texture from the Second Life Grid in the  JPEG format.

The images have been pre-processed to several sizes, and are retrieved from Akamai, not directly from the grid's simulators or asset servers, similarly to how my-secondlife-agni.akamaized.net works for my.secondlife.com, but with a different API (namely, the ability to retrieve a texture given its UUID).

Usage

The Picture Service is invoked using the following URL:

 https://picture-service.secondlife.com/UUID/width x height.jpg

or, alternatively, using:

 https://secondlife.com/app/image/UUID/#

where UUID is the UUID of the texture (or snapshot) to be displayed, width and height represent the desired resolution, and the # stands for one of the predefined sizes, such as:

• Size 1 — 256×192 pixels
• Size 2 — 320×240 pixels
• Size 3 — 60×45 pixels

For the first URL, it is also possible to use a sizing of 100×100 pixels, which doesn't seem to exist as a separate size code/number for the second one

Reasoning

Search results and some Web pages retrieved via the World API sometimes require publishing images extracted from textures submitted by residents. While images specifically designed to be shared publicly — such as profile pictures or images on the SL Marketplace — can be retrieved by using a resident's avatar name at the full resolution it was uploaded, a generic system that can retrieve any texture (or snapshot!) at the original resolution would allow widespread piracy at an even larger scale. As such, only thumbnails are made available, which have too low quality for anything else.

It's also interesting to see that different projects have dealt with texture-to-web-image conversion slightly differently, for the same purposes, and which might indicate having been developed by separate teams — never reusing the same API. Although it seems that all these services, as of 2024 at least, have been placed on Akamai, they have not been unified or standardised. Thus, my.secondlife.com and its avatar pictures (SL and RL), the snapshots sent from in-world to the profile feed, the events portal, the search engine, and the SL Marketplace, all use different APIs to accomplish essentially what is the same purpose: remotely storing and retrieving images, some of which also accessible via the Second Life Viewer in a different format, others never leaving the environment Web (such as the images on the SL Marketplace or the snapshots on the profile feed).

Caveats

For the past two decades, Linden Lab has been internally relying on the JPEG2000 format for the in-world textures, which, at the time SL was first developed, was the only standardised image format that allowed multiple image sizes in the same file, which could be progressively retrieved in better and better resolution, as the user behind the Viewer patiently waited for all the textures to rezz. While today we have much better formats available — allowing essentially the same — JPEG2000 is still relevant in several areas (notably, medical imaging, and as a replacement for the RAW format in some digital cameras).

The major problem is that JPEG2000 is little used outside such specific environments, and, as a consequence, it is unpractical to rely on the end-user having some sort of tool able to easily convert between formats. In the distant past, LL would only accept texture uploads using the Targa format (.tga filename extension), which preserved all raw data in a structured format which could then be relatively easy to convert to JPEG2000. The reverse was not deemed to be of sufficient importance to warrant the assignment of a specific "file format conversion team" of LL developers. Indeed, although there are reference applications which accept any "popular" format (namely, JPEG, PNG and TGA) and convert to and from JPEG2000, such tools are known to be very slow — which is not practical when los of images require immediate conversion. Some open-source solutions were developed independently of the standards body, a few of which are extremely efficient at doing the conversion, the plain and simple truth is that, again, such solutions are not popular among programmers.

Converting between file formats is also a non-trivial task — if you have to develop it from scratch, as seems to be the case with a lot of the software produced by LL. Thus, the different implementations and use-cases, each with its own set of rules.

While the above two URI schemes have been around for a long time, since they're not formally reported as one of the official APIs, it's unknown if Linden Lab will continue to keep them, or will replace them in the future with something else entirely. Third-party developers relying on the Picture Service to use the thumbnails for their own purpose should therefore pay attention to their implementation and make it sufficiently flexible to deal with unexpected and unannounced API changes; there is no (known) public commitment by Linden Lab to keep this API around in its present form — or even suppress it entirely. Caveat utilitor.

At the time of writing this (early 2024) it was unknown if the Picture Service could also retrieve thumbnails from textures stored in the Preview Grid (Aditi).