search

diegorep / pypng

Automatically exported from code.google.com/p/pypng
0 stars 0 forks source link

Leading blanks when using write_packed. #47

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
Bug using write_packed.

Currently exhibited by running texttopng.  For example:

./texttopng hello > t.png ; open t.png

Creates a PNG file of the right size, but has the message " hell" rather than 
"hello".

Original issue reported on code.google.com by d...@pobox.com on 20 Apr 2009 at 7:59

GoogleCodeExporter commented 8 years ago 
A little bit of debugging reveals that it is actually producing an incorrectly 
formatted PNG file.  "png.py" is 
more strict than OS X Preview about decoding PNG files:

$ ./png.py -r < t.png                 
P5 40 8 1
Traceback (most recent call last):
  File "./png.py", line 3297, in <module>
    _main(sys.argv)
  File "./png.py", line 3249, in _main
    write_pnm(outfile, width, height, pixels, meta) 
  File "./png.py", line 3133, in write_pnm
    for row in pixels:
  File "./png.py", line 1984, in _itertools_imap
    for x in seq:
  File "./png.py", line 1388, in iterstraight
    recon = self.undo_filter(filter_type, scanline, recon)
  File "./png.py", line 1259, in undo_filter
    (None, sub, up, average, paeth)[filter_type]()
IndexError: tuple index out of range

The problem being that the byte that specifies the filter type for row 2 is 
completely bogus.  (and the fact that 
this error in the PNG file is not reported very clearly is Issue 11).

The PNG file is written incorrectly because the code to handle Issue 44 
consumes the first row twice.  Normally 
each row is a list (or similar), but if the row is an iterator, as it is when 
texttopng is used, then it all goes 
horribly wrong.

png.py should be fixed to consume each input row exactly once.  By copying if 
necessary.

A test case should be written.

Original comment by d...@pobox.com on 20 Apr 2009 at 8:47

GoogleCodeExporter commented 8 years ago

Original comment by d...@pobox.com on 20 Apr 2009 at 8:47

GoogleCodeExporter commented 8 years ago 
More careful observation reveals that the entire first row of the image is 
missing.  Which is consistent with the 
double consumption bug.

Original comment by d...@pobox.com on 20 Apr 2009 at 1:32

GoogleCodeExporter commented 8 years ago 
Fixed in r135.  It's even simpler in some ways.

Original comment by d...@pobox.com on 20 Apr 2009 at 9:50