On Wed, 13 Jan 1999, Dave Haynie wrote:
> > GIF sucks. It is indeed a very lossy coder. It codes only 256 colors with
> > a stupid color quantizer, therefore your image gets dithered and has the
> > un-appealing look.
>
> Well, not really. GIF is a lossless 8-bit palettized format. If you have
> a program that will offer to save anything beyond an 8-bit image to GIF,
> blame the program, not the GIF format. I tried this in Photoshop and
> PhotoImpact -- both require ME to explicitly generate an 8-bit image
> before I get to create a GIF. And it is indeed lossless -- the image I
> save is exactly the image I requested to save.
Well, OK, then it means you are requested to introduce the loss (by
quantizing 24 bit color to 8) before saving in GIF. So, if you consider
the 8 bit image as your "original" image, than fine.. For photo viewing
purposes, 8 bit paletted image is nowhere useful for me. Whatever method
you use to generate the 8 bit image, it has to make dithering and vector
quantization of colors (lossy, of course). I prefer a quantization of
DCT values in 24 bits (which is JPEG) for photos.
> GIF is primarily useful for artwork integrated into Web pages,
> especially line or drawn art. And it has the advantage of maintaining
> transparency if you want it. It's not suitable for good quality photo
Yes.. Actully transparancy can actually be put in the JPEG. They are the
browsers which don't support it.
> presentation. Though I would debate that any Web-friendly format is much
> good for this, if you're after art. Functionally, though, when you have
Yes, as well. I was just comparing between JPEG and GIF for photo
applications (in favor of JPEG). I am strongly partial to any wavelet coder
for its multi-resolution capability (you can stop synthesizing the image at
particular levels. Especially with SPIHT, this level is arbitrary. You
can compress the image to 1:2, let's say, and while viewing, you can view
at any compression ratio below 1:2, and stop if you are satisfied. This
is really better than the "progressive" loading of JPEG or GIF.
OMer
> 20 or 30 formats your software can write, you have to suspect that there
> comes a time when you need to select the right tool for the job. When I
> wrote a web site that gave a walk-through photo tour of my old house
> when trying to sell it ( pretty effective -- the eventual buyers
> apparently spend lots of time there with friends and family), I put up
> all the (fairly small) photos in highly crunched JPEG, usually dropping
> each file to around 10-15K, depending on what it looked like. The point
> here was certainly illustrating the house nicely, but also making the
> walk-through fast enough so that you could actually walk through it. If
> folks has to wait 5 minutes to download each picture, they would have
> left angry.
>
> > > JPEG gives you nice small files for use on the web etc, but you will lose
> > > information when you use it. I didn't know until recently that the
> > > process
> > > is not reversible - if you save, open, save, the two saved files aren't
> > > the
> > > same.... AFAIK only the JPEG and MPEG formats suffer from this.
>
> > There was (and somehow, is) a huge research on lossy and lossless image
> > compression methods. JPEG is an old standard, therefore adopted by the
> > browsers.
>
> There are certainly a variety of lossy compression algorithms; JPEG and
> MPEG were the first with any sort of wide distribution. There are also
> fractal and wavelet formats, which offer different properties. Wavelet
> compression is gaining a reputation for delivering better quality at the
> same compression rations than JPEG. A friend of mine runs Engineering at
> a computer video-oriented company, and they've successfully used some
> form of wavelet compression rather than MJPEG for video capture. Some of
> the Vivitar digital cameras do also, and deliver more "high quality"
> images in the same memory -- though evaluation of the quality is
> difficult, since they also use a CMOS image sensor, not the more common
> (and currently better) CCD.
>
> Fractal compression offers the interesting property that it's inherently
> scalable. So you could use it for a web page that looks nice at 640x480,
> but all the better at 1280x1024, all based on the same images.
>
> The main reason JPEG/MPEG have caught on, and others haven't, is that
> the others are often quite proprietary, possibly (like GIF) covered by
> someone's patents, and so fairly contrary to the nature of the Web (one
> of the primary driving forces for new image compression techniques).
> Also, when you have working standards like JPEG, it's virtually
> impossible to convince someone like Netscape or Microsoft they need to
> pay YOU money to support a superior image format.
>
> For image archival, why not store images without compression, or both?
> Especially if you're putting them on a CD, you can fit a whole roll of
> film scanned at 1600x1200 on one CD, with both raw and JPEG versions if
> you like, and it costs you $2.00 if you do it yourself, $10.00 if you
> let folks like Mystic or Kodak do it for you.
> --
> Dave Haynie | V.P. Technology, Met@box Infonet, AG | http://www.metabox.de
> Be Dev #2024 | NB851 Powered! | Amiga 2000, 3000, 4000, PIOS One
< This message was delivered via the Olympus Mailing List >
< For questions, mailto:owner-olympus@xxxxxxxxxxxxxxx >
< Web Page: http://Zuiko.sls.bc.ca/swright/olympuslist.html >
|