Google은 원래 JPEG를 대체하기 위해 손실이 있는 이미지 형식으로 WebP를 개발했습니다. 이 형식은 JPEG로 인코딩된 비슷한 품질의 이미지 파일보다 작은 파일을 생성할 수 있었습니다. 이후의 형식 업데이트에서는 무손실 압축, PNG와 유사한 알파 채널 투명도, GIF와 같은 애니메이션 옵션이 도입되었습니다. 이 옵션 모두 JPEG 스타일 손실 압축과 함께 사용할 수 있습니다. WebP는 놀라울 정도로 다재다능한 형식입니다.
WebP의 손실 압축 알고리즘은 VP8 동영상 코덱이 동영상의 키프레임을 압축하는 데 사용하는 메서드를 기반으로 합니다. 상위 수준에서는 JPEG 인코딩과 유사합니다. WebP는 개별 픽셀이 아닌 '블록' 측면에서 작동하며 휘도와 색도 간에 비슷한 구분이 있습니다. WebP의 루마 블록은 16x16이고 크로마 블록은 8x8이며 이러한 '매크로 블록'은 4x4 하위 블록으로 더 세분화됩니다.
WebP가 JPEG와 근본적으로 다른 점은 '블록 예측'과 '적응형 블록 양자화'라는 두 가지 기능이 있습니다.
예측 차단
블록 예측은 주변 블록의 값, 특히 현재 블록의 왼쪽 위에 있는 블록의 값을 기반으로 각 색차 및 휘도 블록의 콘텐츠를 예측하는 프로세스입니다. 이 작업을 실행하는 알고리즘은 상당히 복잡하지만 쉬운 표현으로 표현하면 됩니다. '현재 블록 위에 파란색이 있고 현재 블록 왼쪽에 파란색이 있다면 이 블록이 파란색이라고 가정하세요.'
실제로 PNG와 JPEG 모두 어느 정도 이러한 종류의 예측을 수행합니다. 그러나 WebP는 주변 블록의 데이터를 샘플링한 다음 여러 '예측 모드'를 통해 현재 블록을 채우려고 시도하여 이미지의 누락된 부분을 효과적으로 '그리려고' 시도한다는 점에서 특별합니다. 그런 다음 각 예측 모드에서 제공하는 결과를 실제 이미지 데이터와 비교하고 가장 가까운 예측 일치 항목이 선택됩니다.
가장 근접한 예측 일치가 당연히 완벽한 것은 아니므로 해당 블록의 예측 값과 실제 값 간의 차이가 파일에 인코딩됩니다. 이미지를 디코딩할 때 렌더링 엔진은 동일한 데이터를 사용하여 동일한 예측 로직을 적용하므로 각 블록에 동일한 예측 값이 생성됩니다. 예측과 파일에 인코딩된 예상 이미지 간의 차이가 예측에 적용됩니다. 이는 Git 커밋이 파일의 새로운 사본이 아니라 로컬 파일에 적용되는 차등 패치를 나타내는 방식과 유사합니다.
예를 들어 실제 예측 알고리즘과 관련된 복잡한 수학을 파헤치기보다는 단일 예측 모드를 사용하는 WebP와 유사한 인코딩을 발명하고 이를 사용하여 기존 형식에서와 같이 숫자 그리드를 효율적으로 릴레이할 것입니다. 알고리즘에는 단일 예측 모드가 있는데, 이를 '예측 모드 1'이라고 합니다. 각 블록의 값은 1부터 시작하는 블록의 왼쪽과 위에 있는 블록 값의 합계입니다.
이제 다음과 같은 실제 이미지 데이터로 시작한다고 가정해 보겠습니다.
111151111
122456389
예측 모델을 사용하여 2x9 그리드의 콘텐츠를 결정하면 다음과 같은 결과를 얻게 됩니다.
111111111
123456789
이 데이터는 우리가 개발한 예측 알고리즘에 잘 맞습니다. 예측된 데이터는 실제 데이터와 거의 일치합니다. 물론 완벽한 적합성은 아닙니다. 실제 데이터에는 예측 데이터와 다른 블록이 여러 개 있습니다. 따라서 전송하는 인코딩에는 사용할 예측 메서드뿐 아니라 예측값과 달라야 하는 블록의 차등이 포함됩니다.
_ _ _ _ +4 _ _ _ _
_ _ -1 _ _ _ -4 _ _
앞서 설명한 기존 형식 인코딩과 동일한 종류의 평이한 언어를 사용하세요.
예측 모드 1을 사용하는 2x9 그리드 +4~1x5, -1~2x3, -4~2x7.
결과적으로 놀라울 정도로 효율적인 인코딩된 파일을 만들 수 있습니다.
적응형 블록 양자화
JPEG 압축은 이미지의 모든 블록에 동일한 수준의 양자화를 적용하는 포괄적 작업입니다. 구성이 균일한 이미지라면 분명히 의미가 있습니다. 하지만 실제 사진은 우리 주변의 세상보다 더 균일하지 않습니다. 실제로 이는 JPEG 압축 설정이 JPEG 압축이 뛰어난 고주파수 세부 정보가 아니라 이미지에서 압축 아티팩트가 나타날 가능성이 가장 높은 부분에 의해 결정됩니다.
이 과장된 예에서 볼 수 있듯이 전면에 있는 군주의 날개는 고해상도 원본에 비해 약간 거칠게 보이지만 원본이 없으면 눈에 띄지 않습니다. 마찬가지로, 밀풀의 세부적인 꽃이 피고 전경의 나뭇잎도 볼 수 있습니다. 여러분과 저는 훈련된 눈으로 압축 아티팩트의 흔적을 볼 수 있지만, 압축이 합당한 수준을 훨씬 넘어서는 경우에도 포그라운드의 사물이 여전히 선명하게 보입니다. 사진 왼쪽 상단의 저주파수 정보(나뭇잎의 흐릿한 녹색 배경)는 매우 끔찍합니다. 교육을 받지 않은 뷰어도 품질 문제를 즉시 알아차릴 수 있습니다. 배경의 미묘한 그라데이션이 들쭉날쭉한 단색 블록으로 반내림됩니다.
이를 피하기 위해 WebP는 양자화에 적응형 접근 방식을 취합니다. 즉, 이미지는 시각적으로 유사한 세그먼트 최대 4개로 나뉘고 이러한 세그먼트의 압축 매개변수는 독립적으로 조정됩니다. WebP와 동일한 대규모 압축 사용:
두 이미지 파일의 크기는 거의 같습니다. 군주의 날개를 보면 품질은 거의 동일합니다. 매우 자세히 살펴보면 최종 결과에서 몇 가지 작은 차이를 발견할 수 있지만 전체 품질에는 실질적인 차이가 없습니다. WebP에서는 유제품의 꽃이 조금 더 선명합니다. 다시 말해 두 꽃을 나란히 비교하고 실제로 품질의 차이를 찾지 않는 이상 눈에 띄기에는 충분하지 않을 수 있습니다. 배경은 완전히 다른 스토리입니다. JPEG의 눈에 띄게 명백한 아티팩트의 흔적은 거의 없습니다. WebP는 파일 크기는 동일하지만 훨씬 더 높은 품질의 이미지를 제공합니다. 이 둘을 이렇게 가깝게 비교하지 않으면 정신시각 시스템이 감지할 수 없는 몇 가지 작은 세부정보를 제공하거나 받아들입니다.
WebP 사용
WebP 내부는 JPEG 인코딩보다 훨씬 더 복잡할 수 있지만 일상적인 작업에서는 매우 간단합니다. WebP 인코딩의 모든 복잡성은 JPEG처럼 0~100으로 표현되는 단일 '품질' 값을 중심으로 표준화됩니다. 다시 한 번 말하지만 그렇다고 해서 가장 중요한 하나의 '품질' 설정으로 제한되는 것은 아닙니다. 평소에는 보이지 않는 설정이 파일 크기와 품질에 어떤 영향을 미치는지 더 잘 이해하려면 WebP 인코딩의 모든 세부정보를 고수할 수 있으며, 그렇게 해야 합니다.
Google은 개별 파일이나 이미지 디렉터리 전체를 변환하거나 압축할 수 있는 cwebp 명령줄 인코더를 제공합니다.
$ cwebp -q 80 butterfly.jpg -o butterfly.webp
Saving file 'butterfly.webp'
File: butterfly.jpg
Dimension: 1676 x 1418
Output: 208418 bytes Y-U-V-All-PSNR 41.00 43.99 44.95 41.87 dB
(0.70 bpp)
block count: intra4: 7644 (81.80%)
Intra16: 1701 (18.20%)
Skipped: 63 (0.67%)
bytes used: header: 249 (0.1%)
mode-partition: 36885 (17.7%)
Residuals bytes |segment 1|segment 2|segment 3|segment 4| total
macroblocks: | 8%| 22%| 26%| 44%| 9345
quantizer: | 27 | 25 | 21 | 13 |
filter level: | 8 | 6 | 19 | 16 |
명령줄에 관심이 없다면 Squoosh도 WebP 인코딩 작업을 할 수 있습니다. 다양한 인코딩, 설정, 품질 수준 및 JPEG 인코딩과의 파일 크기 차이를 나란히 비교할 수 있는 옵션을 제공합니다.