반응형
인터넷 환경이 아무리 빨라지더라도 그 바닥(?) 중요 테마 중 하나는 전송량을 줄이는 것이다.

그리고, 전송량 중에서 이미지가 차지하는 비중은 굉장히 높다.


다양한 이미지 포맷이 있지만, 인터넷(특히 웹)에서는 JPEGPNG이 압도적으로 많이 쓰인다.

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



반응형

공유하기

facebook twitter kakaoTalk kakaostory naver band