Lobsters

JPEG XL vs AVIF for web use-cases

웹 이미지 용도별 JPEG XL과 AVIF 비교

여러 이미지와 품질 설정을 대상으로 AVIF와 JPEG XL 인코더의 파일 크기, 인코딩·디코딩 시간, 메모리를 비교했습니다. 일반적인 손실 사진과 스크린샷에서는 대체로 AVIF가 유리하지만, 무손실 압축과 일부 이미지에서는 JPEG XL이 앞서며, 작성자는 기본값으로 AVIF 4:4:4를 권합니다.

에디터 노트

일반적인 웹 사진과 그래픽에 AVIF를 기본으로 권하는 판단은 측정 결과와 맞습니다. 특히 스크린샷과 투명 이미지에서 파일 크기 차이가 컸고, JPEG XL은 대체로 디코딩도 느렸습니다. 다만 이 권고는 한 장비와 제한된 이미지 모음, 특정 인코더 버전에서 나온 결과입니다. 글도 예외 이미지와 지표에 따른 차이를 보여 주므로 모든 이미지에 같은 격차가 난다고 읽을 수는 없습니다. 댓글에서 butteraugli 재측정은 결론을 뒤집지는 않았지만 높은 품질 구간과 libjxl 비교를 바꿨습니다. 손실 압축 품질은 지표 선택이 결과 해석에 영향을 줍니다. 작성자의 제안처럼 실제 이미지로 비교하는 접근이 타당하며, <picture>를 쓰면 브라우저가 여러 형식 가운데 가장 좋은 것을 자동 선택한다는 댓글의 가정은 작성자가 지적했듯 맞지 않습니다. 제시된 결과는 형식 하나를 고를 때의 실용적 기준을 주지만, 다른 인코더나 서비스 환경까지 포괄하는 보편적인 순위를 제공하지는 않습니다.

AI 요약

Jake Archibald는 주요 브라우저에 JPEG XL 지원이 들어온 뒤 AVIF와 실제 웹 이미지 용도별 성능을 비교했습니다. 2024년형 MacBook Pro(M4 Pro)에서 avifenc 1.4.2, libjxl 0.12.0, jixel 0.4.2를 사용했습니다. 이미지 대부분은 블로그 표시 폭의 두 배인 1598픽셀로 맞췄고, SSIMULACRA2와 ColorVideoVDP 점수가 비슷한 결과끼리 파일 크기와 처리 시간을 비교했습니다. 따라서 결과는 특정 이미지와 인코더 버전에 대한 측정이며, 지표에 따라 비교가 달라질 수 있습니다.

손실 사진과 그래픽

일반적인 손실 사진에서는 AVIF 파일이 대체로 더 작았습니다. 기본 설정에서 JPEG XL은 같은 품질의 AVIF보다 보통 15~25% 컸고, 최대 노력 설정에서도 대체로 6~20% 컸습니다. 얼굴 사진에서는 최대 설정 JPEG XL이 AVIF보다 12~17% 컸습니다. 반면 일부 예외 이미지에서는 JPEG XL이 AVIF보다 작았고, 18메가픽셀 사진의 매우 높은 품질 구간에서도 JPEG XL이 따라잡거나 앞섰습니다. JPEG XL 결과는 인코더에 따라 차이가 났습니다. 새 인코더 jixel이 대체로 libjxl보다 작은 파일을 만들었지만, 세밀한 투명도 이미지에서는 손실 알파를 지원하지 않아 파일이 AVIF의 2~3배가 됐습니다.

스크린샷과 일러스트에서는 AVIF의 우위가 컸습니다. 기본 설정의 JPEG XL 파일은 AVIF보다 각각 최대 73~89%, 32~90%가량 커졌고, 최대 노력에서도 더 컸습니다. 작성자는 손실 AVIF가 이런 그래픽을 잘 압축하므로 픽셀 단위로 정확한 결과가 필요한 경우가 아니라면 무손실 형식을 기본으로 쓸 이유가 적다고 봅니다. 다만 품질 측정 지표가 이미지별 시각적 차이를 완전히 반영하지 못할 가능성도 언급합니다. 투명도가 있는 이미지 역시 AVIF가 파일 크기와 처리 시간에서 앞섰습니다.

인코딩 설정과 실행 비용

AVIF는 대체로 인코딩이 빠르고 메모리를 덜 씁니다. jixel은 기본 설정에서 AVIF보다 빠르고 메모리도 적게 쓰는 경우가 있었지만 파일이 더 컸습니다. 비슷한 크기의 파일을 만들려고 노력 수준을 높이면 시간이 크게 늘고, 메모리 사용량도 증가했습니다. libjxl은 높은 노력 설정으로도 파일 크기를 거의 줄이지 못하거나 오히려 커지는 사례가 있었으며, 인코딩 시간이 기본 설정의 여러 배에 달했습니다. 반면 AVIF와 jixel은 이미지에 따라 높은 노력 설정이 파일을 줄이는 데 도움이 됐습니다.

기본 품질 설정으로 인코딩했을 때 SSIMULACRA2 점수는 이미지마다 달랐지만, 세 인코더 모두 비슷한 방향으로 점수가 변했습니다. 작성자는 조사한 이미지 범위에서 AVIF의 단일 품질 설정이 특별히 불안정하다는 증거를 찾지 못했다고 설명합니다. AVIF의 4:2:0 색차 서브샘플링은 인코딩과 디코딩을 빠르게 할 수 있지만 파일 크기를 거의 줄이지 않거나 높은 품질을 내기 어렵게 만들었습니다. 예외로 일부 스크린샷의 높은 품질 구간에서는 파일이 7~18% 작아졌습니다. 작성자는 별도 확인 시간이 없다면 4:4:4를 기본으로 권합니다.

디코딩, 점진 표시와 HDR

AVIF는 일반적으로 JPEG XL보다 디코딩이 빨랐습니다. JPEG XL은 중간 품질에서 보통 2~3배 오래 걸렸고, 매우 높은 품질에서는 차이가 줄었습니다. 일부 이미지와 브라우저에서는 JPEG XL이 더 빠른 예외도 있었습니다. 기존 JPEG를 JPEG XL로 변환하면 추가 손실 없이 파일을 9~20% 줄였고, 큰 이미지는 Chrome과 Safari에서 원본 JPEG보다 빠르게 디코딩되기도 했습니다.

JPEG XL과 AVIF 모두 점진 표시를 지원하지만 방식이 다릅니다. JPEG XL은 저해상도 미리보기에서 세부 타일을 더하는 방식이며, AVIF는 최대 네 개의 프레임을 이어 보여 줍니다. AVIF는 미리보기 모양을 직접 정할 수 있고, 측정한 예시에서는 JPEG XL보다 디코딩이 빨랐습니다. 다만 점진 표시의 실제 사용자 경험에 관한 자료는 부족하다고 작성자는 밝힙니다. HDR에서는 브라우저 디코더가 JPEG XL gain map을 지원하지 않으며 인코딩도 실험적입니다. AVIF gain map은 SDR 이미지와 HDR 보정 정보를 함께 담습니다. PQ 방식과 gain map 비교는 사용한 품질 지표가 서로 크게 달라 단정하기 어렵습니다.

무손실과 최종 권고

무손실 이미지에서는 JPEG XL이 가장 작았습니다. 사진에서 무손실 WebP는 libjxl보다 9~17% 컸고, 무손실 AVIF는 대체로 30% 이상 컸습니다. 다만 jixel의 높은 설정은 디코딩이 느려지는 이미지가 있었고, 무손실 AVIF도 파일이 크고 디코딩이 느렸습니다. 애니메이션 이미지 비교에서는 같은 ColorVideoVDP 점수에서 AVIF가 725kB, JPEG XL이 2.17MB였습니다. 작성자는 애니메이션 이미지 형식 대신 동영상 형식을 쓰라고 권합니다.

웹 이미지의 기본값으로 작성자는 AVIF 4:4:4와 감당 가능한 가장 높은 노력 설정을 권합니다. AVIF 파일이 유난히 크다면 jixel로 JPEG XL 인코딩을 시험해 보라고 덧붙입니다. 두 포맷과 인코더는 계속 개선되고 있으므로 실제 서비스에 쓰는 이미지로 직접 비교하라는 것이 글의 권고입니다.

Lobsters 반응

  • @altano — 제 결론은 이 형식들이 모두 정말 대단하다는 겁니다. F1 이미지 50% 품질은 원본 1.01MB에서 AVIF 23.7kB가 됐는데, iPhone 16 Pro에서 확대하기 전에는 압축된 줄도 모르겠습니다. 제 웹사이트에는 AVIF를 기본으로 씁니다. 이런 좋은 비교 글이 많고 결국 하나를 골라야 하니까요. 고맙습니다, Jake!
  • @cosarara — 스크린샷 예시에서 AVIF와 무손실 이미지의 흰색 밝기가 크게 다릅니다. 링크 밑줄에서 특히 잘 보입니다. People 이미지의 안경 반짝임도 비슷합니다. ... Firefox 157을 쓰고 있다는 걸 이제야 알았습니다. JPEG XL을 기본 지원하지 않아 JavaScript canvas와 실제 AVIF를 비교한 셈입니다. Firefox 158에서 다시 보니 차이가 없습니다. 전체 이미지를 새 탭에서 열어 무손실과 손실 이미지를 비교할 수 있으면 좋겠습니다.
    • @jaffathecake — 레이아웃이 어떻게 비교를 제한하는지 조금 더 알려 주세요. 이미지를 확대해 보기보다 실제 표시되는 크기로 보길 원했습니다. 팝아웃이나 전체 화면 버튼을 추가할 수는 있지만 이미지 크기가 그대로라면 무슨 차이가 있을지 모르겠습니다. 수정: 전체 화면 옵션을 시험해 보니 특히 큰 예시에서는 괜찮네요. 제안 고맙습니다.
    • @cosarara — 100%를 넘겨 픽셀을 하나씩 들여다보는 게 아니라면 확대가 부정행위는 아닙니다. 2000픽셀 이미지를 브라우저가 700픽셀로 줄이면 거의 모든 형식이 무손실처럼 보입니다. 전체 화면 버튼은 도움이 됩니다. 고맙습니다.
  • @lyall — 좋은 분석입니다. SSIMULACRA2가 AVIF에 유리한지 궁금해서 butteraugli 지표로 같은 분석을 다시 했습니다. 결론이 뒤집히지는 않았지만 libjxl에 조금 더 유리하게 바뀝니다. butteraugli는 높은 품질 구간에서 JPEG XL을 AVIF보다 좋게 평가하고, 중간 품질에서도 격차를 줄입니다. 파일 크기에서는 libjxl이 jixel보다 유리합니다. libjxl이 내부적으로 butteraugli를 쓰고 jixel은 SSIMULACRA2를 쓰는 것으로 알고 있으니 자연스러운 결과입니다. 지표가 결과를 바꾸는 지점이 흥미롭습니다.
  • @ndegruchy — 저는 outlier인 것 같은데 여러 형식을 picture 요소에 넣고 브라우저가 가장 좋은 형식을 고르게 합니다. JPG나 PNG로 대체하는 설정도요. 대부분의 도구로 쉽게 만들고 일괄 처리할 수 있습니다. 바이트를 아끼려는 마음은 알지만, 이미지 형식은 예외적인 경우에만 중요합니다. 형식을 하나만 더 생성한다면 나머지도 추가하면 되지 않을까요?
    • @jaffathecake — picture는 그렇게 작동하지 않습니다. 브라우저는 처음으로 유효한 source를 선택하므로 결국 형식을 직접 고르는 셈입니다. 여러 형식 인코딩에 시간을 쓰는 것보다 하나를 고르고 설정을 정하는 편이 낫습니다.
  • @Nicd — 무손실 AVIF가 이렇게 나쁜 결과를 내는 게 흥미롭습니다. WebP보다 파일이 훨씬 크네요. 내부 동작은 거의 모르니 그럴 만한 이유가 있을 수도 있겠지만, 새 형식이 더 나을 거라고 막연히 생각해서 놀랐습니다. 사진 갤러리 썸네일에 AVIF를 고른 제 선택은 이 글로 확인받은 것 같네요.
    • @jaffathecake — 무손실 WebP와 무손실 JPEG XL은 손실 버전과 사실상 다른 코덱입니다. AVIF는 그렇지 않습니다. 그래서 JPEG XL은 품질 99 설정이 품질 100 무손실보다 큰 파일을 만들기도 합니다.

원문: Jake Archibald / 번역·요약: Trawling