Re: Netscape and IE images

Generally in the right direction - just a few points to make...

> That's accurate, at least as far as I can attest.
>
> > CMYK is good for print, because it only allows for up to 16+ thousand
different colors,
> > the maximum capability that printers today, even professional print
presses can do.
>
> You're off by a good bit.  CMYK stores eight bits per color - meaning a
CMYK image
> stores 32 bits per pixel.  This is quite a bit more than the 24-bit color
allowed in RGB.
> (Okay, so maybe I ought to mention that the K channel is pure grayscale,
but gray is a color
> just the same....)

While basically true, this is not really accurate. The 32bit data contained
in a CMYK encoded pixel can indeed contain a larger number of *combinations*
of colour within a certain range - the galmut or spectral range of standard
CMYK is actually more limited then that of RGB data. Galmat describes the
ability of a colour model to faithfully reproduce the intended colour. CMYK
as a colour model is highly restrictive in this respect due to the limited
nature of the CMYK print process. Also, due to great varieties of output
devices & the fact that the CMYK process is based on subtractive colour as
opposed to additive colour (such as L*a*b & RGB data) there are a huge
number of complexities associated with accuratly reproducing CMYK data as
intended.

Theoretically the K (or black) channel could be left out as the CMY channels
would ideally produce a black shade if all were combined. However, even
though some cheaper home printers don't operate with a dedictated black
channel the results of combining the CMY channels do not look particular
accurate (often a deep muddy brown) & not least is the fact that it's far
less efficient using three colours in place of a single one. Hence the K
channel is something of a kludge inherited from the need to service the
limited output of printing devices.

> > RGB is almost limitless, but, allas its in the millions somewhere where
the ammount of
> > distiguishable colors it can allow.
>
> You do have one thing right here - RGB's 24-bit depth translates to 16.7
million colors.
> Your assertion that this is more than CMYK can handle, though, is flat
wrong.

See above. Optimally L*a*b colour is the colour model capable of reproducing
the greatest colour galmut range, this advanced colour model has a much
large galmut then both RGB & CMYK & is capable of encompassing both colour
models.

> > JPG and GIF are different though.  While GIF handles solid color, and
solid color
> > transitions better than JPG (this is why it does well with animations)
and has a smaller file
> > size, JPG handles, on the pixel level, a smoother transition between
similar colors, thus the
> > higher file size (usually used for photographs).
>
> Okay, you've got a dangerous amount of misinformation here.  First up,
JPGs are usually
> much smaller than GIFs given the same image - because JPG uses a lossy
compression
> scheme which allows for really small files for fairly large images.  That
lossy compression is
> also why JPG doesn't handle solid colors well; the compression is geared
toward images that
> are photos as opposed to simple art. Second, GIF handles animations better
than JPG
> because GIF allows for multiple image blocks - saying this is "better"
handling is like saying
> that a monitor is better than a piece of cardboard for displaying a web
page; JPG just doesn't
> have the tools to handle animation.

This is largely correct. While M-JPEG (the M is for motion) is a  format
common in the field of digital video editing, it is used to preserve image
data for each frame by avoiding the very lossy temperal encoding MPEG data
streams use & instead compresses each frame individually with a subset of
the JPEG encoding mechinism used in the JFIF format, it is not however
suited to applictions such as the internet (where filesize is a concern) &
software decoding (where playback speed is a concern). Although there is one
thing to keep an eye on; MNG - the new draft specification by the PNG group
to provide an advanced multiple image (ie. animation) network format based
around a subset of the PNG & JPEG compression techniques.

> Of course, one file format is conspicuous in its absence here: PNG.  IMO,
it's best explained
> by comparison to the other formats here, which makes for a nice little
summary/wrapup:

Good product placement =)

> RGB encoding: GIF, JPG, TIFF, BMP, and PNG.
> CMYK encoding: TIFF, BMP (?), and PNG.

PNG does not support CMYK encoding (at least not natively). There has been
some discussion regarding support of such data in MNG but due to its
inherent complexity & implementation difficulties it has been left out to
date. There is also some feeling that CMYK is too specialised & not really a
requiured component of a network centric image format.

> Palette-based color encoding: PNG (optional), GIF (mandatory).
> True animation (multiple frames): GIF and PNG, but not TIFF, BMP, or JPG.

PNG can only be used in animation as a subset of MNG.

        Cheers,
                Will.

Received on Thursday, 3 February 2000 19:37:48 UTC