Difference between revisions of "Picture Service"
m (No Category:API here!!) |
(Added newly discovered "size" parameter, with a different URL; refactored part of the overall layout, but still requires sa lot of "plishin" ro) |
||
| (One intermediate revision by the same user not shown) | |||
| Line 1: | Line 1: | ||
The picture service is a little-known Web service which retrieves | {{Unsupported API}} | ||
{{:API Portal/navigation}} | |||
__TOC__ | |||
<br clear=all/> | |||
==Description== | |||
The picture service is a little-known Web service which retrieves ''any'' texture from the Second Life Grid in the {{Wikipedia|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 {{code|my-secondlife-agni.akamaized.net}} works for {{code|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: | |||
<nowiki>https://picture-service.secondlife.com/</nowiki>[[UUID]]/''width'' x ''height''.jpg | <nowiki>https://picture-service.secondlife.com/</nowiki>[[UUID]]/''width'' x ''height''.jpg | ||
where UUID is the UUID of the texture (or snapshot) to be displayed, | or, alternatively, using: | ||
<nowiki>https://secondlife.com/app/image/</nowiki>[[UUID]]/# | |||
where [[UUID]] is the UUID of the texture (or snapshot) to be displayed, ''width'' and ''height'' represent the desired resolution, and the {{code|#}} stands for one of the predefined sizes, such as: | |||
* Size 1 — 256×192 pixels<ref>This is also valid for sizes 0 and 5-8, all of which redirect to 256×192; many "default" sizes will do the same, although most randomly selected numbers will show a {{code|Not found}} message using {{code|text/plain}}.</ref> | |||
* 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<ref>Note that the latter actually redirects to the former, adjusting parameters. That's how I managed to figure out which sizes were available! — {{mention|Gwyneth Llewelyn|p=}}, 29 Feb 2024</ref> | |||
==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, {{code|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 ({{code|.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 plan and simple truth is that, again, such solutions are ''not'' popular among programmers (amd3 | |||
==Notes== | |||
{{References}} | |||
[[Category:Unofficial APIs]] | [[Category:Unofficial APIs]] | ||
[[Category:APIs]] | |||
[[Category:Developer Resources]] | |||
Revision as of 20:36, 28 February 2024
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[1]
- 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[2]
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 plan and simple truth is that, again, such solutions are not popular among programmers (amd3
Notes
- ↑ This is also valid for sizes 0 and 5-8, all of which redirect to 256×192; many "default" sizes will do the same, although most randomly selected numbers will show a
Not foundmessage usingtext/plain. - ↑ Note that the latter actually redirects to the former, adjusting parameters. That's how I managed to figure out which sizes were available! — @Gwyneth Llewelyn, 29 Feb 2024