In the same conversation, @Pchelolo brought up a potential issue around image format conversion / selection. We do have a need to support format conversions, for example a conversion from SVG to PNG. However, in order to be able to select such a conversion where needed, clients will either need to know the original type before making the request, or will have to indicate a fixed desired type every time in order to avoid fragmentation (avoid optional default parameter).

This requirement is similar to informing the client about original dimensions, except that the desired file type also //needs// to be sent to the API to avoid default parameter fragmentation. Since we also need to support uses without any rewriting (ex: HTML), including the file type in the URL (for example, as a query parameter) seems to make the most sense.

Example original URL, using query string syntax:
`/2fd4e1c67a2d28fced849ee1bb76e7391b93eb12?f=png`

Another (possibly prettier) option would be to use a custom file extension syntax, but the downside of this would be slightly more effort for parsing.

Edit: Thinking about this some more, I think we should detail a bit more which kind of control over the format we need. Aspects that come to mind:

- Quality selection (esp. for bitmaps). Coarse granularity (high, normal, low) is probably all we want to expose.
- Bitmap vs. vector graphics vs. video. 
  - Clients might want to load the original image in case it is an SVG. For this, they need to know whether an original is a SVG vs bitmap / video before making a request. Specifying the size does not make sense for SVGs in general.
  - Videos: Some clients could offer a video player, rather than displaying a bitmap thumb.
- Selecting a specific bitmap format. This seems questionable, but it's conceivable that there could be client support limitations that would make this useful. Content negotiation might be a better alternative for phasing in new formats like webm.

Can we write down some use specific use cases for format / quality selection?