JPEG XL의 덜 알려진 멋진 기능 중 하나는 JPEG에서 무손실로 트랜스코딩하면서 약 20%의 저장 공간 절감을 얻는 모드임
원본 엔트로피 비트스트림을 그대로 유지하기 때문에 완전히 가역적임
GCP가 이를 DICOM Store API에 적용 중이라, JXL의 공간 절약 효과를 누리면서도 JPEG로 실시간 변환해 제공할 수 있음
우리 회사는 수십 PB 규모의 데이터를 GCP DICOM Store에 저장하고 있어서, 이 기능으로 연간 요금을 크게 절감할 수 있을 것으로 기대함
브라우저의 네이티브 지원도 희망 중이며, Chrome 팀이 결국 지원할 것이라는 이야기를 들었음
평균적인 JPEG 인코더나 mozjpeg와 비교했을 때 어떤 차이가 있는지 궁금함
예전에 GCP DICOM Store를 테스트할 시간이 없었는데, 실제로 써보면 어떤지 궁금함
완전한 PACS인지, WADO 구현인지, 아니면 단순한 커스텀 API인지 알고 싶음
가역적이라면 그냥 JPEG XL로 저장하고 서비스 시 다시 변환하면 되는 것 아닌지 궁금함
혹시 처리 시간이 많이 걸리는 것인지 물어봄
어차피 원본 DICOM을 저장해야 한다면, 트랜스코딩의 의미가 있는지 의문임
저장비용의 대부분은 DICOM 자체일 것 같음
결국 GCP의 대형 고객들이 이 기능으로 큰 이익을 보게 되니, Chrome에서 JXL을 밀어붙이는 이유가 내부 고객 때문이라는 생각이 듦
JPEG XL의 경쟁상대는 AVIF가 아님
AVIF는 이미 사실상 표준으로 자리 잡았고, 거의 모든 브라우저가 지원하며, Apple의 기본 이미지 포맷으로도 쓰이고 있음
JXL은 아직 브라우저 지원이 약하지만, 보존용·전문 사진·의료용 등 틈새 시장에서 자리를 잡아가고 있음
10년쯤 후에는 사람들이 그냥 “JPEG”라 부를 정도로 보편화될 수도 있음
AVIF는 오픈·로열티 프리 표준이며, JPEG/WebP보다 압축 효율이 훨씬 높고, JXL과도 비슷한 수준임
JXL의 최대 이미지 크기가 더 크긴 하지만, 실제 채택은 AVIF가 훨씬 앞서 있음
AV2가 나오면 품질 격차는 거의 사라질 것이고, 두 포맷 모두 발전하면서 비슷한 품질 수준을 유지할 것으로 봄
AVIF가 JPEG이나 WebP보다 압축 효율이 좋은 건 당연하지만, JXL과는 경쟁이 안 됨
현실적인 품질 설정에서는 JXL이 더 높은 압축률과 빠른 인코딩·디코딩 속도를 보임
게다가 progressive decoding도 지원함
AV2가 나오면 따라잡을 수도 있겠지만, 지금은 JXL이 훨씬 앞서 있다고 생각함
Chrome 팀이 JXL 지원을 중단했던 이유 중 하나가 이미 AVIF가 충분히 좋았기 때문이었음
이번 재검토가 그때의 결정과 연결된 것 같음
“Apple의 기본 이미지 포맷이 AVIF”라는 말은 잘못된 것 같음
iPhone은 HEIF를 사용함
libjxl을 직접 써봤는데 메모리 사용량이 많고 불안정했음
고해상도 이미지를 인코딩하려면 테라바이트급 RAM이 필요할 정도였음
코드베이스가 엉망이라 놀랐고, 많은 옵션이 제대로 작동하지 않았음
jxl-rs로 다시 시도하는 건 긍정적이지만, 같은 개발자들이 참여하고 있어서 조심스럽게 보고 있음
Chromium이 JPEG XL 기능을 위해 jxl-rs crate를 사용할 가능성이 높음
아마 충분히 안정화될 때까지 기다리다가 통합하려는 듯함
관련 이슈는 여기에서 확인 가능함
Mozilla는 비슷한 입장이었지만, Google은 한동안 적대적 태도를 보였음
사용자들의 반대에도 불구하고 이슈를 닫았고, 최근에야 다시 열었음
아마 PR 문제나 내부 불만 때문일 수도 있음
jxl-rs는 1년 반 넘게 커밋이 없던 시기가 있었음
지금 잘 진행되는 건 운이 좋았던 결과일 수도 있음
JPEG XL의 참조 구현(C++) 을 봤는데, 2년 전만 해도 코드 품질이 좋지 않았음
보안 문제가 생길 것 같은 느낌이었음
그래서 Mozilla와 Google 모두 메모리 안전한 구현체를 조건으로 JXL 지원을 검토 중임
Rust 버전이 개발 중이며, Google은 Chromium의 모든 디코더를 점차 Rust로 교체하려는 계획을 가지고 있음
사실 지금 시점(2025년)에 C++로 작성된 대규모 이미지 처리 코드는 그 자체로 보안 리스크임
JPEG XL만의 문제가 아님
JPEG XL의 최대 해상도는 1,073,741,823 × 1,073,741,824로, 수백 페타바이트에 달하는 초고해상도 이미지를 표현할 수 있음
현실적으로는 압축 후에도 수십~수백 PB 수준임
600DPI 기준으로는 한 변이 마라톤 거리에 해당함
이런 거대한 이미지를 작은 바이트 공간에 정의할 수 있다면 DOS 공격 벡터가 될 수도 있을 것 같음
A4 용지로 환산하려다 Gemini 계산기가 단위를 혼동해서 엉뚱한 결과를 내놨음
이런 초대형 이미지는 타일링과 피라미드 구조로 다루는 것이 유일한 실용적 방법임
지구 전체를 약 4cm 해상도로 찍은 이미지 정도의 크기일 것 같음
그 해상도로 셀피를 찍으면 초해상도 현미경 수준일 듯함
JPEG XL은 AVIF와 달리 효율적인 progressive decoding을 지원해서, 다운로드 중에도 저화질 미리보기를 빠르게 볼 수 있음
나는 몇 년째 .avif를 사용 중임
완벽하진 않지만 .jpg나 .png보다 훨씬 낫다고 느낌
.webp나 jpeg-xl도 고려했지만, 결과적으로 .avif에 만족함
다만 Google이 웹 표준을 사실상 좌지우지하는 건 불만임
상업 기업이 디지털 생태계를 통제하는 건 바람직하지 않음
“.jpg보다 .avif가 낫다”는 문장에서 .avif를 두 번 반복해서 헷갈림
고품질 JPEG를 작게 만들고 싶다면 jpegli를 써보길 추천함 jpegli GitHub
AVIF의 시각적 무손실 설정을 잘 고르면 jpegli보다 작을 수도 있지만, 평균적으로는 jpegli가 더 효율적임
참고로 영어에서는 “since some years”보다 “for several years”가 자연스러움
JPEG XL은 여러 번 재저장해도 품질 손실이 적어서 웹 환경에 유리함
관련 영상: YouTube 링크
JXL을 없앤 건 “Google 전체”가 아니라 Chrome 팀임
JXL은 Google Zurich 연구소의 Jyrki Alakuijala가 설계했는데, 그는 Chrome 팀이 아닌 Google Research 소속임
Chrome 팀은 Mountain View 중심의 폐쇄적 문화를 가지고 있음
Jyrki는 Brotli, WebP lossless, WOFF2, jpegli 등도 만든 뛰어난 엔지니어임
JpegXL이 폐기된 후 jpegli를 만든 것도 일종의 반응이었음
Hacker News 의견
JPEG XL의 덜 알려진 멋진 기능 중 하나는 JPEG에서 무손실로 트랜스코딩하면서 약 20%의 저장 공간 절감을 얻는 모드임
원본 엔트로피 비트스트림을 그대로 유지하기 때문에 완전히 가역적임
GCP가 이를 DICOM Store API에 적용 중이라, JXL의 공간 절약 효과를 누리면서도 JPEG로 실시간 변환해 제공할 수 있음
우리 회사는 수십 PB 규모의 데이터를 GCP DICOM Store에 저장하고 있어서, 이 기능으로 연간 요금을 크게 절감할 수 있을 것으로 기대함
브라우저의 네이티브 지원도 희망 중이며, Chrome 팀이 결국 지원할 것이라는 이야기를 들었음
완전한 PACS인지, WADO 구현인지, 아니면 단순한 커스텀 API인지 알고 싶음
혹시 처리 시간이 많이 걸리는 것인지 물어봄
저장비용의 대부분은 DICOM 자체일 것 같음
JPEG XL의 경쟁상대는 AVIF가 아님
AVIF는 이미 사실상 표준으로 자리 잡았고, 거의 모든 브라우저가 지원하며, Apple의 기본 이미지 포맷으로도 쓰이고 있음
JXL은 아직 브라우저 지원이 약하지만, 보존용·전문 사진·의료용 등 틈새 시장에서 자리를 잡아가고 있음
10년쯤 후에는 사람들이 그냥 “JPEG”라 부를 정도로 보편화될 수도 있음
AVIF는 오픈·로열티 프리 표준이며, JPEG/WebP보다 압축 효율이 훨씬 높고, JXL과도 비슷한 수준임
JXL의 최대 이미지 크기가 더 크긴 하지만, 실제 채택은 AVIF가 훨씬 앞서 있음
AV2가 나오면 품질 격차는 거의 사라질 것이고, 두 포맷 모두 발전하면서 비슷한 품질 수준을 유지할 것으로 봄
현실적인 품질 설정에서는 JXL이 더 높은 압축률과 빠른 인코딩·디코딩 속도를 보임
게다가 progressive decoding도 지원함
AV2가 나오면 따라잡을 수도 있겠지만, 지금은 JXL이 훨씬 앞서 있다고 생각함
이번 재검토가 그때의 결정과 연결된 것 같음
iPhone은 HEIF를 사용함
고해상도 이미지를 인코딩하려면 테라바이트급 RAM이 필요할 정도였음
코드베이스가 엉망이라 놀랐고, 많은 옵션이 제대로 작동하지 않았음
jxl-rs로 다시 시도하는 건 긍정적이지만, 같은 개발자들이 참여하고 있어서 조심스럽게 보고 있음
Chromium이 JPEG XL 기능을 위해 jxl-rs crate를 사용할 가능성이 높음
아마 충분히 안정화될 때까지 기다리다가 통합하려는 듯함
관련 이슈는 여기에서 확인 가능함
사용자들의 반대에도 불구하고 이슈를 닫았고, 최근에야 다시 열었음
아마 PR 문제나 내부 불만 때문일 수도 있음
지금 잘 진행되는 건 운이 좋았던 결과일 수도 있음
JPEG XL의 참조 구현(C++) 을 봤는데, 2년 전만 해도 코드 품질이 좋지 않았음
보안 문제가 생길 것 같은 느낌이었음
Rust 버전이 개발 중이며, Google은 Chromium의 모든 디코더를 점차 Rust로 교체하려는 계획을 가지고 있음
JPEG XL만의 문제가 아님
JPEG XL의 최대 해상도는 1,073,741,823 × 1,073,741,824로, 수백 페타바이트에 달하는 초고해상도 이미지를 표현할 수 있음
현실적으로는 압축 후에도 수십~수백 PB 수준임
이런 거대한 이미지를 작은 바이트 공간에 정의할 수 있다면 DOS 공격 벡터가 될 수도 있을 것 같음
A4 용지로 환산하려다 Gemini 계산기가 단위를 혼동해서 엉뚱한 결과를 내놨음
과거 HN 논의 모음
Chromium Team Re-Opens JPEG XL Feature Ticket
FSF Slams Google over Dropping JPEG-XL in Chrome
Google set to deprecate JPEG XL support in Chrome 110
Chromium jpegxl issue closed as won't fix
나는 몇 년째 .avif를 사용 중임
완벽하진 않지만 .jpg나 .png보다 훨씬 낫다고 느낌
.webp나 jpeg-xl도 고려했지만, 결과적으로 .avif에 만족함
다만 Google이 웹 표준을 사실상 좌지우지하는 건 불만임
상업 기업이 디지털 생태계를 통제하는 건 바람직하지 않음
jpegli GitHub
AVIF의 시각적 무손실 설정을 잘 고르면 jpegli보다 작을 수도 있지만, 평균적으로는 jpegli가 더 효율적임
관련 영상: YouTube 링크
JXL을 없앤 건 “Google 전체”가 아니라 Chrome 팀임
JXL은 Google Zurich 연구소의 Jyrki Alakuijala가 설계했는데, 그는 Chrome 팀이 아닌 Google Research 소속임
Chrome 팀은 Mountain View 중심의 폐쇄적 문화를 가지고 있음
JpegXL이 폐기된 후 jpegli를 만든 것도 일종의 반응이었음
C++ 기반의 멀티스레드 의존성이 많아 보안 공격면이 커질 수 있다는 이유로 JXL이 지연된 것 같음
Mozilla와 Google 모두 이를 피하기 위해 Rust 구현체를 선호함
표준 자체는 확실히 기존보다 개선된 포맷임
AVIF보다 바이너리 크기도 훨씬 작고, 명세서도 훨씬 간결함
iPhone 17 Pro의 RAW 파일은 JPEG XL로 압축된다고 함