그리고, 전송량 중에서 이미지가 차지하는 비중은 굉장히 높다.
다양한 이미지 포맷이 있지만, 인터넷(특히 웹)에서는 JPEG과 PNG이 압도적으로 많이 쓰인다.
JPEG가 1992년, PNG이 1996년에 발표됐으니 20년정도 지났고, 나올만한 기술은 다 나왔다고 봐야 된다.
즉, 이제 두 포맷의 압축률은 거의 한계점이라 보는 것이 정설이다.
많은 사람들이 그런 줄 알았다…
하지만, 현실은 언제나 외계인이 지배하는 법…
1. PNG
압축의 여력이 더 큰 쪽은 PNG이다.
기본적으로 PNG은 무손실 압축이기 때문에 전처리를 거의 하지 않는다.
필터링 단계가 있기는 하지만, 큰 영향을 주는 정도는 아니다.
PNG 파일의 크기를 줄이기 위한 아이디어는 대략 이런 것들이 있어왔다. (참조 사이트)
- zlib(deflate)의 옵션 바꾸기
- Bit depth 줄이기
- indexed color로 변환
- 알파 채널 감소
다양한 시도들과 연구가 있었는데, 결국 끝판 대마왕이 나와버렸다. tinypng.
이 사이트에 PNG 파일을 올리면 거의 동일한 품질의 훨씬 작은 PNG 파일을 생성해준다.
대략 아래와 같은 작업들을 처리한다(해주는 것 같다)
- 알파 채널을 고려한 최적화된 팔레트 생성
- 화질에 영향을 거의 주지 않는 디더링
- deflate의 옵션을 최고로 올린 압축
이 사이트에 샘플로 올라와있는 이미지는 아래와 같다.
이것이 원본이고...
원본 (56KB / http://tinyPNG.com)
이것이 압축한 결과이다...
압축 결과 (15KB / http://tinyPNG.com)
사실, 이 원본엔 허수가 약간 끼어있다.
투명한(알파 채널이 0인) 영역 일부는 RGB가 흰색(0xffffff)이고, 일부는 검정(0x000000)이다.
어쨌거나 어떠한 이미지를 올려도 저 정도의 압축률을 보여주는 건 사실이다.
(추가) tinypng는 pngquant의 프론트 엔드인데, 이건 github에서 오픈소스로 관리된다… ㄷㄷㄷ
2. JPEG
JPEG는 손실압축으로, 손실이 높을수록 압축률은 더 올라간다.
즉, 작은 파일을 원한다면 화질만 떨어뜨리면 된다.
그리고, 화질을 떨어뜨리지 않는 범위에서의 압축률은 수학적으로 대략 일정하다.
그런 선에서 지금까지의 최종 보스는 libjpeg-turbo였다.
이 라이브러리는 libjpeg를 변형한 것으로 SIMD를 최대한 활용해서 아주 빠르게 동작한다.
덕분에 구글 크롬에도 기본 탑재되는 등 커다란 인기를 누리고 있다.
그래서, 그게 끝판 대마왕인 줄 알았다.
하지만, 파이어폭스의 모질라에서 새로운 대마왕을 등장시켰다.
모질라에서는 mozjpeg이라는 프로젝트를 발표했는데, 목표는 JPEG의 압축률을 10% 이상 끌어올리는 것이다.
현재 발표된 1.0에서는 jpgcrush라는 기능을 탑재했는데, 허프만 코딩을 최적화하는 것 같다.
그리고, 다음 목표는 trellis quantization 기능을 추가하는 것이라 한다.
직접 돌려본 결과, 완벽하게 동일한 결과물에서 파일의 크기를 85,659 → 75,079로 12% 정도 감소시켰다.
게다가 이것은 오픈소스다.
누구나 자신의 프로젝트에 포함시킬 수 있다는 엄청난 장점을 갖고 있다. ㄷㄷㄷ
하지만, 단점도 있는데, 속도가 굉장히 느리다는 것이다.
테스트해보니 13ms → 92ms로 7배 정도 느리게 동작한다. OTL
ffmpeg으로 오디오 변환시 주의사항 한 가지 (0) | 2014.11.16 |
---|---|
여행 사진 GPS 위치 정보 삭제 및 복원기 (0) | 2014.05.19 |
PNG 압축의 괴물 pngquant 간단 소개 (0) | 2014.03.11 |
갈수록 이상해지는 mp4box (0) | 2013.09.30 |
그동안 더욱 빨라진 libjpeg-turbo (2) | 2013.08.06 |