> I would think that accurate platform independent color reproduction
> should be the main priority. For many kinds of commercial sales
> (clothing, flowers, etc) color reproduction is key.
OK, no complaints from me about that one.
Some things to throw into the pot, mainly about TIFF which, in spite of being an
industry standard with considerable commercial "taint" was open to public review
and is one of the most capable multiplatform standards around. I have prefixed
each snippet with the precise image format or topic that I am talking about
which looks a little wooden but helps when my posting gets resampled into little
bits in other postings;-)
- Baseline TIFF 6 has x resolution and y resolution tags, which could be
used to trigger resampling at the client so images were the specified
size regardless of client resolution. This would need to be author
selectable on a per-link basis because in some situations you definitely
do want this behaviour, in others you definitely don't, and in the rest
you don't care either way.
- Baseline TIFF 6 has some other handy tags which a browser could extract, throw
into a document generated on the fly, and display a link to beside the
image. Things like Artist, DateTime, HostComputer, ImageDescription,
Software are all handy things to know in some cases without having to
save the file to disk and running Sam Leffler's tiffinfo over it.
- Extended TIFF 6 spec has an LAB type which clearly gives pretty much
device independent colour within the inherent limits of the CIE standard.
I am aware of those, but even to get decent CIE display would be a big
step forward.
- Extended TIFF 6 has calibrated RGB space support with tags for primary
chromaticities, whitepoint and gamma and even transfer functions if you
want to really do things properly. Oh and reference BlackWhite for headroom
and footroom.
- Extended TIFF 6 has CMYK image support with InkSet (CMYK or not!!),
InkNames (I suggest that these should specify the exact ink and
environment that the separation was generated for, eg SWOP on coated stock,
as there is nowhere else to put this information), DotRange and TargetPrinter
which describes the "printing environment". Whether this means the
phototypesetter that the separations are to be printed on, or the printing
press, or both is unspecified. But then, people don't tweak dot gain to
compensate for miscalibrated imagesetters in this day and age, do they ;-P )
- Extended TIFF 6 supports YCbCr images which is also device independent
although not covering the full device gamut. I know, it can but in practice
this type is used for shuttling video images around so the gamut is less even
than RGB. Plus you get spatial subsampling on the chrominance channels so
there is information loss there too.
- Lastly, Extended TIFF 6 has associated alpha handling (hooray) which would
at last allow proper antialiased graphics with transparency, without having
to guess what the client's background colour is to antialias too. This would
be heaps better than the current GIF89 fudge.
- Printing: wide deployment of Level 2 PostScript printers which claim to
be able to accept images in LAB or XYZ and use internal tables to generate
an accurate representation on paper should in theory mean that decent
images could also be printed off while retaining reasonable appearance.
I would be most interested if someone could point me at a review of current
dye sub printes which have printed out, say, a Macbeth chart and actually
measured the thing to see if the colours are anywhere near their claimed
values. If anyone from Tektronics or Kodak would care to spring to the
defence of their companies' products with some hard figures, please feel free.
- Photoshop (2.5.1 and up): are there any apps that can read and display these
files apart from the implementations of Photoshop on Mac, PC, and the various
Unix platforms it has bravely been ported to?
- Photoshop (2.5.1 and up):We need a MIME type for Photoshop files (would
that be image or application, I wonder) so people can put up files with
all the extra channels intact and exchange them.
- Content type negotiation: Just in case this should ever become a reality, we
need some way to disable it on a link by link basis so that a medical grade
image of someones insides or a commercial grade image does not get converted
to GIF and back, transparently, by some helpful proxy that was only trying
to save you net.bandwidth
- X11R5 and up: X servers claim to have a colour management system. Don't
get your hopes up. This is described in The X resource, issue 0, Fall 1991.
Briefly, it claims to convert colour specifications between colour models,
including CIE ones; to perform colour adjustment due to differences
between the white point the X application thinks it has and the white
point the screen actually has (!) and to do gamut mapping for out of
gamut colours. I was sure there was a demo called Xcmstest but I don't
seem to find it on our HP systems right now. It did a conversion all
right, but assumed an NTSC broadcast monitor which it patently does not
have and which is wildly unrepresentative of modern monitors anyway. This
is of course, more a criticism of the particular implementation that the
underlying concept. Oh, and I got the same results playing with an SGI,
too. Make that two implementations.
- X11R6: Not played with this, anyone got comments on R6isms that would
be helpful in this context?
- X11R5 and up with Level 2 DPS: Supposedly this would let you display CIE
defined colours but how an X application can know about the properties
of the monitor it is displaying on, short of using Xcms (discussed above)
beats me. I suspect a naff conversion with the dreaded NTSC phosphors
again, totally useless if so. Unable to test this as our SGI is sulking and
our HP workstations, wonderful as they are in other ways, don't even come
with a level 1 DPS never mind a level 2.
> Now, obviously, there is no pancea for this problem (different displays
> have different color gamuts, and even the background surrounding the
> CRT display can effect color appearance)
I knew that throwaway line about stylesheets describing how to handle gamut
alarms was a mistake ;-)
Perhaps stylesheets could specify a background colour ("wheat", no, I jest) so
for important images the HTML page could specify a stylesheet with a neutral
grey at, say, D50 or D65 as the background.
Gamut mapping is clearly an important issue as evidenced by the fact that no-one
has satisfactorily solved it yet.
> But standards such as CIE LAB and TEK HVS are at least steps in the
> right direction.
Agree, although last I looked Tek HVS was just the polar form of CIE LUV,
LCuvH with the x axis pointing at a particular "best red" and some scaling
thrown in. No disrespect to the knowledgeable folks at Tektronics intended,
but I don't see that Tek HVC really buys you much.
-- Chris Lilley +--------------------------------------------------------------------------+ | Technical Author, Manchester and North HPC Training & Education Centre | +--------------------------------------------------------------------------+ | 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> | +--------------------------------------------------------------------------+ | This is supposed to be data transfer, not artificial intelligence. M VanH| +--------------------------------------------------------------------------+