본문으로 이동

YCbCr

위키백과, 우리 모두의 백과사전.
YCbCr 색 공간의 시각화
일정한 루마 Y′=0.5에서 CbCr 평면
컬러 이미지와 Y′, CB, CR 구성 요소. Y′ 이미지는 기본적으로 주 이미지의 회색조 복사본이다.

YCbCr, Y′CbCr, 또는 YCBCR 또는 Y′CBCR 표기법은 디지털 영상사진 시스템의 색 이미지 파이프라인 일부로 사용되는 색 공간의 한 종류이다. YPBPR과 마찬가지로 RGB 원색을 기반으로 하며, 둘은 일반적으로 동등하지만 YCBCR디지털 영상을 위한 반면 YPBPR아날로그 시스템에서 사용하도록 설계되었다.[1]

Y′는 루마 구성 요소이고, CB와 CR은 각각 청색-차이적색-차이 색차 구성 요소이다. 루마 Y′(프라임 포함)는 휘도 Y와 구분되는데, 이는 광도가 감마 보정RGB 원색을 기반으로 비선형적으로 인코딩되었음을 의미한다.

Y′CbCr 색 공간은 관련 RGB 원색 및 화이트 포인트로부터의 수학적 좌표 변환으로 정의된다. 기본 RGB 색 공간이 절대적이라면 Y′CbCr 색 공간도 절대 색 공간이며, 반대로 RGB 공간이 불완전하게 정의되어 있다면 Y′CbCr도 마찬가지이다. 이 변환은 ITU-T H.273의 식 32, 33에 정의되어 있다.[2]

합리적 근거

[편집]

컬러 텔레비전 이전에 흑백 텔레비전이 널리 사용되었다. 기존 TV 세트와 카메라의 수가 많았기 때문에 새로운 컬러 방송에 대해 어떤 형태의 하위 호환성이 필요했다. 프랑스 엔지니어 조르주 발랑시는 1938년에 RGB 컬러를 루마 및 색차 신호로 전송하는 시스템을 개발하고 특허를 받았다. 이는 기존 흑백 텔레비전이 루마 정보만 처리하고 색차를 무시하여, 본질적으로 컬러 영상 내에 흑백 영상을 패키징하도록 허용한다. 이러한 하위 호환성 때문에 발랑시의 아이디어를 기반으로 한 시스템은 호환 컬러라고 불렸다. 마찬가지로, 흑백 방송은 추가 처리 회로 없이도 컬러 텔레비전에서 수신할 수 있었다. 기존 방송 주파수 할당을 보존하기 위해 새로운 색차 정보는 루마 정보보다 낮은 대역폭을 받았다. 이는 인간이 흑백 정보에 더 민감하기 때문에 가능하다(오른쪽 이미지 예시 참조). 이를 크로마 서브샘플링이라고 한다.

YCbCr과 Y′CbCr은 색 처리 및 지각 균일성에 대한 실용적인 근사치이며, 빨간색, 녹색, 파란색에 대략적으로 해당하는 원색이 지각적으로 의미 있는 정보로 처리된다. 이를 통해 후속 이미지/비디오 처리, 전송 및 저장은 지각적으로 의미 있는 방식으로 작업을 수행하고 오류를 도입할 수 있다. Y′CbCr은 고해상도로 저장하거나 고대역폭으로 전송할 수 있는 루마 신호(Y′)와 시스템 효율성 향상을 위해 대역폭을 줄이거나, 서브샘플링하거나, 압축하거나, 다르게 처리할 수 있는 두 개의 색차 구성 요소(CB 및 CR)를 분리하는 데 사용된다.

변환

[편집]

YCbCr은 때때로 YCC로 축약되기도 한다. 일반적으로 Y′CbCr, YCbCr, YPbPr, YUV라는 용어는 서로 혼용되어 사용되어 혼란을 야기한다. 주요 차이점은 YPbPr은 아날로그 이미지에 사용되고 YCbCr은 디지털 이미지에 사용되어, YUV로 변환할 때 Umax 및 Vmax(YCbCr에서는 둘 다 임)에 대해 다른 스케일링 값을 갖는다는 점이다. Y′CbCr과 YCbCr은 감마 보정 여부에 따라 값이 다르다.

아래 방정식은 이러한 형식 간의 공통 원칙과 일반적인 차이점을 더 잘 보여준다.

RGB 변환

[편집]

R'G'B'에서 Y′PbPr로

[편집]
RGB에서 YCbCr로 변환

Y′CbCr 신호(디지털 형태로 신호를 배치하기 위한 스케일링 및 오프셋 전)는 YPbPr이라고 불리며, 다음과 같이 세 가지 정의된 상수 KR, KG, KB를 사용하여 해당 감마 조정 RGB (빨강, 초록, 파랑) 소스에서 생성된다.

여기서 KR, KG, KB는 일반적으로 해당 RGB 공간의 정의에서 파생되며 을 만족해야 한다.

동등한 행렬 조작은 종종 "색 행렬"이라고 불린다.

그리고 그 역은 다음과 같다.

여기서 프라임(′) 기호는 감마 보정이 사용되었음을 의미한다. 따라서 R′, G′, B′는 명목상 0에서 1까지의 범위를 가지며, 0은 최소 강도(검정색 표시 등)를, 1은 최대 강도(하양색 표시 등)를 나타낸다. 결과 루마(Y) 값은 명목상 0에서 1까지의 범위를 가지며, 색차(PB 및 PR) 값은 명목상 -0.5에서 +0.5까지의 범위를 가진다. 역 변환 과정은 위 방정식을 역으로 적용하여 쉽게 유도할 수 있다.

Y′PbPr에서 Y′CbCr로

[편집]

신호를 디지털 형태로 표현할 때, 결과는 스케일링되고 반올림되며 일반적으로 오프셋이 추가된다. 예를 들어, Y′ 구성 요소에 사양(예: MPEG-2[3])에 따라 적용되는 스케일링 및 오프셋은 8비트 표현을 사용할 때 검은색의 경우 16, 흰색의 경우 235의 값을 생성한다. 표준은 CB 및 CR의 8비트 디지털화된 버전을 16에서 240 범위로 스케일링한다. 결과적으로 YCbCr 공간에서 색 행렬 또는 처리를 수행할 때 (235-16)/(240-16) = 219/224의 비율로 다시 스케일링해야 하는 경우가 있으며, 이는 후속 처리가 더 높은 비트 심도를 사용하여 수행되지 않을 경우 양자화 왜곡을 초래한다.

입력 데이터의 공칭 범위를 표현하는 데 바람직할 수 있는 것보다 작은 범위의 디지털 값을 사용하게 하는 스케일링은 바람직하지 않은 클리핑을 필요로 하지 않고 처리 중에 일부 "오버슈트"와 "언더슈트"를 허용한다. 이 "헤드룸" 및 "토룸"[4]XvYCC에 의해 지정된 공칭 색 색역의 확장을 위해서도 사용될 수 있다.

235 값은 최대 오버슈트 (255 - 235) / (235 - 16) = 9.1%를 수용하는데, 이는 최대 (검은색에서 흰색까지) 단계의 이론적 최대 오버슈트(깁스 현상) 약 8.9%보다 약간 크다. 토룸은 더 작아서 16 / 219 = 7.3%의 오버슈트만 허용하며, 이는 이론적 최대 오버슈트 8.9%보다 적다. 또한, HDMI에서는 값 0과 255가 예약되어 있으므로 실제 사용 가능한 공간은 약간 더 적다.

Y′CbCr에서 XvYCC로

[편집]

Y′CbCr을 정의하는 방정식은 전체 공칭 RGB 색상 큐브를 회전시키고 더 큰 YCbCr 색상 큐브에 맞도록 스케일링하는 방식으로 구성되므로, Y′CbCr 색상 큐브 내에는 해당 RGB 도메인(최소한 공칭 RGB 범위 내에서는)에서 표현할 수 없는 일부 지점이 존재한다. 이는 일부 Y′CbCr 신호를 올바르게 해석하고 표시하는 방법을 결정하는 데 어려움을 야기한다. 이러한 범위 외 Y′CbCr 값은 XvYCC에서 BT.709 색역 외부의 색상을 인코딩하는 데 사용된다.

ITU-R BT.601 변환

[편집]

디지털 구성 요소 비디오와 함께 사용하기 위한 ITU-R BT.601 (이전 CCIR 601) 표준에 정의된 디지털 표준 텔레비전에 사용되는 Y′CbCr 형식은 해당 RGB 공간(ITU-R BT.470-6 시스템 M 원색)에서 다음과 같이 파생된다.

위의 상수와 공식을 통해 ITU-R BT.601에 대해 다음을 유도할 수 있다.

아날로그 R'G'B'에서 아날로그 YPbPr은 다음과 같이 파생된다.

디지털 Y′CbCr(샘플당 8비트)은 아날로그 R'G'B'에서 다음과 같이 파생된다.

또는 간단히 구성 요소별로

결과 신호는 Y′의 경우 16에서 235까지(Cb 및 Cr은 16에서 240까지) 범위에 있다. 0에서 15까지의 값은 푸트룸(footroom)이라고 불리며, 236에서 255까지의 값은 헤드룸(headroom)이라고 불린다. Y와 Cb, Cr에 대해 다른 양자화 범위가 BT.2020 및 BT.709에도 동일하게 적용된다.

또는, 디지털 Y′CbCr은 디지털 R'dG'dB'd (샘플당 8비트, 각 비트가 전체 범위 사용, 0은 검정색, 255는 흰색)에서 다음 방정식에 따라 파생될 수 있다.

아래 공식에서 스케일링 계수는 가 곱해진다. 이는 분모에 256 값을 허용하여 단일 비트 시프트로 계산할 수 있게 한다.

만약 R'd G'd B'd 디지털 소스에 푸트룸과 헤드룸이 포함되어 있다면, 먼저 각 신호에서 푸트룸 오프셋 16을 빼야 하며, 방정식에 의 스케일 팩터가 포함되어야 한다.

역변환은 다음과 같다.

반올림 없는 역변환(ITU-R BT.601 권고에서 직접 가져온 값 사용)은 다음과 같다.

이러한 형태의 Y′CbCr은 주로 구형 디지털 표준 텔레비전 시스템에 사용되는데, 이는 구형 CRT의 형광체 방출 특성에 맞는 RGB 모델을 사용하기 때문이다.

ITU-R BT.709 변환

[편집]
Rec. 709Rec. 2020 비교

다른 형태의 Y′CbCr은 ITU-R BT.709 표준에 지정되어 있으며, 주로 HDTV 사용을 위한 것이다. 이 새로운 형태는 일부 컴퓨터 디스플레이 지향 응용 프로그램에서도 사용되는데, SRGB가 그렇다(sRGB 형태의 YCbCr에 사용되는 행렬인 sYCC는 여전히 BT.601이다). 이 경우 Kb와 Kr 값은 다르지만, 이들을 사용하는 공식은 동일하다. ITU-R BT.709의 경우 상수는 다음과 같다.

이 형태의 Y′CbCr은 새로운 CRT 및 기타 현대 디스플레이 장비의 형광체 방출 특성에 더 밀접하게 맞는 RGB 모델을 기반으로 한다. BT.709의 변환 행렬은 다음과 같다.

R′, G′, B′ 신호의 정의 또한 BT.709와 BT.601 간에 다르며, 사용 중인 TV 시스템 유형(PAL 및 SECAM과 같은 625라인 또는 NTSC와 같은 525라인)에 따라 BT.601 내에서도 다르며, 다른 사양에서도 추가적으로 다르다. 다양한 설계에서 R, G, B 색도 좌표, 기준 백색점, 지원되는 색역 범위, R, G, B에서 R′, G′, B′를 파생하기 위한 정확한 감마 사전 보정 함수, 그리고 R′G′B′에서 Y′CbCr로 변환할 때 적용되는 스케일링 및 오프셋 정의에 차이가 있다. 따라서 Y′CbCr을 한 형태에서 다른 형태로 올바르게 변환하는 것은 단순히 하나의 행렬을 뒤집고 다른 행렬을 적용하는 문제가 아니다. 실제로 Y′CbCr이 이상적으로 설계될 때, KB 및 KR 값은 RGB 색상 원색 신호의 정확한 사양에서 파생되어, 루마(Y′) 신호가 감마 보정휘도 측정(일반적으로 CIE 1931 색상 자극에 대한 인간 시각 시스템 반응 측정 기반)에 최대한 가깝게 일치하도록 한다.[5]

ITU-R BT.2020 변환

[편집]

ITU-R BT.2020 표준은 BT.709와 동일한 감마 함수를 사용한다. 이 표준은 다음을 정의한다.[6]

  • 이전 항목과 유사하지만 다른 KBKR를 가진 비정상 휘도 Y'CbCr.
  • 정적 휘도 Y'cCbcCrc. Y'는 실제 휘도의 감마 코덱 버전이다.[6]

두 경우 모두 원색에서 파생된 계수는 다음과 같다.

NCL의 경우, 정의는 고전적이다. ; ; . 인코딩 변환은 평소처럼 행렬로 작성할 수 있다.[6] BT.2020-NCL의 디코딩 행렬은 소수점 이하 14자리까지 다음과 같다.

행렬 내의 작은 값들은 반올림되지 않았다. 이들은 정밀한 값이다. 정밀도가 제한된 시스템(예: 8비트 또는 10비트)의 경우, 소수점 이하 6자리만 유지하는 것과 같이 위 행렬의 낮은 정밀도를 사용할 수 있다.[7]

CL 버전인 YcCbcCrc 코드:[6]

  • . 이것은 선형 RGB에서 계산된 실제 휘도에 감마 함수를 적용한 것이다.
  • (만약 인 경우) 또는 . 는 색역에 해당하는 의 이론적 최소 및 최대값이다. 반올림된 "실제" 값은 , 이다. 전체 유도는 권고사항에서 찾을 수 있다.[6]
  • (만약 인 경우) 또는 . 다시, 은 이론적 한계이다. 반올림된 값은 , 이다.

CL 기능은 휘도 보존이 가장 중요할 때(참조: 크로마 서브샘플링 § 감마 휘도 오류), 또는 "전송을 위한 코딩 효율성 개선이 예상될 때" 사용될 수 있다. 이 사양은 이 문제에 대해 ITU-R BT.2246 보고서를 참조한다.[6] BT.2246은 CL이 압축 효율성과 휘도 보존을 개선했지만, NCL은 이전에 HDTV YCbCr에서 색 혼합 및 기타 생산 작업을 처리했던 직원들에게 더 익숙할 것이라고 명시한다.[8]

BT.2020은 PQ 및 HDR을 정의하지 않는다. 이는 SMPTE ST 2084 및 BT.2100에서 추가로 정의된다. BT.2100은 선형 RGB에서 파생된 좋은 색조 선형성을 가진 반인지적 색 공간인 ICTCP의 사용을 도입할 것이다. 이는 "거의 일정한 휘도"이다.[9]

SMPTE 240M 변환

[편집]

SMPTE 240M 표준(MUSE 아날로그 HD 텔레비전 시스템에 사용됨)은 다음과 같은 계수를 가진 YCC를 정의한다.

계수는 240M 표준에 사용된 SMPTE 170M 원색 및 백색점에서 파생된다.

JPEG 변환

[편집]

JFIFJPEG 사용은 수정된 Rec. 601 Y′CbCr을 지원하며, 여기서 Y′, CB, CR은 [0...255]의 전체 8비트 범위를 갖는다.[10] 아래는 6자리 정밀도로 표현된 변환 방정식이다. (이상적인 방정식은 ITU-T T.871을 참조.[11]) 다음 공식에서 각 입력(R,G,B)의 범위 또한 [0...255]의 전체 8비트 범위임을 참고한다.

그리고 역변환은 다음과 같다.

위 변환은 입력이 sRGB로 주어질 때 sYCC와 동일하다. 단, IEC 61966-2-1:1999/Amd1:2003에서는 소수점 이하 4자리만 제공한다.

JPEG는 또한 어도비의 CMYK 입력을 위한 "YCCK" 형식을 정의한다. 이 형식에서 "K" 값은 그대로 전달되는 반면, CMY는 , , 를 가정하여 위 행렬로 YCbCr을 파생하는 데 사용된다. 결과적으로 유사한 서브샘플링 기법이 사용될 수 있다.[12]

BT.470-6 시스템 B, G 원색에 대한 계수

[편집]

이 계수들은 사용되지 않으며, 결코 사용된 적이 없다.[13]

색도 파생 휘도 시스템

[편집]

H.273은 또한 원색과 백색점에서 엄격하게 파생된 상수 및 비상수 휘도 시스템을 기술하는데, 이는 JPEG의 sRGB/BT.709 기본 원색이 BT.601 행렬(BT.470-6 System M에서 파생됨)을 사용하는 상황이 발생하지 않도록 하기 위함이다.

수치 근사

[편집]

빠른 SIMD 부동소수점 프로세서가 개발되기 전에는 RGB → Y′UV의 대부분의 디지털 구현이 정수 연산, 특히 고정소수점 근사를 사용했다. 근사치는 사용되는 숫자(입력 데이터, 출력 데이터 및 상수 값)의 정밀도가 제한되어 있으며, 따라서 일반적으로 계산 속도 향상과 맞바꾸어 마지막 이진 숫자에 대한 정밀도 손실이 허용된다는 것을 의미한다.

Y′ 값은 관습적으로 필터링으로 인한 신호 오버슈트("링잉")를 수용하기 위해 전체 범위 [0, 255]("PC 레벨" 또는 "풀 스윙"이라고 함)를 사용하는 대신 [16, 235] 범위("스튜디오 스윙" 또는 "TV 레벨"이라고 함)로 이동 및 스케일링된다.[14] 양수 또는 음수일 수 있는 U 및 V 값은 항상 양수가 되도록 128과 더해져 U 및 V에 대해 16–240의 스튜디오 범위를 제공한다. (이러한 범위는 비디오 편집 및 제작에서 중요하다. 잘못된 범위를 사용하면 "클립된" 검은색과 흰색이 있는 이미지 또는 저대비 이미지가 생성되기 때문이다.)

BT.601에 대한 근사 8비트 행렬

[편집]

이 행렬은 모든 인수를 가장 가까운 1/256 단위로 반올림한다. 결과적으로, 각 구성 요소에 대해 하나의 16비트 중간 값만 형성되며, 반올림을 포함한 간단한 오른쪽 시프트 (x + 128) >> 8가 나눗셈을 처리할 수 있다.[14]

스튜디오 스윙의 경우:

풀 스윙의 경우:

구글의 스키아는 과거에 위 8비트 풀 레인지 행렬을 사용하여, 안드로이드 기기에서 인코딩된 JPEG 이미지에 약간의 녹색 효과를 일으켰으며, 반복 저장 시 더 눈에 띄었다. 이 문제는 2016년에 더 정확한 버전이 사용되면서 해결되었다. libjpeg-turbo의 SIMD 최적화 덕분에, 정확한 버전이 실제로 더 빠르다.[15]

팩된 픽셀 형식 및 변환

[편집]

RGB 파일은 일반적으로 픽셀당 8, 12, 16 또는 24비트로 인코딩된다. 이 예시에서는 픽셀당 24비트를 가정하며, 이는 RGB888로 작성된다. 표준 바이트 형식은 단순히 r0, g0, b0, r1, g1, b1, ...이다.

YCbCr 팩된 픽셀 형식은 종종 "YUV"라고도 불린다. 이러한 파일은 픽셀당 12, 16 또는 24비트로 인코딩될 수 있다. 서브샘플링에 따라 형식은 크게 4:4:4, 4:2:2, 4:2:0p로 설명될 수 있다. Y 뒤의 아포스트로피는 종종 생략되며, YUV420p 뒤의 "p"(planar를 의미)도 생략된다. 실제 파일 형식 측면에서 4:2:0이 가장 일반적인데, 데이터가 더 축소되고 파일 확장자는 일반적으로 ".YUV"이다. 데이터 속도와 샘플링(A:B:C) 간의 관계는 Y 대 U 및 V 채널의 비율로 정의된다.[16][17] 세 숫자가 뒤따르는 "YUV" 표기법은 모호하다. 세 숫자는 서브샘플링(예: "YUV420")을 나타낼 수도 있고, 각 채널의 비트 심도(예: "YUV565")를 나타낼 수도 있다. 이러한 형식을 명확하게 참조하는 방법은 FourCC 코드를 통하는 것이다.[18]

RGB에서 YUV로 또는 그 반대로 변환하려면 RGB888 및 4:4:4를 사용하는 것이 가장 간단하다. 4:1:1, 4:2:2, 4:2:0의 경우 먼저 바이트를 4:4:4로 변환해야 한다.

4:4:4

[편집]

4:4:4는 픽셀 그룹화가 없으므로 간단하다. 차이점은 각 채널에 주어진 비트 수와 그 배열 방식에만 있다. 기본 YUV3 방식은 픽셀당 3바이트를 사용하며, 순서는 y0, u0, v0, y1, u1, v1이다("u"는 Cb, "v"는 Cr에 사용되며, 아래 내용에도 동일하게 적용된다).[18] 컴퓨터에서는 AYUV 형식이 더 흔히 사용되는데, 이는 알파 채널을 추가하고 a0, y0, u0, v0, a1, y1, u1, v1과 같은 순서를 따르는데, 32비트 그룹을 처리하기가 더 쉽기 때문이다.[16]

4:2:2

[편집]

4:2:2는 각 개념적인 "컨테이너"에서 2개의 픽셀을 수평으로 함께 그룹화한다.[17] 두 가지 주요 배열은 다음과 같다.

  • YUY2: YUYV라고도 불리며, y0, u, y1, v 형식으로 실행된다.
    YUY2 형식
  • UYVY: YUY2의 바이트 스왑된 역순이며, u, y0, v, y1 형식으로 실행된다.

4:1:1

[편집]

4:1:1은 거의 사용되지 않는다. 픽셀은 가로로 4개씩 그룹화된다.[17]

4:2:0

[편집]

4:2:0은 매우 흔하게 사용된다. 주요 형식은 IMC2, IMC4, YV12, NV12이다.[17] 이 네 가지 형식은 모두 "평면형(planar)"으로, Y, U, V 값이 분산되지 않고 함께 그룹화된다. 8비트 채널을 가정할 때, 이들은 모두 픽셀당 12비트를 차지한다.

  • IMC2는 먼저 Y로 전체 이미지를 펼친다. 그런 다음 각 색차 라인을 V0 ... Vn, U0 ... Un 순서로 배열하는데, 여기서 n은 라인당 색차 샘플 수이며, Y 너비의 절반과 같다.
  • IMC4는 IMC2와 유사하지만, U0 ... Un, V0 ... Vn 순서로 실행된다.
  • I420은 더 간단한 설계이며 더 흔하게 사용된다. Y의 전체 이미지가 쓰여지고, 이어서 U의 이미지, 그리고 V의 전체 이미지가 쓰여진다.
    I420 레이아웃
  • YV12는 I420과 동일한 일반적인 설계를 따르며, U 및 V 이미지 간의 순서만 뒤바뀐다.[19]
  • NV12는 8비트 4:2:0 형식 중 가장 흔하게 사용될 수 있다. 안드로이드 카메라 미리보기의 기본값이다.[20] Y의 전체 이미지가 쓰여지고, 이어서 U0, V0, U1, V1 등과 같이 인터리브된 라인이 이어진다.

평면형 형식의 "타일형" 변형도 있다.[21]

각주

[편집]
  1. “YUV, YCbCr, YPbPr colour spaces”. 《DiscoveryBiz.Net》. 2024. 2021년 4월 16일에 확인함. 
  2. “H.273: Coding-independent code points for video signal type identification”. 《www.itu.int》. 2025년 1월 6일에 확인함. 
  3. e.g. the MPEG-2 specification, ITU-T H.262 2000 E pg. 44
  4. “MFNominalRange (mfobjects.h) - Win32 apps” (미국 영어). 《docs.microsoft.com》. 2020년 11월 10일에 확인함. 
  5. Charles Poynton, Digital Video and HDTV, Chapter 24, pp. 291–292, Morgan Kaufmann, 2003.
  6. “BT.2020 : Parameter values for ultra-high definition television systems for production and international programme exchange”. 국제전기통신연합. June 2014. 2014년 9월 8일에 확인함. 
  7. “ITU-T H Suppl. 18”. October 2017. hdl:11.1002/1000/13441. 
  8. “BT.2246-8 (03/2023) The present state of ultra-high definition television”. 《ITU》. 
  9. “Subsampling in ICtCp vs YCbCr” (PDF). Dolby Laboratories, Inc. 2018년 10월 13일에 원본 문서 (PDF)에서 보존된 문서. 
  10. JPEG 파일 교환 형식 버전 1.02
  11. 《T.871: 정보 기술 – 연속 톤 정지 이미지의 디지털 압축 및 코딩: JPEG 파일 교환 형식 (JFIF)》. ITU-T. 2012년 9월 11일. 2016년 7월 25일에 확인함. 
  12. See libjpeg-turbo documentation for: CS_YCCK 'YCCK (AKA "YCbCrK") is not an absolute colorspace but rather a mathematical transformation of CMYK designed solely for storage and transmission', cmyk_ycck_convert(); see
  13. “EBU Tech 3237 Supplement 1” (PDF). 18쪽. 2021년 4월 15일에 확인함. 
  14. 잭, 키스 (1993). 《영상 완전 해부》. HighText Publications. 30쪽. ISBN 1-878707-09-4. 
  15. “Use libjpeg-turbo for YUV->RGB conversion in jpeg encoder · google/skia@c7d01d3” (영어). 《GitHub》. 
  16. msdn.microsoft.com, YUV 비디오 서브타입
  17. msdn.microsoft.com, 비디오 렌더링을 위한 권장 8비트 YUV 형식
  18. “2.7.1.1. 팩된 YUV 형식 — 리눅스 커널 문서”. 《docs.kernel.org》. 
  19. “비디오LAN 위키: YUV”. 《wiki.videolan.org》. 
  20. fourcc.com YUV 픽셀 형식
  21. “2.7.1.2. 평면형 YUV 형식 — 리눅스 커널 문서”. 《docs.kernel.org》. 

외부 링크

[편집]

팩된 픽셀을 위한 소프트웨어 자료: