Re: [GM-help] Progressive JPEG's

[Bob F. <bfr...@si...>]

On Fri, 27 Jun 2003, Jeff Jacober wrote:

> Thanks Glenn, but I'm still not quite sure if this achieves what I would
> like.
>
> If I use:
>
> gm convert image -interlace plane progressive.jpg
>
> I assume 'image' has to be an raw RGB file.  And if I read the
> documentation correctly for the -interlace option, this command will
> create a JPEG where the image is stored in the plane-interlaced format
> (RRR...,GGG...,BBB...).  If this were then interpreted as a 'progressive
> JPEG', would it not be one where the red plane is first loaded, then the
> green plane information is added, and finally the blue?
>
> What I would like to achieve is something different.  Assume I have a
> 12000x12000 pixel image.  I would like to create a progressive JPEG where
> the first 'plane' is a sampled down version of my image (take the
> original and sample it to say, 3000x3000), and the final plane is the
> full image.  When the image is served to a browser, the first 'low-res'
> version would be displayed first, while the full-res version loads.

You have to work within the limits of both the format and the browser.
JPEG is only capable of storing a single image, although it is
possible to request multiple resolutions of the image once you
have the complete JPEG file.  I am not aware of any browser which
supports requesting a subresolution of a JPEG image so JPEG's
capability won't help you unless you write your own browser.

There is an old Netscape HTML hack which allows a low-rez image to be
loaded prior to the high-rez image. I forget the syntax.  I don't
recall that it was terribly effective.

You could use Javascript to accomplish quite a bit more.  Javascript
could be used to load a low-resolution image but the HTML could claim
that it is larger so that most browsers will scale the image to fit.
After a larger image has been loaded, the page would auto-update to
display the larger image.  The key here is if Javascript can provide
your script with a notification once the image is loaded so that it
can display the larger image.

Note that many/most browsers will fail to display a 12000x12000 pixel
image, and it might even crash the user's computer.

If you have control over the server side, then it is good to know that
GraphicsMagick's "MPC" format supports lightning fast reads and crops
so that if your large image is available to the server in MPC format,
then it is quite easy to crop a portion of the image and return it to
the user's browser as a smaller JPEG (returning a cropped region as
JPEG should take less than 1/10th of a second on a typical server).
Some browser-side logic (or server-side CGI form logic) can determine
what region of the image should be requested and displayed.  This
approach is commonly used for map images, which can be *huge*.

By providing MPC files on the server which are pre-scaled to several
different resolutions, the user can be allowed to "zoom" in and out
with very little load on the server.

The drawbacks of MPC are:

  o It actually uses two files rather than one (a file.mpc and a
    file.cache file).
  o The format is architecture specific so it is not a usable archive
    format.
  o The image data is in the *exact* format used in memory by
    GraphicsMagick so it is uncompressed, and takes lots of space.
  o MPC can't be effectively stored in a database like JPEG and PNG
    can.

It seems that many sites use a method whereby the large image is diced
into small tiles in varying resolutions, and then the web server
program determines which tiles are required, composites them together,
and returns the result to the browser.  This method is used by ESPN's
lake mapping interface.  This approach takes a lot of logic, while
using MPC takes just a few lines of code, so I think that if the disk
space is available, using MPC is preferrable over a method which
requires thousands of small files.

Bob
======================================
Bob Friesenhahn
bfr...@si...
http://www.simplesystems.org/users/bfriesen