JPG AVIF 변환

이 변환에 몇 초가 걸리는 이유

AVIF는 AV1 동영상 압축의 정지 프레임 한 장이며, 동영상 압축은 만들기는 비싸고 재생하기는 쌉니다. 기다려야 하는 이유는 전부 이 비대칭에 있습니다. 인코더는 사진을 표현하는 매우 많은 방법 가운데서 최선을 찾고, 그 탐색이 바로 작은 용량을 만들어 냅니다. 큰 사진 한 장에 몇 초가 걸리는 것은 정상이며 문제가 있다는 뜻이 아닙니다. 반면 디코딩은 즉시 끝납니다. 한 번 인코딩해서 여러 번 보는 이미지에는 올바른 거래입니다.

그 대가로 얻는 것은 같은 체감 화질에서 JPEG의 약 절반 용량, 그리고 JPEG가 가장 약한 부분에서의 더 나은 결과입니다. 하늘, 스튜디오 배경, 그림자 같은 매끄러운 그라데이션에 JPEG처럼 계단 현상(밴딩)이 생기지 않고, 강하게 압축한 JPEG에 나타나는 8×8 블록 현상도 아예 생기지 않습니다. AVIF는 투명도와 광색역 색상도 담을 수 있는데, 둘 다 JPEG로는 전혀 담을 수 없습니다.

가지고 있는 가장 좋은 원본에서 시작하세요. JPEG를 다시 인코딩하면 AVIF 인코더가 JPEG의 압축 흔적을 그대로 물려받고, 그것을 실제 디테일과 구분하지 못해 다른 인코더가 남긴 손상을 보존하는 데 데이터를 씁니다. 그래서 같은 사진을 PNG, RAW 내보내기, 카메라 원본에서 한 번에 인코딩한 것보다 용량은 크고 화질은 나빠집니다. 원본이 있다면 원본을 쓰고, JPG밖에 없다면 두 번째 압축이 눈에 보이는 손실을 더하지 않도록 품질을 충분히 높게 유지하세요.

지금은 지원 범위가 넓지만 어디서나 되는 것은 아니며, 이 차이가 파일을 어디에 쓸지에 영향을 줍니다. 현재의 모든 브라우저가 AVIF를 디코딩하므로 웹사이트용이라면 그냥 더 좋은 형식입니다. 브라우저 밖에서는 들쭉날쭉해서 일부 이미지 뷰어, 오래된 휴대폰, 이메일 프로그램, 디자인 소프트웨어는 아직 AVIF를 읽지 못합니다. 그래서 AVIF를 이메일로 보내는 것은 JPG라면 없을 위험을 감수하는 일입니다. 카메라 정보와 위치 메타데이터는 옮겨지지 않습니다.

다른 작업이 필요할 때

기준 인코더는 이 페이지가 줄 수 없는 조절 장치를 제공합니다. avifenc -s 4 --min 20 --max 30 in.jpg out.avif는 인코딩 시간과 용량을 명시적으로 맞바꿉니다. -s 0은 가장 느리고 가장 작으며, -s 10은 거의 즉시 끝나지만 눈에 띄게 큽니다. --jobs all은 모든 코어를 사용하는데, 수백 장이 든 폴더라면 이 차이가 엄청납니다. 브라우저에서는 사진 한 장에 2분을 쓸 수 없지만, 때로는 그 2분이 딱 그 파일에 들일 만한 시간입니다.

웹사이트에서는 형식이 일의 절반일 뿐입니다. picture 요소로 JPEG 대체 이미지와 함께 AVIF를 제공하거나 CDN이 방문자마다 형식을 협상하게 하면, 호환성 위험 없이 용량 이득을 얻습니다. 빌드 단계에서 sharp나 libvips를 쓰면 모든 변형을 자동으로 만들어 주며, 이미지가 몇 장을 넘어가면 실제로 이렇게 처리합니다.