Image debugging/"printf" utility

Hey there, I just wanted to tell people about this image debugging utility I wrote. It's not actually OpenGL-related, but it should be useful for a lot of Win32 OpenGL programmers (since that's what I do, and that's what I wrote it for). Basically it's a small Win32 library that contains a single function: imdebug(...). imdebug(...) is basically like a graphical printf() for images. All it takes is one call to imdebug and you can have an image up on the screen.

It's handy if you're writing code that deals with a bunch of textures, for example, and the textures aren't showing up properly. You can call imdebug() on the texture data just before your call to glTexImage2D to make sure you're uploading what you think you're uploading.
It is actually handy if you're writing pretty much any code involving 2D data, not just images, actually. It's also very handy if you're writing something like a raytracer and don't want to bother with writing a bunch of code to display the results of your raytracer right at first, but you'd still like something more immediate than saving the image to a file and loading it up in another program.

Anyway, here's the URL: http://www.cs.unc.edu/~baxter/projects/imdebug

Check it out and let me know what you think!

--bill baxter
--unc chapel hill

[Arath]

I think it's not very usefull in openGL, since to debug my texture, I draw simple quad in ortho mode.

Arath

Originally posted by Arath:
I think it's not very usefull in openGL, since to debug my texture, I draw simple quad in ortho mode.


Sure, that technique is perfect for some things. But it's not so hot when, for instance you're stepping through the debugger trying to see what's going on in your code. You hit a breakpoint, the debugger window pops up. Doh! It just covered my GL buffer, now I can't see the texture that I drew! Imdebug pops up the image a separate window, and separate process so it doesn't have that "oops I covered the buffer" problem.

Imdebug also gives you more details about an image than a simple blit with glOrtho. As you hover over the image with your mouse it tells you the pixel values under the cursor. Not the buffer value truncated to the card's range as you might see with a GL buffer viewing scope, but the actual value you had in your code. So if your image is of type float, it shows you the floating point values, not 0-255 values.

One more thing is that imdebug also has a history buffer -- you can see not only the last image, but you can go back and see the previous image or the one before that again.

The other thing I use it for is when I'm generating textures programatically say from a PDE grid simulation. In that case a lot of the 2D data you have in your program is not intended for display, they are just intermediates computed along the way to the final solution.

Clearly there are times when you don't need all that, and a simple quad in ortho does the trick.