assistance with texture conversion

[sol]

Hello.

I posted a couple of weeks back about a problem I
was having with OpenGL texture conversion. I've
passed this one around to my friends and none of
us have a clue why this code is not working.

The offending code is around 200 physical lines,
but includes a few headers so rather than attempt
to scrape something together for a forum message,
I've decided to post a tarball of the source.

Please don't be intimidated, there is far less
source code than it first appears and the only
code I'm concerned with is gltex_load.c (the other
code is heavily, heavily tested and imported from
other projects). To compile the code, just type
'make' on any POSIX-ish system (sorry, won't build
on Windows without a POSIX build environment like
MSYS). It requires libpng and SDL (should be
present on most modern systems).

The whole point of the code is to convert pixel
data into a format useful to OpenGL, so for
example, 8 bit paletted pixel data is converted to
24 bit RGB data. 1,2 and 4 bit greyscale is
unpacked to 8 bit greyscale. The tarball loads
data using an independently developed 'pngload'
library, but the actual library itself is designed
to be independent of image file type.

The problem is that for 1, 2 and 4 bit greyscale,
1, 2 and 4 bit indexed and indexed-alpha in any
bit depth results in a corrupted texture. This is
extremely apparent by running './test1' and
comparing the various resulting textures to their
original images (all of the images loaded into the
program are in the DATA subdirectory). Use the up
and down arrow keys to switch textures.

I'd be much obliged if anybody can take a look at
the two functions conv_greyscale() and
conv_indexed() and see if they can work out what's
going on. I'm at a total loss.
Source:

http://waste.corolla.ath.cx/gltexloa...022637.tar.bz2
http://waste.corolla.ath.cx/gltexloa...37.tar.bz2.md5

[gigadude]

Have you tried valgrind or similar tools? How about single-stepping the code in a debugger to see that it's doing what you expect?

[sol]

Yes, we've tried that. Due to the nature of
the code, it becomes awkward to understand in
a debugger, due to the fact that the program is
working with sub 8-bit data and the GNU debugger
doesn't offer any way to print numbers in base 2
(it's laborious to copy and paste numbers into a
separate program, and gdb doesn't seem to offer
a pipe facility).