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."