JPEG XL 반대론: 손실 압축에서 최신 인코더에 밀리고 무손실 이득도 11.9%뿐
- 압축 엔지니어 Gianni Rosato가 JPEG XL 반대 글을 올림. 손실 압축에서 libjxl이 AV1 계열 인코더와 자체 Aperture 대비 CVVDP·MS-SSIM·SSIMULACRA2 지표 모두 크게 뒤짐
- 무손실 우위도 손실 WebP 대비 약 11.9% 작은 수준이고, 1억5700만 화소 사진·1000만 화소 일러스트 등 웹과 동떨어진 데이터셋에서 나온 수치라 새 코덱을 브라우저에 넣을 근거가 약하다고 봄
- JPEG XL은 방향성 예측 모드가 없어 2x2에서 256x256 VarDCT 블록을 주변 화소로 예측하는 WebP 같은 블록 기반 코덱보다 압축 엔지니어 입장에서 불리함
- HN 댓글에서 JPEG XL의 소수 계산 데모가 2KB 이미지로 Finder 미리보기에서 모든 CPU 코어와 4GB RAM을 15초간 점유하는 DoS로 재현됨
- 카메라 제조사 지원은 HEIF에 몰려 있고 JPEG XL을 지원하는 카메라는 사실상 없음. Apple이 HEIC 대신 JXL로 갈 이유는 특허 문제뿐이라는 지적
Hacker News opinions
글쓴이임. 질문 있으면 뭐든 받음
무손실은 WebP 때문에 제외했다는데 WebP 무손실은 8비트 RGB만 쓰지 않나? 무손실은 확장자를 따로 두는 게 덜 헷갈리더라
하나는 오픈이고 하나는 아니라는 점에 가중치를 둬야 하는 거 아님? 아, AVIF가 AV1 기반이구나. 계속 HEIF인 줄 알았음. 철회. 좋은 글
JXL이 가장 잘 맞는 용도가 뭐라고 보나? 다른 포맷 대비 어디서 아직 강한지 궁금함
브라우저가 JXL을 못 열면 카메라 제조사나 프로 편집 도구도 안 쓸 텐데. 엄마한테 아기 사진 이메일로 보내는 시나리오에서 결국 사진이 안 보인다로 끝남
CVVDP 그래프가 너무 불친절함. X축이 인코딩 속도인지 디코딩 속도인지, Y축은 높을수록 좋은지, Aperture가 뭔지 설명이 없음
요즘 AVIF 인코더는 쓰기 편한가? libjxl은 만화처럼 고주파가 심한 입력도 설정 하나로 그럭저럭 뽑아줘서 좋았음
AV1 특허 문제, Sisvel/Access Advance나 Dolby 대 Snap 같은 게 AVIF 대 JXL 비교를 바꾸나?
세상이 달라야 한다는 게 현실을 최적화하지 않을 변명이 된다는 문단 좋았음. 사람들이 저 마지막 문장을 자주 잊더라
JPEG 클래식은 텍스트랑 샤프한 경계도 크로마 서브샘플링만 챙기면 잘 나옴. 새 포맷들보다 계속 우세할 거라고 봄
이건 순수 기술이 아니라 한 회사의 디코더 독점을 깨려는 거 아님? 엔지니어링은 졌지만 모두를 만족시키는 쪽으로 간 승리지
AVIF는 로열티 없고 구글이 아닌 구현도 있음. SVT-AV1이 libaom을 이기고 메타, 넷플릭스, 인텔이 같이 만들었음
프로그레시브 AVIF 대 JXL 비교가 의외였음. Chrome에서 AVIF는 8KB 베이스 레이어 뜨고 270KB까지 아무것도 없다가 한 번에 뜨는데, JXL은 95KB에서 이미 훨씬 좋아 보임
내 사진은 다 HEIC인데 그냥 쓰면 안 되나? 대형 플랫폼이 하루에 쏘는 이미지 수를 보면 비트 절약 이득이 큼. HEIC는 특허가 지저분해서 윈도우 코덱도 $0.99에 팔더라
JXL 소수 계산 데모는 진짜 DoS였음. Finder 미리보기 켜두고 선택만 했는데 2KB 이미지로 15초간 모든 코어랑 4GB RAM을 먹었음. 포맷이 이렇게 유연해도 되나 싶지만 인상적이긴 함
포맷에 유연성이 너무 많으면 사람들은 처음 해결한 용도 하나에만 쓰고 나머지 기능은 무시하게 됨. MP4도 다중 스트림, 자막, 메뉴 같은 걸 다 넣었지만 아무도 안 씀
JXL이 웹에서 안 되면 카메라나 프로 도구가 채택할까? 웹 퍼블리셔마다 트랜스코딩하는 비용을 상쇄할 만한 이점이 거기 있나 싶음