ndc2012 최지호 텍스쳐 압축 기법 소개
TRANSCRIPT
텍스쳐 압축 기법 소개
최지호 바나나피쉬
2012-4-24
텍스쳐
• 게임에서 아주 중요한 요소
• 게임의 비쥬얼을 좌우
• 성능과 밀접한 영향
•사이즈가 가장 크고
•로딩 시갂을 가장 많이 차지
텍스쳐 #2
• 점점 커지고 있다
– 2048x2048x4 = 16MB in RGBA8888
–개수도 증가
• Normal-map/specular-map/AO-map/light-map/env-map…
• 압축은 필수!!!
일반적인 방식
• TGA
• DDS
• DDS + ZIP
• JPEG
TGA
• 알파채널 지원과 비손실 RLE 인코딩(=큰 용량)으로 PNG와 함께 아트 소스로
주로 활용
DDS
• 4x4 블록 기반 (손실) 압축 방식
–DXT1 => 6:1 고정 압축률 (w/o 알파)
• 그래픽카드에서도 압축 유지 –쓸 수 밖에 없는 이유
• 디코딩: 매우 빠름
• 인코딩: 빠르짂 않음
DDS #2
• 4x4픽셀 블록 단위
• Start Color/End Color를 선정
DDS #3 • SC/EC를 각각 R5G6B5로 저장 • 4x4 픽셀 각각에 대해
– 2비트 인덱싱을 저장 • 00: SC • 01: EC • 10: 2/3*SC + 1/3*EC • 11: 1/3*SC + 2/3*EC
• 총 8Bytes(64bits)/블록 • 48바이트 ->8바이트 압축률
DDS 지원 라이브러리 • Squish
– SSE 최적화
• nvtt – Nvidia, squish기반, CUDA 지원
• Compressonator – ATI, 퀄리티 좋음
• J.M.P.’s – Id소프트, MMX/SSE 최적화, 매우 빠름
DDS + ZIP
• DDS만 사용하는 것보다 압축률 높음
• ZIP 압축해제는 비용이 저렴함 – LZMA등이 더 효율적이나 ZIP이 훨씬 빠름
• GPU메모리에도 효율적
JPEG
• 10:1 ~ 20:1 압축률
JPEG #2
• 압축해제 느림
• 퀄리티 컨트롤: 1~100 • libjpeg-turbo 라이브러리
– MMX/SSE/NEON 최적화(iOS지원)
– libjpeg보다 2-4x 빠름
JPEG 압축 과정
• 1. RGB를 YCbCr로 변환
• 2. 8x8블럭 DCT 변환
• 3. Quantize
• 4. Huffman Coding
RGB를 YCbCr로 변환
• 사람의 눈은
/ 보다 / 에 민감
–색상의 변화보다 밝기의 변화에 더 민감
RGB를 YCbCr로 변환 #2
• Y채널: 휘도, 밝기
–원본 크기 사용
• Cb/Cr: Y채널에 대한 Red/Blue의 차이
–원본의 1/4크기로 다운샘플
Y=0.5 일때, Cb/Cr
RGB를 YCbCr로 변환 #3
8x8 DCT (Discrete Cosine Transform)
• 이미지를 8x8픽셀 블록으로 분할
• 8x8블럭을 64개 패턴의 선형 조합으로 분해
• 각 패턴들에 대한 계수를 계산; 64개(=8x8)
Quantize(양자화)
• 정밀도 낮추기
• 1~100까지의 퀄리티 레벨
• C = round(D/Q)
– D : DCT 수행 이후의 계수 값
– Q : 레벨에 따른 Quantize 값
– C : Quantize 결과
Huffman Coding
• 자주 쓰이는 값에 적은 비트 수 할당
• 4개의 Huffman Table이 사용
– Code: 1~16비트 (가변길이)
– Value: 8비트
• 일반적으로 JPEG 표준 테이블 사용
–최적화 가능
(비교적) 새로운 솔루션
• (JPEG 2000)
• JPEG XR
• WebP
• WebP + DDS
• Crunch
(JPEG 2000)
• Discrete Wavelet Transform
• JPEG보다 좋은 화질(=적은 용량)
• JPEG보다 많이 느린 속도
• JPEG보다 많은 메모리 필요
• 결과적으로 비추
JPEG XR
• Microsoft (2007)
• Windows Media Photo, HD Photo
• ISO 표준 포맷 (2009)
• JPEG보다 훨씬 나은 성능과 퀄리티 • JPEG 2000보다는 약갂 떨어지는 퀄리티
• 하지만 JPEG 2000 보다 훨씬 빠름(정수 연산)
JPEG군 비교
• (용량 대비)퀄리티
– JPEG < JPEG-XR < JPEG 2000 • (인코딩/디코딩)속도
– JPEG 2000 < JPEG-XR < JPEG
JPEG XR 기능
•알파 채널 지원
• 그레이스케일 지원
• 16-bit/32-bit 실수형 지원
• 비손실 압축 지원
JPEG XR 지원 라이브러리
• Intel IPP 라이브러리
–상용, 최적화?
• HD Photo Device Porting Kit –최적화 안됨
• Windows Imaging Component
– Windows XP SP3, Vista, 7 에 포함
WebP
• Google (2010) Web을 위한 이미지 포맷
• 표준 아님 – 크롬 브라우저 지원
• JPEG보다 나은 퀄리티
– “WebP 는 JPEG보다 30%이상 더 작다”
• JPEG 2000보다 조금 퀄리티가 떨어지나 빠름 • 라이브러리: libwebp, MMX/SSE 최적화, 오픈소스
WebP 퀄리티 JPG(43.84KB) WebP(29.61KB) http://code.google.com/speed/webp/gallery.html
WebP + DDS
• WebP 로 디코딩 – 작은 파일(스토리지) 사이즈
• DXT 로 인코딩 – GPU 메모리 공갂 절약 – DXT도 인코딩이 빠르지는 않다 – J.M.P. 등의 빠른 실시갂 DXT 인코더 사용
• 단점: 손실 압축을 두번 퀄리티 저하
Crunch
• (원본 이미지가 아닌) DDS 자체를 직접 (손실) 압축
– JPG나 WebP사용 시 들어가는
–추가적인 DDS 인코딩 작업이 필요 없음
• 빠르고 용량도 DDS+ZIP에 비해 충분히 작다
• 단점: 인코딩이 꽤 느림
용량 비교
128
94
76
50
30
0
20
40
60
80
100
120
140
DDS DDS+ZIP JPG Crunch WebP
Size(KB)
(낮은 값일 수록 용량 적음)
로딩(+다운로드) 속도 비교
DDS+ZIP JPG Crunch WebP
로컬속도(ms) 2 4 3 10
네트워크속도(sec) 16.2 11.4 6.3 5
0
2
4
6
8
10
12
14
16
18
(낮은 값일 수록 빠름)
정리
• 용량이 최우선이라면, WebP+DDS –예) 실시갂 스트리밍 다운로드
• 용량과 로딩 속도 둘 다 중요하다면, Crunch • 용량보다는 로딩 속도가 중요하다면,
DDS+ZIP
레퍼런스
• How does JPEG actually work?
– JPEG알고리즘 개요
• JPEG Huffman Coding Tutorial
– JPEG 알고리즘의 쉽고 디테일한 설명
• Image Compression and the Discrete Cosine Transform : DCT 설명
레퍼런스 #2
• Real-Time DXT Compression
– J.M.P의 빠른 실시갂 DXT 압축 기법
• Crunch
– DXT 자체를 손실 압축하는 라이브러리
속도 비교 – 로컬 로딩 • 테스트 환경
–로컬PC, 512x512 RGB 텍스쳐
– JPG , WebP w/ DXT 인코딩, Crunch
• 테스트 결과 – 1. DDS + ZIP : 2 ms / texture – 2. Crunch : 3 ms / texture – 3. JPG : 4 ms / texture – 4. WebP : 10 ms / texture
• 디코딩 속도 의존적
속도 비교 – 네트워크 로딩 • 테스트 환경
– 네트워크 다운로드 – 100개 이상 텍스쳐, 1MB/sec 속도
• 테스트 결과 – 1. WebP : 4 ( 4MB) + 1 = 5 sec – 2. Crunch : 6 ( 6MB) + 0.3 = 6.3 sec – 2. JPG : 11 (11MB) + 0.4 = 11.4 sec – 3. DDS + ZIP : 16 (16MB) + 0.2 = 16.2 sec
• 파일 크기 의존적
용량 비교
타입 사이즈 비고
RAW 768KB =512x512x3
DDS 128KB 6:1압축률
DDS + ZIP 94KB 8:1압축률
JPG 76KB 10:1압축률
Crunch 50KB 15:1압축률
WebP 30KB 25:1압축률