코덱 비교 심사숙고하기

크롬이 JPEG XL 실험을 중단한다는 소식(https://news.hada.io/topic?id=7709)에 이슈 트래커가 왜 지우냐는 질문으로 도배가 되었는데요, 이에 AVIF 측에서 자신들이 비교한 벤치마크 자료를 올려서 항변한 적이 있습니다(https://storage.googleapis.com/avif-comparison/index.html). 이 글은 해당 자료에 대한 분석과 JPEG XL 측의 반론입니다.

단순히 JPEG XL 옹호/반대를 떠나서 이미지 포맷의 비교에 대해서 중요한 점을 짚고 넘어가기 때문에 읽어 볼 만 합니다. 요점만 몇 개 정리하면:

• AVIF 측의 디코딩 속도는 크롬 및 libjxl 옛 버전에 기초하였으며 따라서 과장되어 있다. 최근 버전 기준으로는 JPEG XL (기본 설정) ~= 12비트 AVIF < JPEG XL (빠른 디코딩 설정) ~= 8비트 AVIF < JPEG로부터 재압축한 JPEG XL이고, 각 부등호는 10% 차이 정도 밖에 나지 않음.

• 전체 디코딩 속도보다 사용 가능한 이미지가 어느 시점에 나오느냐가 더 중요하고, JPEG XL은 점진적(progressive) 디코딩을 지원하므로 여기서 큰 잇점을 가진다. (웹에서 Largest Contentful Paint 같은 얘기를 하는 것과 동일한 맥락입니다)

• 인코딩 성능과 인코딩된 이미지의 품질을 별도로 비교하고 있는데, libjxl은 인코딩 성능과 인코딩 품질을 완전히 독립적으로 조절할 수 있지만 AVIF를 비롯한 다른 인코더는 대부분 이게 불가능하기 때문에 그렇게 비교할 수 없다.

• 제시된 인코딩시 목표 품질 범위가 너무 넓고 확률 분포를 생각하지 않았다. "On the fly"로 지칭된 최하 품질은 누구도 무슨 용도로든 사용할 수 없을 정도로 저품질이다. 또한 AVIF는 평균적으로 저화질 이미지에서 강세를 보이나 조금만 파일 크기가 커져도 JPEG XL이 크게 앞서는 경우가 많은데, 이를 적절하지 않은 방법으로 평균을 내서 JPEG XL의 강점이 희석되는 결과를 낳았다.

• 테스트에 사용된 데이터 집합이 부적절하다. 무손실 압축에서는 잡지 이미지를 스캔한 Kodak 집합을 사용하고 손실 압축에는 보통 벡터 그래픽이나 무손실 압축을 사용하는 Noto Emoji 집합이 들어 있는데, 둘 다 일반적으로 무손실 및 손실 압축을 쓰는 용례가 아니다.

• 이미지 압축 성능이 현재를 위한 논의라면, 이미지 포맷이 지원하는 기능은 미래를 위한 것이다. 한 번 브라우저에 들어간 이미지 포맷을 제거할 수 없다면 그만큼 더더욱 기능에 중점을 두어 평가해야 한다.

[lifthrasiir]

출근하기 전에 급하게 쓰다 보니 자잘하게 틀린 부분이 있는데요(...), "on the fly"는 엄밀히 말하면 최하 품질이 아니라 최고 속도입니다(다만 JPEG XL을 제외한 대부분의 인코더에서 품질과 역의 상관관계를 가집니다). 또한 Kodak 데이터 집합은 제가 무슨 생각을 했는지 잡지라고 썼습니다만 실제로는 필름에서 스캔된 것입니다.

[xguru]

JPEG XL의 장점