색 관리 시스템

같은 숫자, 다른 색

RGB 값은 “빨강 채널을 최대로 켜라”는 장치 의존 값(device-dependent values)이다. 그 결과로 나오는 빛의 3자극치는 원색의 분광 분포, 백색점, 전달 함수에 따라 달라진다. 5장에서 원색 xy와 백색점으로 RGB→XYZ 행렬을 유도했다. 같은 (1, 0, 0)을 서로 다른 공간의 행렬에 넣으면 아래 표처럼 완전히 다른 색이 된다.

표 16-1. 같은 숫자 (1, 0, 0)이 다섯 공간에서 나타내는 색. 모두 이 장의 핵심인 ICC 프로파일 연결 공간(PCS: D50 XYZ, 2° 관측자)으로 옮겨 비교했다. sRGB 빨강과 Display P3 빨강의 차이는 ΔE00 = 7.1로, 인쇄 허용차(ΔE00 1~3)의 두세 배다. Adobe RGB 빨강은 xy 색도가 sRGB와 같지만 Y가 0.2225 대신 0.3111이다. 백색을 맞추느라 원색의 상대 휘도 배분이 달라졌기 때문이다.

장치마다 숫자의 의미가 다르니, 장치 A의 숫자를 장치 B에서 같은 색으로 재현하려면 변환이 필요하다. 입력 장치 N종과 출력 장치 M종이 있을 때 모든 쌍에 대해 변환을 따로 만들면 N×M개가 필요하다. 대신 모든 장치를 하나의 장치 독립 공간(Profile Connection Space, PCS)에 연결해 두면 장치마다 “나 ↔ PCS” 변환 하나씩, 총 N+M개면 된다. 이것이 ICC 색 관리의 전부라고 해도 과언이 아니다.

ICC 프로파일의 구조

ICC(International Color Consortium)는 1993년 결성된 업계 컨소시엄으로, 프로파일 파일 형식을 ICC.1 규격으로 정한다. 현재 판은 ICC.1:2022(프로파일 버전 4.4)이며 그 이전 판(4.3)은 ISO 15076-1:2010으로도 발행되었다. 지금도 많은 파일이 쓰는 v2(2.1~2.4) 프로파일과 v4는 구조는 같지만 몇몇 규칙이 다르다.

프로파일 연결 공간(PCS)

PCS는 두 가지 인코딩 중 하나다. PCSXYZ는 CIE 1931 XYZ, PCSLAB는 CIELAB이며 둘 다 다음 조건을 공유한다.

• 관측자: CIE 1931 2° 표준 관측자(3장).
• 조명/백색: D50. 헤더의 PCS 광원 필드는 XYZ = (0.9642, 1.0000, 0.8249)로 고정이다(s15Fixed16 고정소수 인코딩 값).
• 상대값: 완전 확산 반사면(또는 매체 백색)의 Y = 1. 즉 PCS의 기본 의미는 매체 상대(media-relative) 측색값이다.
• 관찰 조건: ISO 3664의 그래픽 아트 표준 관찰 조건(D50, 0/45 측정 기하)을 기준으로 한다.

프로파일의 바이트 구조

프로파일 클래스

표 16-2. ICC.1의 프로파일 클래스. 장치 링크는 두 프로파일을 미리 합성한 결과라서 CMYK→CMYK처럼 “검정은 K 하나로만” 같은 장치 수준 제약을 지킬 수 있다. PCS를 거치면 K 정보가 Lab에 녹아 사라지기 때문이다.

행렬/TRC 프로파일과 LUT 프로파일

가산 혼합이 잘 성립하는 디스플레이는 채널별 1차원 곡선(TRC: Tone Reproduction Curve)과 3×3 행렬만으로 정확히 표현된다. 이것이 행렬/TRC(matrix/TRC, matrix-shaper) 프로파일이다. 필요한 태그는 rXYZ·gXYZ·bXYZ(행렬의 세 열), rTRC·gTRC·bTRC(곡선), wtpt(매체 백색), v4에서는 chad(색순응 행렬)다.

프린터처럼 잉크가 겹치며 산란·흡수가 비선형으로 얽히는 장치는 행렬로 설명되지 않는다(17장). 이때는 다차원 룩업 테이블(CLUT)을 쓰는 LUT 프로파일을 쓴다. 인텐트별로 A2B0/A2B1/A2B2(장치→PCS: 지각적/상대 측색/채도)와 B2A0/B2A1/B2A2(PCS→장치)를 따로 둘 수 있다. 절대 측색 인텐트에는 전용 태그가 없다. 상대 측색 태그 결과를 매체 백색(wtpt)으로 스케일해 계산한다.

CMM이 하는 일

CMM은 두 프로파일(또는 여러 개)을 읽어 인텐트에 맞는 태그를 고르고, 필요하면 절대 측색 스케일링과 블랙 포인트 보상을 넣어 하나의 변환으로 합성한다. LittleCMS(lcms2), Apple ColorSync, Windows의 WCS/ICM, Adobe CMM 등이 있다. 성능을 위해 행렬/TRC끼리의 연결은 “곡선 → 하나의 3×3 → 곡선”으로 축약하고, LUT가 끼면 전체 사슬을 새 3D LUT로 미리 샘플링해 두는 것이 보통이다. 이 샘플링이 9절에서 다룰 보간 오차의 근원이다.

왜 D50인가, 그리고 chad 태그

PCS 백색이 D50인 이유는 역사적이면서 실용적이다. 색 관리가 탄생한 그래픽 아트(인쇄·출판) 업계의 표준 관찰 조건이 D50이다. 교정쇄와 인쇄물을 비교하는 관찰 부스는 ISO 3664에 따라 D50 시뮬레이터(P1: 2000 lx, P2: 500 lx)를 쓴다. 인쇄물의 측색값도 관례적으로 D50, 2°로 보고된다(ISO 13655). 그래서 PCS를 D50으로 고정하면 인쇄 측색 데이터는 변환 없이 바로 PCS가 된다.

대신 D65 백색을 가진 디스플레이(sRGB, P3, Rec.709/2020)는 프로파일을 만들 때 한 번 색순응해야 한다. ICC 규약은 “디스플레이의 백색이 PCS의 D50 백색에 대응한다”는 상대 측색 해석을 쓴다. 즉 관찰자가 모니터 백색에 완전히 순응했다고 보고, 모니터 백색 (0.9505, 1, 1.0891)을 D50 백색 (0.9643, 1, 0.8251)로 옮기는 3×3 색순응 변환(CAT)을 원색 행렬에 미리 곱해 둔다. v4는 이 행렬을 chad(chromaticAdaptationTag) 태그에 기록하고, 권장 방법은 선형화된 Bradford 변환이다(8장).

D65 (0.3127, 0.3290) → D50 (0.3457, 0.3585)에 대해 계산하면

변환 체인을 따라가기

행렬/TRC 프로파일 두 개를 잇는 변환은 다음 일곱 단계다. 각 단계가 무엇을 하는지, 어디서 정보가 사라지는지(클리핑) 숫자로 확인해 보자.

여기서 “왕복 오차”는 클리핑과 8비트 반올림을 거친 목적 값을 다시 PCS로 되돌려 원래 색과 비교한 ΔE00이다. 가멋 안의 색은 8비트 반올림만 남아 ΔE00이 0.3 이하이고, 가멋 밖의 색은 클리핑만큼 오차가 커진다. 이 단순한 클리핑이 바로 다음 절에서 볼 상대 측색 인텐트의 기본 동작이다.

렌더링 인텐트

목적 장치의 가멋이 소스보다 작으면 일부 색은 재현할 수 없다. 이를 어떻게 처리할지 정하는 정책이 렌더링 인텐트(rendering intent)다. ICC.1은 네 가지를 정의하지만 각 인텐트의 구체적 알고리즘은 정하지 않는다. 지각적·채도 인텐트의 매핑은 프로파일 제작 소프트웨어가 정해 B2A0/B2A2 테이블에 구워 넣는다. 그래서 같은 프린터라도 프로파일 제작 도구에 따라 지각적 결과가 다르다.

표 16-3. 네 가지 렌더링 인텐트. 괄호 안 숫자는 헤더의 인텐트 코드이자 A2B/B2A 태그 번호다(절대 측색은 1번 태그 + 백색점 스케일링).

백색점과 흑점 처리

인쇄물의 “백색”은 종이다. 고급 코팅지도 L* ≈ 95, b* ≈ −2 정도이고 신문지는 L* ≈ 82로 꽤 어둡다. 상대 측색·지각적·채도 인텐트는 소스 백색을 종이 백색으로 매핑한다(종이에는 잉크를 찍지 않는다). 절대 측색 인텐트는 PCS 값을 매체 백색 비율로 스케일해 원래의 절대 측색값을 재현하려 한다.

흑점도 문제다. 소스(모니터)의 흑색은 L* ≈ 0이지만 인쇄의 가장 진한 검정은 코팅지에서 L* ≈ 10, 비코팅지에서 20 이상이다. 상대 측색으로 그냥 보내면 L*가 출력 흑점보다 어두운 모든 그림자 색이 출력 흑점 하나로 뭉개진다. 블랙 포인트 보상(BPC, Black Point Compensation)은 소스 흑점을 출력 흑점으로 옮기는 선형 스케일을 XYZ에 적용해 이를 막는다. Adobe가 공개한 방식이 ISO 18619로 표준화되었다.

이 모델에서 코팅지 출력은 60개 견본 중 36개가 가멋 밖이고 신문지는 52개가 밖이다. 코팅지 상대 측색의 평균 ΔE00은 약 6.3, 지각적은 약 7.1이다. 지각적이 평균 오차는 더 크지만 그라데이션과 그림자 계조를 지킨다. ΔE 평균이 작다고 좋은 인텐트가 아니라는 점이 핵심이다. 계조가 중요한 사진에는 지각적 또는 “상대 측색 + BPC”가, 로고처럼 특정 색을 정확히 맞춰야 할 때는 상대 측색이 쓰인다.

소프트 프루핑과 가멋 경고

소프트 프루핑(soft proofing)은 인쇄 결과를 종이에 찍기 전에 화면에서 미리 보는 것이다. 원리는 간단하다. 이미지를 출력 프로파일로 보내 CMYK를 얻고(선택한 인텐트), 그 CMYK를 다시 출력 프로파일의 A2B로 PCS로 되돌린 뒤, 모니터 프로파일로 표시한다. 두 번째 단계를 상대 측색으로 하면 종이 백색이 모니터 백색으로 보이고, 절대 측색으로 하면 종이 백색 시뮬레이션이 된다.

종이 백색 시뮬레이션을 켜면 처음에는 화면 전체가 “칙칙하다”고 느낀다. 화면의 최대 백색(모니터 백색)이 이미지 바깥 UI에 남아 있어 눈이 그쪽에 순응하기 때문이다. 실제 인쇄물을 볼 때는 종이 백색에 순응하므로 그렇게 보이지 않는다. 그래서 숙련된 작업자는 이미지 주변을 회색 또는 종이색으로 채운 전체 화면 모드에서 소프트 프루프를 판단한다.

운영체제·브라우저·파일의 색 관리

태그가 없으면 sRGB

웹의 기본 규칙은 단순하다. 색 프로파일이 없는(untagged) 이미지와 CSS의 #rrggbb·rgb() 색은 sRGB로 간주한다(CSS Color 4). 브라우저는 이미지에 내장된 ICC 프로파일이나 코드 포인트(cICP, nclx)를 읽어 디스플레이 프로파일로 변환한다. 그래서 같은 파일이라도 프로파일을 지워 버리면 숫자는 그대로인 채 해석만 sRGB로 바뀐다.

CSS Color 4부터는 sRGB 밖의 색을 직접 지정할 수 있다. color(display-p3 1 0 0), color(rec2020 …), color(a98-rgb …), 그리고 장치 독립 표기인 lab(), oklch()가 있다. 미디어 쿼리 @media (color-gamut: p3)로 화면 가멋을 판별하고, canvas도 getContext("2d", {colorSpace: "display-p3"})로 P3 버퍼를 쓸 수 있다.

운영체제

macOS는 ColorSync로 창 합성 단계에서 모든 앱의 출력을 디스플레이 프로파일로 변환한다. 앱이 색공간을 밝히지 않으면 sRGB로 본다. Windows는 오랫동안 색 관리를 앱 책임으로 두었다. 색 관리를 하지 않는 앱은 sRGB 숫자를 그대로 패널에 보내므로, 광색역(P3·Adobe RGB급) 모니터에서는 같은 숫자가 더 넓은 원색으로 해석되어 과포화된다. 피부가 붉게 뜨고 하늘이 형광처럼 보이는 현상이다. 모니터의 “sRGB 모드”는 패널 내부에서 sRGB 가멋을 흉내 내 이 문제를 피하는 장치이고, 최근 Windows 11은 자동 색 관리(ACM) 옵션을 제공한다.

파일에 프로파일 싣기

JPEG은 APP2 마커의 ICC_PROFILE 세그먼트(64 KB 단위로 분할)에, PNG는 iCCP 청크(또는 sRGB 청크, HDR용 cICP 코드 포인트)에, WebP는 ICCP 청크에, AVIF/HEIF는 colr 박스(ICC 또는 nclx 코드 포인트)에, TIFF는 태그 34675에 프로파일을 싣는다. 코드 포인트(ITU-T H.273의 원색·전달 함수·행렬 번호)는 몇 바이트로 표준 공간을 지정하는 가벼운 방법이고, 영상 코덱(15장)과 HDR(14장)에서 주로 쓴다.

영상·VFX 파이프라인: ACES와 OCIO

ICC는 “장치 → 장치”의 정적 이미지 세계에서 자랐다. 영화·VFX는 여러 카메라의 영상을 합성하고 극장·HDR TV·스트리밍 등 여러 출력에 맞춰 내보내야 해서 다른 체계를 쓴다. 핵심 구분은 다음 두 가지다.

• 장면 기준(scene-referred): 값이 장면의 상대 휘도에 비례한다. 18% 반사 회색 = 0.18, 하이라이트는 1을 훨씬 넘을 수 있다(상한 없음). 합성, 조명, 모션 블러처럼 물리적으로 빛을 더하는 연산은 여기서 해야 맞다.
• 디스플레이 기준(display-referred): 값이 특정 디스플레이(백색 100 cd/m² sRGB, 1000 cd/m² PQ 등)에서 낼 빛을 나타낸다. 범위가 [0, 1]로 닫혀 있고 톤 매핑이 이미 들어 있다. ICC 디스플레이 프로파일은 이 세계에 속한다.

표 16-4. ACES 색공간의 원색. AP0는 스펙트럼 궤적 전체를 감싸도록 잡은 삼각형이라 초록 원색이 y = 1, 파랑 원색이 y < 0인 허수 원색이다. 그래서 AP0에서 직접 합성·조명 연산을 하면 원색 사이 혼합이 지각적으로 어색해진다. AP1은 Rec.2020을 거의 감싸면서 모든 원색이 궤적 근처의 실재 색에 가깝게 잡혀 렌더링 작업 공간에 적합하다. 백색 (0.32168, 0.33767)은 CCT 약 6000 K로 흔히 “D60 근사”라 부르지만 CIE 주광 궤적 위의 점은 아니다.

OpenColorIO 설정

OpenColorIO(OCIO)는 ASWF(Academy Software Foundation)가 관리하는 색 관리 라이브러리로, Nuke, Maya, Blender, Houdini 등이 공통으로 쓴다. ICC가 “장치마다 프로파일 하나”라면 OCIO는 “스튜디오마다 설정 파일 하나”다. YAML 설정에 색공간 목록과 각 색공간 → 기준 공간 변환, 역할(role), 디스플레이·뷰를 정의하고, 모든 앱이 같은 파일을 읽어 같은 변환을 쓴다.

# 개념 예시 (실제 ACES 설정을 크게 축약)
ocio_profile_version: 2
roles:
  scene_linear: ACEScg          # 합성·조명 연산 공간
  color_timing: ACEScct         # 그레이딩 공간
  compositing_log: ACEScct
colorspaces:
  - !<ColorSpace>
    name: ACEScg
    to_scene_reference: !<BuiltinTransform> {style: ACEScg_to_ACES2065-1}
displays:
  sRGB - Display:
    - !<View> {name: ACES SDR, view_transform: …, display_colorspace: …}

“역할”은 앱이 “선형 작업 공간이 뭐지?”라고 물을 때의 답이다. 덕분에 텍스처 페인팅 앱과 렌더러와 합성기가 서로의 내부 사정을 몰라도 같은 공간에서 일한다. 뷰(view)는 장면 기준 데이터를 특정 디스플레이에 보여 주는 출력 변환이다. 원본 데이터는 바꾸지 않고 보는 방식만 바꾼다.

정밀도: 양자화 누적과 3D LUT 보간

색 관리 변환은 수학적으로는 가역이어도 실제로는 두 가지 오차가 생긴다. (1) 각 단계 결과를 8비트·16비트 정수로 저장할 때의 양자화, (2) LUT 격자점 사이를 보간할 때의 보간 오차다.

8비트 왕복 변환

8비트 sRGB 이미지를 8비트 ProPhoto 작업 공간으로 변환했다가 다시 sRGB로 돌아오면 어떻게 될까. ProPhoto는 가멋이 매우 넓어 sRGB 색들이 코드 공간의 일부에만 몰린다. sRGB 빨강 램프 256단계를 ProPhoto에 담으면 빨강이 R′ = 0~192 범위에 들어가 코드 간격이 성기다. 다시 돌아오면 서로 다른 입력이 같은 출력으로 합쳐져 계조가 사라지고(콤 히스토그램), 이것은 되돌릴 수 없다.

3D LUT의 격자와 보간

LUT 프로파일의 CLUT, 그리고 영상 업계의 .cube 3D LUT는 입력 큐브를 \(N\times N\times N\) 격자로 나눠 격자점에서만 정확한 출력을 저장한다. 격자점 사이는 보간한다. 두 방법이 널리 쓰인다.

표 16-5. 시뮬레이터와 같은 계산으로 얻은 3D LUT 보간 오차(ΔE00, 무작위 3,000색). 17³ LUT는 16비트로 29 KB, 33³은 216 KB다. 감마 인코딩 격자라면 17³만으로도 평균 ΔE00 0.04로 인지 한계(약 1) 아래이고, 최대 오차는 sRGB 원색 근처의 급한 곡률에서 나온다. 같은 33³라도 선형광 격자는 최대 4.5로, 격자 배치가 크기보다 중요할 수 있다.