Until now there has been some confusion over the role of the sign when describing bitmap heights (in the biHeight field of BITMAPINFOHEADER) especially when using both DirectDraw surfaces and video capture drivers simultaneously (DirectDraw surfaces heights are described in DDSURFACEDESC using the unsigned field dwHeight). To clarify usage, the following statement comes from Microsoft's PC99 specification:
"RGB pixel
formats may be described with a BITMAPINFOHEADER that has a negative biHeight value to
indicate that the vertical orientation of the image is top-down, but using the sign of
biHeight to indicate orientation is only valid for RGB (uncompressed) formats. For other
compression types, described with a FOURCC code in the biCompression field, the FOURCC
code uniquely identifies the compression and orientation. It is not valid to describe the
orientation with the sign of biHeight.
Common YUV formats such as UYVY, YV12, and YUY2 are top-down
oriented. It is invalid to store an image with these compression types in bottom-up
orientation. The sign of biHeight for such formats must always be set positive by drivers
producing such formats, and the sign must be ignored by any driver receiving such formats.
For proprietary compression formats with an associated FOURCC, any orientation is
acceptable, but must always be the same for all bitmaps of that FOURCC."