Re: filetype extensions

lilley@v5.cgu.mcc.ac.uk (Chris Lilley, Computer Graphics Unit)
Errors-To: listmaster@www0.cern.ch
Date: Mon, 9 May 1994 23:52:38 +0200
Errors-To: listmaster@www0.cern.ch
Message-id: <94050922481812@cguv5.cgu.mcc.ac.uk>
Errors-To: listmaster@www0.cern.ch
Reply-To: lilley@v5.cgu.mcc.ac.uk
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: lilley@v5.cgu.mcc.ac.uk (Chris Lilley, Computer Graphics Unit)
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: filetype extensions 
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas

"Daniel W. Connolly" <connolly@hal.com> said:

> 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>   | 
+-----------------------------------------------------------------------------+