Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!wuarchive!waikato.ac.nz!comp.vuw.ac.nz!actrix!templar!jbickers
From: jbickers@templar.actrix.gen.nz (John Bickers)
Newsgroups: comp.graphics
Subject: Re: Image file format poll results
Message-ID: <1112.tnews@templar.actrix.gen.nz>
Date: 7 Mar 91 00:52:48 GMT
References: <1991Feb12.120203@Unify.com> <513@lysator.liu.se> <23390@well.sf.ca.us>
Organization: TAP, NZAmigaUG.
Lines: 30

Quoted from <23390@well.sf.ca.us> by knoll@well.sf.ca.us (John Knoll):
> Oh, come on. "The IFF format is an EXCELLENT structure...."  I disagree
> in that the image format (ILBM) really bites.

    The method of storing pixels is specific to ILBMs. A variation on
    that could be used (and probably is for 24-bit data) for more
    efficient storage for different hardware.

    The IFF part of things (for example, an ILBM could be given a new
    chunk that contains byte-per-pixel data, without breaking old
    display programs) is fine, and the level of flexibility it provides
    has been followed to some extent in the move from things like GIF
    towards things like TIFF on other platforms.

> The pixel values are stored in bitplanes, so if you want to read the value
> of a single pixel of an 8-bit image, you have to access 8 bytes in different

    This particular example is a crock. Several popular PClone formats
    (GIF, PCX, etc etc etc) compress their data, so it's not possible to
    extract a single pixel from a file easily.

> I find this kinda stupid.

    Part of handling IFF files well is getting away from the olde
    concept of fixed positional stuff all over the place. The fact that
    you can embed ILBMs, animation data, and sound data in a single IFF
    file, is an example of the idea's flexibility.
--
*** John Bickers, TAP, NZAmigaUG.        jbickers@templar.actrix.gen.nz ***
***         "Patterns multiplying, re-direct our view" - Devo.          ***