웹 활용 사례로 비교한 JPEG XL과 AVIF

웹용 손실 압축 사진은 대체로 AVIF가 더 작음 . 같은 품질에서 JPEG XL 파일은 기본 압축 노력 설정 기준 보통 1525%, 최대 설정 기준 620% 더 컸지만, 일부 사진에서는 JPEG XL이 앞섬
스크린샷, 일러스트, 투명 이미지에서도 AVIF가 우세 했으며, 비트 단위로 정확한 결과가 필요한 경우가 아니라면 스크린샷에도 손실 압축을 활용할 수 있음
JPEG XL 인코더 선택이 결과를 크게 바꿈 . 새로운 jixel은 대체로 libjxl보다 작은 파일을 만들지만, 알파 채널을 항상 무손실로 인코딩해 복잡한 투명 이미지에는 불리함
프로그레시브 렌더링은 두 형식 모두 가능 하지만 브라우저 지원과 미리보기 구성 방식이 다름. HDR에서는 JPEG XL의 게인 맵을 브라우저 디코더가 지원하지 않는 제약 이 있음
무손실 압축과 기존 JPEG의 추가 손실 없는 변환은 JPEG XL의 강점 임. 일반 웹 이미지의 현재 기본 선택으로는 AVIF 4:4:4를 권장하며, 결과가 유난히 클 때 jixel과 비교할 만함
비교 조건과 품질 지표
JPEG XL이 모든 주요 브라우저에 도입된 시점 에서, 형식의 이론적 한계보다 현재 구현의 파일 크기와 처리 성능을 비교함
벤치마크 스크립트 로 여러 품질과 압축 노력 설정을 시험했으며, 2024 MacBook Pro의 M4 Pro 에서 실행함
주요 품질 지표는 SSIMULACRA2 이며, ColorVideoVDP 로도 교차 확인함
SSIMULACRA2는 50을 중간 품질, 70을 높은 품질, 80을 매우 높은 품질, 90을 시각적 무손실로 분류하지만, 이 분류가 고밀도 화면을 고려하는지는 불확실함
시각적 비교에는 원칙적으로 각 인코더의 최대 압축 노력을 사용하되, 최대 설정에서 파일이 더 커지는 경우는 제외함
libjxl은 e10

, AVIF는 s0

, jixel은 extraslow

가 최대 압축 노력 설정임
품질 점수와 실제 눈에 보이는 결과가 항상 일치하지는 않음
중간 품질의 F1 사진에서 jixel의 로고 주변 잡음과 글자 가독성 저하, 일러스트의 색상 블록은 같은 점수의 다른 결과보다 두드러져 보였음
보관용과 달리 블로그 삽화에는 전송 성능도 중요함. 확대 시에만 고해상도 이미지를 불러오려면 VisualViewport

API 같은 접근을 사용할 수 있음
손실 사진: 일반적인 우세와 예외
F1 사진 에서는 같은 품질의 최선 JPEG XL 결과가 AVIF보다 기본 설정에서 1417%, 최대 설정에서 615% 컸음
낮은 품질에서 AVIF는 디테일을 부드럽게 만드는 반면, JPEG XL은 더 거친 패턴을 만드는 경향이 있었음
ColorVideoVDP도 비슷한 순위를 보였으며 AVIF의 우세를 더 크게 평가함
인물 사진 에서도 JPEG XL은 기본 설정에서 1724%, 최대 설정에서 1217% 컸음
jixel이 전체 품질 범위에서 libjxl보다 나았으며, libjxl 기본 결과는 AVIF보다 3050% 컸음
AVIF가 얼굴을 지나치게 부드럽게 만든다는 우려와 달리, 이 인물 사진 표본 의 낮은 품질에서는 두 형식 모두 얼굴을 부드럽게 처리함
Squoosh 의 기본 이미지인 레서판다 사진 은 격차가 작았음
기본 설정의 jixel 파일은 AVIF보다 26% 컸고, 최대 설정에서는 SSIMULACRA2 기준 거의 동률이거나 매우 높은 품질에서 최대 5% 작았음
반면 ColorVideoVDP 기준으로는 최대 설정에서도 AVIF가 512% 유리해, 확실한 승자를 정하기 어려웠음
족제비 사진 은 JPEG XL이 이긴 예외이며, 두 지표가 모두 이를 뒷받침함
최선 JPEG XL 파일이 기본 설정에서 411%, 최대 설정에서 12~27% 작았음
jixel medium

만으로도 AVIF 최대 설정보다 418% 작은 파일을 만들었고, 속도와 메모리에서도 유리했음
모든 인코더가 같은 품질 설정에서 이 사진에 낮은 점수를 기록했지만, 피사체 품질을 해치지 않고 배경 잡음을 줄이는 처리는 시각적으로 수용할 만했음
이미지 크기를 바꿔도 대체로 AVIF의 우세가 유지 됐지만, 초고품질 대형 이미지는 예외가 있었음
작은 F1 이미지 에서 JPEG XL은 기본 설정 기준 1318%, 최대 설정 기준 1220% 컸음. 기본 설정 인코딩은 모두 50ms 미만, 메모리는 40MB 미만이고 디코딩도 수 ms여서 처리 성능 차이의 실질적 중요성은 작았음
1,800만 화소 이미지 의 중간/높은 품질에서는 JPEG XL이 기본 설정 기준 1846%, 최대 설정 기준 2854% 컸음
SSIMULACRA2 약 85에서는 libjxl 기본 설정이 AVIF 기본 설정과 비슷해졌고, 최대 설정의 jixel은 AVIF보다 약 6% 작았음
스크린샷, 일러스트, 투명 이미지
스크린샷 은 AVIF의 우세가 컸으며, 정확한 픽셀 보존이 필요하지 않다면 손실 압축도 충분히 활용할 수 있었음
기본 설정의 최선 JPEG XL 결과는 중간/높은 품질에서 7389%, 매우 높은 품질에서 2944% 컸음. 최대 설정에서도 2373% 컸음
libjxl은 기본 설정에서 SSIMULACRA2 약 45~78 사이의 결과를 만들지 못했지만, jixel에는 이런 공백이 없었음
jixel의 기본 비활성화 기능인 patches

는 높은 압축 노력에서 파일을 10~29% 줄였지만, 기본 fast

에서는 효과가 없었음
libjxl 최대 설정은 매우 높은 품질에서 오히려 파일을 3340% 키우고 약 7배 오래 걸렸음
일러스트 도 AVIF가 유리했지만, 도달 가능한 손실 압축 품질에는 한계가 있었음
시험한 일러스트 는 복잡한 음영 때문에 최소화하고 압축한 SVG도 1.1MB였으며, 래스터 형식이 파일 크기와 디코딩/그리기 시간에서 유리했음
SSIMULACRA2 80까지 JPEG XL은 기본 설정에서 3265%, 최대 설정에서 2255% 컸고, 그 이상의 품질에서는 격차가 더 벌어짐
손실 AVIF는 최대 품질에서도 약 87점에 머물렀음. JPEG XL은 90점에 도달했지만 자체 무손실 버전보다 850% 커져 무손실이 더 나았음
jixel patches

는 이 이미지의 크기를 줄이지 못하고 인코딩 시간과 메모리만 늘렸음
투명 이미지 는 알파 채널의 압축 방식이 결과를 크게 좌우함
AVIF는 기본적으로 알파 품질을 본 이미지 품질에 맞춰 손실 압축함. libjxl은 기본적으로 무손실이므로, 시험에서는 알파 품질을 본 이미지와 같게 조정함
jixel은 알파 품질 설정 없이 항상 무손실로 처리해, 기본 설정 파일이 AVIF의 1.93.1배였음
libjxl 결과도 AVIF보다 기본 설정에서 3144%, 최대 설정에서 61~70% 컸으며, 최대 노력에서는 자체 기본 설정보다 최대 8% 커졌음
투명도는 품질 측정에도 제약을 줌
SSIMULACRA2는 완전 투명 픽셀을 완벽한 일치로 계산하므로, 투명 영역이 많으면 불투명 이미지보다 점수가 높아짐
ColorVideoVDP는 알파 채널을 지원하지 않아 관련 이미지의 비교에 사용하지 못함
인코딩 비용, 디코딩 속도와 기본 설정
파일 크기까지 고려하면 대체로 AVIF의 인코딩 효율이 높았음
jixel 기본 설정은 보통 AVIF보다 빠르고 메모리도 적게 쓰지만, 더 큰 파일을 만드는 대가가 있음
F1 사진에서 jixel이 AVIF 기본 파일 크기에 맞추려면 extraslow

가 필요했고, 인코딩 시간은 18~27배, 메모리는 약 10배가 됐음
레서판다와 족제비처럼 jixel 파일 크기가 이미 경쟁력 있는 사진에서는 속도와 메모리도 장점이 됐음
압축 노력 증가는 AVIF와 jixel에서 유용하지만 추가 개선 폭은 점차 줄어듦
F1 사진에서 AVIF s5

는 기본 대비 약 3배의 시간으로 약 10%를 줄였음
jixel slow

는 같은 사진에서 약 3.7배의 시간으로 9~13%를 줄였지만, extraslow

는 추가 3~8% 절감에 slow

대비 약 8배의 시간과 9배의 메모리가 필요했음
libjxl 최대 노력은 여러 이미지에서 개선 폭이 작고 시간과 메모리 비용은 컸으며, 스크린샷과 투명 이미지에서는 파일이 더 커지기도 했음
대형 이미지에서는 메모리 비용이 특히 중요함
1,800만 화소 시험에서 AVIF 기본 설정은 약 560MB, libjxl 기본 설정은 중간/높은 품질에서 약 2.5GB를 사용함
최대 설정에서는 libjxl이 56.4GB, jixel이 6.88.3GB를 사용함
jixel 기본 설정은 AVIF보다 약 35% 적은 메모리를 사용했으며, 매우 높은 품질에서는 slow

가 AVIF s5

와 비슷한 크기를 3341% 빠르게 인코딩함
디코딩은 대체로 AVIF가 빠름
JPEG XL은 중간 품질에서 보통 23배 오래 걸리지만 , 매우 높은 품질에서는 격차가 줄거나 Chrome에서 역전되기도 함
스크린샷에서는 JPEG XL이 23.8배, 일러스트의 중간/높은 품질에서는 24.6배 오래 걸렸음
Safari는 일부 jixel 결과에 특히 느렸으며, 대형 이미지의 중간/높은 품질에서는 AVIF 대비 5배 이상 걸렸음
캐시에서 읽는 이미지처럼 다운로드 비용이 줄어드는 경우에는 느린 디코딩이 파일 크기 이점을 약화할 수 있음
AVIF의 기본 선택으로는 4:2:0보다 4:4:4가 적합함
색상 해상도를 줄이는 4:2:0은 인코딩/디코딩이 더 빠르고 메모리가 적게 들지만, 대체로 파일 크기 이점이 작고 높은 품질에 도달하기 어려웠음
예외적으로 스크린샷의 SSIMULACRA2 70 이상에서는 718% 작았음
투명 이미지에서는 오히려 427% 커지고 약 79점을 넘지 못했음
고정 품질 설정이 AVIF에서 특별히 불안정하다는 증거는 이 표본에서 없었음
avifenc -q 50

, cjxl -q 70

, jixel 품질 80을 비교하자 이미지별 점수 변동 방향이 세 인코더에서 비슷했음
표본은 작지만, 족제비에서 낮고 스크린샷에서 높은 품질을 선택하는 경향은 시각적으로도 납득할 만했음
Halide Compression의 추가 분석 에서도 품질 일관성을 살펴볼 수 있음
프로그레시브 렌더링과 미리보기
JPEG XL과 AVIF 모두 다운로드 중 미리보기를 표시할 수 있지만 지원 범위가 다름
JPEG XL은 Chrome과 Firefox 에서 프로그레시브 표시를 지원하며, Safari는 최종 이미지만 표시함
AVIF는 현재 Chrome만 지원 하며, Firefox 패치 는 진행 중임
JPEG XL의 progressive DC

와 AVIF의 프레임 기반 구성은 서로 다른 방식임
JPEG XL은 저해상도 이미지를 먼저 표시하고 고해상도 타일을 가져오며, jixel도 최근 이 기능을 추가함
AVIF는 최종 이미지를 포함해 최대 4개 프레임을 제공하고, 후속 프레임이 이전 데이터를 재사용할 수 있음
AVIF는 미리보기의 해상도, 흐림 정도와 내용까지 직접 정할 수 있지만 구성이 더 복잡함
미리보기의 유용성은 단순히 얼마나 일찍 표시되느냐만으로 판단하기 어려움
1,800만 화소 예시에서 AVIF는 약 11.5kB로 차량 종류와 팀을 알아볼 수 있는 미리보기를 보여줬음
JPEG XL은 약 2kB에 BlurHash 같은 미리보기를 표시했지만, AVIF 수준의 미리보기 품질에는 약 63kB가 필요했음
사용자 경험에 관한 데이터는 부족함. 불안정한 연결에서는 데이터가 뭉쳐 들어오므로 작은 이미지나 지나치게 많은 중간 단계의 효용은 불확실함
부분적으로 선명해진 이미지를 사용자가 로딩 중인 상태가 아니라 초점이 잘못 맞은 완성 이미지로 오해할 수 있다는 우려도 있음
JPEG XL의 프로그레시브 비용은 인코더와 설정에 따라 달랐음
SSIMULACRA2 약 70으로 맞춘 대형 이미지에서 libjxl은 오히려 6~10% 작아졌음
jixel은 기본 fast

에서 12% 커졌지만 extraslow

에서는 10% 작아졌음. 다만 ColorVideoVDP 기준으로 품질 차이를 반영하면 각각 약 18% 증가, 약 2% 감소였음
디코딩 영향도 달라 libjxl은 Firefox에서 약 10% 빨라졌지만 Chrome과 Safari에서는 1220% 느려졌음
프로그레시브 AVIF는 인코딩 비용이 크지만 최종 결과는 대체로 경쟁력 있었음
일반 구성은 메모리를 약 2배 사용하고, 기본 설정 인코딩도 약 2배 오래 걸렸음. Chrome 디코딩은 2944% 느려졌음
최종 프레임을 키프레임 으로 만들면 이전 프레임 의존성이 없어져 디코딩 추가 비용을 해소함. 인코딩은 더 오래 걸리지만 파일은 비프로그레시브 대비 35% 증가에 그쳤음
시험한 프로그레시브 AVIF는 152181kB, jixel extraslow

는 166kB, jixel 기본 설정은 252kB, libjxl은 233242kB였음
추가 비용을 포함해도 AVIF 디코딩은 JPEG XL보다 1.66배 빨랐음
HDR: PQ 압축과 게인 맵의 차이
PQ와 게인 맵은 디스플레이의 표현 범위를 다루는 방식이 다름
지각적 양자화(PQ) 는 픽셀 값을 최대 10,000니트의 절대 밝기에 대응시킴. 화면이 표현하지 못하는 밝기와 색상은 브라우저/운영체제가 톤 매핑하며, 결과는 플랫폼마다 다름
게인 맵 은 보통 SDR 기본 이미지에 픽셀별 밝기와 색상 변화를 더함. SDR에서는 원래 의도한 기본 이미지를 표시하고, HDR에서는 기기가 감당할 수 있는 만큼만 변화를 적용함
CSS와 <picture>

의 dynamic-range

미디어 쿼리 로 SDR/PQ를 선택할 수 있지만, HDR 지원 기기의 실제 표현 범위가 부족하면 여전히 톤 매핑에 의존함
JPEG XL 게인 맵은 형식상 가능하지만 브라우저에서 사용할 수 없음
브라우저 디코더 지원이 없고 인코딩 도구도 실험적이거나 정리가 덜 된 상태임
AVIF는 SDR 이미지와 HDR 이미지를 입력받아 게인 맵을 계산하고 인코딩함
Pixel 10 Pro와 2024 MacBook Pro의 최대 밝기, Pixel 10 Pro의 낮은 밝기에서는 게인 맵 이미지가 PQ보다 나았음. 이 조건에서는 기기의 HDR 여유 범위가 줄어듦
HDR 품질 측정은 불확실성이 커서 PQ 결과 중심으로 해석해야 함
일반 SSIMULACRA2는 SDR만 처리하므로 fast-ssim2 의 실험적 HDR 모드를 사용함. 다른 절의 점수와 직접 비교할 수 없음
ColorVideoVDP는 HDR을 기본 지원하며, 이번에는 1,500니트 모니터를 모델링함
두 지표 모두 게인 맵의 화면 적응 이점을 반영하지 못하고, 압축 효율 평가도 크게 엇갈렸음
PQ 파일 크기는 JPEG XL이 유리했지만 우세한 인코더와 격차는 지표마다 달랐음
HDR SSIMULACRA2에서 jixel 기본 결과는 PQ AVIF보다 8% 작거나 최대 3% 컸고, 최대 노력에서는 최대 15% 작았음
ColorVideoVDP에서는 libjxl 기본 결과가 PQ AVIF보다 2853% 작아 뚜렷이 앞섰음
게인 맵 AVIF도 HDR SSIMULACRA2에서는 PQ보다 3138% 컸지만, ColorVideoVDP에서는 11~25% 작았음
HDR 인코딩은 jixel, 디코딩은 대체로 AVIF가 유리했음
jixel 기본 설정은 PQ AVIF보다 약 2배 빠르고 메모리는 약 30% 적게 사용함. 게인 맵 AVIF는 계산과 두 이미지 인코딩 때문에 PQ보다 약 3배 느렸음
PQ와 게인 맵 AVIF의 디코딩 속도는 비슷했음. HDR JPEG XL은 Firefox에서 약 4배 오래 걸렸으며 개선 작업 이 진행 중임
AVIF와 jixel slow

까지는 추가 압축 노력이 유효했지만, libjxl 최대 설정은 27% 절감에 약 15배의 시간이 들었음
기존 JPEG 변환과 무손실 압축
JPEG XL은 기존 JPEG를 추가 손실 없이 920% 줄였음
F1 사진에서 너비 400픽셀은 약 9%, 4,900픽셀은 약 20% 절감했으며, 원래 JPEG 품질이 높을수록 절감 폭은 조금 작았음
libjxl과 jixel의 파일 크기는 사실상 같았음
작은 이미지는 JPEG보다 디코딩이 1.42.7배 느렸지만 차이는 12ms였음. 약 1,000픽셀부터 Chrome과 Safari에서 비슷해지고, 가장 큰 크기에서는 약 절반의 시간이 들었음
원본이 있다면 AVIF나 JPEG XL로 새 손실 압축본을 만드는 편이 더 나음
무손실 파일 크기는 JPEG XL이 확실히 우세했음
다만 일반적인 웹 이미지에는 무손실이 필요한 경우가 드묾
기본 설정에서 libjxl이 거의 모든 이미지에서 가장 작았으며, 일러스트만 WebP와 비슷했음
사진의 무손실 WebP는 917% 컸고, 전체 시험 이미지의 무손실 AVIF는 33122% 컸음
최대 노력에서 libjxl과 jixel은 몇 % 차이였으며, WebP는 544%, AVIF는 29176% 컸음
무손실 처리 비용은 이미지와 인코더에 따라 선택이 갈림
libjxl 기본 인코딩은 0.10.5초로 WebP보다 빠르고 AVIF와 비슷하면서 파일은 더 작았음
WebP 기본 메모리는 55110MB로 libjxl의 110~250MB보다 적었지만, 사진에서는 최대 노력으로도 libjxl 기본 파일 크기를 따라잡지 못했음
WebP는 디코딩이 빠름. 사진의 첫 로딩에서는 대체로 JPEG XL의 크기 절감이 이를 상쇄하지만, 스크린샷과 일러스트에서는 WebP의 디코딩 이점이 우세했음
무손실 AVIF는 크기도 크고 디코딩도 느려, Chrome에서는 libjxl 결과의 최대 4배가 걸렸음
jixel 무손실은 높은 압축 노력의 디코딩 비용을 주의해야 함
medium

은 libjxl 기본보다 0.523% 작고 사진의 최선 결과와 23% 차이였지만, 메모리가 470~670MB이고 디코딩도 더 느렸음
slow

와 extraslow

사진은 디코딩에 약 200290ms가 걸려 libjxl의 2295ms보다 2~13배 느렸음. 투명 이미지에서도 비슷한 문제가 있었지만 스크린샷과 일러스트에는 없었음
기본 fast

는 4080ms로 인코딩이 매우 빠르지만, 사진 파일은 libjxl보다 1632%, 스크린샷과 일러스트는 약 80% 컸음
patches

는 무손실 스크린샷을 49% 줄였지만 일러스트에는 효과가 없었음
libjxl 최대 무손실 노력도 비용이 큼
사진은 기본 대비 27%, 스크린샷과 일러스트는 약 25% 작아졌지만, 946초로 기본보다 50180배 오래 걸렸음
jixel은 비슷한 압축 결과를 수 초 안에 만들었음
애니메이션과 현재의 선택 기준
움직이는 콘텐츠에는 이미지 애니메이션보다 동영상 형식을 권장 함
같은 ColorVideoVDP 9.5점의 짧은 클립에서 애니메이션 AVIF는 725kB, JPEG XL은 2.17MB였음
JPEG XL은 각 프레임을 개별 인코딩해 아티팩트 위치가 프레임마다 달라지면서 잡음이 두드러졌음
애니메이션 AVIF는 사실상 AV1 동영상의 재포장이며, AV1 MP4와 컨테이너만 바꿔 무손실 왕복 변환이 가능함
애니메이션 AVIF의 재생 구현에도 문제가 있음
Firefox에서는 괜찮았지만 Chrome과 Safari의 재생은 좋지 않았음. 동영상에는 <video muted autoplay>

를 사용할 수 있음
애니메이션 AVIF는 투명도를 지원하지만 AV1 동영상은 지원하지 않으며, 동영상 투명도 문제 는 별도로 남아 있음
현재 권장 기본값은 AVIF 4:4:4와 감당 가능한 높은 압축 노력임
AVIF 결과가 유난히 크다면 jixel로 JPEG XL을 만들어 비교 할 만함
두 형식 모두 최근 크게 개선됐으므로 이 권장은 바뀔 수 있음. 잘못된 정보와 이를 되풀이하는 AI 답변 대신 실제 사용할 이미지로 시험하는 것이 중요함
JPEG XL을 둘러싼 과열된 논쟁과 실제 압축 성능은 구분할 필요가 있음
프로젝트 지도자 중 한 명이 Google에서 JPEG XL 개발팀에 속해 있었음에도 Google의 억압을 주장하는 음모론이 있었고, 같은 지도자는 JPEG XL을 썼다면 코로나 이후 해고를 피했을 것이라는 발언 을 했음
사용 사례를 묻는 과정에서 인종차별주의자라는 비난 까지 나온 경험도 있었음
jixel의 등장은 AVIF와 JPEG XL 사이의 경쟁을 실질적으로 강화 함. 현재 결과에서 어느 쪽이 이기든, 더 나은 이미지 압축을 위한 경쟁은 사용자에게 이익이 됨
댓글과 토론