| cr88192 2006-03-19, 3:55 am |
| ok, I recently wrote code for deflating and also writing out png files
(second day for the writer, 2 days ago wrote new inflater and loader code).
so, for the most part, it works ok, apart from a few problems:
it seems my code can sometimes generate pngs that can't be read correctly by
anything other than my loader code (where they are read fine).
this is the case with: windows (ms picture viewer and paint can't read the
files), likewise for Gimp (gives an error message and gives an image showing
a bunch of squares containing pieces of that and other images).
I eventually found the webpng tool, which gives the message "invalid
literal/lengths set" for these images, but have thus far been unable to
figure what it means exactly (some anal rule/hueristic it is checking?...).
afaict, my deflate code is generating sane output (looking at the literal
lengths table, the values look about right). initially, there was a problem
where I was being lazy and outputing the whole tables (literal lengths,
distance lengths, code length codes) regardles of whether the last few
entries were actually used, but I changed this, and now it works, sometimes
(for some undefined reason, things didn't like it when there were all of 286
length codes, 32 distance codes, and 19 code lengths, all the time...).
more so, I don't know why it mattered, RFC1951 doesn't say much of anything
about requiring one to only include used entries (or even use RLE on the
length codes for that matter). yet, these apps seem to care about this kind
of thing...
then of course, if bugs still remain in my inflate/deflate code, I wouldn't
be all that surprised. eg, major pita bugs existed in the "tree balancing"
code (used for dealing with huffman trees that were "too deep", worked by
recursing into the tree and rebalancing nodes so long as that part of the
tree was too deep, starting at the leaves and working twards the root). if
was also a hassle getting my encoder/decoder to stop at "just the right
spot", eg, so the adler32 checksum would be in the right place.
actually, as implemented, the code can potentially write non-conformant
files, eg, ones with up to 64kB lz windows, but the limits are set lower
(this may be a setable option later, eg, for internal uses of deflate).
otherwise, afaict, what limits I can find have been followed.
thus far, all this seems to be working, sort of. hopefully it is less buggy
than my last code...
lame is that my ratios are a little worse than those of images output by the
gimp. this is possibly because I hard-coded the filtering (I was lazy, it
does not check the filters, instead it always uses paeth...). also possible
is remaining issues in my deflate code hurting ratios...
or such...
|