In message <[email protected]>, Chris Lilley, Computer Graphic
s Unit writes:
>"Daniel W. Connolly" <[email protected]> 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?
Very good point. Now... can we go back in time and pretend that I had said:
"Assume, for the sake of argument, that this caching server implements
100% intvertible translation between gif and tiff."
>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.
Another good poing. It appears that clients should be able to express
a tolerance (and lack thereof) for information loss in conversion.
>> 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?
Something like:
Accept: image/gif; t=1.0
The Accept: header already specifies things like how much it costs the client
to deal with the given format, and tolerance on how long it is willing to wait
for a conversion. We just add one that says "my tolerance for information loss
is 1.0, i.e. no information loss is tolerable." For help icons and such, you
would set t=0.9 or so.
To reiterate: we need to be able to put this info _in_the_link_markup_, since
it is not only a function of the client's capabilities, but also of the author's
intent. For example, when I create a link to a help icon, I don't care if a few
color bits here and there get changed. But if I'm linking to a medical image,
I certainly do care!
> 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.
I agree with your evidence, but not with your conclusion that _all_
"such conversions must be ruled out." We just need to be careful! Keep
all the issues on the table and allow references to express _exactly_
what they refer to, and how much "slop" they'll tolerate.
Dan