> The latter form will probably work for now... but what about the future
> when there may be caching proxy servers with built-in graphics conversion?
> Such a proxy may have image/tiff, and it may be able to generate image/gif
> faster than going round-trip to the original server.
Um. If you ask a proxy for foo.gif (or foo with accept image/gif) it is supposed
to ask the original server for the expiry and last-modified date to be sure that
the version it has is exactly, in every detail, the same as the original.
Conversion in the manner you suggest negates all this. If the proxy has bar.tif
and converts it to bar.gif, it is not necessarily the same as the original
servers version. What quantisation algorithm was employed - Heckbert's? Wu's? In
what colour space? RGB? CXMYK? CIELAB (TIFF supports all of these). How many
colours was it quantised to, and is the resolution the same?
For people who are text oriented and view images as minor decoration, these
differences are inconsequential. But you cannot be certain that the content of
the image is of so little worth. And plenty of people are using the web to
distribute scientific visualisations, medical images, computer graphics for
example where these differences are extremely important.
> We must be very careful about time-to-live, conversion quality, etc.
> to be sure that the proxy servers don't compromise the protocol.
Indeed. How are you going to specify that the quality does not matter (eg a
silly little help icon in xpm and you want it as a gif) or does matter (a
medical image) and how much it matters? If a proxy is supposed to guarantee you
get the same result as going direct, then such conversions must be ruled out.
And yet, for many purposes, the conversions would be entirely adequate. But let
us not rule out certain applications of the web just because many current images
are content-free.
Having recently put up some images on the web as part of a paper I gave on gamut
mapping and so on, where the differences between images were small but vital,
this issue is of immediate concern to me.
> Enough Purism to save yourself from having to re-engineer your solution
> down the road, mixed in the enough Pragamatism to make it useful to
> your user community today
What an excellent aphorism! Unfortunately if these things get enshrined in
standards, this flexible balance goes out the window and you have to specify
exactly what happens in each case. Ho hum.
-- Chris Lilley +-----------------------------------------------------------------------------+ | Technical Author, ITTI Computer Graphics and Visualisation Training Project | +-----------------------------------------------------------------------------+ | Computer Graphics Unit, | Internet: C.C.Lilley@mcc.ac.uk | | Manchester Computing Centre, | Janet: C.C.Lilley@uk.ac.mcc | | Oxford Road, | Voice: +44 61 275 6045 | | Manchester, UK. M13 9PL | Fax: +44 61 275 6040 | | X400: /I=c/S=lilley/O=manchester-computing-centre/PRMD=UK.AC/ADMD= /C=GB/ | | <A HREF="http://info.mcc.ac.uk/CGU/staff/lilley/lilley.html">my page</A> | +-----------------------------------------------------------------------------+