텍스쳐 압축 기법 소개

최지호
바나나피쉬
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에 비해 충분히 작다
• 단점: 인코딩이 꽤 느림
용량 비교
140   128

120

100           94                          (낮은 값일 수록 용량 적음)
                         76
80

60                                50

40                                         30

20

 0
      DDS   DDS+ZIP      JPG     Crunch   WebP

                      Size(KB)
로딩(+다운로드) 속도 비교
           18
           16
           14
           12
           10
           8
           6
           4
           2
           0
                DDS+ZIP   JPG    Crunch   WebP   (낮은 값일 수록 빠름)
로컬속도(ms)           2       4       3       10
네트워크속도(sec)      16.2     11.4    6.3      5
정리
• 용량이 최우선이라면, WebP+DDS
 – 예) 실시갂 스트리밍 다운로드
• 용량과 로딩 속도 둘 다 중요하다면, Crunch
• 용량보다는 로딩 속도가 중요하다면,
 DDS+ZIP
Q/A
• 감사합니다!
• jiho.choi@wemade.com
레퍼런스
• 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압축률

Ndc2012 최지호 텍스쳐 압축 기법 소개

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