WebP
최근 수정 시각:
|
구글이 WebP를 개발하여 무료로 공개하는 이유는 세계 인터넷 플랫폼 점유율에서 구글이 가지고 있는 절대적인 위상과 그에 따른 천문학적인 관리 비용 때문이다. 구글 혼자서 엄청난 트래픽을 사용하고 있는데, 방대한 양의 이미지 포맷만 최적화해도 트래픽이 크게 줄어 비용을 아낄 수 있다. 게다가 인터넷 속도가 빨라질수록 광고 매출도 늘어나기 때문에 구글은 항상 인터넷 속도를 올리려고 노력한다.
그래서 구글의 서비스는 웹 브라우저를 확인해서 브라우저가 WebP를 지원하면 JPEG이나 PNG 대신 WebP를 보내준다. 예를 들면 유튜브 썸네일도 WebP로 되어 있다.[1] 다만 썸네일 이미지 업로드의 경우 WebP를 지원하지 않는 문제가 있다.[2]
그래서 구글의 서비스는 웹 브라우저를 확인해서 브라우저가 WebP를 지원하면 JPEG이나 PNG 대신 WebP를 보내준다. 예를 들면 유튜브 썸네일도 WebP로 되어 있다.[1] 다만 썸네일 이미지 업로드의 경우 WebP를 지원하지 않는 문제가 있다.[2]
움직이는 GIF처럼, WebP도 움직이는 영상을 지원한다. 웹 브라우저 지원 여부 테스트 사이트
GIF는 1987년에 개발되었다. 이런 구식 포맷은 단점이 많은데, 우선 압축률이 낮아서 파일 크기가 너무 크며, 256색만 지원하기 때문에 움짤을 만들 때 특정 색상이 깨지기도 한다.
하지만 2010년에 만들어진 WebP는 이런 문제들이 개선됐다. 압축률이 높아서 파일 크기가 작은 것은 물론이고, 색상 수에 제한이 없으므로 색상이 깨지는 일도 없다.
거의 모든 면에서 WebP가 우월하지만 거의 모든 브라우저와 사이트가 지원하는 GIF의 호환성이 압도적인데다 품질의 목적으로는 HTML5의 Video 기능을 이용하는 편이 훨씬 유연하다 보니 WebP의 Animated 기능은 호환성이나 성능이나 GIF와 동영상 사이에 낀 애매한 포지션에 위치하고 있다 보니 GIF를 완전히 대체하기 힘들 것이다. 현시점에서 순전히 움짤 용도로만 사용되는 GIF가 정지 이미지와 움짤 모두 포용하는 WebP보다 두 배 이상 사용되고 있다.
GIF는 1987년에 개발되었다. 이런 구식 포맷은 단점이 많은데, 우선 압축률이 낮아서 파일 크기가 너무 크며, 256색만 지원하기 때문에 움짤을 만들 때 특정 색상이 깨지기도 한다.
하지만 2010년에 만들어진 WebP는 이런 문제들이 개선됐다. 압축률이 높아서 파일 크기가 작은 것은 물론이고, 색상 수에 제한이 없으므로 색상이 깨지는 일도 없다.
거의 모든 면에서 WebP가 우월하지만 거의 모든 브라우저와 사이트가 지원하는 GIF의 호환성이 압도적인데다 품질의 목적으로는 HTML5의 Video 기능을 이용하는 편이 훨씬 유연하다 보니 WebP의 Animated 기능은 호환성이나 성능이나 GIF와 동영상 사이에 낀 애매한 포지션에 위치하고 있다 보니 GIF를 완전히 대체하기 힘들 것이다. 현시점에서 순전히 움짤 용도로만 사용되는 GIF가 정지 이미지와 움짤 모두 포용하는 WebP보다 두 배 이상 사용되고 있다.
PNG 포맷처럼 알파 채널을 지원한다.
여러 그래픽 소프트웨어들이 WebP를 지원하지 않는다. 단, Adobe Photoshop의 경우 CC 2022부터[5], CLIP STUDIO PAINT의 경우 3.0부터 지원이 추가되었다.
호환성이 나쁘다는 단점은 시간이 흐르면서 해결이 되고 있기는 하다. 2021년 애플이 WebP를 지원하면서 WebP도 서서히 사용처를 늘려가고 있다. 다만 시간이 흐르면서 2019년에 AV1을 기반으로 한 AVIF와 JPEG XL이 등장[6]하는 등 더 나은 포맷이 나왔다는 점은 WebP의 미래를 어둡게 만들기도 한다. 로열티 무료 최신 포맷들의 브라우저 지원 문제가 해결되면 WebP의 위치를 가져갈 가능성이 있다.
호환성이 나쁘다는 단점은 시간이 흐르면서 해결이 되고 있기는 하다. 2021년 애플이 WebP를 지원하면서 WebP도 서서히 사용처를 늘려가고 있다. 다만 시간이 흐르면서 2019년에 AV1을 기반으로 한 AVIF와 JPEG XL이 등장[6]하는 등 더 나은 포맷이 나왔다는 점은 WebP의 미래를 어둡게 만들기도 한다. 로열티 무료 최신 포맷들의 브라우저 지원 문제가 해결되면 WebP의 위치를 가져갈 가능성이 있다.
WebP는 표준 RIFF으로 되어 있어 Animated WebP는 libwebp의 Muxing API를 통하거나 RIFF를 직접 파싱해 사용할 수 있다.
하지만 프로그램들 중 libWebP의 Demux 기능을 사용하지 않고 디코딩하는 프로그램들의 경우 애니메이션 기능이 지원되지 않는다. 이 때문에 구글의 플랫폼과 이를 올바르게 사용한 몇몇 프로그램들을 제외한 플랫폼과 프로그램에서 움직이는 WebP 재생에 문제를 일으키고 있다.
libwebp는 여타 다른 인코더들처럼 한 프레임의 인코딩/디코딩 기능을 지원한다. 그러나 가장 간단한 이 방법은 별도의 demux 를 하지 않으며 그에 따라 이 방법으로 파일을 디코딩을 하게 되면 (
윈도우의 기본 사진 뷰어인 사진 앱에서 움직이는 WebP를 완벽하게 지원하지 못한다.[7] Microsoft Store에서 WEBP 확장을 설치하면 Microsoft Edge 브라우저에서 열 수 있다. 확장자를 jpg나 png 같은 걸로 바꾼 뒤에 사진 앱에서 여는 것도 가능하나, 이 방법으로 열면 움직이는 WebP는 첫 프레임만 보인다.
iOS, iPadOS는 버전 14부터, macOS도 Big Sur부터 WebP를 지원하지만, Safari와 훑어보기를 제외하고는 정지 이미지만 지원하며, 움직이는 WebP를 지원하지 않는다. 움직이는 WebP를 사진 앱에 저장하더라도 정지 이미지로만 보인다. iOS14부터 iOS17까지 제대로 지원하지 않는 것을 보면 애플에선 별로 지원할 마음이 없어 보인다. iOS·iPadOS 17과 macOS Sonoma에 와서야 훑어보기에 움직이는 WebP 지원을 추가했으나 이마저도 부드럽게 처리 못한다.
하지만 프로그램들 중 libWebP의 Demux 기능을 사용하지 않고 디코딩하는 프로그램들의 경우 애니메이션 기능이 지원되지 않는다. 이 때문에 구글의 플랫폼과 이를 올바르게 사용한 몇몇 프로그램들을 제외한 플랫폼과 프로그램에서 움직이는 WebP 재생에 문제를 일으키고 있다.
libwebp는 여타 다른 인코더들처럼 한 프레임의 인코딩/디코딩 기능을 지원한다. 그러나 가장 간단한 이 방법은 별도의 demux 를 하지 않으며 그에 따라 이 방법으로 파일을 디코딩을 하게 되면 (
WebPGetInfo()->WebPDecode####()) 컨테이너의 첫번째 청크만 디코딩 되지만 (APNG 미지원 디코더를 사용해 APNG 파일을 디코딩 했을때와 동일) libwepdemux의 파서(WebPAnimDecoderNew()->WebPAnimDecoderGetNext())를 사용하면 Frame payload를 파싱 후 demux한 payload를 디코딩하는 방식으로 원리 자체도 매우 단순하고 다른 정지영상/동영상 컨테이너들의 demuxer 사용과 딱히 다를게 없다. 그런데 위에서 언급한 첫번째 방법을 사용한 프로그램들은 멀티프레임 디코딩을 지원하지 못하고 있다.윈도우의 기본 사진 뷰어인 사진 앱에서 움직이는 WebP를 완벽하게 지원하지 못한다.[7] Microsoft Store에서 WEBP 확장을 설치하면 Microsoft Edge 브라우저에서 열 수 있다. 확장자를 jpg나 png 같은 걸로 바꾼 뒤에 사진 앱에서 여는 것도 가능하나, 이 방법으로 열면 움직이는 WebP는 첫 프레임만 보인다.
iOS, iPadOS는 버전 14부터, macOS도 Big Sur부터 WebP를 지원하지만, Safari와 훑어보기를 제외하고는 정지 이미지만 지원하며, 움직이는 WebP를 지원하지 않는다. 움직이는 WebP를 사진 앱에 저장하더라도 정지 이미지로만 보인다. iOS14부터 iOS17까지 제대로 지원하지 않는 것을 보면 애플에선 별로 지원할 마음이 없어 보인다. iOS·iPadOS 17과 macOS Sonoma에 와서야 훑어보기에 움직이는 WebP 지원을 추가했으나 이마저도 부드럽게 처리 못한다.
iOS, iPadOS나 Mac은 기술적으로는 WebP 포맷의 파일을 열람할 수 있으나, 시스템 내부적으로는 jpeg이나 png와 같은 타 범용 이미지 포맷과는 별개의 미디어 포맷으로 처리한다. 순정 사진 앱에서 WebP 세부사항을 볼 경우, iOS 앱에서 확장자 정보가 비어있고, macOS 사진 앱에서는 JPEG라고 잘못 표시된다. 정작, iOS14와 Big Sur 다다음에 나온 iOS16과 macOS Ventura에서 지원 시작한 AVIF는 각 사진 앱에서 바르게 AVIF라 표시된다.
그 예로 iOS, iPadOS의 사진앱은 WebP 포맷의 이미지 파일을 열람할 수 있으나, 실제로 Mac이나 Windows, Android와 같은 타 플랫폼과 USB 인터페이스로 연결하여 이미지를 불러올 때에는 jpg나 png, heic, gif와 같은 표준 이미지 파일만이 조회되고 WebP 파일은 조회되지 않는다.
또한 iOS, iPadOS의 사진앱에서 Documents와 같은 서드파티 파일관리 앱으로 WebP 파일을 이동할 경우 상당수의 앱에서는 WebP 포맷을 이미지 포맷으로 인식하지 못해 섬네일 이미지 열람이 안됨은 물론, 공유 기능을 이용해도 이미지 포맷이 아닌 일반 데이터 파일로 인식하기에 사진앱으로 저장하기 기능을 사용하지 못한다.
iOS, iPadOS 26 기준 정상적으로 인식한다.
그 예로 iOS, iPadOS의 사진앱은 WebP 포맷의 이미지 파일을 열람할 수 있으나, 실제로 Mac이나 Windows, Android와 같은 타 플랫폼과 USB 인터페이스로 연결하여 이미지를 불러올 때에는 jpg나 png, heic, gif와 같은 표준 이미지 파일만이 조회되고 WebP 파일은 조회되지 않는다.
또한 iOS, iPadOS의 사진앱에서 Documents와 같은 서드파티 파일관리 앱으로 WebP 파일을 이동할 경우 상당수의 앱에서는 WebP 포맷을 이미지 포맷으로 인식하지 못해 섬네일 이미지 열람이 안됨은 물론, 공유 기능을 이용해도 이미지 포맷이 아닌 일반 데이터 파일로 인식하기에 사진앱으로 저장하기 기능을 사용하지 못한다.
iOS, iPadOS 26 기준 정상적으로 인식한다.
성능이 낮거나 저전력 기기(스마트폰 포함)의 사양에 따라 높은 리소스를 필요로 하기도 한다. GIF보다 WebP가 트래픽을 아낄 수 있다고 해도, 그 WebP를 렌더링하는 과정에서 배터리, 램, CPU 등을 많이 점유/소비해 효율이 극히 떨어질 수밖에 없다. 이는 JPG가 하드웨어 디코딩(보다 더 신속하게 재생되면서도 리소스를 절약할 수 있다)을 지원하는 반면 WebP는 널리 보급되지 않아 하드웨어 디코딩을 지원하지 않는 경향이 있기 때문이다. 대표적으로 Apple 기기들이 그렇다.
Safari에서는 움직이는 WebP를 지원 하지만, Android(Chromium)나 Windows와 달리 Safari에서는 느리거나 끊겨서 재생이 되는 경우가 있다. iPhone과 iPad, Mac에 들어가는 애플리케이션 프로세서에 WebP의 VP8 하드웨어 디코더가 없어 CPU로 디코딩하며, Safari 브라우저마저 비효율적으로 동작하기 때문이다. 특히 frame disposal method를 사용한 움직이는 WebP는 파일 크기를 더 줄일 수 있지만 디코딩 부담이 커 최신 iPhone도 재생을 버거워한다.[8]
최신 버전의 꿀캠과 같이 All-Intra 코딩을 사용하면 iPhone에서도 잘 보이는 WebP 파일을 만들 수 있지만 CPU로 디코딩하는 한계점은 여전하므로 해상도가 높으면 버벅거린다. 자세한 것은 이곳을 참고하자.
macOS의 Safari에서도 같은 문제가 있지만, iOS와 iPadOS와 달리 타사 브라우저에 WebKit을 강제하지 못하므로 Chrome이나 Firefox 등, 비 Webkit 브라우저를 쓰면 그나마 정상적으로 출력된다.
Safari에서는 움직이는 WebP를 지원 하지만, Android(Chromium)나 Windows와 달리 Safari에서는 느리거나 끊겨서 재생이 되는 경우가 있다. iPhone과 iPad, Mac에 들어가는 애플리케이션 프로세서에 WebP의 VP8 하드웨어 디코더가 없어 CPU로 디코딩하며, Safari 브라우저마저 비효율적으로 동작하기 때문이다. 특히 frame disposal method를 사용한 움직이는 WebP는 파일 크기를 더 줄일 수 있지만 디코딩 부담이 커 최신 iPhone도 재생을 버거워한다.[8]
최신 버전의 꿀캠과 같이 All-Intra 코딩을 사용하면 iPhone에서도 잘 보이는 WebP 파일을 만들 수 있지만 CPU로 디코딩하는 한계점은 여전하므로 해상도가 높으면 버벅거린다. 자세한 것은 이곳을 참고하자.
macOS의 Safari에서도 같은 문제가 있지만, iOS와 iPadOS와 달리 타사 브라우저에 WebKit을 강제하지 못하므로 Chrome이나 Firefox 등, 비 Webkit 브라우저를 쓰면 그나마 정상적으로 출력된다.
2021년 4월 16일 기준 지원하는 브라우저들이다. 2025년 2월을 기준으로 브라우저단에서는 지원 안할 걱정은 전혀 하지 않아도 되는 수준이라고 보면 된다. 버전 출처
- Chromium 기반
- Microsoft Edge - 18[12] 이상
- Midori 리눅스용 브라우저
- Konqueror 리눅스용 브라우저
웹 사이트에서 WebP 확장자 업로드 및 허용 처리는 지지부진했다. 왜냐하면 WebP가 나온 타이밍이 동영상 처리가 아주 간편해진 HTML5 출시 직전이었기 때문에 아주 나빴고, 그런 이유로 구글에서도 유기해 버렸기 때문. 개발자들도 굳이 이런 귀차니즘을 무릅쓸 필요성을 느끼지 못했다.[19] 아이폰에서 지원하기 시작하자 많은 사이트들이 WebP를 지원하기 시작했다. 하지만 움직이는 WebP는 여전히 제대로 볼 수 없고 아이폰 사용자가 많은 해외 유명 사이트들은 아직도 WebP를 지원하지 않는 경우가 많다. 결과 2022년 기준 아직까지도 비효율적인 GIF가 여전히 현역으로 활약하며 트래픽을 잡아먹고 있다[20]. 국내는 2021년 중순 이후로 WebP를 지원하는 커뮤니티 사이트들이 늘어났고 아이폰 호환 기능이 있는 꿀캠을 많이 사용하는 편이라 점진적으로 gif의 점유율을 대체할 것으로 기대된다.
- 루리웹에서 2021년 5월 기준 WebP를 지원하기 시작했다. 다만 트래픽 절감을 위해 mp4로 바꾸어서 업로드된다.
- 개드립넷에서는 대강 2021년 8월 중순부터 지원하기 시작했다. 이전에도 WebP를 올리는 방법이 있었다. 바로 확장자를 gif, mp4, png, jpg 등으로 바꿔서 서버에 업로드하고, 글 본문에 이미지 삽입을 해서 브라우저가 파일의 확장자를 알아서 WebP로 디코딩을 하는 식으로 .
- 일베 운영진의 공지에 의하면 2023년 4월 8일부터 지원했다고 한다.
- 미디어위키에서는 2015년 11월 출시된 1.26에서 업로드를 지원하기 시작했다. 다만, 업로드할 때 png로 썸네일을 생성하여 제공한다.
- 나무위키에 움짤 업로드 시 WebP 파일 사용은 권장하지 않는다. 나무위키 이미지 서버는 업로드된 이미지가 일정시간 후 열화되는데, WebP 움짤 파일은 업로드 직후에는 정상적으로 보이지만, 이후 열화될 때 모든 프레임 정보를 잃고 정지 이미지가 되어버린다.
- 나무위키에 벡터 그래픽스를 제외한 정지 이미지를 업로드하면, 나무위키 서버에서 yuv420p 색공간을 가진 손실 압축 WebP 파일로 자동 변환되지만, 그렇다고 해서 사용자가 사전에 WebP 이미지로 변환하여 업로드하는 것은 권장하지 않으며, 가로가 1024px 이하인 이미지의 경우, 원본의 이미지를 그대로 업로드하는 것을 추천한다. 무손실 이미지를 업로드하든 손실 압축 이미지를 업로드하든 서버에서는 항상 재손실 압축을 하여 서버에 업로드된 이미지는 항상 업로드 전보다 열화된다. 그리고 나무위키 서버에서는 가로가 1025px 이상인 이미지는 비율이 유지된 체 가로가 1024px이 아닌 1000px로 축소되어 업로드되는데, 원본의 가로가 1025px 이상인 이미지의 열화를 최소화하려면, 픽셀의 리사이징 과정과 색공간 변환 과정이 동시에 수행되도록 무손실 이미지 코덱인 png 파일로 변환하는 동시에 가로를 1024px 리사이징 후, 이 이미지를 업로드해야 한다.
- 짤방을 나타날때 쓰는 짤방.gif 형태의 제목에서 짤방.webp 형태의 제목이 늘어나기 시작했다. WebP의 사용이 늘어남에 따라 많아진 듯.
- 알고리즘 특성상 이미지가 뿌옇게 변하는 현상이 있는데 움짤을 만들 때 카툰처럼 색상이 적고 극단적인 색변화가 일어나는 경우 그런 현상이 육안으로 크게 드러날 수 있다. 이런 경우 무손실로 하는 것이 좋다.
[1] WebP 적용 이후, 유튜브의 개별 썸네일은 서버상에서 확장자 변경, 적용까지 시간이 조금 걸린다.[2] '이미지 파일이 아닙니다' 라면서 썸네일 이미지 업로드가 되지 않는 이상한 문제가 있다. 니들이 만든 이미지 포맷이잖아[3] 지금은 JPEG도 무손실 압축을 지원하지만, 무손실 압축을 지원하는 JPEG 공식 버전은 WebP(2010)보다 4년 늦은 2014년에야 나왔다. 그 이전에도 무손실 JPEG 자체는 가능했지만, 압축 과정 대부분을 생략해서 손실을 피하는 편법에 가까웠기 때문에 포맷만 JPEG이지, PNG가 JPEG 대비 가장 불리한 소스를 줘도 PNG보다 압축률이 구려지는 등 엄청 큰 용량의 결과물이 나오는 문제가 있다. 물론 지원 자체는 JPEG 2000(2000년대 초)와 JPEG XR(2006년)이 더 먼저지만, JPEG 2000과 JPEG XR은 보급에 실패한 포맷으로 거의 안 쓰이기 때문에 '보급률 + 손실/비손실을 단일 규격으로 모두 지원'으로 따지면 오히려 WebP가 (HEIC 등에 비해 상대적으로) 원로에 가까운 위치다.[4] https://developers.google.com/speed/webp/faq?hl=ko[5] 이하 버전을 사용 중이면 플러그인을 이용해 사용할 수 있다.[6] 다만 이 최신 포맷들은 리소스 소모가 커 하드웨어 디코딩이 되기 전에는 널리 퍼지지 못하고 있다. 다만 이쪽은 하드웨어 디코딩을 준비하는 회사들이 많다.[7] Windows 11의 사진 앱(버전 2023.11050.16005.0 기준)으로 움직이는 WebP는 첫 프레임만 보인다.[8] frame disposal method는 움직이는 GIF에서 사용된 기술로 동영상의 인터프레임 코딩 방식과 유사하게, 이미지를 작은 블럭으로 나눠서 그 이전 블럭을 그대로 쓰게 하는 방식이다.[9] 2014년 1월 14일 출시[10] 2019년 1월 29일 출시[11] 2020년 9월 16일 출시[12] 2018년 11월 13일 출시[13] 2016년 4월 19일 출시[14] 2011년 6월 28일 출시[A] [16] 2012년 11월 5일 출시[B] [18] 2014년 1월 28일 출시[19] 이미지에 전문적인 이미지 호스팅 사이트만 해도, imgur는 WebP를 지원하지 않고 기타 경쟁 사이트들도 비슷한 상황이다. https://imgbb.com/는 HEIC도 지원한다.[20] 이 문제 때문에 gif를 업로드하면 무조건 MP4로 변환하는 사이트도 많은 편이다.[21] 단, 여전히 iOS상에서는 재생 속도가 떨어지는 등의 문제가 있다.[22] 중단 당시 크롬 이외의 브라우저가 완전히 WebP를 표시할 때까지는 다시 지원할 예정이 없다고 했다. 다만, 다시 지원하기 전에도 지원 중단 이전에 올라왔던 WebP 사진을 보는 것은 가능했다.[23] 2021년 4월 기준[24] microsoft store app[25] XnView Classic은 불가[26] 2018년 버전[27] 구글 개발자용 콘솔 프로그램.(다운로드)[28] 설치하면 Microsoft Edge, Windows 10의 기본 사진 앱과 탐색기 미리보기(썸네일)로 WebP 이미지를 볼 수 있다. 상술했듯이 사진 앱에서는 2023-08-14 기준으로는 WebP를 완벽하게 지원하지 않는다.[29] 2016버전부터 이미지 삽입을 지원하기는 하는데, 불러오는 화면에서 WebP를 선택할 수가 없어서 '모든 파일'로 선택해서 불러와야 한다. 2019 버전부터는 정식으로 지원하는데, 움직이는 WebP는 지원하지 않는다. 삽입하면 첫 프레임만 정지화면으로 보여준다.[30] 현재 윈도우 11 그림판에서도 불러오기는 잘 되지만, 저장은 다른 포맷으로 해야 한다.[31] 기존 YUV(YCbCr) 색공간과 4:2:0 크로마 서브샘플링에 더해 YIQ, YCoCg 색공간과 4:4:4 크로마 서브샘플링이 실험 중에 있다.[32] 이 때 사진을 한번 더 클릭하면 새창에서 원본이 나오긴 한다.
이 저작물은 CC BY-NC-SA 2.0 KR에 따라 이용할 수 있습니다. (단, 라이선스가 명시된 일부 문서 및 삽화 제외)
기여하신 문서의 저작권은 각 기여자에게 있으며, 각 기여자는 기여하신 부분의 저작권을 갖습니다.
나무위키는 백과사전이 아니며 검증되지 않았거나, 편향적이거나, 잘못된 서술이 있을 수 있습니다.
나무위키는 위키위키입니다. 여러분이 직접 문서를 고칠 수 있으며, 다른 사람의 의견을 원할 경우 직접 토론을 발제할 수 있습니다.