WebP 파일 검사기

사용법

1. .webp 파일을 상자에 놓으세요. 사진, 투명 배경 스티커, 애니메이션, 깨졌다고 의심되는 파일 모두 됩니다.
2. 먼저 파일 형태를 보세요. 단순 손실, 단순 무손실, 확장은 서로 다른 레이아웃이고 단순 형태만 아는 디코더는 확장 파일을 거부합니다.
3. 선언된 캔버스와 이 브라우저가 디코딩한 크기를 비교하세요. 일치해야 정상이며, 브라우저가 파일을 거부했다면 발견 목록이 이유를 알려줍니다.
4. 청크 표에서 레이아웃을 확인하세요. fourcc, 오프셋, 선언 크기, 패드 바이트 여부가 나옵니다. 인코더를 디버깅한다면 이 오프셋부터 보면 됩니다.
5. 애니메이션이면 프레임 표를 보세요. 오프셋은 이미 절반 필드에서 원래 값으로 되돌려 놓았고, 0ms 프레임은 크롬에서 100ms로 재생됩니다.

자주 묻는 질문

어떤 .webp는 VP8 청크로 시작하고 어떤 것은 VP8L이나 VP8X로 시작합니다. 같은 포맷인가요?

컨테이너와 확장자를 공유할 뿐 비트스트림은 다릅니다. 단순 손실 형태는 VP8 키 프레임 하나를 감싸며, 이는 VP8 비디오가 시작할 때 쓰는 인트라 프레임과 같습니다. 단순 무손실 형태는 VP8L 스트림을 감싸는데 이는 자체 엔트로피 코딩과 색 변환을 가진 완전히 다른 코덱입니다. 확장 형태는 VP8X 청크를 먼저 두어 별도 ALPH 청크의 알파, ICC 프로파일, Exif, XMP, 애니메이션까지 담을 수 있게 하고 그 뒤에 이미지 데이터를 놓습니다. 오래된 디코더가 어떤 WebP는 열고 다음 것은 거부하는 이유가 여기 있습니다. 단순 형태는 2010년, 확장 형태는 2011년에 나왔고 라이브러리마다 지원 시점이 달랐습니다. 첫 청크의 fourcc가 형태를 결정하는 유일한 단서입니다.

애니메이션 프레임 오프셋이 실제의 절반처럼 보입니다. 왜 그런가요?

실제로 절반이 저장되어 있기 때문입니다. ANMF 헤더는 프레임의 X와 Y를 실제 오프셋을 2로 나눈 24비트 값으로 담고, 그래서 프레임은 짝수 좌표에만 놓일 수 있습니다. 필드를 그대로 출력하는 리더는 x=8인 프레임을 x=4로 보여주고, 원시 값을 쓰는 합성기는 모든 프레임을 캔버스 가장자리에서 절반 거리에 그립니다. 눈에 확 띄는 오류가 아니라 미묘하게 어긋난 것처럼 보이는 버그입니다. 같은 헤더가 너비와 높이도 −1로 저장하므로 32픽셀 폭 프레임은 31로 기록됩니다. 이 도구는 오프셋을 두 배로, 크기에 1을 더해 보여주므로 여기 숫자는 디코더가 실제로 그리는 위치와 같습니다.

지속 시간을 0ms로 선언한 프레임은 어떻게 되나요?

0초 동안 표시되지는 않습니다. 크롬을 비롯한 블링크 기반 브라우저는 WebP 프레임의 지속 시간이 0이면 100ms로 대체합니다. 아주 짧은 지연을 가진 GIF 프레임에 하는 처리와 같으며, 0은 무한히 빠른 애니메이션 요청이 아니라 실수라고 보는 것입니다. 파이어폭스와 사파리가 늘 같은 선택을 한 것은 아니고 ffmpeg 같은 명령줄 도구는 0을 그대로 두어 다른 프레임 레이트를 만듭니다. 결과적으로 선언된 지속 시간의 합은 실제 재생 길이가 아닙니다. 이 도구는 두 합계를 모두 보여주므로 타이밍에 의존하기 전에 차이를 확인할 수 있습니다.

캔버스와 그 안의 이미지 크기가 다릅니다. 브라우저가 늘리거나 레터박스를 넣나요?

정지 이미지라면 둘 다 아닙니다. libwebp는 VP8X 캔버스가 그 안의 VP8 또는 VP8L 프레임 크기와 같아야 한다고 요구하고, 다르면 파일을 거부합니다. 크롬, 파이어폭스, 사파리 모두 libwebp로 WebP를 디코딩하므로 크기가 어긋난 정지 이미지는 어디서도 표시되지 않습니다. 애니메이션은 규칙이 달라 캔버스가 더 커도 됩니다. 각 ANMF 프레임은 자기 오프셋에 합성되고 캔버스를 벗어난 부분은 잘립니다. 그래서 이 도구는 정지 이미지의 캔버스−비트스트림 불일치는 발견 사항으로 보고하고, 캔버스를 넘치는 프레임은 따로 알려줍니다.

재생만 잘 되면 RIFF 크기 필드가 왜 중요한가요?

그 필드가 맞아야만 재생이 됩니다. 오프셋 4의 네 바이트는 파일 크기에서 8을 뺀 값이어야 하고(그 8은 RIFF fourcc와 크기 필드 자신입니다), libwebp는 디코딩 전에 이를 검사합니다. 중간에 끊긴 다운로드는 원래 크기 필드를 그대로 둔 채 끝부분 바이트만 잃으므로 필드가 너무 커지고, 깨진 이미지 아이콘 외에는 아무 메시지 없이 거부됩니다. 반대 경우는 메타데이터를 덧붙인 뒤 필드를 다시 기록하지 않은 인코더로, 일부 도구는 읽지만 브라우저는 읽지 못하는 파일이 나옵니다. 이 도구는 두 숫자를 모두 출력해 어느 쪽인지 알려주고, 마지막 청크 뒤에 남은 바이트도 따로 표시합니다.

투명도는 어떻게 저장되고, 같은 그림인데 ALPH 청크가 있을 때와 없을 때가 왜 생기나요?

방식이 세 가지입니다. 무손실 파일은 알파를 VP8L 스트림 안에 기록하고 헤더의 힌트 비트만 켭니다. 손실 파일은 VP8에 알파 채널 자체가 없으므로 그렇게 할 수 없어 확장 파일을 만듭니다. 알파 플래그를 켠 VP8X, 알파 평면을 담은 ALPH 청크(무손실로 압축하며 수평·수직·그라디언트 필터를 선택적으로 적용), 그리고 색을 담은 VP8 청크입니다. 애니메이션은 이를 프레임마다 반복하므로 어떤 프레임에는 ALPH가 있고 어떤 프레임에는 없을 수 있습니다. 하나 더 알아둘 점은 손실 인코더가 보통 완전 투명 픽셀의 색을 버려 용량을 아낀다는 것입니다. 합성하거나 블러를 넣기 전까지는 보이지 않으며, libwebp의 exact 옵션이 그 색을 보존합니다.

관련 도구