I've recently been working with the netpbm ppm format and I have hit 

bug in all netpbm formats.  I am aware of the long standing povray issue 
with the netpbm file formats header where the height and width need to 
be on the same line as the magic number though that is not a requirement 
of the official format.  This bug is different.

Namely in working with a larger number of ppm files I hit cases where a 


the first byte of data after the line feed (LF) (Ubuntu linux 12.04) 
happens to have a carriage return (CR) value.

The code which is set up to interpret the netpbm headers is reading a 

pulling in the first byte of data with the CR value as part of the line. 
When the read by binary data, 8 or 16 bits at a time, starts the povray 
read code is offset into the data by one byte too many.

The result from 10,000 meters, if input values were completely random 
file to file, would be netpbm read fails for size that make no sense in 
1/256 files. In practice & depending on data some might never see fails 
while an unfortunate few might almost always fail.

I'd make some argument any CR following a LF character should not be 
pulled in as part of the line read even on windows/dos systems where 
CRLF is the usual line termination order. I think though the real fix is 
better netpbm header reading code which more strictly breaks apart  the 
header on the first whitespace character doing the last depth break 
aware of the file size so it can decide what portion of any valid 
sequence of whitespce characters after the decimal depth value is data 
and not whitespace.

If this is all known and I missed it, please let me know. If not an 
understood bug with the netpbm binary reads,  would someone please 
confirm the bug. I have posted a tarball to p.b.misc which when unpacked 


fails.ppm data is all 0x0D while works.ppm data bytes are all 0x0C.

Thanks for your time.
Bill P.

Post a reply to this message

On 08/10/2013 03:01 PM, William F Pokorny wrote:
>...
Posted this and the tarball to http://bugs.povray.org as : "FS#307 - 
netpbm, ppm, read bug where first data byte CR char" so we do not lose 
track of it.

For anyone hitting this issue... My work around was to convert to the 
PNG format which povray interprets without issue. If using the netpbm 
program, pnmtopng, to convert, you might need to change the default 
gamma correction from the ppm format if it contained linear data.

Bill P.

Post a reply to this message