Three.js r187, 색 공간 변환 행렬 순서 수정

다른 원색으로 변환할 때의 오류입니다

한국시간 2026년 10월 30일 공개된 Three.js r187에는 색 공간 변환 행렬의 순서를 바로잡은 수정이 포함됩니다. 중요한 범위는 서로 다른 원색 체계 사이의 GPU 변환입니다. 기본적인 sRGB 경로를 사용하는 모든 화면이 이전부터 잘못 표시됐다는 뜻은 아닙니다.

PR #34952는 r170 이후 서로 다른 원색 간 변환에서 GPU 결과가 잘못될 수 있었다고 설명합니다. CPU 쪽 ColorManagement.convert()와 Color.getRGB()는 올바르게 동작했지만, GPU에 넘기는 행렬 구성과 WebGL 셰이더의 행렬 적용 방향에는 문제가 있었습니다. 따라서 CPU에서 계산한 색이 맞는다고 화면 출력까지 같다고 결론 낼 수 없었습니다.

행렬은 순서를 바꾸면 결과도 바뀝니다

색을 한 원색 체계에서 다른 체계로 옮길 때는 출발 색을 XYZ로 바꾸고, 그 결과를 도착 색 공간으로 변환합니다. 열벡터 기준으로는 도착 공간의 fromXYZ 행렬이 왼쪽, 출발 공간의 toXYZ 행렬이 오른쪽에 와야 합니다. 기존 GPU용 행렬 생성은 이 순서가 뒤집혀 있었습니다.

WebGLProgram에서는 색 벡터와 행렬을 곱하는 방향도 수정됐습니다. 두 문제가 함께 있었으므로 단순히 출력 색의 밝기나 텍스처 값을 조절해 해결할 종류의 오류가 아닙니다. 반면 같은 원색을 유지하는 기본 sRGB 경로는 PR이 설명한 영향 범위에서 제외됩니다.

숫자로 확인한 결과의 범위

작성자는 MeshBasicMaterial의 렌더 결과를 readPixels로 읽고 CPU의 Color.getRGB() 결과와 비교했습니다. 흰색의 Linear-sRGB에서 Display-P3 변환을 예로 들면, 수정 전에는 일부 채널이 기대값보다 낮았지만 수정 후에는 기대한 흰색과 일치했다고 보고합니다. 이 설명은 PR의 검증 결과를 요약한 것이며 직접 측정한 결과는 아닙니다.

특히 WebGPURenderer 관련 측정은 WebGL2 백엔드에서 수행됐습니다. 같은 색 변환 노드가 사용된다는 설명과 네이티브 WebGPU 장치에서 실제 검증했다는 주장은 구분해야 합니다. PR에는 양방향 변환을 확인하는 단위 테스트도 추가됐지만, 그것만으로 모든 디스플레이와 브라우저의 색 표현을 보장하지는 않습니다.

색 보정을 되돌리기 전에 확인하세요

프로젝트에서 검토한다면 사용 중인 작업 색 공간, 출력 색 공간, 렌더러와 백엔드를 먼저 기록해 보세요. 서로 다른 원색 간 변환을 실제로 쓰는지 확인한 다음, 단순한 재질과 알려진 색을 출력해 버전 전후 값을 비교하는 편이 좋습니다. 조명과 후처리까지 한 번에 바꾸면 변환 오류와 연출 차이를 분리하기 어렵습니다.

과거에 색 차이를 상쇄하려고 재질 값을 조정했다면 업데이트 후 결과도 다시 볼 필요가 있습니다. 다만 실제 영향이 확인되지 않은 프로젝트에서 일괄 보정을 지우라는 의미는 아닙니다. 이번 변경은 색 관리 전체를 교체한 기능이 아니라 특정 GPU 변환 경로의 계산 순서를 수정한 것이므로, 자신의 설정과 맞는 범위부터 검증하는 것이 핵심입니다.

출처

• Three.js r187 공식 릴리스
• PR #34952 · 색 변환 행렬 순서와 CPU·GPU 비교