BMP pixel rows may begin at the bottom or at the top. Inspect the signed height and header, use an orientation-marked sample, and verify converted PNG and JPG files instead of hiding a decoder problem with a manual flip.
BMP → PNG
Recognize the two BMP row directions
Windows device-independent bitmap data is not always stored from the visual top row to the bottom row. In a common BITMAPINFOHEADER case, a positive height describes a bottom-up bitmap whose pixel array begins with the bottom scanline. A negative height can describe a top-down bitmap whose array begins with the top scanline. A decoder must interpret the sign and map stored rows into display coordinates; reading every array as top-down can produce a vertical flip.
Prepare a source whose orientation is unambiguous, such as an image with TOP written near one edge, BOTTOM near the other, and an asymmetric shape. Record width, signed height, bit depth, and compression from the header, then open the original in several viewers. If only one program flips it, that decoder is suspect. If every program agrees, the pixels may already have been written in the wrong order by the creating application.
- Inspect the sign of the height
- Use an asymmetric orientation target
- Compare multiple BMP decoders
The height sign can communicate row direction, not merely the absolute pixel height.
Separate row order from other orientation problems
A vertical row-order flip is different from a camera rotation or an Exif Orientation issue. BMP workflows generally should not be diagnosed as if they were JPEG orientation workflows. If text remains readable left to right but the top and bottom exchange places, investigate row order first. A 90-degree rotation, horizontal mirror, or combined transform points toward the capture program, an earlier conversion, or an additional display operation.
Screen-capture APIs and older applications sometimes move DIB memory into a BMP file while pairing the wrong height sign with the row array. Renaming the extension or manually flipping the final image hides the symptom without fixing the production path. Record the source application, intermediate operations, and final converter, then compare the image after each step. When possible, create a known-good and faulty file from the same target and compare their headers and first rows.
- Distinguish flips from rotations
- Trace each creation and conversion step
- Compare known-good and faulty headers
Check row padding and pixel offsets
BMP scanlines can include padding for alignment. If a decoder advances by visible pixel bytes rather than the correctly padded row size, the image may show diagonal drift, colored bands, or truncated rows rather than a clean flip. Verify the pixel-data offset, bit depth, width, and calculated bytes per scanline. Test widths that do not naturally align to the storage boundary because they expose padding mistakes more readily than convenient dimensions.
Palette-based and compressed BMP variants add more conditions, so success with one uncompressed 24-bit sample does not prove universal support. If production inputs include 1-, 4-, or 8-bit palettes, 16- or 32-bit pixels, alpha-like channels, or compression, test each actual class. Avoid guessing new header offsets or patching bytes in place. Re-decoding the preserved source with a conforming implementation and writing a standard output is usually safer than manual repair.
- Calculate padded scanline size
- Test inconvenient image widths
- Cover real bit depths and palette types
Diagonal drift or colored rows often indicate padding or offset errors, not only reversed row order.
Compare PNG and JPG output for the intended use
Converting BMP to PNG provides a lossless reference that is well suited to checking orientation, sharp edges, and exact colors. JPG adds lossy compression and has no alpha channel, so it is less suitable for diagnosing tiny text or boundary pixels. Verify the PNG first, then create a JPG only when the destination needs it and evaluate JPEG quality and any background compositing as separate decisions.
Place the source BMP, PNG, and JPG at the same displayed dimensions and compare the corners, top row, bottom row, and marked orientation. Look for a missing line, padding-related color shift, or alpha change rather than checking only whether the picture appears upright. If a converter automatically corrects a malformed source, document that fact: another tool may interpret the same source differently even though the first output looked right.
- Use PNG as the diagnostic reference
- Compare first and last rows
- Document any automatic correction
Approve representative BMP types end to end
Build a test set with top-down and bottom-up files, several widths, palette images, and the 24- or 32-bit variants used in production. Convert each through the actual BMP-to-PNG or BMP-to-JPG tool and open the results in the target application plus an independent viewer. Confirm top and bottom, dimensions, colors, alpha behavior, and complete edge rows. Use fresh filenames and checksums so an image cache cannot show an older result.
Record the original header values, creating application, converter version, output settings, and test environment. Do not repair a failed derivative by flipping and overwriting it; return to the source and decode it correctly. The final practical check is to upload both the marked target and a real business image to the delivery service, download its versions, and compare them pixel for pixel at the edges. Start batch conversion only after every required class passes.
- Test top-down and bottom-up inputs
- Avoid stale preview caches
- Inspect the downloaded service output
Both an orientation target and a real production BMP should pass before a folder-wide conversion begins.
Key takeaways
- In common DIB structures, a positive height can indicate bottom-up rows while a negative height can indicate top-down rows.
- A decoder that ignores the sign may vertically flip an image or behave inconsistently across applications.
- Use a visibly asymmetric sample and inspect header values to separate row-order faults from rotation or source-capture problems.
- After conversion, verify orientation, dimensions, color, padding, and edge rows in the real receiving system.
Frequently asked questions
Why can BMP store the bottom row first?
Traditional DIB layouts can use a bottom-up array for a positive height, and the decoder reconstructs the visual top-to-bottom order.
Does a negative BMP height always mean corruption?
No. In supported header forms, a negative height can intentionally indicate a top-down bitmap.
Can I simply flip the converted image in an editor?
That may fix one visible file but leaves the decoder or source inconsistency unresolved, so later files can fail again.
Is diagonal image drift also a row-order problem?
It more often suggests an incorrect padded scanline size or pixel offset, which should be checked with width and bit depth.
What is the final conversion check?
Convert a marked target and real BMP, then compare orientation, edge rows, dimensions, and color in the actual downloaded delivery files.