Re: Image quality on the web

Joel A Crisp (Joel.Crisp@bristol.ac.uk)
Fri, 18 Nov 1994 10:06:09 +0000 (GMT)

Messages sorted by: [ date ][ thread ][ subject ][ author ]
Next message: Chris Lilley, Computer Graphics Unit: "Re: Inline support for vector files"
Previous message: Bob Denny: "RE: POSTing images?!!?"
Maybe in reply to: Chris Dobbs: "Image quality on the web"
Next in thread: Chris Lilley, Computer Graphics Unit: "Re: Image quality on the web"

Chris Lilley said :
>
> Yechezkal-Shimon Gutfreund said
>
> > 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.
This is also important on monitors. The big problems are the degree of
user control over the parameters at client end, user ignorance about
viewing and display conditions, background illumination.
The colour of an object depends on the texture of the surface, the
reflectance and adsorption of the surface, the angle of incidence of
the light source AND viewer, and the spectrum of the light source.
( I know you all know this, but someone out there may not ! )
All of these generate problems. Texture is obvious. Most colours
which people wish to represent on the screen are originally adsorption
based ( mostly ), whereas screens are emmision based ( and non-linear ).
This causes another mapping problem. The angle of incidence is
essentially uncontrollable, as is the spectra of the light source.
Any file format which wishes to produce a 'true' representation of
a colour should be capable of specifing all of these at 'preferred' values -
however, there are so many different ( and conflicting ) specifications
of colour spaces and colour transformation equations that this is
almost impossible.
>
> 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;-)
CHOP !!
>
>
> - 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.
And a standard for representing the units which these are specified in,
along with prefered re-sampling method and dither method.
>
> - 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.
Copyright and distribution rights ( and PGP authentication of content ? )
are notable ommissions here. As well as organisation, keywords, and
a generic 'comments' field to really screw up standardisation !
This would also be nice to be able to encapsulate, so that source 1
supplies a content authenticated image to source 2, who then encapsulate
it with additional meta-information with overall content authentication
without having to affect the auth info on the original image.
>
> - 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.
We found that a number of companies we were suppling to ( in my previous
job ) were not happy with CIE-LAB for colour representation on screen.
Particularly car paint manufactures, who have a high gloss on the
final surface. I suppose what I'm really trying to say, is that colour
representation is less important than 'appearance' representation.
>
> - 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.
This is going in the right direction, if the user is given the
ability to correctly set up a display system using these parameters.
( As Chris points out below on X11R5 )
>
> - 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 )
People do tweak monitor caliabration tho'
>
> - 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.
This is one of ( many ) my biggest problems with Photo-CD.
>
> - 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.
Agreed. There is also the problem that in digitised images of any type,
the backgound is not often uniform - black translates to about 48 shades
when digitising from our videodisk via a TARGA board. The noise inherent in
the system makes automatic background detection difficult. We rely on
a combination of thresholding and spatial frequency analysis to do this,
with some success. It is however a bit slow ;-(
>
> - 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.
I think this will also depend on the company producing consistant dyes,
and the customer always buying from the same supplier. The degree of
variation we saw between products form different suppliers which were
*suppose* to be identical was astonishing. Even the varience in one
company's colour was quite extreme. Aging is also a factor here.
>
> - 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.
No comment. ( Other than it is a commercial package ).
>
> - 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.
Make that a generic problem with this type of representation attempt.
See my comments at the start.
>
> - 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.
I'm sulking 'cos I don't *have* an SGI ! ;-(
>
> > 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.
I am more inclined to talk about power values at frequencies within a
10nm spectra.....with the conditions of sampling heavily specified. This
may be converted into CIE et al. , and is the most accurate representation
currently available. The inter-instrument agreement and repeatability
of modern spectrophotometers such as the Machbeth 7000 [ assuming you cut
the earth wire on the serial port to stop the ground loops ;-( ] is quite
good. One company ( I forget the name ) uses a spectro head hung
in front of the monitor, and one on the printer output, which are used
to calibrate the system every couple of hours. Even then, they still
have representation problems. ( The company may have been Stork Igs ).
>
> 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|
> +--------------------------------------------------------------------------+
My theory on AI - it'll only work when you can get a neural net drunk ! ;-)
( Try drifting standing waves on the power supply to a neural grid... )
>
BTW, all of this is great, but the first problem is persuading the
content experts to give you decent samples in the first place. No matter
how good your file format is, it can't correct for a pathologist taking
a photo with the wrong aperture or the harsh artifacts introduced by
flash lights. Or indeed, of the wrong bit of body being photographed. ;-(

Joel

-- 
Joel Crisp                           joel@asmodeus.demon.co.uk ( Linux/33 ) 
Multi-Media Technical Support for Bristol Uni.     Joel.Crisp@bristol.ac.uk
Educational Technology Support Service

Next message: Chris Lilley, Computer Graphics Unit: "Re: Inline support for vector files"
Previous message: Bob Denny: "RE: POSTing images?!!?"
Maybe in reply to: Chris Dobbs: "Image quality on the web"
Next in thread: Chris Lilley, Computer Graphics Unit: "Re: Image quality on the web"