mir.pe (일반/밝은 화면)
최근 수정 시각 : 2024-10-30 09:32:58

AVIF

🖼️ 그래픽 포맷
{{{#!wiki style="margin:0 -10px -5px; min-width:300px; min-height:calc(1.5em + 5px); word-break:keep-all"
{{{#!folding [ 펼치기 · 접기 ]
{{{#!wiki style="margin:-6px -1px -11px" 		<colbgcolor=#555> 비트맵 <colbgcolor=#555> 손실 압축 JPEG AVIF▶Lα · BPG▶α · FLIF▶α · HEIF▶ · WebP▶α · RAW · DDS▶Lα · PSD▶Lα
무손실
압축 		APNG▶α · DNG · EXRα · GIF▶ · PCX · PNGα · RGBEα · TGAα · TIFFLα
무손실 무압축 BMPα
벡터 AI · CDR · SVG
▶: 애니메이션 기능 지원 / L: 다중 레이어 지원 / α: 알파값 지원
관련 틀: 그래픽 · 오디오 · 비디오
}}}}}}}}}

1. 개요2. 특징
2.1. 최신 포맷, 고성능2.2. 낮은 범용성2.3. 이미지 컨테이너2.4. 타 포맷과 비교
2.4.1. WebP와 비교2.4.2. HEIF와 비교2.4.3. JPEG XL과 비교2.4.4. Moz JPEG과 비교
3. 지원 현황
3.1. 운영체제 / 브라우저 및 웹 사이트3.2. 응용 프로그램
4. 여담

1. 개요

AV1-based Image Format

Alliance for Open Media에서 개발한 이미지 파일 형식이다. # 1.0.0버전은 2019년에 나왔다.

AVIF는 AV1 비디오 코덱을 통해 인코딩된 I-프레임을 그대로 이미지로 사용할 수 있도록 AOMedia에서 별도의 이미지 컨테이너로 개발한 것이다. "ISOBMFF"[1] 기반으로 만들어졌으며, HEIF를 살짝 개조하여 AV1으로 인코딩된 이미지를 담은 컨테이너라 생각하면 편하다.

자유소프트웨어 관점에서는 WebP의 후계자 격이며, HEIF(+ H.265)에 맞서는 대항마의 성격을 지닌다.

2. 특징

2.1. 최신 포맷, 고성능

AVIF는 GIF( 움짤), JPG( 사진), PNG(무손실)[2]등의 전통적인 이미지 포맷을 대체하기 위해 출시(된 HEIF의 대항마로 출시)되었다. 전통적인 이미지 포맷이 출시된 이래로 4:4:4 크로마 서브샘플링, 깊은 색 심도, ITU-R BT.2100 표준 기반 HDR 지원, 여러 이미지(다중레이어, 애니메이션, 타일 등) 지원, 짧은 음성 지원, 메타데이터 지원 등 여러 요구사항에 대응하는 새로운 포맷의 필요성이 대두되었기 때문이다. 무엇보다도 뛰어난 압축 효율이 눈에 띈다. 많은 개선점이 있기에 여러 곳에서 사실상 표준인 JPG를 계속 쓸 수 있음에도 AVIF를 도입할 계획을 갖고 있다.[3]

구글과 넷플릭스 같은 데이터 통신량이 많은 기업들을 중심으로 고효율 AV1 코덱을 개발했고, 이를 확장하여 고효율 이미지 포맷을 개발하였다. 그 성능에 대한 비교는 다음과 같다.

2.2. 낮은 범용성

최신 포맷(2019년)인만큼 최신 포맷들이 겪는 범용성 문제를 겪고 있다.

우선 AVIF를 지원하는 뷰어가 없었다. AVIF를 제대로 구현하려면 AVIF 스펙을 이해하고 앱을 개발할 절대적인 시간이 필요하다. 공개 라이브러리를 가져다 쓴 앱은 이를 지원하는 라이브러리가 만들어질 때까지 손가락을 빨고 있어야 한다. 특허가 걸려있는 기술은 혹시라도 없는지 검토할 시간도 필요하다. 결국 시간 문제라 시간이 지나면서 이 문제는 조금씩 해결되고 있다. 자세한 내용은 지원 현황(후술) 참고.

오피스 스위트에서 AVIF를 지원하지 않는 것도 문제이다.[6] AVIF를 웹 브라우저에서 불 수 있는 시점임에도 오로지 jpg, gif, png 이미지만 삽입할 수 있으며, AVIF는커녕 이미 예전부터 있던 WebP조차 문서에 삽입할 수 없는 상태이다.[7] 이를 보면 AVIF를 문서 삽입용 이미지로 활용하는 것은 아주 요원하다고 볼 수 있다.

AVIF가 압축 효율이 높은 만큼 고성능의 프로세싱 능력이 요구된다. 이미지 파일 하나 정도는 어떻게든 처리한다 싶지만, 파일 탐색기 미리보기 같은 상황에서 여러 이미지의 썸네일을 불러오는 일을 할 경우 jpg/webp와 달리 컴퓨터가 눈에 띄게 버벅이는 현상을 느낄 수 있게 되고, 수많은 짤 중에 필요한 짤 찾는 데 가랑비에 옷 젖듯 시간이 꽤 소모될 수 있다.[8] 움짤과 같은 이미지 여러개를 짧은 시간에 처리하고자 한다면 컴퓨터 성능에 더욱 부담을 안겨줄 수 있다. CPU, GPU, AP 등이 하드웨어 디코딩을 지원하면 보다 수월해지겠지만, 그런 하드웨어는 2021년 처음 선보이기 시작했다. 이와 관련해서는 역시 시간이 해결해 줄 문제이다.

AVIF 파일이 흔히 존재하지 않는다는 이유도 여러 곳에서 AVIF를 지원하지 않는 이유이기도 하다. 거의 존재하지 않은 파일을 위해서 굳이 일을 만들 필요가 없기 때문이다. AVIF 파일이 흔치 않은 이유는 AVIF를 만들 때 역시 고성능의 프로세싱 능력과 시간이 들어 AVIF를 만들 의지를 꺾기 때문이며(움짤 만들 때 느낄 수 있다.) AVIF 인코딩이 가능한 하드웨어가 나와야 이 문제가 해결될 것으로 보인다. 그리고 2021년 8월 기준 아직 AV1 인코딩이 가능한 일반인용 하드웨어가 출시되지 않았다.

대형 온라인 회사의 경우 일반 소비자와 달리 스토리지 요금(용량)을 줄이기 위해서 고효율 이미지를 적극적으로 도입하는 경향이 있다.[9] 하지만 웹 브라우저가 AVIF를 지원해야 이를 활용할 수 있다는 문제가 있다.[WebP] 웹 브라우저들은 2020년 여름즈음부터 이를 겨우 지원하기 시작했다.

여기까지 보면 AVIF는 한동안 쓰일 일이 없는 포맷처럼 보인다. 하지만 구글이 적극적으로 밀고 있고, AOMEDIA에 참여하는 다양한 하드웨어, 소프트웨어 회사들이 있기 때문에 WebP(구글 혼자 밀었다.)보다 전망이 밝은 편이다. 이미 유튜브에서 AV1을 반강제적으로 보내주고 있고, 이를 보기 위해서라도 AV1을 지원하는 하드웨어가 줄지어 출시될 것으로 예상되며, 하드웨어가 받쳐주는 구글의 안드로이드폰들의 카메라가 (아이폰이 HEIF사진을 만들어 댄 것 처럼) AVIF 사진을 찍어댄다면 각종 뷰어 AVIF를 볼 수 있게 개선되어야 하는 선순환체인이 이루어질 것으로 예상된다. 참고로 HEIF의 경우 안드로이드 파이(2018)에서 API를 지원하기 시작했고, 갤럭시 S10(2019)부터 HEIF 사진을 찍을 수 있었다. 안드로이드 11(2020)부터 Pixel 순정카메라에서 HEIF 저장옵션을 지원했다. AVIF는 안드로이드 12(2021)부터 AVIF API를 지원한다. 이르면 2022년, 넉넉히 2023년이면 AVIF 사진이 보급될 것으로 예측해 볼 수 있다.[갤럭시]

애플 기기는 2022년 가을 iOS 16, iPadOS 16, macOS Ventura(13)에서 AVIF를 네이티브로 지원한다. macOS 점유율이야 그렇다치고 iOS는 IT 시장에서 의미 있는 점유율을 가지고 있으므로 AVIF가 보급되는데 긍정적인 영향을 미칠 수 있을 듯하다. 다만, iOS16.2, iPadOS 16.2, macOS Ventura 13.1 기준으로 애니메이션 AVIF는 지원하지 않는다. Safari는 애니메이션 AVIF일 경우 아에 이미지를 못 띄우고, 사진 앱 등에 어떻게 넣더라도 정지 이미지로 보일 뿐이다. 2023년 iOS 17, iPadOS 17, macOS Sonoma의 Safari에서 애니메이션 AVIF도 지원 하기 시작했다. 다만, 사진 앱은 모든 OS에서 여전히 지원하지 않으며, 훑어보기는 macOS에서만 애니메이션 AVIF를 지원한다.

특히 BPG나 HEIF에 쓰이는 H.265와는 달리 AV1은 특허 라이선스에서 훨씬 자유롭기 때문에 AVIF 보급을 머뭇거릴 걱정이 덜하다는 점도 근 미래의 AVIF 범용성에 이점을 제공한다.[12] 특히 AV1 연합에 애플이 참여하였기 때문에 WebP[WebP]와 달리 어른의 사정으로 AVIF 보급이 지체될 일은 없어보인다.

2.3. 이미지 컨테이너

이미지 컨테이너로 개발되어 다양한 방식의 이미지를 같은 확장자 안에 담을 수 있다. 손실압축, 비손실압축 이미지를 담을 수 있으며, 이미지 여러개를 넣어서 다중 레이어 및 움짤과 같은 애니메이션도 지원할 수 있다. [14]

두고봐야 알겠지만, 영상코덱의 발전에 따라 같은 컨테이너에 코덱만 달리 지원할 수 있을 것으로도 보인다. jpg2000 같은 걸 안 쓰고 jpg를 몇십년 썼던 것 같은 상황은 점차 사라질 것으로 기대된다.

특정 이미지에 특정 확장자를 써왔던 과거에 익숙했던 사람들은 무손실 파일과 손실압축 파일이 같은 확장자를 쓴다는 것을 우려하기도 한다. 확장자로 이미지의 속성을 가늠할 수 없기 때문이다. 반면 메타데이터( 태그) 관리를 중요시하는 사람들은 범용적인 컨테이너 등장을 반기기도 한다. 코덱이나 기타 기술적인 것들의 버전이 올라가도 태그를 읽고 쓰는 방법은 그대로 유지될 것이기 때문이다.

2.4. 타 포맷과 비교

포맷별 이미지 품질 비교 사이트

2.4.1. WebP와 비교

WebP는 구글이 AVIF 이전에 보급하고자 했던 포맷이기 때문에 많이 비교되곤 한다.

손실 압축과 무손실 압축을 전부 지원하기 때문에 AVIF는 WebP처럼 GIF, PNG, JPEG 등의 상용 이미지 포맷을 대체할 수 있다. 또한 애니메이션 기능이 있어 움짤로 쓸 수 있으며, 압축 효율이 뛰어나다는 점까지 WebP를 쏙 빼닮았다.

하지만 WebP가 출시되고 9년 뒤에 나온 포맷이기 때문에 품질 대비 용량 효율은 더 좋다. 또 AVIF는 WebP와 다르게 VP8이 아니라 AV1 기반으로 돌아가기 때문에 움짤 용도로 쓴다면 WebP보다 더 안정적이다. 더구나 AV1은 구글과 마이크로소프트, 애플 등이 같이 만든 비디오 코덱이므로 아이폰 같은 특정 플랫폼에서 끊긴다거나 하는 문제도 없을 것으로 예상된다.

단, 무손실 RGB 이미지를 저장하는 데에 쓰는 용도(PNG 대체)로는 무손실 WebP보다 무손실 AVIF의 효율이 더 떨어질 수 있다. 단순한 패턴의 이미지(웹페이지를 캡처한 경우라든지)를 압축하는 경우 PNG보다도 압축률이 떨어질 수도 있다. 이럴 경우 차라리 Lossless WebP를 쓰는 것이 더 효율이 좋다.

2.4.2. HEIF와 비교

코덱이 유료다. 이미지를 보려면 돈을 내야 한다(...) 정확히 말하면 HEIF를 볼 수 있는 이미지 뷰어가 공짜가 아닐 것이다. MS 스토어에서도 코덱을 유료로 팔고 있으며, 이미 구매한 장치(노트북/그래픽카드 등) 제조사에서 공짜(덤)으로 코덱을 제공하는 현실이다. HEIF 호환성, HEVC의 복잡한 라이선스 참고.

성능은 AVIF와 비등하다.

2.4.3. JPEG XL과 비교

FLIF의 최종 진화형 포맷인 JPEG XL(.jxl)[15]과 비교될 여지도 있다. 이쪽은 AVIF보다도 최신 포맷이라 베타버전 수준이지만, JPEG의 후속이고 처리속도가 빠르면서도 적절한 압축을 가하는 기술이 적용된 포맷이다. 즉, 고압축과 저용량은 avif, 빠른 처리 속도와 무손실압축은 jxl이 상대적으로 강점을 보일 것으로 예측된다.

현재는 웹 브라우저에서 flag를 설정해야 jxl 파일을 읽을 수 있어 접근성이 떨어지는 상황인데, 크롬[16]에서 jxl 보는 기능을 탑재하지 않겠다고 하여 jxl의 앞날에 그림자가 드리워졌다. 아이폰에서 지원하지 않았던 WebP처럼 웹 사이트들이 지원하지 않을 여지가 매우 높고, BPG처럼 아는 사람만 아는 (소수의 이미지 뷰어만 지원하는) 파일 형식이 될 듯 하다.

2.4.4. Moz JPEG과 비교

Moz JPEG은 JEPG(jpg) 이미지 그 자체이며, 모질라 재단에서 제공한 도구(라이브러리)로 jpg 인코딩을 최적화 한 "같은 화질 대비 용량을 줄인 방식의 jpg 이미지"이다. 장점은 jpg, 단점 역시 jpg란 특징이 있다. 용량 절약 수준은 꽤 적절하여 WebP와 비등한 수준(큰사진 Moz JPEG, 작은사진 WebP 이득)이라 볼 수 있다.

Avif를 비롯 위에 언급된 최신 규격들보다 Moz JPEG의 용량절약 효과가 뒤떨어짐에도 본 문단에서 이를 언급하는 이유는 JPEG 파일이 미리보기, 썸네일 보기, 메타데이터 보기, 다량의 이미지 스크롤하기 등 이미지 탐색 과정에서 빠른 반응속도(오랜 역사를 거친 최적화 속도)를 보여주기 때문이다. 즉 용량에서 좀 손해를 보더라도 작업시간을 절약하는 이점을 챙길 수 있게 된다. 문서에 이미지 삽입, 인터넷 게시판에 업로드 등을 하고자 할 때 파일 형식을 따로 변환할 필요 없이 바로 사용할 수 있다는 장점도 있다.

고화질(적게 압축~양자화) 저장시에는 jpg와 avif 용량 차이는 그다지 체감되지 않기 때문에 사진 원본(고해상도 이미지)은 원본 그대로 두거나 Moz JPEG로 용량을 살짝만 최적화 하는 것이 적절하다 판단하는 사람들이 많다.[17] 그런데 중화질~저화질(많이 압축~양자화) 저장시에는 jpg와 avif가 크게 대비되는데 jpg는 (아무리 Moz JPEG이라 할지언정) 화질이 붕괴수준으로 무너지는 모습을 보이며, 반면 avif는 화질이 떨어지는게 살짝 거슬릴 뿐 여전히 괜찮은 화질을 유지하고 있는 모습을 확인할 수 있다. 특히 작은 해상도의 사진( 짤방)의 경우 jpg(Moz JPEG)와 avif의 화질/용량 격차는 더욱 크게 벌어진다.

3. 지원 현황

3.1. 운영체제 / 브라우저 및 웹 사이트

3.2. 응용 프로그램

[참고] AV1 라이브러리 - AOM (2017. 6.), FFmpeg libaom (2018. 4.), dav1d (2018. 12.), rav1e (2019. 1.), SVT-AV1 (2019. 5.).

4. 여담



[1] ISO base media file format, MPEG-4 Part 12. 소위 말하는 . MOV–. MP4 컨테이너. mp4box(LGPL v2.1 오픈소스)로 다룰 수 있음을 의미한다. [2] 다만 무손실 압축 포맷 이미지로서는 결점이 있다. 자세한건 후술. [3] 하드웨어 기술발전 관점에서 보면, 비디오램 가격이 떨어지고 용량이 증가하면서 PC에서 고해상도의 이미지를 재생하는 경향이 이어져왔고(SD→HD→FHD→4K→8K), 컨텐츠 용량이 커지면서 이를 감당해야 하는 HDD/SSD용량 문제, 이를 스트리밍하는 네트워크 대역폭 문제가 불거졌으며, 나날이 발전하는 CPU/GPU의 데이터 처리능력에 기대어 연산량이 많은 고성능 압축 코덱을 구현/좌절/보급해 나가는 과정에 있는 것이다. 명암비가 낮은 LCD에서 명암비가 높은 AMOLED로 디스플레이가 전환이 되면서, jpg 등이 표현을 하지 못하는 깊은 색심도를 가진 새로운 이미지포맷을 요구하게 된 것이다. [4] 최대 신호 대 잡음비 [5] 구조적 유사도 - 체크해주는 사이트 # [6] 문서 열람에 장애가 없도록 기술적 정책을 보수적으로 잡는 경향을 고려하면, 문서 작성에 최신기술이 즉각 반영되지 않는다고 이를 문제삼을 수는 없다라는 관점도 있을 수 있다. 일단 본 문단에서는 AVIF를 활용할 수 없다는 점 자체만 지적한다. [7] 인사이더(베타)에서 준비중이란 소식은 있다. # [8] 앱의 최적화 문제와도 연결되니 AVIF만의 문제라고 치부할 수는 없긴 하지만(...) [9] 날 잡아서 서버에 사진 트랜스코딩(압축)하는 썰 푸는 블로그 - Antman 프로젝트 개발기. [WebP] WebP의 경우, 애플이 OS/Safari 브라우저에서 WebP를 (오래도록) 지원하지 않았기 때문에 대다수의 웹 서비스들은 아이폰/아이패드(대략 모바일 접속의 절반) 호환성을 위해 WebP 게시/업로드 도입에 적극적이지 못했다. [갤럭시] 현재, 갤러리 - AVIF 인식가능 / 내파일(탐색기) - AVIF 썸네일 불가, 실행시 이미지취급 가능 / 카메라 - AVIF 저장불가 [12] jpg, gif가 오래된 기술임에도 널리 쓰이는 이유가, 아이러니하게도 오래된 기술이기 때문에 특허가 모두 해제되었기 때문이기도 하다. 요즘 gif 움짤의 효율과 퀄리티가 과거에 비해 급격히 상승할 수 있었던 것도 gif 특허 만료 이후이기 때문이란 해석도 가능하다. [WebP] [14] 컨테이너로 이미지를 담는 포맷에는 TIFF가 있다. [15] 10여년 전 마이크로소프트가 개발한 JPEG XR과는 다르다. [16] 사실상 엣지 포함 크로뮴 브라우저 전부 미지원. 즉 현재로서는 파이어폭스만 지원할 여지가 높은 상황. [17] 사람에 따라 기준이 다르며 이견이 있을 수 있다. [갤럭시] [19] 하지만 애플 사파리는 AVIF를 지원하지 못하는데, OS차원에서 지원을 해야 하기 때문이다. # [20] 주요 운영체제가 AVIF를 지원하는 과정의 애매한 과도기에 부지런히 AVIF를 도입(게시)했던 사이트. [21] 2018년 2월 릴리즈 된 오픈소스 HEIF 디코더 라이브러리 이기도 하다. [22] EXIF등 메타데이터를 수정하는 프로그램. 원본 메타데이터(촬영일자)를 그대로 Ctrl CV(exiftool -TagsFromFile "원본.jpg" "아웃풋.avif")하는 등의 작업이 가능하다. [23] 이미지 생성/변환 등을 위한 CLI 오픈소스 프로그램이며, magick -quality 80 test.jpg test.avif 또는 magick -define heic:speed=2 test.jpg test.avif 등의 명령어를 입력하면 avif 변환을 할 수 있다. 그 외 다른 변환 명령어도 있으며, 여러 파일 일괄변환을 할 수도 있다. [24] 한 때 CLI 방식으로 다수의 사진을 일괄변환할 수도 있었으나 Link, 사용법, 현재는 미지원. [25] 움짤 생성 위한 기능인데( 명령 프롬프트에 ffmpeg -i "video.mp4" "animated.avif"), 일반 그림/사진도 생성 가능하다(ffmpeg -i "인풋.jpg" "아웃풋.avif" 또는 ffmpeg -i "인풋.jpg" -c:v libsvtav1 -crf 5 -preset 3 "아웃풋.avif"). SVT-AV1 코덱 설정 가이드를 참고하여, 파라미터( 참조값) 응용도 가능하다. 라이브러리 중 libsvtav1 대신 libaom-av1를 사용할 수도 있는데 이것은 꽤 느리니(덧붙여 썸네일이 불거지는 붉어지는 버그가 있는 듯 하다.) 자세한 설명은 생략한다. 폴더 하나에 사진이 여러개 있는 경우 배치 파일.bat 파일을 만들어 일괄변환시킬 수 있다.
FFmpeg에 익숙하다면 더 나아가서 필터 기능을 사용하여 리사이즈 (scale), 잘라내기 (crop), 회전 (rotate), 뒤집기 (hflip), 화이트밸런스 (colorcorrect), 회색조 (monochrome), 색상조절 (colorchannelmixer), 색상복원 (grayworld), 샤픈, 블러 등등을 할 수도 있다. [26] 여담으로 Windows on ARM의 경우 64bit 설치가 불가하나 포터블 버전으로 실행할 수 있다. [27] Interchange(구), Image(신) 등 두문자의 원래 단어는 다소 다르긴 하다.

분류