요약
웹 이미지는 대부분 아직 AVIF가 낫고, 무손실 압축에서는 JPEG XL이 확실히 앞섭니다.
웹 개발자 제이크 아치볼드가 JPEG XL이 주요 브라우저에 모두 들어온 것을 계기로 두 형식을 직접 벤치마크했습니다. 형식의 이론적 한계가 아니라 지금 쓸 수 있는 인코더로 사진, 스크린숏, 투명 이미지, HDR, 애니메이션을 비교했습니다.
왜 중요한가
- 모든 브라우저가 두 형식을 지원하게 되면서 형식 선택이 지원 여부가 아니라 실제 효율의 문제가 됐습니다.
- 기본은 AVIF로 두고, 결과가 유난히 큰 이미지만 JPEG XL로 시험해 보라는 실무 기준을 제시했습니다.
- 새 JPEG XL 인코더 jixel이 기존 libjxl보다 대체로 작은 파일을 만들어 두 형식의 경쟁이 이어질 것으로 봤습니다.
핵심 내용
- 기본 설정의 사진에서 JPEG XL은 같은 화질의 AVIF보다 15~25% 컸고, 최고 압축 설정에서도 6~20% 컸습니다.
- 스크린숏, 일러스트, 투명 이미지에서는 AVIF가 훨씬 작았고, 디코딩도 JPEG XL보다 1.3~3배 빨랐습니다.
- 무손실 사진은 JPEG XL이 확실히 앞섰고, 같은 사진을 WebP로 만들면 9~17%, 무손실 AVIF로 만들면 30~120% 더 컸습니다.
- 기존 JPEG 파일을 화질 손실 없이 JPEG XL로 바꾸면 용량을 9~20% 줄일 수 있었습니다.
- 권장 기본값은 AVIF 4:4:4(색 정보를 줄이지 않는 방식)에 감당할 수 있는 가장 느린 압축 설정입니다.
HN 반응
- 비교 이미지가 이상하게 보인다는 지적에 저자는 JPEG XL 미지원 브라우저용 대체 렌더러 탓이라고 인정했고, Firefox 지원이 며칠 전에야 들어왔다는 반론도 나왔습니다.
- MP3 인코더 LAME처럼 인코더가 무르익는 데 오래 걸리니 승자를 단정하기 이르다는 신중론과, 저장소·전송량을 크게 줄여 AVIF를 이미 쓴다는 경험담이 함께 나왔습니다.
libjxl이 effort 7을 넘으면 느려지는 가장 큰 이유는 Butteraugli라는 지각 오차 지표를 반복해서 평가하고 최적화하는 루프(양자화 가중치를 조정하는 과정) 때문입니다. 이 과정과 libjxl 인코딩의 다른 몇몇 계산은 데이터 병렬 처리에 알맞아서, 멀티코어 CPU보다 GPU에서 더 빠르게 돌아갑니다.
관심 있는 분이 계실까 해서 말씀드리면, 저는 GPU 가속을 지원하는 libjxl 포트(지금은 CUDA와 Metal 지원)를 만들고 있습니다. 훨씬 빨라져서 libjxl의 보통 속도에 가깝습니다. https://github.com/yunho-c/gjxl 이고, 이미지를 대량으로 JPEG XL로 인코딩하는 용도에 맞춰져 있습니다. 보통 effort(7)에서도 약 2.9배 빠릅니다.
AVIF는 훌륭한 포맷이라 저는 운영 중인 서비스에서 쓰고 있습니다. (적어도 2k 이하 이미지에서) 최적의 설정을 찾느라 시간을 꽤 들였는데, 이미지를 AVIF로 바꾸려는 분께 도움이 되도록 말씀드리면, 아래 설정이 용량을 가장 작게(10배 이상 작게) 만들면서도 품질이 좋고 PNG 투명도까지 지원했습니다.
음, 직접 해 보진 않았지만 저는 상당히 회의적입니다. avifenc는 이제 정지 이미지에 맞게 아주 잘 최적화돼 있는데, 여기서는 그걸 전부 건너뛰고 계시네요.
이 설정이 지금까지 제게는 아주 잘 맞았습니다. 더 나은 설정을 아시면 꼭 한번 써 보고 싶습니다.
avifenc입니다. 최신 버전으로요.
아, "avifenc"가 별도의 실행 파일인 줄은 몰랐습니다. 알려 주셔서 감사합니다. 꼭 비교 테스트를 해 보겠습니다.
libavif에 들어 있는 도구입니다. 저는 보통 직접 컴파일해서 썼습니다.
https://github.com/aomediacodec/libavif
avifenc는 enable-chroma-deltaq 같은 인자도 지원합니다. 저도 그런 인자를 써 봤다가 최근에 그만뒀는데, 눈에 띄게 달라진 건 없었습니다.
제 앱에서는 jpeg를 쓰다가 2년 전에 webp로 바꿨습니다. 이미지와 영상의 썸네일을 만들어서 보여주는 용도인데, 이제는 avif가 더 맞을 것 같네요. 불만스러운 점이 있으셨나요? 지금 avif를 고려 중이라 의견을 듣고 싶습니다.
무손실이어야 하거나 색 구성이 단순한 이미지라면 WEBP가 여전히 더 나은 선택일 겁니다(큰 차이는 아니지만요). AVIF에서 가장 크게 부딪힐 문제는 구형 환경 지원입니다. 특히 지원이 늦었던 Apple 기기가 그렇습니다.
그 밖에는 저장 용량과 전송 속도가 크게 줄어든다는 점이 최신 웹 애플리케이션에 아주 매력적입니다.
데스크톱 앱이라 avif를 쓰지 못할 이유가 없겠네요. 감사합니다!
저는 MP3 시대를 겪어 봤습니다. 여러 분야의 전문가들이 힘을 모아 LAME과 그 수많은 매개변수를 만들어 내서 마침내 주변의 웬만한 오디오 포맷보다 낫게 만드는 데 수년, 어쩌면 수십 년이 걸렸죠. 그래서 이번에는 기다려 보는 쪽으로 기울고, "승자"가 나왔다는 발표도 곧이곧대로 받아들이지 않을 생각입니다. 코덱이 성숙하고 다듬어지는 모습은 아직 한참 더 지켜봐야 합니다.
WebP의 우수성에 대한 큰소리도 기억합니다. 결국 같은 파일 크기에서는 우리가 아는 JPEG 아티팩트 일부를 이상한 새 아티팩트와 맞바꾼 정도였습니다.
새 포맷이 파고들어 일반 대중이 신경 쓰게 만들 만큼 큰 여지가 이 분야에 있다고는 생각하지 않습니다. 이미지 압축은 전반적으로 이미 해결된 문제처럼 보입니다. 차선책은 콘텐츠 제작자도 신경 쓸 필요가 없게 만드는 포맷, 즉 다양한 용도(손실, 무손실, 고속, 애니메이션, HDR, 프로그레시브 등)에서 최고이거나 그에 충분히 가까운 포맷을 내놓는 것입니다. 제가 순진하게 받은 인상으로는, jxl이 흥미로운 지점은 대체로 거기에 있습니다.
사람들이 신경 쓰려면 어떤 개선이 필요하다고 보세요?
진심으로 궁금합니다. 선입견이 생기지 않게 제 답은 스포일러 링크로 달아 둘게요: https://lgms.nl/p/cau/?b64&ZVRNb9QwEL0j9T%2BMKqFtpe1Cqcq9qoTUAwIJLhwn8SRxN%2FFEtrPB%2FHreOFso4tCN5c7Hm%2Ffe%2BIkkPGshXpxXalSPiTg4WgcJNBUafRM5Fmp1GR2lIfpwpDT6fshjoUZaXpLQw8Pju2%2BzyE%2FiKLjNWSLlgQN9%2Fnpnh4wfOZdveRLyYU9PtNaqz0vKFOVGQqtOKMj6CkjL40g%2BU6%2FqDvTdSq2cgFqXfqBOI6FaVmRFd7MdU%2BaYaUk%2B9Mi8eHPx5su8JGpGFK5YdMFfVyGtvEG1agd6yjTweJJU%2F5f8L7G4VzQYoidgCjtECsca53zXSQR6GwttPIKSd3LTlBv7UpaU056mpR1olJQ2diOK6QQWqwIG9oWjfe1TofrQjosDoKQYLnEnudDEsUcnjMon9efIc8A0owM5JScnGXXGt5M2JwqafSsMFs7tZR65yAaVmlK%2FoGB3EuI2e2SXv6o4QrlY8mA4jXWc0jZRzz4YyY86zRw8upsJeEyA53TOlmEC7EkO%2FYF%2BgP2lkTqiYuKYNvybF%2BrN6uGp6oo0C8ImRcFJgxRSEIzM1bsMvR4qTbjmMQq7AtGBFG4EG5B%2BV6cmpg4DGeYVt9Mc9SSThGwjhQN9ghDHscCPO0f9YvpUQO2feTZorY1lozPd3r%2F9p9CV72onE%2Fca6tmJ02Z6wD4XnLkYz3Y5S%2BamZDFHQ4ukXV6tfBBxqXp4mWeFi70JW2fcYQ8mPkLjBYG4dyqp9loHDxlm9aF2jFLnhnacQJchbjWkZapU60aJCYMir7ByXbxesEicPRIrZmtiZj8GXV8W25RDTgyJLv%2Fvhw5mFZOCpvkO0aXqB4qKLihYd4fhshnu%2BvD%2B9p6qEWO6pKsq5mSvC5phF2KwlULQx%2FNK2PNjwHb2OhA64mkaFMa%2BrgEvcHux1alUD9z4uu5nVC%2BLppAU3Eyc028%3D
또 하나 흥미로운 틈새는 JPEG와 RAW 사이입니다. RAW 파일은 다루기 번거롭고, JPEG는 비트 심도 같은 문제 때문에 편집하기 곤란합니다. 저는 그냥 사진을 찍고 싶지, 편집이니 변환이니 하는 건 하고 싶지 않습니다. 그래도 가끔은 조금만 손보면 좋아질 사진이 있는데, 그럴 때는 큰 JPEG도 한계가 있습니다. 비트 심도 같은 것이 맞지 않습니다.
WebP를 실제로 쓸 때 경험상 훨씬 나쁘게 만드는 건, 많은 웹 서버가 원본(대개 JPEG)을 손실 방식으로 WebP로 변환해 내보내도록 설정돼 있다는 점입니다. 대역폭을 줄이려는 것이기도 하고, 구글에서 나온 웹 속도 보고서를 만족시키려는 것이기도 한데, 그 보고서는 결국 구글 기술을 밀어주는 셈이죠. 차이가 눈에 확 띄는 경우가 많습니다. 예를 들어 질감이 흔적도 없이 뭉개집니다. Accept 헤더에서 WebP를 빼면 서버가 원본을 내보내게 할 수 있어서 도움이 됩니다.
그러니 포맷 사이의 기술적 차이와, 현실에서 실제로 받게 되는 파일의 차이가 서로 맞지 않는 겁니다.
제 생각에 그 F1 이미지는 AVIF의 문제가 무엇인지를 정확히 보여 주는 증거입니다. 자세히 보면 차체의 아름다운 하이라이트가 지워지고 그럴듯한 다른 것으로 대체돼 있습니다. 한번 보고 나면 안 보이는 척할 수 없는데, 아직도 사람들이 이걸 예시로 든다는 게 어이가 없습니다.
블로그의 큼직한 히어로 이미지처럼 전체적인 인상만 주면 되고 아무도 자세히 들여다보지 않는 용도라면 AVIF 성능이 인상적이긴 합니다. 하지만 제가 미러리스로 찍은 사진을 압축할 때는 감흥이 없습니다. 저는 휴대폰 스냅이 아니라 미러리스로 찍은 사진처럼 보이기를 기대하니까요.
그 하이라이트를 동그라미로 표시해 주실 수 있나요? 아래 두 파일을
아, 이런, 제가 말한 건 이 이미지였어요.
https://jakearchibald.com/2020/avif-has-landed/demos/compare/?show=f1
그런데 글쓴이가 다른 걸 링크했네요! 사람들이 드디어 그 이미지가 별로라는 걸 깨닫고 새 걸로 바꿨나 봅니다. 제가 착각했네요.
그때는 후광(halo)조차 없었는데요!
저도 최대한 자세히 보고 있는데 무슨 말씀인지 모르겠습니다. (저는 자동차도 사진도 잘 모릅니다.) 하이라이트가 뭘 뜻하나요? 무엇을 찾아봐야 하나요? 반사광인가요?
Eni 로고와 ApeCoin 로고 사이를 보세요. 무손실 쪽에는 따로 만든 부품을 조립한 듯한 선이 보입니다. ApeCoin 옆에는 둥근 부품도 있는데, 무손실 버전에만 있고 AVIF에는 없습니다. 다만 JPEG XL도 이런 것들이 대부분 사라지긴 합니다.
제가 알아챈 건 이 정도이고, 저도 자동차나 사진은 잘 모릅니다.
원본은 사진 한 장입니다.
"따로 만든 부품을 조립한 듯한 선"이라는 말씀을 가리키신 거라면, 사진이 여러 조각으로 조립됐다는 뜻이 아니라 자동차의 일부(패널 같은 것)가 그렇다는 뜻이었습니다. 패널 사이의 그 선들이 더는 보이지 않았어요.
아, 그렇군요, 하하!
저도 같은 생각입니다. 제 눈에 나빠 보이는 건 낮은 품질의 jixel뿐입니다.
아, 잠깐. 무슨 일인지 알겠어요.
JPEG XL을 지원하지 않는 브라우저로 보고 계셔서 WASM 렌더러로 대체되고 있는데, 그쪽이 크기 조절을 다르게 처리하는 것 같습니다.
완전히 제 잘못입니다. 그 대체 렌더러를 넣은 게 좋은 일인 줄 알았는데, 결과가 똑같지 않아서 사람들에게 잘못된 인상을 주고 있네요.
무손실 버전이 JPEG XL이라서 AVIF와 차이가 나는 겁니다.
그런데 비교용이면 브라우저 지원 문제를 피하려고 전부 png로 변환하지 않은 이유가 있나요?
이제 모든 브라우저가 AVIF와 JPEG XL을 지원합니다. 다운로드 크기가 줄어드는 이점을 그대로 살리고 싶었어요.
Firefox가 지원을 추가한 게 겨우 사흘 전인데요! 그리고 ESR 버전은 해당되지도 않고요.
물론 그렇긴 한데, 이건 기술적인 독자를 대상으로 한 기술적인 글이니까요.
~~기술적인~~ 어떤 독자라도 업데이트가 4일쯤 밀려 있을 가능성이 얼마나 될까요? (힌트: 아주 높음)