Re: [png-implement] Progressive image loading advantage for limited devices ?

Are there archives of PNG implement on the web? All I could find was:
http://pmt.sourceforge.net/mailing-lists/png-implement/

My original post is nicely archived here on w3-di (or is it www-di,
sigh!):
http://lists.w3.org/Archives/Public/www-di/2004Dec/0010.html

On Thu, Dec 16, 2004 at 08:41:05AM -0800, John Bowler wrote:
> It depends on the format how well this works.  For example it works very
> well with JPEG - even baseline JPEG (although for *baseline* it is still
> necessary to transmit the whole image.)  For PNG it *may* work OK depending
> on the nature of the image.  The PNG encoding just transmits a subset of the
> pixels - it doesn't do any averaging across the image (as in JPEG), so if
> the pixels which are *not* transmitted contain important information the
> result may be bad.

Hmm, averaging sounds important feature then for the image format.

> One specific case where the image will not look good is if it contains text.
> Text can be displayed on lower resolution devices, but this requires the
> highest quality (near perfect) resampling.  If this isn't done the text
> either looks "fuzzy" (broken anti-aliasing) or "blocky" (this is what will
> happen with PNG interlacing).  Blocky text is invariably illegible.

Images should never contain text IMO, so this case will not worry me.

> >This would avoid having the entire image transferred on a typically
> >limited (thin and noisy) wireless network connection.
> >It would also save expensive/limited memory/computation of resizing the
> >image on the device.
> Right - it's better if possible to do the resizing *before* transmission.

To clarify does the resizing here refer to a computation required? Or
just reading the first bytes of a "interlaced PNG stream"?

> If you can't do this then it is possible to take a slightly higher
> resolution sub-image from the start of an interlaced PNG stream and
> downsample that to the correct size on the device.  Notice that you will
> still have to resize on the device unless you are prepared to display the
> image on as little as half the screen.

Not entirely sure why you need to resize (computation on the end device,
mobile). Or why you implied it will only show on "as little as half the
screen". You mean the screen I referred to being 50x50?

> If you can pre-process the image before transmission then it is better, for
> PNG, to resample the whole image down to a factor of two of the required
> size.  (The final resampling on the device then has a bounded memory
> requirement and is computationally slightly easier.)

That sort of sucks. Requiring a computation on the server all the time
an image is downloaded from a mobile device.  It would be much better if
this was somehow a feature in the format.

> >When it comes to zooming on the image, perhaps a protocol to read the
> >next few bytes through the network efficiently...
> Yes, you can do that with PNG so long as you retain the original sub-image
> (i.e. the result of the original partial decode, before any on-device
> resizing).  If the user is able to both zoom and pan then it gets a little
> tricky - you potentially end up allocating space for the whole decompressed
> image on the device because the user could zoom in to the highest resolution
> then pan around the image.

Oh this is exciting. Are there any implementations of this? I have been
toying with many Nokia devices in my research, but I have never come
across this feature in a an image viewer. 

A desktop test case would be just as good.

> Is the "progressive loading" feature what I am looking for?

You didn't answer my question ! :)

Best wishes,

Received on Sunday, 19 December 2004 03:18:52 UTC