Chrome 155, Rust로 다시 짠 디코더로 JPEG XL 지원 시작

이미지 포맷 또 하나 추가되는 거네. xkcd 927이 바로 생각남.

JPEG2000 때처럼 특허랑 라이선스 지옥인 거 아님?

아님. JPEG XL은 공개 표준임.

안전한 코드 짜려고 Rust에 기대야 한다는 게 좀 그렇네.

그게 왜 나쁨?

1비트 per pixel 이하 구간에선 AVIF가 여전히 낫던데. JXL이 그걸 이길 수 있나?

내 경험은 다름. 학회 논문을 아주 작은 썸네일로 압축해봤는데 그 용도로는 JXL이 AVIF보다 훨씬 나았음.

아주 압축된 이미지는 페이지 호스팅 비용 줄이려는 쪽 관심사니까 AVIF가 나을 수도 있음. 근데 고품질 사진에서는 AVIF가 JXL을 못 따라감. 내 사진 보관용으로도, 예쁜 이미지 깔린 웹사이트를 좋게 보는 기준으로도 JXL이 맞음.

Chrome에서 한번 뺐다가 다시 넣는 거 보니 감회가 새롭다. 인기 브라우저가 지원을 안 해서 발목 잡혀 있던 포맷인데, 이제 풀린 셈임.

libjxl 보안 버그 때문이었지. Project Zero가 구글 브라우저팀에 insecure decoder 넣지 말라고 경고했던 걸로 기억함.

구글에서 아무도 이득 못 보니까 뺐다가, 이제 누가 승진하려고 다시 넣은 거 아님?

왜 브라우저가 모든 미디어 포맷을 떠안아야 함? 시스템 공용 라이브러리로 빼서 다 같이 쓰면 안 되나?

구글이 뺐다가 다시 넣은 게 이 스토리의 핵심임. 큰 회사일수록 자존심이 세서 이런 건 쉽지 않은데, 이제 JXL은 남을 듯.

주요 브라우저 전부 지원하고 Firefox도 곧 붙음. 주요 OS도 다 지원함.

다음은 폰이랑 카메라임. 오랜 파편화 끝에 공통 이미지 포맷이 다시 생기면 진짜 좋겠음.

전환점은 Adobe가 차기 PDF 스펙에 JXL을 승인 압축 알고리즘으로 넣은 거였음. 브라우저들이 PDF 렌더러도 하려면 디코더를 어차피 넣어야 했고, 그 디코더를 img 태그에도 노출한 거임.

iOS에서 iPhone 16 이상이 사진을 JXL로 저장할 수 있게 된 것도 한몫했을 듯.

그 이론들 다 과한 추측임. 실제로는 기존 라이브러리 보안 문제 고칠 비용이 아깝다고 버린 건데, 업계 채택이 늘고 안전한 새 라이브러리가 나오면서 결정이 바뀐 거임. 그 Rust 라이브러리도 Chrome 팀이 만든 게 아님.

그건 아닌데. JXL은 스펙, 레퍼런스 구현, Rust 구현까지 다 구글 주도임. 구글 경영진이 왜 막겠음. Chrome 엔지니어들이 크고 당시 채택률 낮고 AVIF·WebP랑 겹친다고 싫어한 거지.

새 포맷 나올 때마다 앱 호환성 위기가 떠오름. Telegram은 아직도 webp를 스티커로 취급하고 macOS도 지원 갱신이 한참 걸림.

윈도우에 HEIC 실수로 옮기면 난리 남. 우리 학교 LMS에 WEBP 올리려다 실패한 학생도 있고.

JXL은 특허 부담이 적고 라이선스도 용도에 맞음. 구현이 복잡한 것 빼면 안 쓸 이유가 없음. 프로그레시브 렌더링 덕에 썸네일을 따로 만들 필요가 없는 게 제일 마음에 듦.