: t...@netcom.com (Tom Lane) writes:
: >  2. Palette image storage: essential to keep, though it might be enough
: >     to support only 4 and 8 bits per pixel, not 1 to 8 as GIF does.
: >     Odd-size bit depths are more complex to program and don't compress
: >     very well --- the space savings may be illusory.

: I've always figured that having the format support arbitrary bit depths mainly
: made it easier for the decoder to deal with:  ie, it knows ahead of time that
: there'll be no more than 16 colors, or 256 colors, or whatever.  I believe
: that, other than the smaller colortable in the header of the file, it makes
: no difference on the compression.  (An '8-bit' image with two colors should
: compress nearly as well as a '1-bit' image with two colors.)

Agreed.  1, 4 and 8 bit should be supported at the very least.  I don't
think that odd bit depths would cause that much trouble.  Maybe even
an odd number of colors, for example 175 palette entries (just to save
space in the palette, but the indices would be 8 bit in this case, of
course).

By the way, the format should also support greyscaled images without
needing to store a palette.  For example, 8 bit greyscaled images
(0=black, 255=white).  Obviously, a palette for such images is
superfluous and would just waste space.
I think it is also advisable to transform greyscaled images to
delta representation before compression.

: >  3. Lossless true color storage: not in GIF89, but many people want to
: >     add this.  Do we need both 16 and 24 bits/pixel, or just 24?

: I'd like to see this added, but I won't cry if it doesn't make it.
: [...]
: I'd think the a
: plane-wise LZ-ish compression scheme would do reasonably well.

You're probably right.  The problem is, that lossless compression
methods yield poor compression on typical 24 bit images (i.e.
photographic material), while JPEG yields best compression (but
lossy) on just that type of images.

How about using lossless JPEG for the 24 bit variant of the new
format?  Or something similar to lossless JPEG?  As far as I
know, lossless JPEG is quite simple and easy to implement (as
compared to lossy JPEG).

Another suggestion for 24 bit images:
First, the image should be separated into its RGB components
(perhaps not the whole image, but line by line, because that
needs considerably less memory on both the encoding and decoding
side).
Second, the components are transformed into delta representation
(i.e. for each sample the difference to its predecessor ist stored,
rather than the sample itself).  For typical 24 bit images, the
delta representation compresses certainly better than the original
data.
Third, the resulting data is compressed using either gzip,
LZHUF or something similar to lossless JPEG (the original
lossless JPEG method is not applicable to delta representation).

I think the above process should compress pretty well.

: Incidentally, I'm entirely against support for 16-bit images (of
: either variety:  truecolor or greyscale).
: [...]

I fully agree.

: Basically, here's what I'd like to see:
:   1 image per file
:   support for 1-8 bit colormapped images,
:     with reasonable lossless compression,
:     and a 'transparent' color
:   support for 24-bit truecolor images,
:     with reasonable lossless compression,
:     *no* transparent color in 24-bit mode

That seems very reasonable to me.  I'd like to add the possibility
of greyscaled images (1-8 bit) without color map.

: And I think that would nicely handle nearly everything that JPEG doesn't.

I think so, too.

A few thoughts about the basic format:
 - It should contain a "magic word" at the very beginning,
   preferably the name of the format (see below), so it can
   be easily identified.  Some version number or feature byte
   should also be added.
 - The file should be divided into chunks, similar to IFF
   or GIF, each chunk starting with a byte (or word) which
   identifies its type, followed by its size (for easily
   skipping the chunk).
 - There should be some rules defining the order of chunks,
   so it can be read in a serial way.  For example, the
   palette (if existant) should precede the actual pixel
   data.  The chunk defining the image size should be the
   very first in the file, immediately followed by a copyright
   notice chunk (if existant).
 - The format should be extendable, i.e. it should be possible
   to add more application specific chunks, which may be
   ignored by other applications.

By the way, has anybody an idea how to call the new format?
Maybe this is a little premature, but people like to have
names for things...  Once we agreed on a name, everything
else should be as easy as patenting xor to change a bit's
value...  :-)

How about "PING" ("Ping Is Not Gif") ?  The 3 byte extension
for DOS people could be either .pin or .png.
Or how about "TNT" ("The New Thing", as Brad suggested) ?
On the other hand, I think the name should be pronounceable,
just like "GIF".

Regards,
   Oliver Fromme, author of QPEG

--
Oliver Fromme, Leibnizstr. 18-61, 38678 Clausthal, Germany
Internet/Usenet email address:  fro...@rz.tu-clausthal.de
WWW server:  http://www.rz.tu-clausthal.de/~inof/Welcome.html