>A colleague of mine recently offered the following observation:
>> [It was] discovered that Mosaic imposes a 50 color/image stipulation.
>> So, if an image has more than 50 colors in it, the Mosaic
>> browser reduces the number of colors to 50--it utilizes a
>> median cut algorithm.
> I believe he was referring to NCSA Mosaic, but I have yet to
> confirm this.
He was referring to the default behaviour of NCSA Mosaic for X when displaying
on a pseudocolor visual. So, the Mac and PC Mosaic programs, which are quite
different programs, may well not suffer from this problem. Also, NCSA Mosaic for
X does not suffer from this problem when displaying to a TrueColor or
DirectColor visual; here, each GIF is displayed with the full 256 colours each.
Furthermore, it is only a default and can be changed. I had Mosaic set up to
allocate 200 colours, for example. The reason this was done was apparently to
avoid colour clashing when running an MPEG viewer I am quite happy to have all
my windows turn green on the odd occasion that I run an MPEG viewer, if it gives
me better images.
> My question to this list: Is this a widespread limitation of
> web clients?
Well yes, in that often clients run in environments with inadequate or grossly
inadequate numbers of colours. 32k colours gives good results; 256 colours gives
severe limitations but is frequently used, and I recently saw someone access a
page on computer graphics from a PC running in 16 colour VGA. Gross.
Of course, cleint can choose to do something other than the fastest and nastiest
colour quantiser they happen accross. Median cut is not so bad, either, it could
be truncation ;-) Netscape for X, for example, appears to do Floyd-Steinberg
error diffusion dithering which frequently gives better results on pages with
many images, all using very different pallettes.
> Due to some shared source library which enforces it?
No, not at all. Each client does whatever their implementors chose to do.
> More generally, I would be interested in any reference material, specs,
> or guidelines for the handling of image display in clients.
There are guidelines out there which explain how to quantise all the images on
one page down to the same colourmap, of 256 or even of 50 colours. This is a bad
idea in general. The aim should be to maximise the quality of image provided by
the server, and let the clients hack the images down as needed. Plenty of PC and
Mac users run their browsers in a 32k colours or 16M colours environment.
Kludging the GIFs so that they cope with current behavious of a particular
browser in certain situations is a short term fix.
Of course, if you are providing, say, a CWIS and you know that the vast majority
of your users are running with 50 colour Mosaics on slow lines with slow CPUs,
then the wins in transmission speed (GIFS with large blocks of the same colour
are smaller) and decoding speed may be more important.
But in general, optimise the quality of what you send.
And as for quantising all the GIFS on one page to the same colourmap; apart from
the inevitable reduction in quality compared to an optimum pallette for each
GIF, plus the reduction in quality caused by doing two quantisations (24 bit
original to 256 colour GIF, then again to a different 256 colours) how do you
know that these pictures will not be used on other pages in combination with
other GIFS?
> I would also be interested in any such material on image quality standards
> for the web. My sense is that this does not exist
Pretty much. Netscape, Chimera and emacs w3 allow inline JPEG and often these
are smaller than GIF and look better on displays with more colours. There is no
particular consensus on things like gamma - servers running where their
webmasters use SGI's tend to have no gamma correction, relying on the default
1.7 correction in SGI's X server and forgetting that they are the only
manufacturer to do this.
Simnilarly people who use Photoshop on a Mac tens to assume that the image will
be gamma corrected at 1.8 prior to viewing, which of course on PCs and most Unix
workstations, on OpenVMS and VM and CMS and indeed on Macs when displayed
inline, it isn't. Arena now has a gamma command line oprtion which is nice.
The TIFF spec says that RGB TIFF should incorporate a gamma of 2.2
Utah RLE and TIFF include tags that tell you what the image gamma and assumed
display gamma is, but cludgy unix utilities like the pbm toolkit (useful, but
kludgy hacks nonetheless) ignore all this information.
You don't see many PhotoCD files flying around the net, probably because of the
well-documented furore when PhotoCD specs were witheld from hobbyist developers
which I am sure you are aware of.
For myself, on servers I maintain:
- Baseline TIFF 5 images are gamma corrected to 2.2 as per the spec
- JPEG JFIF images we tend not to use becuase, dealing with computer graphics we
may want to analyse the images and lossy compression is no use there. Some
images which are just decorative may well use JPEG though
- all GIFS are quantised to 256 colours unless they clearly require less (ie if
quantising to less looks the same when viewed on a 24 bit screen
This seems to give the best results on the various browsers we have access to
and looks fine except on SGI machines where the images are rather washed out and
faint from being gamma corrected twice. We do say on our web pages what the
gamma used was, so SGI users who care could save the images to disk and view
with
xv -visual TrueColor -gamma 0.45
if they really want.
In the future - well, TIFF 6 includes a CIE LAB image type and I would be most
pleased if browsers supported this, none do at the moment and neither do
external viewsers. But it would give device independent colour.
Hmm - so should style sheets include instructions on how to deliver gamut
warning alarms? ;-)
> The prevalence of imaging on the web is large and likely to grow. Given
> all the attention paid to the quality of text display, it seems appropriate
> that we should do the same for images.
Complete agreement.
> If
> I get confirmation that this is relatively uncharted territory, I may
> start an effort to address it.
Interested to see your proposals here.
Be aware though that the web is very much an open standards forum when framing
your proposals, and remember that PhotoCD access from Unix boxes and other less
common platforms lags behind Mac and PC deployment of PhotoCD plugins. Also the
number of people viewing images is vastly greater than the number of people
creating them (shame but true) and that even shareware viewers are enough to put
off some sites. To be viable, multiplatform free viewers are a must.
If however you want to talk about image quality standards for gamut, colour
space, headroom and footroom, gamma, using the web to move around colour
corrected prepress images, etc then I am most interested to hear what you have
to say.
-- Chris Lilley +--------------------------------------------------------------------------+ | Technical Author, Manchester and North HPC Training & Education Centre | +--------------------------------------------------------------------------+ | Computer Graphics Unit, | Internet: [email protected] | | Manchester Computing Centre, | Janet: [email protected] | | 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> | +--------------------------------------------------------------------------+ | This is supposed to be data transfer, not artificial intelligence. M VanH| +--------------------------------------------------------------------------+