Comments on REC-PNG-20031110

Hi,

  Regarding <http://www.w3.org/TR/2003/REC-PNG-20031110>, in the process
of implementing an IDAT recompressor I've implemented parts of the PNG
specification. In this I found three things hard to understand. The
first thing is how IDAT chunks encode filter type and the scanline data.
This is mentioned in passing somewhere, but it is not as clear as, say,
some indented

  +-------------+------------------------------------+
  | Filter type | Filtered data for this scanline... |
  +-------------+------------------------------------+

The second thing is the discussion of filters. Filters map from source
to destination, but section 9.2 isn't quite phrased this way. It's hard
to properly understand the "pixel versus byte" distinction early on in
the section, and the notation in table 9.1 is hard to understand. I got
confused a couple of times in what order things had to be done, what it
really means to have `Filt(x)` in the reconstruction function and so on.

One ambiguity for instance is that it's not really clear what `Orig(x)`
is since from the perspective of the scanline for `x` there are two
original values for the other variables, before and after they had their
filter applied. The same goes for `Recon(a)`, is that before or after it
had its scanline filter removed? While I figured out the answer, I did
understand these things incorrectly initially.

(It would have helped a lot had there been some pseudo-code showing how
you get from the color and depth values to the advance width and how you
resolve the aforementioned ambiguity, or at the least something about
how you can decode top-down but need to encode bottom-up or with a se-
parate buffer.)

The third issue is the CRC calculation. These days there are very many
things that go by "CRC" with various polynominals and whatnot. Since I'd
rather not code my own implementation, or use the specification's code,
I went looking for the right library, but that's not very easy. It would
have helped if there had been a reference, like saying this is the same
CRC that is used by gzip.

Similarily, in 5.1 "A four-byte CRC (Cyclic Redundancy Code) calculated
on the preceding bytes in the chunk, including the chunk type field and
chunk data fields, but not including the length field." is confusing.
What is says is that you really only take the type field and the data,
as far as I understand it anyway, so saying "including" the only things
you include is misleading.

(As an aside, the second to last paragraph in 9.2 seems malformed and
there are a couple of " ." instances that should not be there.)

regards,
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Friday, 4 March 2011 03:30:14 UTC