Chromium이 JpegXL을 병합함
(chromium-review.googlesource.com)- Chromium 코드베이스에 JpegXL 디코더가 통합되어, 브라우저가 JXL 포맷 이미지를 처리할 수 있게 됨
- 변경 사항은 Gerrit 코드 리뷰 페이지에서 “Wire up JXL decoder” 라는 제목으로 확인 가능
- 이 병합은 JpegXL 포맷 지원을 위한 핵심 단계로, 디코더 연결 작업이 포함됨
- 코드 리뷰는 Chromium의 src 저장소 내 변경사항(7184969) 으로 등록됨
- 웹 브라우저의 차세대 이미지 포맷 지원 확대라는 점에서 의미가 있음
Chromium의 JpegXL 디코더 통합
- Gerrit 코드 리뷰 항목 “Wire up JXL decoder (7184969)” 는 Chromium 프로젝트에 JpegXL 디코더를 연결하는 변경사항임
- 이 변경은 Chromium의 src 저장소 내에서 수행됨
- 코드 리뷰 플랫폼은 chromium-review.googlesource.com을 사용함
- 제목 그대로, JXL(JpegXL) 디코더를 브라우저 내부에 연결(wire up) 하는 작업을 의미함
- 페이지에는 추가 설명이나 코드 세부 내용은 표시되지 않음, 단순히 변경 제목만 확인 가능
기술적 맥락
- JpegXL은 차세대 이미지 압축 포맷으로, 기존 JPEG 대비 효율 향상을 목표로 함 (원문 내 직접 언급 없음, 단 기술명만 존재)
- Chromium에 디코더가 병합됨으로써, JXL 이미지 처리 기능이 코드 수준에서 활성화될 기반이 마련됨
- 이 변경은 브라우저 엔진의 미디어 디코딩 체계 확장과 관련된 기술적 진전임
문서 상태
- 페이지는 Gerrit 코드 리뷰의 캐시된 스냅샷으로 표시됨
- “shadow DOM이 숨겨져 있다”는 경고 문구가 포함되어 있으나, 실제 코드 내용은 표시되지 않음
- 따라서 본 문서에서 확인 가능한 정보는 변경 제목과 리뷰 식별자(7184969) 뿐임
Hacker News 의견들
-
Cloudinary 블로그 글을 봤는데, webp, jpegxl, avif, jpeg 등을 비교한 오래된 명작 글임
차트가 잘 정리되어 있고, AVIF는 매우 느림 -
jxl-rs 라이브러리는 JPEG XL의 Rust 구현체임
비교적 새 프로젝트지만 Rust 덕분에 보안 안정성 면에서 안심이 됨
예전 Chromium 논의 때는 이 라이브러리가 없었음- Google이 JPEG XL을 거부한 이유가 ‘관심 부족’ 때문이었던 걸로 기억함. 보안 문제 때문은 아니었던 듯함
- “Rust가 보안 걱정을 덜어준다”는 말에 동의하지 않음. 메모리 안전성은 보안 그 자체가 아님
Rust가 과신을 불러올 수 있고, 위협 모델링을 생략하는 경우가 생김
오히려 주의 깊은 C 프로그래머가 더 안전할 수도 있음 - 실제로 unsafe 코드가 얼마나 있는지 확인해봤음
검색 결과 링크
-
최근 WebP와 AVIF를 비교해봤는데, WebP는 거의 즉시 인코딩되는 반면 AVIF는 1MP 이미지에 20초 이상 걸림
JXL은 아직 지원이 적어서 실제로는 못 쓰지만, WebP 수준의 속도에 더 나은 품질을 기대함- rav1e는 업데이트가 수년째 멈춘 상태라서 aom이나 svt-av1 같은 인코더를 쓰는 게 낫다고 함
- AVIF는 CPU 사용 파라미터를 조정해야 함. 기본 설정이 너무 높은 CPU 레벨을 써서 느림
내 환경에서는 2MP AVIF를 100ms 정도에 생성함
-
JPEG XL의 공개 명세(spec) 가 자유롭게 접근되지 않는 게 아쉬움
- 비공개 표준을 유지하는 건 부끄러운 일이라고 생각함
- ISO, IEC 같은 기관의 수많은 문서가 유료 벽(paywall) 뒤에 있는 현실이 문제임
-
또 하나의 새 이미지 포맷을 받았는데, 결국 변환 없이는 못 쓰는 상황이 반복될까 걱정됨
- 그래도 Microsoft조차 JPEG XL 애드온을 냈고, Google이 물러난 지금은 진짜 기회가 있다고 봄
Microsoft Store 링크 - 실제로는 이미 많은 앱이 지원함 — Affinity, Photoshop, Microsoft Photos, Gimp, 그리고 iOS 17+/macOS 12+의 시스템 전역 지원까지 있음
Chromium이 오히려 늦은 편임 - 물론 새로운 포맷은 항상 10년 정도의 도입 기간이 필요함
- 그래도 Microsoft조차 JPEG XL 애드온을 냈고, Google이 물러난 지금은 진짜 기회가 있다고 봄
-
위키에서 본 JPEG XL의 기능 목록을 읽어보니, 다중 채널 이미지나 멀티페이지 문서 같은 흥미로운 기능이 있음
좋은 점도 있지만, 점점 TIFF처럼 복잡해지는 느낌임 -
JPEG과 JPEG-XL 사이에는 여전히 많은 공통점이 있음
새 구현체가 기존 JPEG 지원까지 통합하면 코드 크기 절감이 가능하지 않을까 궁금함- 실제로 그 기능을 위한 이슈가 JPEG-XL Rust 저장소에 열려 있음
이슈 #513 링크
- 실제로 그 기능을 위한 이슈가 JPEG-XL Rust 저장소에 열려 있음
-
개인적으로는 WEBP처럼 새로운 포맷보다 기존 JPEG을 계속 쓰려 함
대부분의 프로그램이 지원하고, 일반 사용자에게는 JPEG + PNG면 충분함
간단한 애니메이션은 GIF, 복잡한 건 영상으로 처리하면 됨- “JPEG XL”은 이름과 달리 단순히 JPEG 확장판이 아님
PNG보다 작은 용량으로 무손실 인코딩이 가능하고, 기존 JPEG을 20% 더 압축하면서 복원 가능한 트랜스코딩도 지원함
HDR, 와이드 감마, 점진적 로딩 등 다양한 기능이 있어 웹 전송에도 이상적임
jpegxl.info 참고 - WebP는 이제 사실상 표준 포맷으로 봐도 됨
Safari 14 이후 모든 주요 브라우저가 지원하고, Windows 10·macOS Big Sur 이후 기본 탑재됨
지원 현황, 소프트웨어 목록 참고 - GIF는 이제 비효율적임. 동영상으로 대체하는 게 5~10배 효율적임
관련 글
- “JPEG XL”은 이름과 달리 단순히 JPEG 확장판이 아님
-
JPEG XL, WebP, AVIF 논쟁을 오래 들어왔지만 잘 몰랐음
벤치마크를 보면 JpegXL이 WebP보다 압축 속도와 크기 모두 우수한데, 왜 Chromium은 채택을 주저했는지 궁금함- WebP와 AVIF는 VP8/AV1과 코드가 공유되어 브라우저 통합이 쉬움, 반면 JPEG-XL은 별도 코드베이스라 구현 부담이 큼
또한 libjxl은 C++ 10만 줄이 넘는 코드라 보안 취약점 위험이 있었음
Rust 구현이 성숙해지면서 Chrome이 다시 검토하는 듯함 - JPEG XL은 점진적 디코딩을 지원함
데모 영상 - Google은 “비슷한 포맷이 여러 개면 보안 위험만 늘어난다”며 AVIF 하나면 충분하다고 주장했음
- AVIF는 낮은 bpp(저화질)에서는 좋지만 무손실은 약함, 반면 JXL은 고화질·무손실에서 강함
- 과거 JPEGXL C++ 라이브러리가 유지보수 중단 상태였는데, Rust 버전이 등장하면서 브라우저 채택이 가능해졌음
- WebP와 AVIF는 VP8/AV1과 코드가 공유되어 브라우저 통합이 쉬움, 반면 JPEG-XL은 별도 코드베이스라 구현 부담이 큼
-
JPEG XL이 애니메이션을 지원하는지 궁금했음
- 지원은 하지만 프레임 간 압축이 없어 비효율적이라 일반 영상보다 용량이 큼
- Chrome 플랫폼 상태 페이지에 따르면 애니메이션, HDR, 점진적 디코딩 모두 지원함
상세 링크 - 실제로 Canary 브라우저에서 테스트했더니 애니메이션이 잘 작동했음
- 누군가 농담처럼 말하길, WebP는 사실상 “비디오 포맷인 이미지”인데, JPEG XL은 “이미지 포맷인 비디오”라서 역설적인 대칭 구조가 생겼다고 함 😄
