I took a look at the tftbmp.pde example in the TFTLCD library (that's the one we're talking about, right?) and I found a couple of problems:
1. Bitmap row padding (as suggested above): Each row of pixels in the file is padded out to a multiple of 4 bytes. The padding bytes, if any, must be skipped when reading the file. The sketch doesn't do that, which will cause the bitmap to be displayed incorrectly if its width isn't a multiple of 4.
2. Top-down bitmaps: The bitmap height field (BITMAPINFOHEADER.biHeight) may be negative. This indicates that the bitmap rows are stored in top-down order instead of the usual bottom-up. This isn't commonly done, but I have seen it on occasion. tftbmp.pde doesn't handle this case - I think it will just display nothing.