Raster graphics (PNG, JPEG, and the rest) are used in a variety of contexts and a variety of resolutions, but most are come from a small number of sources, above all the digital cameras. Since the digital cameras still are marketed by the megapixel, and the lazy option is to publish the oversized photos unedited. This leads to unnecessary bits clogging up the Internet, slow downloads and excessive memory use.
Modern image formats are designed for lower bandwidth, with interlaced and progressive functionality, showing the image in progressively improving resolution as the bits arrive, but there is no functionality to say that enough bits have been transferred already and that any further bits won’t add to the quality of the image.
The usual approach is to generate thumbnails based on the full-size images, and let the thumbnails function as links to the full-size image. The problem with this approach is that the image and the thumbnail are unconnected. Given the image address you can’t use the thumbnail to quickly display a rough outline of the image until it is downloaded, given the thumbnail you can’t download the image if the resolution is insufficient, and there is no way to cache an image’s thumbnail.
Given the multimegapixel image sources there will be at least three levels of raster images, the original which tend to be too large for any useful purpose, the edited/enhanced Web image, and the scaled down and often cropped thumbnail. The same applies to the audio and video media types as well, only here the downsampled files can be even more dramatically smaller than the raw source files.
A thumbnail should link to the image it is derived from and describe the list of operations done to generate the thumbnail. In formats that supports it like PNG this could be stored in a chunk, but markup is a more generalised solution.
I would also suggest markup for the two types of scaling: file size and resolution. An image would have associated many URLs, for different combinations of file and image sizes.The file format could of course change. PNG for small resolution would be preferable to JPEG, for a certain file size.There could be mirrors for the same image in different locations, if the user doesn’t care about file size and resolution as much as download speed.How I see it working is this. The webmaster would markup the available images (XLink could be used, I think), with CSS or another mechanism declaring the preferred image display size.A la Turbo, the user could set his preference for Quality or Speed, and the browser would load the best matched image from the closest location available.The user would then have the option to reload the image at the desired size and resolution.
One suggestion for HTML5 would be rel=”source”, with the semantics that the linked resource is the source for the content of the document (for the ‘link’ element) or the content of the link (for the ‘a’ element). This isn’t sufficient for a seamless thumbnail handling, but it is enough to associate thumbnails with their source images, or the images with their sources (or for that matter non-images with their source resources). Modern image formats have metadata chunks, but when referring to other resources (in this case source) they are exposed to link rot as the linked resource may have moved after the derivated image was generated. For fully describing the relationship between the resources some form of markup external to the images would be desirable. Ideally this would enable all the related image resources to be accessed from the same URL.