Почему RGBTRIPLE и RGBQUAD хранят данные в порядке BGR?

Question

В Windows структуры RGBTRIPLE и RGBQUAD определяются в обратном порядке.Это настолько нелогично, что я думаю, что это было сделано намеренно.Это, конечно, не имеет значения, но меня это достаточно напугало, и я чувствую, что стоит спросить.Итак, почему?

Определения:

typedef struct tagRGBTRIPLE {
        BYTE    rgbtBlue;
        BYTE    rgbtGreen;
        BYTE    rgbtRed;
} RGBTRIPLE, *PRGBTRIPLE, NEAR *NPRGBTRIPLE, FAR *LPRGBTRIPLE;

typedef struct tagRGBQUAD {
        BYTE    rgbBlue;
        BYTE    rgbGreen;
        BYTE    rgbRed;
        BYTE    rgbReserved;
} RGBQUAD;

Answer 1

На машине с прямым порядком байтов (например, x86 и друзья) структуры точно соответствуют формату цветных данных растрового изображения.

Answer 2

Хранение порядка цветов само по себе не имеет абсолютно никакого особого значения: вы можете хранить компоненты в любом порядке, важно просто согласовать, какой порядок был выбран.

Тем не менее, формат BGRдля этих структур соответствует порядок компонентов, используемый для DIB (по крайней мере, на машинах с прямым порядком байтов - но весь формат DIB разработан с учетом LE), поэтому, если у вас есть 24-битный DIB в памяти, вы можете прочитать его данные о цвете, используяRGBTRIPLE структура и «перемещение» ее с помощью арифметики указателей;однако, это не относится к 32-битным DIB и RGBQUAD («зарезервированный» байт должен быть первым членом).

Вместо этого используется структура RGBQUAD для палитры DIB;байт заполнения почти наверняка по соображениям производительности позволяет напрямую использовать данные палитры, считанные из файла, в качестве таблицы поиска цветов, сохраняя их на границах DWORD.

Итак, почему был выбран порядок BGR дляDIBs на первом месте?Я предполагаю, что это имело некоторое преимущество в производительности во времена разработки DIB (мы говорим о Presentation Manager из OS / 2, ~ 1988), возможно, преобразование из DIB в формат оперативной памяти большинства графических карт было дешевле ввот так.

РЕДАКТИРОВАТЬ

Хорошо, предположение о том, что заказ остался в OS / 2 Presentation Manager, подтверждается этой статьей 1992 года в КБ , который явно указывает, что

Красный, зеленый и синий байты расположены в обратном порядке (позиция красного цвета с синим) в соответствии с соглашением Windows.Это еще один недостаток совместимости с Presentation Manager.

(кстати, мой самый ненавистный остаток от OS / 2 PM в DIB - это обратный порядок строк, происходящий из системы координат по умолчанию, используемой в OS / 2 PM)