Message-Id: <mailto:199501060508.XAA12538@library.wustl.edu> Date: Fri, 6 Jan 1995 03:23:35 GMT From: Tom Lane <mailto:tgl@NETCOM.COM> Subject: Re: progressive transmission To: Multiple recipients of list IMAGELIB
mailto:ported@RPI.EDU writes: > If I missed someone else mentioning this, forgive the repitition. There's a
> good example of progressive transmission available for everyone to try: the
> Netscape WWW clients do this with at least GIF images - perhaps also with
> JPEG? Anyway, it is a pleasure to use.
Netscape supports this only for GIFs, and only when the GIF file is stored in "interlaced" order (the first scan provides every 8th scanline, the next every 4th, etc). Early beta releases drew just the supplied scanlines, yielding a sort of "venetian blind" visual effect. Since about version 0.94, they've duplicated the supplied scanlines vertically to fill in the as-yet-unsupplied area. This creates a rather odd-looking effect, IMHO: horizontal resolution is fine, but vertical resolution starts out awful and improves as scanlines are filled in.
Progressive transmission of JPEGs is not currently supported by any WWW software, but the JPEG standard specifies how to do it, and you can expect to see the capability eventually. (If I quit browsing netnews and start coding, that is :-).) Here's some info from the JPEG FAQ:
Subject: [11] What is progressive JPEG?
A simple or "baseline" JPEG file is stored as one top-to-bottom scan of the image. Progressive JPEG allows the image to be stored as a series of scans of increasing quality. The first scan shows the image at the equivalent of a very low quality setting, and therefore it takes very little space. Successive scans improve the quality. Each scan adds to the data already provided, so that the total storage requirement is about the same as for a baseline JPEG image of the same quality as the final scan. (Basically, progressive JPEG is just a rearrangement of the same data into a more complicated order.)
The advantage of progressive JPEG is that if an image is being viewed on-the-fly as it is transmitted, the viewer sees an approximation to the whole image very quickly, with gradual improvement of quality as one waits longer; this is much nicer than a slow top-to-bottom display of the image. The disadvantage is that each scan takes about the same amount of computation to display as a whole baseline JPEG file would. So progressive JPEG only makes sense if one has a decoder that's much faster than the communication link.
Up until recently, there weren't many applications in which progressive JPEG looked attractive, so hardly any implementations of it are available. But with the popularity of WWW browsers running over rather slow modem links, and with the ever-increasing horsepower of personal computers, progressive JPEG is starting to look like a win for WWW. I expect that progressive JPEG capability will start to appear in WWW browsers during 1995.
regards, tom lane organizer, Independent JPEG Group