RGBTRIPLE 및 RGBQUAD가 BGR 순서로 데이터를 저장하는 이유는 무엇입니까?

Windows에서 RGBTRIPLE 및 RGBQUAD 구조체는 역순으로 정의됩니다. 너무 직관력이 없기 때문에 고의적으로 행해졌을 것입니다. 그것은 물론 중요하지 않습니다. 그러나 이것은 저를 도청하여 충분히 가치있는 것이라고 생각합니다. 왜?RGBTRIPLE 및 RGBQUAD가 BGR 순서로 데이터를 저장하는 이유는 무엇입니까?

정의 : 조금 엔디 기계 (일명 x86 및 친구)에

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;

출처

2011-03-13 rotanimod

나는 그것을 가지고 내기 것 (덧붙여 말하자면, DIB의에서 OS/2에서 오후 내 가장 싫어 나머지는 OS/오후 2시에 사용되는 좌표계 기본에서 오는 행의 역순입니다) endianess와 관련이 있습니다. –

색상 순서 저장소는 특별한 의미가 없습니다. 어떤 순서로든 구성 요소를 저장할 수 있지만 중요한 것은 선택한 순서에 동의하는 것입니다.

여전히 이러한 구조의 BGR 형식은 DIB (적어도 리틀 엔디안 컴퓨터에서는 가능하지만 모든 DIB 형식은 LE를 염두에두고 설계되었습니다)에 사용되는 구성 요소 순서와 일치하므로 24 비트 DIB 메모리에서 RGBTRIPLE 구조체를 사용하여 색상 데이터를 읽고 포인터 연산을 사용하여 "이동"할 수 있습니다. 그러나 32 비트 DIB 및 RGBQUAD ("예약 된"바이트 첫 번째 구성원이 있어야합니다) 마찬가지입니다.

RGBQUAD 구조는 대신 DIB의 팔레트에 사용됩니다. 패딩 바이트는 성능상의 이유로 거의 확실합니다. 파일에서 읽은 팔레트 데이터를 색상 표의 룩업 테이블로 직접 사용하여 DWORD 경계로 유지합니다.

그래서 왜 DIB에 대해 BGR 순서가 선택 되었습니까? DIB가 설계된 시점에 성능 이점이 있다고 가정합니다 (우리는 OS/2의 Presentation Manager에 대해 말하고 있습니다, 1988 년). 아마도 DIB에서 대부분의 그래픽 카드의 메모리 내 형식으로 변환하는 것이 더 저렴했을 것입니다. 이 방법.

EDIT

좋아, 명시 적

레드 지정 순서는 OS/2 프리젠 테이션 매니저로부터 나머지가 this 1992 KB article 의해 확인한다는 가정하에, 녹색 , 파란색 바이트는 Windows 규칙에서 반대 순서 (빨간색은 파란색으로 바뀝니다)입니다. 이것은 Presentation Manager와의 호환성에서 또 다른 문제입니다.

는

출처

2011-03-13 21:27:24

고마워, 나는 그 배치가 다른 기본 시스템과 잘 작동하도록 고안되었다고 생각했지만, 그게 기본 시스템이 그 표현을 사용하기로 결정한 이유에 대해 질문했다. 당신의 설명이 가장 좋은 방법이었습니다. – rotanimod

구조체 정확히 비트 맵의 색상 데이터의 데이터 형식과 일치.

출처

2011-03-13 21:15:46 Erik

RGBTRIPLE 및 RGBQUAD가 BGR 순서로 데이터를 저장하는 이유는 무엇입니까?

답변

관련 문제