Red Hat Bugzilla – Bug 58745
rawtopgm mishandles littleendian flag
Last modified: 2015-03-04 20:10:05 EST
From Bugzilla Helper: User-Agent: Mozilla/4.78C-MyBrowser [en] (X11; U; Linux 2.4.9-13 i686) Description of problem: Using rawtopgm with 2-byte images gives the same result with or without the -littleendian flag. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. rawtopgm -bpp 2 -littleendian 100 100 raw.data >little.pgm 2. rawtopgm -bpp 2 100 100 raw.data >big.pgm 3. diff little.pgm big.pgm Additional info: looking in the current netpbm source, rawtopgm calls read_from_file function incorrectly, using: read_from_file(ifp,bpp,littleendian,row,col) but should be: read_from_file(ifp,bpp,row,col,littleendian) SO, littleendian flag is actually the row number, and we have a big-endian first row followed by all little-endian rows. Bad row & col values don't hurt anything because it's only for error messages.
It looks like rowskip is also mangled in rawtopgm. In i386 RedHat 7.2, rowskip values seem to have no effect. Compiling netpbm for IRIX, I found that declaring rowskip as double doesn't work when processing arguments as type OPT_FLOAT. Rowskip should be a float. Also, it seems that rowskip is a flot to support non-integral skip amounts. This must be useful sometimes, but non-integer values won't work for 16 bit raw data. The endianness will flip because there's no attempt to skip in integral 16 bit amounts.
I'll updated the netpbm package to the latest release in the next couple of days. If you could give that on a shot and see if that fixes your problem i'd greately appreciate it. Read ya, Phil
It looks like the littleendian flag got fixed, but now there's another bug. It only shows up with -O3 optimization. In this piece of code: compute_image_size(const struct cmdline_info cmdline, const long nread, int * const rows_p, int * const cols_p) { if (cmdline.autosize) { cmdline.autosize is treated as always true, but only with -O3. Strangely, if I print that value anywhere within the subroutine, it works OK. It also works OK if I remove the const qualifier from the cmdline argument. Dang... Otherwise looks good.
OK, i've updated the netpbm to the latest release (9.24), so i'm closing this bug as resolved rawhide. As we don't build our packages with -O3 but rather -O2 the second bug you mentioned shouldn't happen, so everything should work as expected. :-) Read ya, Phil