Image Display, Manipulation, and Control

MNG includes nine chunks for manipulating and displaying image objects and for providing a kind of programmability of the decoder's operations. The most complex of these is the framing chunk, FRAM. It is used not only to delimit the chunks that form a single frame, but also to provide rendering information (including frame boundaries, where clipping occurs) and timing and synchronization information for subsequent frames. Included in FRAM's timing and synchronization information is a flag that allows the user to advance frames, which would be necessary in a slide show or business presentation that accompanies a live speaker.

The CLIP chunk provides an alternate and more precise method for specifying clipping boundaries. It can affect single objects or groups of objects, not just complete frames, and it can be given both as absolute pixel coordinates and in terms of a relative offset from a previous CLIP chunk. Images that are affected by a CLIP chunk will not be visible outside the clipping boundary, which allows for windowing effects.

The LOOP and ENDL chunks are possibly the most powerful of all MNG chunks. They provide one of the most fundamental programming functions, the ability to repeat one or more image-affecting actions many times. I mentioned earlier that 16million.mng, the MNG image with all possible 24-bit colors in it, makes use of a pair of loops; those loops are the principal reason the complete image can be stored in less than 500 bytes. Without the ability to repeat the same copy-and-paste commands by looping several thousand times, the MNG version would be at least three times the size of the original PNG (close to 1,000 times its actual size)--unless the PNG version were simply renamed with a .mng extension.

In addition to a simple iteration count, which can go as high as two billion, the LOOP chunk can provide either the decoder or the user discretionary control over terminating the loop early. It also allows for control via signals (not necessarily Unix-style signals) from an external program; for example, this capability might be invoked by a program that monitors an infrared port, thus enabling the user to control the MNG decoder via a standard television remote control.

Often used in conjunction with loops and clipping is the MOVE chunk, one of MNG's big advantages over animated GIFs. As one might expect, MOVE allows one or more already defined image objects to be moved, either to an absolute position or relative to the previous position of each object. Together with LOOP and ENDL, MOVE provides the basis for animating sprites. Thus, one might imagine a small Christmas MNG, where perhaps half a dozen poses of a single reindeer are cloned, positioned appropriately (with transparency for overlaps, of course!), and looped at slightly different rates in order to create the illusion of eight tiny reindeer galloping independently across the winter sky.[97]

[97] Add a few more poses of a waving fat guy in a sleigh, and you'll swear you hear sleigh bells ringing and chestnuts roasting on an open fire.

Up until now, we've glossed over the issue of how or whether any given image is actually seen; the implication has been that any image that gets defined is visible, unless it lies outside the image frame or local clipping region. But an object-based format should have a way of effectively turning on and off objects, and that is precisely where the SHOW chunk comes in. It contains a list of images that are affected and a 1-byte flag indicating the ``show mode.'' The show-mode flag has two purposes: it can direct the decoder to modify the potential visibility of each object, and it can direct the decoder to display each object that is potentially visible. Note that I say potential visibility; any object outside the clipping region or frame or completely covered by another object will clearly not be visible regardless of whether it is ``on.'' Among the show modes SHOW supports is one that cycles through the images in the specified range, making one potentially visible and the rest not visible. This is the means by which a single sprite frame in a multipose animation--such as the reindeer example--is displayed and advanced.

In order to provide a suitably snowy background for our reindeer example, MNG provides the background chunk, BACK. As with PNG's bKGD chunk, BACK can specify a single color to be used as the background in the absence of any better candidates. But it also can point at an image object to be used as the background, either tiled or not. And either the background color or the background image (or both) may be flagged as mandatory, so that even if the decoder has its own default background, for example, in a web browser, it must use the contents of the BACK chunk. When both the background color and the background image are required, the image takes precedence; the color is used around the edges if the image is smaller than the frame and not tiled, or if it is tiled but clipped to a smaller region, and it is the ``true'' background with which the image is blended if it has transparency.

Finally, MNG provides a pair of housekeeping chunks, SAVE and SEEK. Together, they implement a one-entry stack similar to PostScript's gsave and grestore commands; they can be used to store the state of the MNG stream at a single point. Typically, this point would represent the end of a prologue section containing such basic information as gamma and chromaticity, the default background, any non-changeable images (the poses of our reindeer, for example), and so forth. Once the SAVE chunk appears--and only one is allowed--the prologue information is effectively frozen. Some of its chunks, such as gAMA, may be overridden by later chunks, but they will be restored as soon as a SEEK chunk is encountered. Any images in the prologue are fixed for the duration of the MNG stream, although one can always make a clone of any such image and move that instead.

The SEEK chunk is allowed to appear multiple times, and it is where the real power lies. As soon as a decoder encounters SEEK, it is allowed to throw out everything that appeared after the SAVE chunk, flush memory buffers, and so forth. If a MNG were structured as a long-form story, for example, the SEEK chunks might be used to delimit chapters or scenes--any props used for only one scene could be thrown away, thus reducing the memory burden on the decoder.

That summarizes the essential structure and capabilities of MNG. I've skipped over a few chunks, mostly ancillary ones, but the basic ideas have been covered. So let us now take a look at a few examples.