Most programs that support viewing of GIF files display both normal and interlaced GIFs completely properly. Netscape Navigator provides an additional feature: since images in Netscape are normally decoded and displayed incrementally (as data comes in over the network), the fact that interlaced GIFs are decoded and displayed incrementally means that the image appears to "fade in".
In Netscape Navigator beta 0.9 and 0.91, this gives a "venetian blind" effect as the data arrives and is displayed. As of Netscape Navigator beta 0.92 and beyond, we have adopted a suggestion from Paul Haeberli of Silicon Graphics and changed our code to replicate available lines of the image during the first three (of four) decoding stages. In this way, the user sees a complete, albeit not fully "fleshed-out" image after the first of the four passes; subsequent passes progressively enhance the quality of the image until, at the end of the fourth pass, the entire image is in place at full resolution.
If you find the above three paragraphs confusing, don't worry. Just try this (image borrowed from NYWeb):
If you are using Netscape Navigator, the first image should have been downloaded and displayed from top to bottom, and the second image should have faded in using either the "venetian blind" effect or the "progressive enhancement" effect, depending on which beta version of Netscape you're using.
If you are not using Netscape Navigator, both images should have appeared just fine anyway.
So, assuming you find the interlacing to be a positive effect under Netscape Navigator, you can convert any GIF image on your server to be interlaced without at all affecting how other browsers view the image. Just use one of these utilities:
ppmtogif has a -interlace option. So you can
convert an existing GIF to an interlaced GIF as follows:
cat foo.gif | giftoppm |
ppmtogif -interlace > foo-interlaced.gif
SRC value for an IMG tag, and Netscape Navigator will decode and display the image just as it would a GIF image. The big advantage of JPEG images is that the compression ratios can be much higher for most images (particularly "real life" images). JPEG is also a "lossy" compression method, meaning that you don't generally get the exact same image data upon decoding that you had when you encoded the image. During the encoding process, you can generally specify the "quality" of the encoding. Specifying a low quality value can give you an even higher compression ratio.
While Netscape Navigator supports JPEG images across platforms, many existing browsers do not support inlined JPEGs. For your documents to work with those browsers as well as Netscape, your server will have to be smart enough to send GIF images to non-Netscape Navigator browsers and JPEG images only to the Netscape Navigator browsers (and other browsers that support JPEG images -- we expect many browsers will support JPEG as a standard image format in the near future). We will be providing information on how to do this soon.
(Note that HTTP's "format negotiation" support, via the request's "Accept" values, unfortunately generally does not give the server enough information to decide whether to send GIF or JPEG images to the client, since many browsers support sending JPEG images to external viewing applications and therefore tell the servers they support the JPEG format when they do not in fact do so internally. This is a sad deficiency of the current protocol and we expect it to be rectified in the future.)See a comparison of a GIF image and several JPEG versions of the same image.
For this reason, Netscape Navigator allows you to specify an image's height and width as attributes of the IMG tag. The height and width are normally specified in pixels. For example, if you are inlining an image that is 413 pixels wide and 356 pixels high, the IMG tag would look like this:
<IMG SRC="foo.gif" WIDTH=413 HEIGHT=356>
Browsers that do not have support for the WIDTH and HEIGHT attributes to the IMG tag will simply ignore them and lay out the document normally.
Netscape Navigator, on the other hand, will use the height and width information to pop in place a properly-sized bounding box upon encountering the IMG tag and will continue laying out the document text, with no performance delay to go discover the width and height of the image over the network. (See the next section for details on what happens if the width and/or height given in the IMG tag are different than the actual width and/or height of the image.)
Most general-purpose image utility programs will give you the exact size of an image in pixels.
WIDTH and/or HEIGHT values in an
IMG tag that differ from the actual width and/or height of
the image, Netscape Navigator will use the width and height values specified in the IMG tag and scale the actual image to fit. For example, if you have an image that is actually 123 pixels wide and 78 pixels high, but you create a document that inlines the image as follows:
<IMG SRC="b.gif" WIDTH=492 HEIGHT=312>
...the image will be scaled to fit the dimensions 492 by 312. This means you can purposely cause any image (GIF or JPEG) to be scaled to a larger size (or, for reasons I can't imagine, a smaller size) on the fly, by Netscape Navigator. See an example of scaling in action.
As before, browsers that do not do auto-scaling will cleanly ignore
any WIDTH and HEIGHT attributes you add to
your IMG tags and will display the inlined image at the
normal, unscaled size.
LOWSRC, to
IMG, as follows:
<IMG SRC="highres.gif" LOWSRC="lowres.jpg">
Browsers that do not recognize the LOWSRC attribute cleanly
ignore it and simply load the image called "highres.gif".
Netscape Navigator, on the other hand, will load the image called "lowres.jpg" on its first layout pass through the document. Then, when the document and all of its images are fully loaded, Netscape Navigator will do a second pass through and load the image called "highres.gif" in place. This means that you can have a very low-resolution version of an image loaded initially; if the user stays on the page after the initial layout phase, a higher-resolution (and presumably bigger) version of the same image can "fade in" and replace it.
You can freely mix and match GIF (both normal and interlaced) and JPEG images using this method. You can also specify width and/or height values in the IMG tag, and both the high-res and low-res versions of the image will be appropriately scaled to match.
Here are some examples:
LOWSRC is a 7,752-byte JPEG; SRC is a
113,164-byte non-interlaced GIF. They are the same size, 360 by 398,
and are not auto-scaled. Here.
LOWSRC is a 16,721-byte JPEG; SRC is a
113,469-byte JPEG. They are the same size, 642 by 595,
and are not auto-scaled. Here.
LOWSRC is a 6,358-byte JPEG; SRC is a
64,714-byte JPEG. They are not the same size (the LOWSRC
image is quite a bit smaller); the HEIGHT and
WIDTH values of the bigger image are given in the
IMG tag, causing the smaller image to be scaled up.
Here.
LOWSRC is a 3,769-byte
JPEG; SRC is a 547,935-byte interlaced GIF. Again,
they are not the same size, and the HEIGHT and
WIDTH values of the bigger image are given in the
IMG tag. Here.
LOWSRC images and all of the document
text before making the second pass through and loading the high-res
images. Unfortunately, there may be problems with this theory
at the moment -- they're being worked on.
IMG tag, the second image (the image specified by the SRC attribute) will be scaled to the dimensions of the first (LOWSRC) image. Reason: by the time Netscape Navigator knows the dimensions of the second image, the first image has already been displayed in the document at its dimensions.
marca@mcom.com.