ee3.mokpo.ac.kree3.mokpo.ac.kr/khchoi/Multimedia/MultimediaTheoryand... · 2017-03-02 ·...
113
Transcript of ee3.mokpo.ac.kree3.mokpo.ac.kr/khchoi/Multimedia/MultimediaTheoryand... · 2017-03-02 ·...
멀티미디어 시스템 이론 및 실습
2013.12
정보전자공학과
최 경 호
목 차
1. 멀티미디어 시스템 ·············································································································1
1.1 서 론 ·······························································································································1
1.2 멀티미디어 네트워킹 시스템 구성요소 ···································································2
2. 데이터 압축 ·························································································································5
2.1 코딩 이론 ·······················································································································5
2.2 엔트로피 코딩 ···············································································································6
2.3 허프만 코딩 ···················································································································7
2.4 산술 부호화 ···················································································································8
2.5 RLC 코딩 ·····················································································································10
2.6 JPEG 코딩 ····················································································································10
3. 비디오 코딩 ·······················································································································18
3.1 서 론 ·····························································································································18
3.2 디지털 비디오 코딩 압축 기술 ···············································································21
3.3 MPEG-4 ························································································································24
3.4 H.264/MPEG-4 AVC ·································································································27
4. HEVC 코딩 ························································································································34
4.1 서 론 ·····························································································································34
4.2 HEVC 구조 ··················································································································35
5. 프로그래밍 실 습 ·············································································································41
5.1 멀티미디어 데이터 캡처 ···························································································41
5.2 비디오 데이터 처리 ···································································································55
5.3 HEVC 설치, 코딩, 디코딩 ························································································63
5.4 YUV 디스플레이 ·········································································································85
5.5 JPEG 영상 압축 ··········································································································88
6. MPEG-7 ······························································································································94
6.1 서 론 ·····························································································································94
6.2 MPEG-7 비주얼 디스크립터 분석 ··········································································95
7. 결 론 ·································································································································111
- 1 -
제 1 장 멀티미디어 시스템
1.1 서론
기존 서킷 스위칭 전화망이 패킷 스위칭, 인터넷 기반의 멀티미디어 네트워킹
환경으로 변화되며 컴퓨팅 환경 및 네트워크 망의 진화가 빠르게 일어나고 있다.
뉴스, 텔레비젼, 엔터테인먼트 분야에서 해당 컨텐츠를 실시간 혹은 온디멘드 형태
로 제공하기 위해 독자적인 스트리밍 망을 구축, 서비스하고 있으며 원격 강좌, 비
디오 화상 회의, 메시징, 엔터테인먼트, 멀티미디어 키오스크 등의 다양한 응용 서
비스가 활성화 되고 있다. 멀티미디어 서비스는 단방향 서비스에서 그림 1.1 에서와
같은 인터넷 망 기반의 다양한 양방향 서비스로 진화되고 있다.
그림1.1 다양한 양방향 멀티미디어 서비스 개념도
디지털 데이터 압축 기술의 진보로 고해상도, 고품질의 디지털 방송이 도래하였
으며 여기에 사용자와의 대화기능이 결합되어 다양한 서비스로 진화되고 있다. 추
가적으로 유무선 네트워킹 환경의 진화는 사무실이나 집 밖에서도 고속의 인터넷
서비스를 제공하고 있다. 데이터 망의 진화 내용은 표 1.1 과 같다.
- 2 -
Services/Networks Data ratesPOTS
TISDN
ADSL
VDSL
CATV
OC-N/STS-N
Ethernet
Fast Ethernet
Gigabit Ethernet
FDDI
802.11b
802.11a/g
28.8–56 kbps
64–128 kbps
1.544–8.448 Mbps (downlink) 16–640 kbps (uplink)
12.96–55.2 Mbps
20–40 Mbps
N · 51.84 Mbps
10 Mbps
100 Mbps
1000 Mbps
100 Mbps
1, 2, 5.5, and 11 Mbps
6–54 Mbps
표 1.1 데이터 망과 데이터 전송속도의 진화
멀티미디어 서비스는 디지털 방송으로부터 인터넷 망에서의 멀티미디어 스트리
밍으로 변화되고 있으며, 유선의 인터넷 망에서 무선의 인터넷 망 서비스로 진화되
고 있다. 그림 1.2 는 무선 인터넷 망에서 활용되는 기술에 대한 통신 거리와 데이
터 전송용량간의 관계를 보여준다.
그림 1.2 다양한 IEEE 802.11 a/b/g/n 무선랜 기술의 데이터 전송용량과 도달
거리간 관계도
- 3 -
1.2 멀티미디어 네트워킹 시스템 구성요소
멀티미디어는 텍스트, 음성, 오디오, 영상, 비디오, 그래픽스, 애니메이션, 문서
등 다양한 포멧의 데이터를 결합 및 연계한 데이터로 정의된다. 멀티미디어 데이터
를 성공적으로 전송 및 분배하기 위해 고려해야 할 중요한 4가지 구성요소가 있다.
압축되지 않은 멀티미디어 데이터는 표 1.2 에서와 같이 방대한 양의 데이터에 해
당하며 고속 인터넷 망을 이용하는 경우에도 데이터 전송에 필요한 대역폭이 충분
하지 못하게 된다. 그래서 첫 번째 구성요소는 멀티미디어 데이터의 압축 기술 이
라고 할 수 있다.
표 1.2 멀티미디어 데이터의 전송 요구량
SourceBandwidth
(Hz)Sampling rate (Hz)
Bits per
sampleBitrate
Telephone voice 200–3400 8000 samples/s 12 96 kbps
Wideband speech 50–7000 16 000 14 j224 kbps
Wideband audio
(2 channels)20–20 000 44100 samples/s
16 per
channel
1.412 Mbps
(2 channels)
B/W documents 300 dpi 1 90 kb per inch2
Color image 512x512 246.3 Mb per
image
CCIR-601 (NTSC) 720x576x25 (DVD) 24 248.8 Mbps
CCIR-601 (PAL) 720x576x725 24 248.8 Mbps
Source input format
(SIF)F352x240x30 (VCD) 12 30 Mbps
Common intermediate
format (CIF)352x288x30 12 37 Mbps
Quarter CIF (QCIF) 176x144x7.5 12 2.3 Mbps
High definition DVD 1920x1080x30 24 1492 Mbps
멀티미디어 데이터의 압축은 전송망의 효과적인 사용 및 통신에 요구되는 전력
을 절감하는 차원에서도 매우 중요한 구성요소라 할 수 있다. 서로 다른 터미널 간
에 압축된 비트스트림의 전송 및 수신 단말기에서의 디코딩을 위해서 압축을 위한
표준기술이 요구된다. 데이터가 압축되면 압축된 비트스트림은 패킷으로 만들어지
고 인터넷 망을 통해서 보내지게 된다. 따라서, 인터넷에서의 전송된 데이터의 품질
을 보증(Quality of Services)하는 것이 두번째 중요한 구성요소가 된다. 인터넷 망
에서의 패킷 지연, 패킷 손실, 부자연스러움(jitter) 등의 최소한의 요구조건을 만족
- 4 -
하도록 하는 기술의 개발이 필요하며, 이를 위해 네트워크 레벨이나 혹은 응용 프
로그램 레벨에서의 다양한 기법이 활용되고 있다.
무선망의 진화와 다양한 무선 단말기의 보급에 따라 유선망과 무선망이 결합된
네트워킹 환경에서 멀티미디어 정보의 전송과 분배를 위한 멀티미디어 네트워킹 기
술이 세번째 중요한 구성요소가 된다. 무선망에서는 전송에러가 증가하게 되며, 이
에 따라 유선 인터넷 망에 비해 패킷손실이 많이 발생하게 된다. 이를 극복하기 위
해 물리계층, MAC (Medium Access Control) 계층, 네트워크 혹은 응용프로그램
계층에서의 다양한 QoS 기법이 결합되어 사용되어야 한다.
마지막 구성요소로, 멀티미디어 통신 기반의 멀티미디어 방송, 인터넷 기반 방송,
메시징 서비스, 온라인 미팅 등의 다양한 서비스는 멀티미디어 네트워킹 환경 및
다양한 터미널 환경에서 상호 호환되어 동작되어야 하며 디지털 컨텐츠에 대한 저
작권(DRM, Digital Rights Management) 보호 기능도 포함하고 있어야 한다.
본 교재에서는 멀티미디어 시스템의 핵심 구성 요소 중의 하나인 비디오와 관련
된 최신 기술을 집중적으로 소개 하도록 구성하였다. 이와 함께 실무에서 요구되는
프로그래밍 개발 능력의 향상을 위한 실습 프로그램을 구성하여 학생들의 멀티미디
어 시스템 관련 실무능력을 극대화 하도록 하였다. 멀티미디어 데이터의 저장 및
처리 기술에 대한 실습을 통해서 기초적인 멀티미디어 처리 기술 및 프로그래밍 개
발 능력을 키우도록 하며, 2013년 국제표준으로 확정된 MPEG-HEVC (High
Efficiency Video Coding) 의 이론과 실습을 통해서 졸업후 멀티미디어 응용 시스템
의 개발에 국제표준 기술을 적용할 수 있는 전문가로 양성되도록 준비하였다.
- 5 -
제 2 장 데이터 압축
2.1 코딩 이론
코딩은 크게 Source 코딩과 채널 코딩으로 나눌 수 있다. Source 코딩은 영상의
압축 등에 사용되는 기법을 채널 코딩은 데이터의 오류 검출을 위한 Error
Correction 코딩을 의미한다. 일반적인 데이터/영상/비디오의 전송환경은 그림 2.1
과 같다.
그림 2.1 일반적인 영상/비디오의 전송 과정과 코딩기법과의 관계
Source 코딩에는 원래 데이터의 손실 유무에 따라 손실(Lossy)과 무손실
(Lossless) 코딩으로 구분된다. 영상과 비디오의 압축에 사용되는 표준에서는 손실과
무손실 압축 알고리즘을 결합하여 사용한다.
데이터의 압축과 복원과정을 통해서 데이터의 압축 비율을 계산할 수 있다. 그
림 2.2와 같이 복원된 데이터와 원래 데이터와의 관계에 따라 손실과 무손실을 판
정할 수 있으며 데이터의 압축 비율이 계산된다.
그림 2.2 영상의 압축 및 복원
- 무손실 압축: = X
엔트로피 코딩 혹은 복원가능 코딩 이라고 함
- 손실 압축: ≠ X
- 6 -
원래 신호와 가깝게 복원이 가능하지만 원래 신호는 복원 불가함
- 압축 비율:에사용된비트수에사용된비트수
무손실 압축은 엔트로피 코딩이라고도 불리우며 Run-length 코딩, 허프만 코딩
(Huffman coding), 산술부호화 (Arithmetic coding) 등이 이에 해당된다. 무손실 압
축은 데이터의 완벽한 복원이 가능하여 의학문서나 비즈니스 문서 등의 중요 문서
를 압축하기 위해 많이 사용된다.
2.2 엔트로피 코딩
이산 정보원의 정보량은 정보의 발생에 대한 불확실성에 비례한다. 즉, 심볼 집
합 이 있고 각각의 확률이 라고 했을때, 정보량
는 다음과 같이 정의된다.
log
log , (2.1)
여기서 정보량의 단위는 비트를 의미한다. 엔트로피는 각각의 심볼당 갖는 평균
적인 정보량으로 다음과 같이 정의된다.
log , (2.2)
여기서 H(z)의 단위는 심볼당 비트수이며, 심볼을 표현하기 위한 최소한의 비트
수를 의미한다. 예를 들어 바이너리 심볼의 경우에 각각의 확률 P에 대한 엔트로피
는 그림 2.3과 같다.
그림 2.3 바이너리 심볼에서의 심볼 확률에 따른 엔트로피 값 예
- 7 -
심볼수가 2개와 4개인 경우, 각 심볼의 확률이 아래와 같다고 하면 (2.2)에 의한
엔트로피를 계산해 보면 다음과 같다.
i = 2, p1 = 1, p2 = 0 => H = 0
i = 2, p1 = 1/2, p2 = 1/2 => H = 1
i = 4, p1 = p2 = p3 = p4 = 1/4 => H = 2
i = 4, p1 = 0.5, p2 = p3 = 0.17, p4 = 0.16 => H = 1.79
2.3 허프만 코딩
허프만 코딩은 1952년 David A. Huffman 이 개발한 엔트로피 코딩 알고리즘
으로 무손실 압축 기법에 해당한다. 허프만 코드는 확률 값을 이용하여 소팅된 바
이너리 트리를 기반으로 코딩 테이블을 생성한다. 예를 들어, 심볼 집합
이고, 각 심볼의 발생 확률이
일 때, 허프만 코드를 생
성하는 과정은 그림 2.3과 같다.
그림 2.3 허프만 코드 생성 과정 예
우선 확률이 큰 값에서 작은값으로 순서대로 정렬을 한다. 그림 2.3에서와 같이
제일 큰 확률값을 갖는 심볼 를 제일 위로, 제일 작은 확률을 가지는 심볼 를
제일 아래로 가도록 정렬 한다. 정렬을 한 이후에는 확률이 제일 작은 아래의 두
개 확률을 더해서 확률값을 다시 정렬 한다 (그림 2.3의 단계 1 참조). 반복적으로
아래의 두 개 확률값을 더해서 확룰값을 정렬한다. 이것을 마지막 두 개의 심볼이
남을때까지 반복한다 (단계 4).
이 과정이 끝나면 마지막 단계의 심볼들에 0 과 1을 부여하고 반복적으로 이 전
단계에 해당하는 심볼에 0과 1을 부여하여 코드를 생성하게 된다. 그림 2.4에 허프
만 코드를 할당하는 과정이 나타나 있다. 예를 들어, 심볼 에는 1이라는 코드가
할당되고, 심볼 에는 코드 01011가 할당됨을 의미한다.
- 8 -
그림 2.3 허프만 코드 할당 과정 예
허프만 코딩 기법은 다음과 같은 특징을 갖는다:
- 블록 코드: 각 입력 심볼에는 정해진 크기의 불변 코드가 부여되며, 디코딩은
다음에 발생하는 심볼의 순서와 무관하게 현재 코드값을 이용하여 진행됨
- 디코딩 과정 불변: 어떠한 심볼이 코딩되어도 디 코딩 과정은 하나의 동일한
방법으로 진행함
- 엔트로피 값에 근사함: 평균 코드 길이 L 은 엔트로피 값에 근사함
log ,
L = 0.42x1 + 0.31x2 + 0.12x3 + 0.09x4 + 0.04x5 + 0.02x5
= 2.06 bits/심볼
2.4 산술 부호화 (Arithmetic Coding)
허프만 코딩이 입력 심볼들의 확률이 알려진 경우에 최적의 성능을 보여주긴
하지만 입력 심볼들의 확률이 정확히 알려지지 않은 경우에는 산술 부호화가 더 나
은 압축 성능을 나타낼 수 있다. 산술 부호화는 허프만 코딩의 일반화된 형태라고
볼수 있으며, 그 구체적인 적용 예는 그림 2.4와 같다. 5가지 실볼 시퀀스
를 갖는 데이터를 가정해 보자. 5가지 심볼 시퀀스는 4개의 심볼로
표현된다고 하고 각각의 확률이 그림 2.4와 같다고 하자. 우선 각각의 심볼의 확률
값을 기준으로 심볼들이 가지는 초기 구간을 설정해야 한다. 즉, 은 [0, 0.2) 의
구간을 는 [0.2, 0.4) 등으로 구간 설정을 한다.
다음 단계에서는 그림 2.5과 같이 입력 심볼에 대해서 초기 설정된 구간을 확장
하여 입력 심볼을 표현하는 것이다. 즉, 은 [0, 0.2)의 값에 포함되고, 다음에 입
- 9 -
력된 는 [0.04, 0.08) 로, 는 [0.056, 0.072), 그리고 는 [0.0624, 0.0688), 마지
막으로 는 [0.06752, 0.0688)로 확장되는 것이다.
그림 2.4 산술 부호화를 위한 초기 구간값 설정
그림 2.5 산술 부호화 인코딩 과정
5가지 실볼 시퀀스 는 임의의 유리수, 예를 들어 0.068 로 코딩
된다. 즉, 5가지 심볼을 3자리수 10진수로 표현할 수 있다. 엔트로피를 구해 보면
log 이며, 산술 부호화에 의한 압축 성능
은 임력 심볼이 5개이고, 출력 심볼이 3개이므로 3/5=0.6 비율의 10진수로 표현됨
을 알 수 있다.
- 10 -
2.5 RLC 코딩 (Run-Length Coding)
입력 심볼의 확률이 0.5를 넘는 경우에는 허프만 코딩이 아닌 산술 부호화 코딩
이나 RLC 코딩을 사용하는 것이 더 효과적이다. RLC 코딩은 매우 간단한 비 손실
압축 기법으로 반복되는 심볼과 그 갯수를 표현하는 방법이다. RLC 코딩의 예는
다음과 같다.
입력 심볼 시퀀스:
0,0,-3,5,1,0,-2,0,0,0,0,2,-4,3,-2,0,0,0,1,0,0,-2
Run-length sequence:
#2,-3,5,1,#1,-2,#4,2,-4,3,-2,#3,1,#2,-2
(2,-3)(0,5)(0,1)(1,-2)(4,2)(0,-4)(0,3)(0,-2)(3,1)(2,-2)
2.6 Joint Photographic Experts Group (JPEG) 코딩
영상의 압축과 코딩을 위한 ISO/IEC 10918-1/2/3 표준으로 Sequential DCT,
Progressive DCT, Sequential Lossless, Hierarchical 모드를 지원한다. 입력 영상을
8x8 크기의 블록들로 나누고 DCT 변환을 수행한 후에 양자화 및 지그재그 스캔한
후에 엔트로피 코딩하여 얻어진다. 그림 2.6에 Sequential DCT 기반의 JPEG 시스템
블록도가 나타나 있다.
그림 2.6 Sequential DCT 기반의 JPEG 시스템
- 11 -
단계별 처리과정을 자세히 살펴보면 다음과 같다.
- 입력 영상을 8x8 로 구성된 블록으로 나눔 (그림 2.7 참조).
그림 2.7 입력 영상을 8x8 블록으로 나눈 예
- 컬러 영상의 경우 그레이 부분과 컬러 부분으로 나누어 처리를 진행함. 즉,
RGB를 YCbCr로 변경함 (그림 2.8 참조).
그림 2.8 RGB 영상을 YCbCr 4:2:2, 4:1:1 포맷으로 읽는 예
RGB에서 YCbCr로 변환하기 위해 사용되는 변환 메트릭스는 다음과 같다.
- Discrete Cosine Traansform (DCT) 변환을 수행함. DCT 변환은 푸리에 변환에
- 12 -
비해서 영상에서의 redundancy (중복) 성분의 제거에 효과적임. 영상에서의 2차원
DCT 변환은 다음의 식으로 표현됨.
ïî
ïíì ==
úûù
êëé +
úûù
êëé +
=
úûù
êëé +
úûù
êëé +
=
åå
åå
= =
= =
otherwise
wwC
where
vyuxvuFvCuCyxf
vyuxyxfvCuCvuF
u v
x y
,1
0,21
)(
16)12(cos
16)12(cos),()()(
41),(
;16)12(cos
16)12(cos),()()(
41),(
7
0
7
0
7
0
7
0
pp
pp
입력 영상 f(x,y) 의 8x8 블록에 대해서 주파수 변환 F(u,v) 되고, DCT 역변환을
통해서 다시 영상 f(x,y)로 변환된다. DCT 기저 영상은 그림 2.9와 같으며 DCT 역
변환은 기저 영상의 가중치 합이라고 할 수 있다 (그림 2.10 참조).
그림 2.9 DCT 변환에 사용되는 기저영상
- 13 -
그림 2.10 DCT 변환 기저 영상 가중치 합의 예
- DCT 변환된 계수는 미리 정해진 양자화 테이블을 통해서 양자화 됨. Y 성분
과 CbCr 성분의 양자화 테이블은 표 2.1, 표 2.2와 같음.
표 2.1 Y 성분에 대한 양자화 테이블
16 11 10 16 24 40 51 61
12 12 14 19 26 58 60 55
14 13 16 24 40 57 69 56
14 17 22 29 51 87 80 62
18 22 37 56 68 109 103 77
24 35 55 64 81 104 113 92
49 64 78 87 103 121 120 101
72 92 95 98 112 100 103 99
표 2.2 CbCr 성분에 대한 양자화 테이블
17 18 24 47 99 99 99 99
18 21 26 66 99 99 99 99
24 26 56 99 99 99 99 99
47 66 99 99 99 99 99 99
99 99 99 99 99 99 99 99
99 99 99 99 99 99 99 99
99 99 99 99 99 99 99 99
99 99 99 99 99 99 99 99
즉, DCT 변환된 결과 F(u,v)를 표 2.1과 2.2의 값 Q(u,v)를 이용하여 나눈후에
정수화 하여 표현하게 됨.
- 14 -
정수화
- DC 성분은 이전 DC 성분과의 차이값을 코딩하고 지그재그 스캔, Run-Length
Coding 을 통한 데이터의 추가 압축을 함 (그림 2.11 참조).
그림 2.11 DC 성분 코딩 및 지그재그 스캔
예를 들어, DCT 변환 결과가 다음과 같다고 하자.
양자화 테이블을 이용한 양자화 결과는 다음과 같다.
- 15 -
이전 블록에서의 DC 값이 12라고 가정했을 때 지그재그 스캔후 RLC 코딩의 결
과는 다음과 같다. EOB 는 End of Block을 의미함.
{3, 0, -2,-1,-1,-1, 0, 0,-1, EOB}
=> 3,(1,-2), (0,-1), (0,-1), (0,-1), (2,-1), EOB
허프만 코딩의 또 다른 예로 다음과 같은 AC 부분의 RLC 코드가 있다고 하자.
허프만 코딩을 해보자. RLC 결과 => (0,57) (0,45) (4,23) (1,-30) (0,-8) (2,1) (0,0)
- 각각의 RLC 값은 해당하는 값이 포함되는 카테고리와 값으로 다시 표현된다.
JPEG에서 정의되어 있는 DC, AC 카테고리 값과 해당 카테고리에서 표현 가능
한 값은 다음과 같다.
표 2.3 카테고리와 계수 값
- 16 -
- (0,57) (0,45) (4,23) (1,-30) (0,-8) (2,1) (0,0) 값중에서 오른쪽에 있는 값을 카테
고리와 해당 값으로 코딩한다. ((0,0), (15,0) 는 예외.)
즉, 57은 카테고리 6에 포함되며 해당하는 비트값은 111001 이므로 (0,57) 은
(0,6,111001)로 변환되며, (0,45)는 카테고리 6 이므로 (0,6,101101)로 변환된다. 즉,
(0,57) (0,45) (4,23) (1,-30) (0,-8) (2,1) (0,0) 는 다음과 같이 변환된다.
=> (0,6,111001) ; (0,6,101101) ; (4,5,10111); (1,5,00001) ; (0,4,0111) ; (2,1,1) ; (0,0)
- 괄호안의 앞 2개의 수를 바이트로 변환한다. 첫 번째 수는 앞에 나타났던 0 의
개수(Run)를 두 번째 수는 카테고리(Category) 값을 의미한다. 표 2.4는 JPEG에서
정의된 AC 코드를 의미한다.
표 2.4 JPEG AC code
- 17 -
(0,6,111001)에서 0/6은 111000 이고 (4,5,10111)에서 4/5는 1111111110011001 이
므로 최종 JPEG 비트 스트림은 다음과 같다.
111000 111001 , 111000 101101 , 1111111110011000 10111 ,
11111110110 00001 , 1011 0111 , 11100 1 , 1010
- 실제 값의 코딩을 위해서 해당 값이 양수인 경우에는 해당하는 이진수로 코딩함
- 코딩해야 하는 값이 음수인 경우에는 1의 보수로 코딩함
참고로 DC 의 허프만 코드 값은 표 2.5와 같다.
- 18 -
표 2.5 JPEG DC 코드
JPEG 코딩으로 압축된 영상의 예는 그림 2.12와 같다. 파일이 압축이 되어도 영
상의 품질에는 크게 문제가 없음을 알 수 있다.
그림 2.12 Univ. of Washington 캠퍼스 영상 (왼쪽 영상: 180 KB BMP 포맷, 오
른쪽 영상: 13 KB JPEG 포맷)
- 19 -
제 3 장 비디오 코딩
3.1 서론
디지털 영상 코딩에 추가하여 비디오 코딩에는 표 3.1의 다양한 데이터 포맷과
다음의 기술적인 이슈 들이 존재한다.
표 3.1 디지털 비디오 포맷
- 컬러 샘플링: 컬러 비디오의 처리해야 할 데이터 양을 줄이기 위해 컬러 성분
에 대해서 sub 샘플링을 진행한다. DVD, MPEG-1/MPEG-2 등에서 사용하는 4:2:0
포맷, Betacam에서 사용하는 4:2:2 포맷 등이 있다 (그림 3.1 참조).
- 인트라 프레임 압축: 한 장의 영상 압축에 사용되는 기법으로 JPEG 압축에서
와 같이 영상 내에서의 공간적인 중복성을 이용하여 비디오를 압축하는 기법을 의
미한다.
- 인터 프레임 압축: 비디오 압축 기법에서 가장 차별화 되며 중요한 단계에 해
당하는 것으로 프레임과 프레임 사이의 시간적인 중복성에 기반하여 비디오를 압축
하는 것으로 움직인 추정, 움직임 보상의 기법이 활용된다.
- 엔트로피 코딩: JPEG에서 사용되는 엔트로피 코딩과 유사한 것이다.
- Rate 컨트롤: 양자화 단계에서의 양자화 단계를 조정하는 것으로 비디오 전체
의 비트 레이트를 정해진 저장 용량이나 전송 용량에 맞게 조정하는 것을 의미한
다.
- 20 -
그림 3.1 Interlaced 와 progressive 스캔 비디오, 두가지 4:2:0 포맷
디지털 비디오 코딩은 International Telecommunication Union (ITU-T) 의 H.261
을 시작으로 2013년의 MPEG-HEVC (High Effeciency Video Coding) 까지 지속적
으로 진화해 오고 있다.
MPEG-1 비디오 코딩 표준은 1.5 Mbps 데이터 레이트에 352x240 입력 비디오
(SIF) 로 NTSC 비디오와 352x288 SIF로 PAL 비디오를 대체하기 위한 목적이 있었
으며 비디오 CD (VCD) 포맷의 표준으로 이용되었다. MPEG-2 비디오 코딩 표준은
MPEG-1을 개선하여 개발되었으며 High Definition (HD) 급의 DVD 에 사용되었
다.
MPEG-4는 객체 기반의 비디오 코딩 표준으로 기존의 MPEG-1/MPEG-2와는 차
별화된 기능을 가지고 개발 되었다. H.264/MPEG-4 AVC 다음 버전으로 2013년도
- 21 -
에 국제 표준으로 개발된 MPEG-HEVC (High Efficiency Video Coding) 는 Ultra
HDTV를 포함하도록 개발되었다.
그림 3.2 디지털 비디오 코딩 표준의 진화 (2013년도에 MPEG-HEVC 개발됨)
3.2 디지털 비디오 코딩 압축 기술
디지털 비디오 압축은 데이터 저장 공간을 줄이거나 데이터 전송을 효과적으로
하기 위해서 수행된다. 이를 위해서 통계적인 기법, 데이터의 중복성 제거, 엔트로
피 코딩 기법을 활용한 기법 등이 활용되고 있다. 데이터의 압축 효율을 높이는 것
과 비디오의 품질과는 트레이드오프 관계가 있으며, 데이터의 압축 효율을 높이기
위해서는 압축 알고리즘 구현상의 복잡도가 증가한다는 단점이 있다.
비디오 코딩 알고리즘은 통계적인 기법, 변환 함수를 이용한 기법, 예측 기반 기
법, 데이터 보간 기반 기법 등의 다양한 기법이 있다. 그림 3.3 은 비디오 코딩에
사용되는 다양한 압축 기법을 보여준다.
- 단순한 기법으로 Run-length encoding 기법이 있다. 허프만 코딩 기법, 산술
부호화 기법 등과 결합하여 효과적으로 데이터를 압축할 수 있다. 단순하게 데이터
삭제 (truncation) 에 의해서 데이터를 줄이는 기법도 있다. 이 기법은 DCT 변환에
서 양자화에 의해서 데이터를 제거하거나 공간영역에서 RGB 나 YCbCr 데이터의
비트수를 줄여 데이터를 줄이는 방법이다. 이외에도 Look-up table을 이용한 기법
도 있다. RGB 컬러에서 나올수 있는 224 = 1600만 컬러를 28 = 256 컬러의 LUT를
통과후 디스플레이 하는 기법 등을 의미한다.
- 22 -
- 데이터 sub 샘플링: 컬러 성분을 sub 샘플링 해서 4:2:2 혹은 4:2:0 등으로 처리
하는 것을 의미한다. 이 기법은 인간의 눈이 컬러 변화에 상대적으로 둔감하다는
특성을 기반으로 데이터를 줄이는 것이다.
그림 3.3 다양한 비디오 압축 기법
- 엔트로피 코딩: 발생 확률이 높은 심볼에는 적은 비트수를 할당하고 발생 확률
이 낮은 심볼에는 많은 비트수를 할당하여 심볼당 코딩에 사용되는 평균 비트수를
줄일 수 있다. 허프만 코딩과 산술 부호화 코딩 기법이 이에 해당한다.
- 예측 부호화 (Predictive coding), 모션 추정: 공간적으로 혹은 시간적으로 이
웃한 화소값 혹은 변환 함수 적용후의 계수값 들이 유사성이 높은 경우에는 그 차
이 값 정보 만을 코딩하여 데이터를 압축하는 효과를 얻을 수 있다. 데이터의 중복
성이 높은 경우에는 유사성이 높은 데이터의 값과 원 데이터와의 차이값을 이용하
여 코딩하는 것을 의미한다.
비디오의 경우, 영상 내에서 유사한 영역을 찾아서 (즉, motion estimation) 해당
영역의 정보 (즉, motion vector) 와 원래 영상과의 차이값을 DCT 변환, 양자화,
RLC 코딩, 허프만 코딩 하여 보낸다. 그림 3.4를 보면 영상에서 코딩 블록과 유사
한 영역을 찾기 위해 설정한 탐색 영역 (search area)을 보여 준다. 그림에서 16x16
크기의 매크로 블록을 설정하여 모션 추정을 수행하는 예를 보여준다.
- 23 -
그림 3.4 모션 추정을 위해서 16x16 매크로블럭을 나눈 예(위)와 현재 프레임 n
에서 이전 프레임 n - 1을 참조하여 유사한 블록을 찾기 위해 설정한 탐색 영역 예
(아래)를 보여줌
탐색 영역 내에서 블록내 화소값 차의 절대값 합이 제일 작은 위치를 찾아 유사
한 블록으로 판정을 하게 된다. 판정에 사용되는 함수는 (3.1)과 같다.
argmin argmin
(3.1)
- 24 -
3.3 MPEG-4
MPEG-4 에서는 기존의 비디오 코딩 표준과는 다른 객체 기반의 비디오 코딩
기법을 적용하였다. Synthetic 영상과 컴퓨터 에니메이션, 2D, 3D를 포함하고 있다.
MPEG-4의 전체적인 개요가 그림 3.5에 나타나 있다.
그림 3.5 MPEG-4 객체 기반 멀티미디어 코딩 표준
MPEG-4에서는 구체적으로는 오디오 비주얼 미디어 객체를 다루기 위한 다음의
특징을 포함하고 있다 (그림 3.6 참조).
- 미디어 객체 코딩 (Media objects coding): 오디오, 비주얼, 오디오-비주얼 컨텐
츠를 포함하는 미디어 객체를 압축하도록 지원하고 있다. 2-D 혹은 3-D 미디어 객
- 25 -
체는 자연적인 혹은 합성(synthetic) 객체 일수 있으며 카메라 혹은 마이크로 캡처된
것이나 컴퓨터에 의해 생성된 것을 모두 포함한다.
- 미디어 객체 구성(composition): 미디어 객체 들을 이용하여 새로운 미디어 객
체를 생성이 가능하다.
- 미디어 객체 다중화(multiplex): 미디어 객체와 관련한 multiplexing 이나 동기
화 작업이 가능하다. 이를 통해서 특정 미디어 객체에 맞는 Quality of Service를 제
공 가능하다.
- 미디어 객체 인터액션(interaction): 오디오 비주얼 화면과의 인터액션이 가능하
도록 지원한다.
그림 3.6 MPEG-4 특징과 적용 범위
MPEG-4 특징의 하나로 얼굴 애니메이션 기능 제공을 위해 얼굴을 구성하는 특
징점과 애니메이션 파라메터를 정의한다. 그림 3.7과 같이 84개의 3-D 특징점을 정
의하고 68개의 얼굴 애니메이션 파라메터를 정의한다
- 26 -
xy
z
11 . 5
1 1 .4
1 1. 2
10 . 2
1 0. 4
1 0 .1 0
1 0 .81 0. 6
2 .1 4
7 .1
1 1 .6 4 .6
4 .4
4 .2
5 .2
5 .4
2 . 10
2. 1 22 .1
1 1 .1
To ngue
6 .26. 4 6 .3
6 .1M outh
8 .18 .9 8. 1 0
8 .58 .3
8 . 7
8 . 2
8. 8
8 .48 .6
2. 2
2 . 3
2 . 6
2 . 82 . 9
2 .72 .5 2. 4
2 .12 .1 2 2 .1 1
2 .1 42 . 1 0
2. 1 3
1 0 .61 0. 8
1 0 .4
10 . 2
1 0 .1 05. 4
5 .2
5 .3
5 .1
1 0. 1
1 0 .910 . 3
1 0 .51 0 .7
4 .1 4 .34 .54 . 6
4 .4 4 .2
11 . 111 . 2 1 1 .3
11 . 4
11 . 5
x
y
z
N ose
9 .6 9 .7
9 .1 4 9 . 13
9 .1 2
9 . 2
9. 4 9 .1 5 9 .5
9 .3
9 .1
Te eth
9. 1 09. 1 1
9 .8
9 .9
Fe ature p oin ts a ffe cte d by F APsOthe r fe ature p oin ts
R ight eye Left eye
3 .1 3
3 .7
3 .9
3. 5
3. 1
3. 3
3 .1 1
3 .1 4
3 .1 0
3 . 12 3. 6
3. 4
3. 23 .8
그림 3.7 MPEG-4 얼굴 애니메이션 파라메터 정의
- 27 -
3.4 H.264/MPEG-4 AVC (Advanced Video Codec)
H.264/MPEG-4 AVC 는 H.264/AVC 라고도 불리우며 ITU-T Video Coding
Experts Group (VCEG)과 ISO/IEC Moving Picture Experts Group (MPEG)이 공동
으로 개발한 국제표준이다. H.264/MPEG-4 AVC 는 기존의 비디오 코딩 표준과는
다른 deblocking filter, 인트라 프레임 예측, integer transform, 움직임 예측에 있어
서 multiple reference frame을 사용, 개선된 엔트로피 코딩 기법 등의 특징을 가지
고 있다. 기존의 표준에 비해서 압축 성능을 평균적으로 2배 정도 개선한 것으로
MPEG-4 AVC의 블록도는 그림 3.8과 같다.
그림 3.8 MPEG-4 AVC 블록도
- Deblocking filter: JPEG, MPEG-1, MPEG-2, MPEG-4에서 블록 기반의 DCT 변
환을 사용하였고 이를 통해서 공간적인 중복성을 제거하여 압축을 하였다. 그러나,
블록 기반의 DCT 변환후에 양자화를 거치면서 데이터의 손실이 발생된다. 복원과
정에서 DCT 역변환을 하고 이 과정에서 블록 경계에서 잡음이 발생되게 된다.
블록 경계에서 발생되는 이러한 잡음을 제거하기 위해서 MPEG-4 AVC 에서는
deblocking filter를 이용한다. 컬러 성분(chroma)에 대해서는 8x8 필터를 적용하고,
Luma (흑백) 성분에는 16x16의 블록을 이용하여 적용한다. 디블록킹 필터를 적용하
여 블록에서 발생하는 잡음을 제거한 예는 그림 3.9와 같다.
- 28 -
그림 3.9 디블록킹 필터 적용전(왼쪽)과 적용후(오른쪽) 영상
디 블록킹 필터의 적용은 Boundary strength (경계면에서의 값)에 따라 적용하게
되며 경계면 양쪽의 블록이 인트라 코딩되어 있고, 경계면이 매크로 블록의 경계인
경우에는 강력한 필터링이 요구된다 (그림 3.10 참조).
그림 3.10 deblocking filter 적용을 위한 경계면
디블록킹 필터의 적용 조건은 다음과 같다.
BS (Boundary strength) > 0 and
|p0-q0| < and |p1-p0| < and |q1-q0| ≤ ,
여기서 , 는 양자화 파라메터인 QP 값에 따라 결정되며 오프셋 값인
FilterOffsetA, FilterOffsetB를 사용하여 QP의 값을 조정하여 원하는 강도의 필터링
을 적용할 수 있다.
- 인트라 예측 (Prediction): 휘도성분에 대한 인트라 예측은 4x4, 8x8 블록에 대
한 9 가지 예측 모드와 16x16 블록에 대한 4가지 예측모드로 구성된다. 즉, 4x4 블
록의 예측을 위해 왼쪽 혹은 위쪽의 코딩된 블록을 이용한다 (그림 3.11, 3.12 참조).
- 29 -
B C
A
D
0 1 4 5
2 3 6 7
138 9 12
15141110
8화소
16화소
그림 3.11 4x4 인트라 예측 방법
그림 3.12 4x4 인트라 예측에서의 9가지 예측 모드
16x16 블록의 경우에는 그림 3.13과 같은 수직, 수평, 평균, 평면 등 4가지의 예
측 모드를 가진다.
- 30 -
H
V ……
H
V
H
V Mean(H+V)
H
V
.
.
.
.
예측모드0(수직) 예측모드1(수평) 예측모드2(평균값) 예측모드3(평면)
그림 3.13 16x16 인트라 예측 (휘도 성분)
16x16 색차 성분의 인트라 예측은 휘도 성분과 같이 4가지 예측모드를 제공하고
색차신호의 Cb 와 Cr은 예측방향은 동일하며 휘도 성분과의 예측방향은 독립적으
로 선택된다 (그림 3.14 참조).
H
V Mean(H+V)
예측모드0(평균값)
H
V
.
.
.
.
예측모드1(수평)
H
V ……
예측모드2(수직)
H
V
예측모드3(평면)
그림 3.14 16x16 인트라 예측 (색차 성분)
- Motion Compensation: 움직임 보상에 사용하는 블록의 크기를 다양화 하여 움
직임 보상의 정확도를 높이도록 지원한다. MPEG-2에서는 16x16을 MPEG-4에서는
16x16, 8x8 블록을 사용하였으나 H.264 에서는 16x16 블록에서 4x4 블록까지 다양
한 블록의 크기를 지원한다. 그림 3.15에 H.264에서 지원하는 다양한 블록의 크기
정보를 보여준다. 실제 적용 예는 그림 3.16에 나타나 있다.
그림 3.15 H.264/AVC 의 움직임 보상을 위한 다양한 블록
- 31 -
그림 3.16 다양한 블록의 움직임 보상 적용 예
Motion estimation 블록의 크기가 8X8 화소보다 클 경우:
참조 픽쳐 번호와 움직임 벡터를 움직임보상 블록마다 부호화 함.
움직임보상 블록의 크기가 8X8 화소보다 작을 경우
sub_mb_type에서 블록형상을 표시한 후 서브 매크로 블록마다, 참조 픽쳐
번호와 움직임 벡터를 부호화 함 (그림 3.17 참조).
각 움직임보상 블록의 참조픽쳐번호
mb_type ref_idx0 ref_idx1 mv0 mv1
mb_type sub_mb_type ref_idx0 ref_idx1 ref_idx2 ref_idx3 mv0 mv1 mv2 mv3
각 움직임보상 블록의 움직임 벡터각 서브매크로블록의 참조픽쳐번호
각 움직임보상 블록의 움직임 벡터
mb_type
ref_idx
mv
: 매크로블록타입
: reference_index
: motion vector
그림 3.17 움직임 보상 부호화 방법
움직임 보상을 위해서 H.264 에서는 여러장의 참조 프레임을 가질 수 있다. 이
를 위해 참조 영상 마다 임의의 가중치를 부여한다. 그림 3.18은 3개의 참조 프레임
을 이용하여 영상을 코딩하는 예를 보여준다.
- 32 -
그림 3.18 여러장의 영상을 이용한 motion compensation 예
- 변환 함수: H.264 에서는 4x4 단위의 직교변환을 이용한다. 데이터의 수가 적
고 연산의 유효자리수가 적어 구현이 용이하다는 장점을 가진다.
예측후의 luma 및 chroma 성분의 나머지(residual) 값에 대해서 4x4 integer 변
환을 적용한다. 2-D 정수변환의 가로-세로 방향 decomposition 후의 1차원 변환 메
트릭스는 다음과 같이 정의된다.
H =
(3.2)
16x16 화소 휘도 성분의 직교 변환의 경우에는 매크로 블록을 4x4 화소 블록으
로 분할하고 분할된 4x4 블록에 정수변환을 수행한다.
변환 후에 DC 성분은 모아서 4x4 화소의 DC 블록을 생성하고 4x4 화소 DC 성
분에 하다마드 변환을 적용한다.
16x16이 아닌 나머지의 경우에는 4x4 화소 단위로 나누어 정수변환을 수행한다.
이것이 그림 3.19에 나타나 있다.
- 33 -
그림 3.19 16x16 휘도 성분의 정수 변환
16x16 크기의 색차 성분의 정수변환은 휘도 성분과 동일하게 계산한다. 단 Cb
와 Cr 성분의 경우 DC 성분의 크기가 2x2 인 하다마드 변환을 진행한다.
- 34 -
제 4 장 HEVC 코딩
4.1 서론
기존의 H.264/MPEG-4 AVC 는 MPEG-2와 표 4.1과 같은 차이점을 갖는다. 인
트라 프레임 예측, 멀티플 레퍼런스 프레임, 1/4 픽셀 모션 벡터, 디블록킹 필터, 정
수 변환 등의 다양한 차이점을 가진다. 코덱에서 요구되는 계산량 등 복잡도는 증
가하였으나 영상의 압축 효율을 약 2배 개선 하였다.
표 4.1 MPEG-2와 MPEG-4 AVC의 중요 특징
2013년 1월에 확정된 HEVC 국제 표준은 H.264에 비해서 압축 효율을 2배 이상
개선하고 Ultra HDTV를 지원하기 위해서 개발 되었다. 이번 장에서는 HEVC의
특징에 대해서 자세히 알아본다.
- HEVC 표준이란 무엇인가, 그리고 MPEG 4-AVC 와의 구체적인 차이점은 무엇
인가 ?
- HEVC 에서는 인코딩된 비디오 시퀀스의 포맷을 정의하고 있으며, 인코딩된 데
이터의 디코딩을 위한 다양한 툴을 함께 제시하고 있음
- HD 급 비디오를 넘어서는 비디오가 보편화되어 가고 있으며 모바일 단말기의
컴퓨팅 파워의 증가로 2013년도 모바일 단말기가 2003년도 데스크탑 컴퓨터의 성
능을 능가하고 있다. 따라서, 새로운 표준의 개발이 필요하게 되었음
HEVC 의 동작 원리는 기존의 표준과 큰 틀에서는 유사하다고 볼수 있다.
- 하나의 프레임을 여러개의 블록으로 나눔
- 35 -
- 각각의 블록을 inter 혹은 intra 코딩 기법을 이용하여 예측함
- 예측된 값을 원래의 프레임 값에서 빼줌
- 빼고 남은 나머지 값을 DCT 변환을 이용하여 변환하고 양자화 함
- 양자화된 값을 지그제그 스캐닝하고 예측정보, 모드정보 등의 헤더 파일을 모두
엔트로피 코딩 기법을 이용하여 코딩함
4.2 HEVC 구조
HEVC 표준의 전반적인 개념은 그림 4.1과 같다. HEVC 에서는 그림 4.1에서와
같이 코딩된 비디오의 포맷을 정의하며, 디코딩을 위한 방법을 함께 제시하고 있다.
그림 4.1 HEVC 표준
HEVC 가 가지는 특징을 간단히 기술하면 다음과 같다.
- HEVC 는 기존 표준에 비해서 다양한 블록 분할 기능을 제공함
- 각각의 비디오 프레임은 여러개의 슬라이스로 분할되며 각각의 슬라이스는
Coding Tree Units 로 구성됨
- Coding Tree Unit 은 이전 표준에서 사용되었던 매크로 블록과 같은 개념이며
기본적인 코딩 단위에 해당함
- Coding Tree Unit 은 최대 64 x 64 크기를 가질수 있음
- Coding Tree Unit 은 quadtree 구조의 Coding Unit 으로 나누어 짐
- 각각의 Coding Unit 은 Inter 혹은 Intra 방식으로 예측되며 하나 혹은 복수개
의 transform unit을 가지고 있음 (그림 4.2 참조)
- 36 -
그림 4.2 HEVC의 다양한 블록 분할 기능
HEVC 에서는 하나의 프레임에 대해서 여러개의 슬라이스로 나누어짐
- 그림 4.3은 하나의 슬라이스가 6개의 64x64 Coding Tree Units을 가진 예를 보
여주며 그림 4.4는 하나의 64x64 CTU가 4개의 32x32 영역으로 나누어진 예를 보
여줌
그림 4.3 하나의 슬라이스가 6개의 64x64의 CTU를 가진 예
- 37 -
그림 4.4 하나의 64x64 CTU가 4개의 32x32 영역으로 나누어진 예
HEVC 블록 예측 기법의 중요 특징은 다음과 같다.
- 각각의 프레임은 Intra 혹은 Inter 예측으로 코딩됨
- 첫 번째 프레임은 Intra 예측으로만 코딩됨
- 나머지 프레임은 하나 혹은 여러개의 참조 프레임을 가짐
- 각각의 Prediction Unit 은 Inter 혹은 Intra 방식으로 예측됨
- 각각의 Coding Unit 은 하나 혹은 여러개의 Prediction Units 으로 나누어짐
HEVC 코딩에서 사용되는 Transform and quantization 기법의 중요 특징을 다시
정리하면 다음과 같다.
- 블록 기반의 예측을 수행한 이후에 원래의 영상과의 차이값을 구하게 됨
- 차이값을 코딩해서 전송해야 하며, 이를 위해서 Transform 코딩을 진행하게 됨
- Transform 코딩을 위해 각각의 Coding Unit에 대해서 32x32, 16x16, 8x8, 그리
고 4x4의 변환을 적용하게 됨
- Transform 코딩을 완료한 이후에는 양자화를 진행하게 됨
- 양자화 종료후에는 그 결과값을 지그제그 스캐닝 함
- 그림 4.5 에서와 같이 각각의 CU에 서로 다른 크기의 Transform을 적용하며,
양자화후 지그제그 스캐닝을 진행함
HEVC Entropy coding 의 구체적인 내용은 다음과 같다.
- HEVC 비트 스트림은 DCT 변환후의 양자화된 계수값을 포함하고 있음
- Prediction을 위한 모션 벡터와 prediction mode 정보를 포함하고 있음
- 38 -
그림 4.5 각각의 CU에 서로 다른 크기의 Transform을 적용후 지그제그 스캔함
- Coding Tree Unit, Coding Unit 정보등을 포함하고 있음
- HEVC Entropy coding 은 이들 모든 정보를 Context Adaptive Binary
Arithmetic Coding (CABAC) 기법을 이용해서 엔트로피 코딩하도록 함
- 그림 4.6은 CABAC 코딩을 이용하여 코딩된 예를 보여주며, 파란색으로 가득찬
부분이 많은 비트수가 할당된 부분을 의미함
그림 4.6 CABAC 코딩을 이용하여 코딩된 예
- 39 -
HEVC 기타 기능은 다음과 같다.
- Mode and Motion vection prediction: HEVC 에서는 예측을 위해 다양한 타입
의 모드와 예측 기법을 포함하고 있음
- Deblocking filter: 블록 연결 부분에서 발생되는 잡음을 제거하기 위해서 컬러
성분과 그레이성분의 영상에 대해서 각각 deblocking filter를 적용함
- Sample Adaptive Offset: 옵션으로 제공되는 필터이며 디코딩된 비디오를 조금
더 스무스하게 하거나 객체의 에지를 개선하기 위해서 사용될 수 있음
- Sample Adaptive Offset 필터는 비선형 필터로 HEVC 비트 스트림에 포함될
수 있으며 look-up table를 이용하게 됨
고속의 병렬연산을 위한 기능을 추가로 제공함
- Tiles 이라는 것을 제공하여 병렬로 디코딩 되도록 지원하고 있음
- Tiles 은 픽처내의 사각형 영역으로 정의됨
- Wavefront parallel processing 이라는 인코더 모드를 제공하며 상위 두 개의
CTU가 디코딩되면 아래의 CTU를 병렬로 디코딩 되도록 지원함
이외에도 프로파일, 레벌, 타이어 등의 정보를 제공하여 영상의 크기, 초당 프레임
수, 비트레이트 등의 정보에 맞는 HEVC 코딩 툴을 결정하도록 지원함
HEVC에서 정의된 용어는 표 4.2와 같다.
- 40 -
표 4.2 HEVC에서 새롭게 정의된 용어
- 41 -
제 5 장 프로그래밍 실습
5.1 멀티미디어 데이터 캡처
이번 실습의 목적은 크게 다음의 3가지 이다.
- MFC를 이용하여 Graphical User Interface (GUI)를 작성해 보는 것
- 비디오를 캡쳐하는 프로그램을 작성하는 것
- 비디오를 디스플레이하는 프로그램을 작성하는 것
5.1.1 실습의 개요
비디오를 지원하는 프로그램을 개발하는 것은 마이크로소프트에서 제공하는 라
이브러리를 이용하면 쉽게 가능하게 된다. Video For Window (VFW)를 이용하면
비디오를 캡처하거나 디스플레이 하는 등의 기능을 쉽게 이용 가능하다. 현재 작성
된 실습은 비주얼스튜디오 2010에서 테스트 되었다.
5.1.2 New MFC 프로젝트 생성
5.1.2.1 프로젝트 타입 선택
- 새로운 응용 프로그램을 생성하기 위해서 비주얼 스튜디오를 시작한다.
- 파일 => 새로 만들기 => 프로젝트를 선택한다
- 생성할 프로젝트 타입은 C++ 이고 서브타입은 “MFC" 이다. 그리고 ”MFC 응
용 프로그램“을 생성할 것이다
- “위치”에는 생성할 프로젝트가 저장할 폴더를 지정한다. 예를 들어 Users 폴더
아래에 각자 이름과 그 아래에 class\multimedia 라고 생성하도록 하자.
C:\Users\각자이름\class\multimedia\
- 이름에는 비디오캡처를 위한 이름으로 “VideoCapture" 라고 입력하고 ”확인
“을 누른다.
이들 과정이 그림 5.1에 나타나 있다.
- 42 -
그림 5.1 파일 => 새로 만들기 => 프로젝트 과정을 통해 프로젝트 생성
- 그림 5.2의 다이얼로그 화면이 나타나면 “다음”을 선택하여 추가 옵션을 선택
하도록 한다.
그림 5.2 MFC 응용 프로그램 마법사 소개 다이얼로그로 “다음”을 누른다
- 43 -
5.1.2.2 응용 프로그램의 종류 선택
- 응용 프로그램의 종류를 선택하기 위한 옵션 다이얼로그 (그림 5.3 참조)가 나
타난다.
- 응용 프로그램 종류에서 “대화상자기반”을 선택한다. 여기서는 다이얼로그 형
태의 프로그램을 생성하고자 하기 때문이다.
- 리소스 언어는 디폴트로 두고, “유니코드 라이브러리 사용”을 선택하지 않도록
한다.
- 프로그램 스타일은 “MFC 표준”으로 선택한다.
- MFC 사용은 “공유 DLL에서 MFC 사용”을 선택한다.
- “다음“을 선택하여 사용자 인터페이스 메뉴 선택으로 이동한다.
그림 5.3 응용 프로그램 종류 선택
- 44 -
5.1.2.3 사용자 인터페이스 특징 선택
- 사용자 인터페이스에 나타날 특징을 선택한다. 여기에서 선택한 것에 따라 사
용자 인터페이스가 디스플레이 된다 (그림 5.4 참조).
- “최소화 상자”, “최대화 상자”, “시스템 메뉴”, “정보 상자”를 선택하도록 하자.
- 선택이 종료되면 “다음”을 누른다.
그림 5.4 사용자 인터페이스 설정
- 45 -
5.1.2.4 추가 기능 설정 (Advanced features)
- 다음의 메뉴 (그림 5.5) 에서는 Advanced 특징을 선택하도록 지원한다.
“ActiveX 컨트롤” 과 “공용 컨트롤 매니페스트”를 체크한다.
- 선택이 종료되면 “다음”을 누른다.
그림 5.5 고급 (Advanced) 기능 설정
- 46 -
5.1.2.5 생성될 클래스 정보
- 다음의 메뉴 (그림 5.6) 에서는 생성될 클래스의 이름을 지정하게 한다. 디폴트
로 이름이 지정되며 필요에 따라 이름을 변경할 수 있다.
- 여기에서는 이름을 변경하지 않고 “마침”을 누른다.
그림 5.6 생성될 클래스 이름 설정
5.1.2.7 비주얼 스튜디오 활용
- 비주얼 스튜디오를 이용하여 코드, GUI, 리소스 등을 확인하는 방법을 알아본
다.
- 솔루션 탐색기: 솔루션 탭을 선택하면 프로젝트 내의 소스파일, 헤더파일, 리소
스 파일의 내용이 트리구조로 디스플레이 된다. (그림 5.7 참조)
- 클래스 뷰: 클래스 뷰 탭을 선택하면 클래스를 보여주고 해당 클래스의 멤버
변수와 함수를 디스플레이 한다. (그림 5.8 참조)
- 리소스 뷰: 리소스 탭을 선택하면 프로젝트에서 사용되는 멀티미디어 리소스를
디스플레이 한다. (그림 5.9 참조)
- 47 -
그림 5.7 솔루션 탐색기 화면
- 48 -
그림 5.8 클래스 뷰 화면
- 49 -
그림 5.9 리소스 뷰 화면
- 50 -
5.1.3 생성된 프로젝트 솔루션에 파일 추가 및 빌드
- 솔루션 탭에서 “소스 파일”을 선택한다. 다음의 파일이 존재함을 확인하라.
VideoCapture.cpp
VideoCaptureDlg.cpp
stdafx.cpp
- 솔루션 탭에서 “헤더 파일”을 선택한다. 다음의 파일이 존재함을 확인하라.
VideoCapture.h
VideoCaptureDlg.h
Resource.h
stdafx.h
- 실습을 단순화 하기 위해서 배포된 프로그램을 통해 아래의 파일들을 제공하
였다. 아래의 파일을 생성한 프로젝트에 추가하도록 할 것이다.
Header Files:
VideoCapture.h
VideoCaptureDlg.h
VideoIn.h
VideoOut.h
Source Files:
VideoCapture.cpp
VideoCaptureDlg.cpp
VideoIn.cpp
VideoOut.cpp
APS Files:
VideoCapture.aps
Resource Files:
resource.rc
Resource Folder:
res
- 배포된 실습 코드에는 3개의 폴더, “VideoCapture”, “VideoPlayback”, 그리고
“AuidoUI” 가 존재한다.
- 우선 비디오캡쳐 프로그램 생성을 위해서 비주얼 스튜디오를 잠시 종료하고
“VideoCapture" 내의 .h, .cpp 모든 파일과 res 폴더를 현재 생성한 프로젝트 파일
이 있는 위치에 복사한다. (Overwrite 함.)
- 비주얼 스튜디오를 다시 시작하고 기존의 프로젝트에 복사한 .h 와 .cpp 파일
을 모두 추가해 주어야 한다. 이를 위해, 솔루션 탭의 헤더파일에서 마우스의 오른
- 51 -
쪽을 누른후 “Header files" => "추가(Add)" => "기존항목(Existing Item)"를 선택한
다. 그리고, 디렉토리 내의 모든 .h 파일을 찾아서 추가해 주면 된다. 동일한 방법으
로 ”Source files" => "추가(Add)" => "기존항목(Existing Item)"을 선택하여 모든
.cpp 코드를 추가해 준다. (그림 5.10 참조)
그림 5.10 존재하는 헤더 파일을 프로젝트에 추가하는 과정
이제 “stdafx.h" 파일을 열고 마지막 부분에 다음의 라인을 추가한다. (이미 있으
면 추가할 필요가 없다.)
#include "vfw.h"
#pragma comment(lib, "vfw32")
- 이제 솔루션을 빌드할 준비가 완료되었다. “빌드” => “솔루션 빌드”를 선택하
여 프로그램을 컴파일하고 링크한다. 에러 없이 완료가 되면 프로그램을 실행한다.
- 52 -
5.1.4 프로그램 실행
- 프로그램을 실행하면 동작 화면은 그림 5.11과 같다. 비디오 캡처링의 시작을
위해서 비디오 캡처링 장치에 연결을 해야 한다.
- “Settings" => "Connect Camera" 메뉴를 선택한다.
그림 5.11 카메라 연결 메뉴
- 카메라가 연결되면 레코드 버튼을 눌러 비디오 캡처링을 시작한다. (그
림 5.12 참조)
그림 5.12 비디오 캡처링 버튼
- 53 -
- 레코딩을 종료하기 위해서는 정지 버튼을 누른다. (그림 5.13 참조)
그림 5.13 레코딩 종료
- 레코딩 된 비디오를 파일로 저장하기 위해서 “File" => "Save"를 선택한다. 파
일 이름을 지정하면 해당 이름으로 비디오 파일이 생성된다. (그림 5.14 참조)
그림 5.14 비디오 파일 저장
- 54 -
5.1.5 비디오 디스플레이 프로그램 작성
- 비디오 캡쳐 프로그램의 작성과정과 동일한 과정을 통해서 비디오 디스플레이
프로그램을 작성한다.
- 새로운 응용 프로그램을 생성하기 위해서 비주얼 스튜디오를 시작한다.
- 파일 => 새로 만들기 => 프로젝트를 선택한다
- 생성할 프로젝트 타입은 C++ 이고 서브타입은 “MFC" 이다. 그리고 ”MFC 응
용 프로그램“을 생성할 것이다
- 위치에는 생성할 프로젝트가 저장할 폴더를 지정한다. 예를 들어 Users 폴더
아래에 각자 이름과 그 아래에 class\multimedia 라고 생성하도록 하자.
C:\Users\각자이름\class\multimedia\
- 이름에는 비디오 디스플레이를 위한 이름으로 “VideoPlayback" 을 입력하고 ”
확인“을 누른다.
- 배포된 프로그램에서 “VideoPlayback" 폴더의 모든 파일을 복사한다.
- .h 파일과 .cpp 파일을 앞에서의 과정과 동일하게 프로젝트에 추가한다.
- 솔루션을 빌드하고 실행하여 그림 5.15 의 실행 화면을 확인한다.
그림 5.15 비디오 디스플레이 실행 화면
- 55 -
5.2 비디오 데이터 처리
이번 실습은 5.1에서 수행한 비디오 캡처링 실습의 확장이다. 5.1 비디오 캡처링
프로그램의 메뉴를 수정하고 비디오 신호를 받아서 처리하는 실습을 진행한다. 이
번 실습은 숙제의 형태로 진행하게 되며 총 6문제를 해결하면서 프로그램 능력을
학습하게 된다. 숙제로 진행하는 경우에는 문제당 1점씩 총 6점에 추가적인 기능을
구현하는 경우에 1점씩 추가하여 최대 10점 만점으로 하면 된다. 추가적인 기능은
메뉴를 차별화해서 다시 디자인하거나, 영상처리 알고리즘을 추가하거나 하면 된다.
배포된 템플릿 코드를 이용하여 프로그램을 완성하면 된다.
- 문제 1. 현재 소스에 가우시안 마스크는 3x3으로 적용되어 있습니다.
이를 아래의 5x5로 수정하시오.
5x5 가우시안 마스크
3x3 마스크 적용 결과 화면 예
5x5 마스크 적용 결과 화면 예
- 56 -
- 문제 2. 현재 작성되어 있는 Sobel을 참조하여 Sobel의 X와 Y축의 변화량을 각
각 추출하는 부분을 작성하세요.
현재 작성된 코드에 의한 결과 화면
Y축 방향 결과 화면
X축 방향 결과 화면
- 57 -
- 문제 3. Threshold를 기준으로 이진화하는 메뉴를 추가/적용 하세요.
CThreshold 다이얼로그 클래스를 이용하여 이진화 메뉴 오픈시 사용자가 값을 입
력하여 이진화 결과를 출력하는 부분을 작성하세요
CThreshold 클래스
메뉴 추가 결과
- 58 -
사용자 값 입력 예
결과 화면 예
- 59 -
- 문제 4. 언샤프 마스크를 인터넷에서 찾아 메뉴에 추가하고 적용하세요.
추가된 메뉴 예
결과 화면 예
- 60 -
- 문제 5. 현재 화면을 그레이스케일로 변환하는 부분에 코드가 빠진 부분이 있
습니다. 이를 채워 넣으세요.
추가된 메뉴 예
결과 화면 예
- 61 -
- 문제 6. 현재 화면은 RGB 컬러 화면입니다. 이 화면의 절반은 R성분만 남은
반은 B 성분만 남기는 함수를 작성하고 이를 메뉴에 추가 적용하여 보세요.
추가된 메뉴 예
결과 화면 예
- 62 -
* 프로그래밍 힌트
- 배포된 코드을 수정하여 프로그램을 완성하십시오.
- 현재 프로그램의 영상처리 부분은 모두 쓰레드에서 처리됩니다.
xImageProcessing 함수 부분에 해당합니다.
문1. 마스크는 이미 주어졌으므로 해당하는 코드를 참조하여 수정합시다
문2. 현재 완성되어 있는 Sobel 함수는 X와 Y축의 변화량을 “모두 구한” 이후
더한 것입니다.
문3. CThreshold 다이얼로그를 “생성”하고 사용자가 입력한 값을 어떻게 “업데
이트”하는가를 해결하는 문제입니다.
문4. 언샤프 마스크는 주어진 마스크와 값만 다른 형태입니다. 다른 부분의 코드
를 참조하여 작성하시면 됩니다.
문5. 그레이스케일 변환 공식은 R+G+B/3 입니다.
문6. 실제 어떤 배열 안에 들어가 있는 영상 데이터의 값은 RGB 순으로 배열되
어 있지 않을 수 있습니다.
- 63 -
5.3 HEVC 설치, 코딩, 디코딩 실습
5.3.1 HEVC 설치 및 컴파일
- HEVC 소프트웨어는 다음의 장소에서 다운로드 받을수 있다.
hevc.info
https://hevc.hhi.fraunhofer.de/svn/svn_HEVCSoftware/
- 표 5.1 에 사용 가능한 프로젝트 파일이 나타나 있다. 본 실습에서는 비주얼
스튜디오 9 의 솔루션 파일을 이용하여 실습을 진행하도록 한다. 비주얼 스튜디오
10 인 경우에는 자동으로 변환하여 사용하면 된다. (이미 다운받은 파일을 배포하여
하여 실습을 진행할 예정임.)
표 5.1 사용 가능한 프로젝트 파일
개발 환경 프로젝트 파일 위치MS 비주얼 스튜디오 8
MS 비주얼 스튜디오 9
Xcode
Linux
build/HM_vc8.sln
build/HM_vc8.sln
HM.xcodeproj
build/linux/makefile
- 배포된 HEVC 프로그램을 작업 디렉토리에 복사한다.
- 비주얼 스튜디오를 실행한다.
- 배포된 HEVC 프로그램에서 솔루션 파일을 오픈하여 실행한다.
- 그림 5.16 은 솔루션 파일을 오픈하게 되면 확인할 수 있는 결과 화면이다.
- “빌드” 메뉴에서 프로그램을 다시 빌드한다.
- 64 -
그림 5.16 HEVC 솔루션 파일
5.3.2 HEVC 인코더 실행
- 배포된 HEVC 인코더의 실행을 위해서는 파라메터 파일을 함께 입력해 주어야
한다.
TAppEncoder [-h] [-c config.cfg] [--parameter=value]
-h 파라메터 사용방법에 대해서 출력한다.
-c 사용할 환경설정 (configuration) 파일을 지정한다.
--parameter=value 주어진 파라메터에 값을 지정한다.
- 65 -
명령어에 주어지는 파라메터는 주어진 순서에 따라서 처리된다. 예를 들어,
TAppEncoder -c file1.cfg --UseFoo=7 -c file2.cfg
처리결과:
- file2.cfg에서 지정된 파라메터들이 file1에서 지정한 파라메터 값을
갱신하게 됨
- file1.cfg 디폴트 파라메터를 지정된 값으로 변경함
- file2.cfg에서 "UseFoo" 라는 파라메터를 지정하지 않는다면
"UseFoo" 는 7 로 셋트됨
결론적으로 다음과 같은 형식으로 사용하면 크게 문제가 없다.
TAppEncoder -c encoder_intra_main.cfg -c BQMall.cfg
encoder_intra_main.cfg 파일에서 자주 사용하는 파라메터를 미리 지정하고,
BQMall.cfg 파일에서 해당 영상에 대한 파라메터만 지정하는 예가 된다.
비주얼 스튜디오 상에서 디버깅으로 실행을 할 경우에는 여러개의 프로젝트중에
서 인코더를 실행해야 하므로 “TAppEncoder"에서 마우스 오른쪽 버튼을 클릭하고
”시작 프로젝트로 설정“을 선택한 이후에 프로그램을 디버깅해야 인코더를 실행하
게 된다.
그리고, 디버깅시에 파라메터를 전달하기 위해서는 그림 5.17 과 같이 -c
encoder_intra_main.cfg -c BQMall.cfg 로 넘겨 주어야 프로그램이 실행된다. 이때,
configuration 파일은 프로젝트 파일이 있는 폴더에 함께 있어야 한다. (그림 5.18
참조)
- 66 -
그림 5.17 HEVC 인코더 실행을 위한 argument 설정 예
그림 5.18 프로젝트 빌드시에 프로젝트 파일이 존재하는 폴더에 configuration
파일이 존재하는 예
- 67 -
5.3.2.1 encoder_intra_main.cfg 의 내용:
HEVC 인코더 사용예에서 각 configuration 파일이 지정한 파라메터의 내용은 다음
과 같다.
#======== File I/O =====================
BitstreamFile : str.bin
ReconFile : rec.yuv
#======== Unit definition ================
MaxCUWidth : 64 # Maximum coding unit width in pixel
MaxCUHeight : 64 # Maximum coding unit height in pixel
MaxPartitionDepth : 4 # Maximum coding unit depth
QuadtreeTULog2MaxSize : 5 # Log2 of maximum transform size for
# quadtree-based TU coding (2...6)
QuadtreeTULog2MinSize : 2 # Log2 of minimum transform size for
# quadtree-based TU coding (2...6)
QuadtreeTUMaxDepthInter : 3
QuadtreeTUMaxDepthIntra : 3
#======== Coding Structure =============
IntraPeriod : 1 # Period of I-Frame ( -1 = only first)
DecodingRefreshType : 0 # Random Accesss 0:none, 1:CDR, 2:IDR
GOPSize : 1 # GOP Size (number of B slice = GOPSize-1)
# Type POC QPoffset QPfactor temporal_id #ref_pics_active ref_pic #ref_pics reference
pictures
Frame1: B 1 0 1 0 4 1 0
#=========== Motion Search =============
FastSearch : 1 # 0:Full search 1:EPZS
SearchRange : 64 # (0: Search range is a Full frame)
HadamardME : 1 # Use of hadamard measure for fractional ME
FEN : 1 # Fast encoder decision
FDM : 1 # Fast Decision for Merge RD cost
#======== Quantization =============
QP : 32 # Quantization parameter(0-51)
MaxDeltaQP : 0 # CU-based multi-QP optimization
MaxCuDQPDepth : 0 # Max depth of a minimum CuDQP for
sub-LCU-level delta QP
DeltaQpRD : 0 # Slice-based multi-QP optimization
RDOQ : 1 # RDOQ
ChromaQpOffset : 0 # ChromaQPOffset
- 68 -
ChromaQpOffset2nd : 0 # ChromaQPOffset2nd
#=========== Entropy Coding ============
#=========== Deblock Filter ============
DeblockingFilterControlPresent: 0 # Dbl control params present (0=not present, 1=present)
LoopFilterOffsetInAPS : 0 # Dbl params in APS or SliceHeader (0=SliceHeader, 1=APS)
LoopFilterDisable : 0 # Disable deblocking filter in slice header (0=Filter, 1=No Filter)
LoopFilterBetaOffset_div2 : 0 # Range: -13 ~ 13
LoopFilterTcOffset_div2 : 0 # Range: -13 ~ 13
#=========== Misc. ============
InternalBitDepth : 8 # internal bit-depth = BitDepth + BitIncrement
#=========== Coding Tools =================
SAO : 1 # Sample adaptive offset (0: OFF, 1: ON)
ALF : 0 # Adaptive loop filter (0: OFF, 1: ON)
ALFEncodePassReduction : 0 # Reduce ALF encoding passes (0:Original
16-pass, 1: 1-pass, 2: 2-pass encoding)
LMChroma : 0 # Chroma from luma intra prediction mode (0:
OFF, 1: ON)
NSQT : 0 # Non-square transforms (0: OFF, 1: ON)
AMP : 0 # Asymmetric motion partitions (0: OFF, 1: ON)
ALFMaxNumFilter : 128 # ALF Max Number Filters per picture
ALFParamInSlice : 1 # ALF params in SliceHeader or APS (0=APS,
1=SliceHeader)
ALFPicBasedEncode : 0 # ALF LCU-based or picture-based encoding
(0: LCU-based, 1: Picture-based)
SAOInterleaving : 1 # SAO interleaving flag (0: SAO parameter in
APS, 1: SAO parameter in slice data)
#============ Slices ================
SliceGranularity : 0 # Slice granularity relative the LCU size
SliceMode : 0 # 0: Disable all slice options.
# 1: Enforce maximum number of LCU in an
slice,
# 2: Enforce maximum number of bytes in an
'slice'
# 3: Enforce maximum number of tiles in a slice
SliceArgument : 1500 # Argument for 'SliceMode'.
# If SliceMode==1 it represents max.
SliceGranularity-sized blocks per slice.
# If SliceMode==2 it represents max. bytes per
slice.
# If SliceMode==3 it represents max. tiles per
- 69 -
slice.
LFCrossSliceBoundaryFlag : 1 # In-loop filtering, including ALF and DB, is
across or not across slice boundary.
# 0:not across, 1: across
EntropySliceMode : 0 # 0: Disable all entropy slice options.
# 1: Enforce maximum number of LCU in an
entropy slice,
# 2: Enforce maximum number of bins/bits in an
'entropy slice'
EntropySliceArgument : 180000 # Argument for 'EntropySliceMode'.
# If EntropySliceMode==1 it represents max.
SliceGranularity-sized blocks per slice.
# If EntropySliceMode==2 it represents max. bins
per entropy slice.
#============ PCM ================
PCMEnabledFlag : 0 # 0: No PCM mode
PCMLog2MaxSize : 5 # Log2 of maximum PCM block
size.
PCMLog2MinSize : 3 # Log2 of minimum PCM block size.
PCMInputBitDepthFlag : 1 # 0: PCM bit-depth is internal
bit-depth. 1: PCM bit-depth is input bit-depth.
PCMFilterDisableFlag : 0 # 0: Enable loop filtering on I_PCM
samples. 1: Disable loop filtering on I_PCM samples.
#============ Tiles ================
TileInfoPresentFlag : 1 # 0: tiles parameters are NOT present
in the PPS
# 1: tiles parameters are present in
the PPS
UniformSpacingIdc : 0 # 0: the column boundaries are
indicated by ColumnWidth array, the row boundaries are indicated by RowHeight array
# 1: the column and row boundaries
are distributed uniformly
TileBoundaryIndependenceIdc : 1 # 0: the column and row boundaries
do NOT break prediction mechanisms
# 1: the column and row boundaries
break prediction mechanisms
NumTileColumnsMinus1 : 0 # Number of columns in a picture
minus 1
ColumnWidthArray : 2 3 # Array containing ColumnWidth
values in units of LCU (from left to right in picture)
NumTileRowsMinus1 : 0 # Number of rows in a picture
minus 1
- 70 -
RowHeightArray : 2 # Array containing RowHeight values
in units of LCU (from top to bottom in picture)
TileLocationInSliceHeaderFlag : 0 # If TileBoundaryIndependenceIdc==0
flag is ignored.
# 1: Enable writing tile location
information to slice header.
# 0: Disable writing tile location
information to slice header.
TileMarkerFlag : 1 # If TileBoundaryIndependenceIdc==0
flag is ignored.
# 1: Enable writing tile markers.
# 0: Disable writing tile markers.
MaxTileMarkerEntryPoints : 4 # Maximum number of uniformly-spaced
tile entry points (using tile markers).
# Default=4. If number of tiles <
MaxTileMarkerEntryPoints then all tiles have entry points.
TileControlPresentFlag : 1 # 0: tiles behavior control parameters
are NOT present in the PPS
# 1: tiles behavior control parameters
are present in the PPS
LFCrossTileBoundaryFlag : 1 # In-loop filtering is across or not across
tile boundary.
# 0:not across, 1: across
#============ WaveFront ================
WaveFrontSynchro : 0 # 0: No WaveFront synchronisation
(WaveFrontSubstreams must be 1 in this case).
# >0: WaveFront synchronises with the
LCU above and to the right by this many LCUs.
WaveFrontFlush : 0 # 0: No CABAC resets are performed.
# 1: A CABAC reset is performed at
the end of each LCU line.
WaveFrontSubstreams : 1 # >0: This many substreams per
slice (or per tile if TileBoundaryIndependenceIdc=1) will be produced.
#=========== Quantization Matrix =================
ScalingList : 0 # ScalingList 0 : off, 1 : default, 2 :
file read
ScalingListFile : scaling_list.txt # Scaling List file name. If file is not
exist, use Default Matrix.
#============ Lossless ================
LosslessCuEnabled : 0 # 1: Set "qpprime_y_zero_transquant_bypass_flag=1"
and enable the lossless mode as well as the RD-based mode selection process.
- 71 -
### DO NOT ADD ANYTHING BELOW THIS LINE ###
### DO NOT DELETE THE EMPTY LINE BELOW ###
5.3.2.2 BQMall.cfg 의 내용:
#======== File I/O ===============
InputFile : ../../../TestSeq/BQMall_832x480_60.yuv
InputBitDepth : 8 # Input bitdepth
FrameRate : 60 # Frame Rate per second
FrameSkip : 0 # Number of frames to be skipped in input
SourceWidth : 832 # Input frame width
SourceHeight : 480 # Input frame height
FrameToBeEncoded : 100 # Number of frames to be coded (original=600)
BQMall.cfg 파일에서는 코딩할 파일에 대한 정보를 포함한다. 즉, 파일의 이름
(InputFile), 프레임레이트, 영상의 가로/세로 크기 등을 기술한다.
5.3.2.3 인코더 파라메터 정의
HEVC 인코더에서 사용되는 파라메터는 다음과 같이 정의된다.
표 5.2 파일, 입출력 파라메터 정의 (일부)
옵션 표현 디폴트 내용
InputFile -i
입력 비디오 파일을 지정한다
비디오 파일은 YCbCr 4:2:0 만
지원함.BitstreamFile -b 출력 비트 스트림 파일명
ReconFile -o
코딩과 함께 디코딩되어 생성될
비디오 파일 (reconstructed
video file)SourceWidth -wdt 0 비디오의 폭SourceHeight -hgt 0 비디오의 높이InputBitDepth 8 코딩에 사용할 비트의 depth
FrameRate -fr 0 입력 비디오의 프레임 레이트
FrameSkip -fs 0 처음에 스킵할 비디오 프레임수
FramesToBeEncoded -f 0 코딩될 프레임의 총수를 지정
HEVC 인코더에서 사용되는 나머지 파라메터를 상세히 정의하면 다음과 같다.
- 72 -
표 5.2 파일, 입출력 파라메터 정의 (계속)
- 73 -
표 5.3 프로파일, 레벨 파라메터
표 5.3 유닛, 단위 파라메터
- 74 -
표 5.4 코딩 구조 파라메터
표 5.5 모션 estimation 파라메터
- 75 -
표 5.6 모드 결정 파라메터
표 5.7 양자화 파라메터
- 76 -
표 5.8 엔트로피 코딩 파라메터
표 5.9 슬라이스 코딩 파라메터
- 77 -
표 5.10 deblocking 필터 파라메터
- 78 -
표 5.11 코딩 tools 파라메터
- 79 -
표 5.12 rate 컨트롤 파라메터
- 80 -
표 5.13 VUI 파라메터
- 81 -
표 5.14 SEI 메시지
- 82 -
표 5.15 하드코디드(hardcoded) 인코더 파라메터: CommonDef.h 상수
5.3.3 HEVC 디코더 실행
- 배포된 HEVC 디코더의 실행을 위해서는 파라메터 파일을 함께 입력해 주어야
한다.
TAppDecoder -b str.bin -o dec.yuv [options]
인코딩이 결과로 생성된 바이너리 파일이 str.bin 이라고 하고, 디코딩의 결과로
생성될 파일의 이름을 dec.yuv 라고 지정한 것이다. 여기서 디코딩 결과로 생성될
파일은 yuv 포맷을 가진다.
비주얼 스튜디오 상에서 디버깅으로 실행을 할 경우에는 여러개의 프로젝트중에
서 디코더를 실행해야 하므로 “TAppDecoder"에서 마우스 오른쪽 버튼을 클릭하고
”시작 프로젝트로 설정“을 선택한 이후에 프로그램을 디버깅해야 디코더를 실행하
게 된다.
디버깅시에 파라메터를 전달하기 위해서는 그림 5.19 과 같이 -b str.bin -o
dec.yuv를 argument로 넘겨 주도록 해야만 프로그램이 실행된다.
- 83 -
그림 5.19 디코더 실행을 위한 argument 설정
- 84 -
디코더 프로그램에서 사용되는 파라메터는 다음과 같이 정의되어 있다.
표 5.16 디코더 옵션
- 85 -
5.4 YUV 디스플레이 실습
HEVC 인코더 프로그램의 입력으로 사용되는 데이터는 YUV 4:2:0 포맷을 하고
있으며 디코딩 결과로 나온 결과 파일의 포맷도 YUV 이다. 즉, YUV 포맷의 데이
터를 디스플레이 하는 모듈이 필요하게 된다.
이번 실습에서는 YUV 데이터 파일 디스플레이 모듈을 구현해 봄으로써 필요시
HEVC 인코더 혹은 디코더 모듈과 결합하여 하나의 응용 프로그램을 구현하는 능
력을 익히고자 한다
RGB 컬러 포맷을 YUV 포맷으로 변환하는 방법은 다음의 변환식으로 정의 된
다. 배포된 프로그램에서는 아래의 변환식을 이용하여 YUV 입력 데이터를 RGB 로
변환후에 화면에 디스플레이 한다.
- RGB to YUV 변환:
Y = (0.257 * R) + (0.504 * G) + (0.098 * B) + 16
Cr = (0.439 * R) - (0.368 * G) - (0.071 * B) + 128
Cb = -(0.148 * R) - (0.291 * G) + (0.439 * B) + 128
- YUV to RGB 변환:
B = 1.164(Y - 16) + 2.018(Cb - 128)
G = 1.164(Y - 16) - 0.813(Cr - 128) - 0.391(Cb - 128)
R = 1.164(Y - 16) + 1.596(Cr - 128)
실습을 위해 배포된 프로그램에서 다음의 솔루션 파일을 로딩한다.
imgDisp1.sln
솔루션 파일을 로딩하면 그림 5.20 의 화면을 볼수 있다. 이 실습 프로그램은
YUV 비디오의 디스플레이 기능 외에 다른 기능이 추가 되어 있는 프로그램으로 실
습을 통해서 YUV 디스플레이 부분만을 남겨두고 나머지는 제거하거나 YUV 디스
플레이 하는 부분만을 찾아내어 다른 프로그램에서 활용하는 것을 목적으로 한다.
- 86 -
그림 5.20 YUV 디스플레이를 위한 솔루션 파일 로딩 화면
- 솔루션을 로딩후에 “빌드” 메뉴의 “솔루션 빌드”를 진행한다.
- 솔루션 빌드가 종료되면 디버그 모드를 이용하여 프로그램을 실행한다.
- 프로그램 실행화면은 그림 5.21, 5.22와 같다.
- 프로그램이 실행되면 YUV 파일명을 입력한다. 현재 프로젝트 파일이 있는 폴
더 아래에 존재하는 YUV 파일인 “carphone_qcif.yuv"를 입력한다.
- 영상의 width 와 height 정보로 176, 144를 각각 입력한다.
- 컬러 디스플레이를 위해서 "please enter option number :" 에 10을 입력한다.
- 나머지 입력의 경우 그림 5.21을 참조하여 입력하도록 한다.
- 87 -
그림 5.21 YUV 비디오 디스플레이 프로그램 실행 화면
그림 5.22 YUV 비디오 디스플레이 화면
실습의 결과물로 프로그램에서 YUV 디스플레이 모듈과 관련 없는 부분을 모두
제거하여 제출하거나, 실습 프로그램을 이용하여 다른 YUV 디스플레이 프로그램을
제작하면 된다.
- 88 -
5.5 JPEG 영상 압축 실습
다음의 코드는 Matlab을 이용한 JPEG 영상 압축-복원 실습을 위한 코드이다. 실
습을 통해서 JPEG 영상 압축 기법에 대한 이해도를 높이고 실무 능력을 키우기 위
해 준비 하였다. 이 코드는 Matlab 홈페이지에서 다운로드 되었으며 흑백 영상에
대해서 실습을 진행하고자 한다.
%% LOSSY COMPRESSION-DECOMPRESSION USNIG DISCRETE COSINE TRANSFORM TECHNIQUE.
function[]=dct1(filename,n,m)
% "filename" is the string of characters including Image name and its
% extension.
% "n" denotes the number of bits per pixel.
% "m" denotes the number of most significant bits (MSB) of DCT Coefficients.
% Matrix Intializations.
N=8; % Block size for which DCT is Computed.
M=8;
I=imread(filename); % Reading the input image file and storing intensity values in 2-D matrix I.
I_dim=size(I); % Finding the dimensions of the image file.
I_Trsfrm.block=zeros(N,M); % Initialising the DCT Coefficients Structure Matrix "I_Trsfrm" with the
required dimensions.
Norm_Mat=[16 11 10 16 24 40 51 61 % Normalization matrix (8 X 8) used to Normalize the DCT
Matrix.
12 12 14 19 26 58 60 55
14 13 16 24 40 57 69 56
14 17 22 29 51 87 80 62
18 22 37 56 68 109 103 77
24 35 55 64 81 104 113 92
49 64 78 87 103 121 120 101
72 92 95 98 112 100 103 99];
save('LenaInitial.txt','I');
%% PART-1: COMPRESSION TECHNIQUE.
% Computing the Quantized & Normalized Discrete Cosine Transform.
% Y(k,l)=(2/root(NM))*c(k)*c(l)*sigma(i=0:N-1)sigma(j=0:M-1)y(i,j)cos(pi(2i+1)k/(2N))cos(pi(2j+1)l/(2M))
% where c(u)=1/root(2) if u=0
% = 1 if u>0
for a=1:I_dim(1)/N
for b=1:I_dim(2)/M
for k=1:N
for l=1:M
prod=0;
for i=1:N
for j=1:M
prod=prod+double(I(N*(a-1)+i,M*(b-1)+j))*cos(pi*(k-1)*(2*i-1)/(2*N))*cos(pi*(l-1)*(2*j-1)/(2*M));
end
end
if k==1
prod=prod*sqrt(1/N);
else
prod=prod*sqrt(2/N);
end
if l==1
- 89 -
prod=prod*sqrt(1/M);
else
prod=prod*sqrt(2/M);
end
I_Trsfrm(a,b).block(k,l)=prod;
end
end
% Normalizing the DCT Matrix and Quantizing the resulting values.
I_Trsfrm(a,b).block=round(I_Trsfrm(a,b).block./Norm_Mat);
end
end
% zig-zag coding of the each 8 X 8 Block.
for a=1:I_dim(1)/N
for b=1:I_dim(2)/M
I_zigzag(a,b).block=zeros(1,0);
freq_sum=2:(N+M);
counter=1;
for i=1:length(freq_sum)
if i<=((length(freq_sum)+1)/2)
if rem(i,2)~=0
x_indices=counter:freq_sum(i)-counter;
else
x_indices=freq_sum(i)-counter:-1:counter;
end
index_len=length(x_indices);
y_indices=x_indices(index_len:-1:1); % Creating reverse of the array as "y_indices".
for p=1:index_len
if I_Trsfrm(a,b).block(x_indices(p),y_indices(p))<0
bin_eq=dec2bin(bitxor(2^n-1,abs(I_Trsfrm(a,b).block(x_indices(p),y_indices(p)))),n);
else
bin_eq=dec2bin(I_Trsfrm(a,b).block(x_indices(p),y_indices(p)),n);
end
I_zigzag(a,b).block=[I_zigzag(a,b).block,bin_eq(1:m)];
end
else
counter=counter+1;
if rem(i,2)~=0
x_indices=counter:freq_sum(i)-counter;
else
x_indices=freq_sum(i)-counter:-1:counter;
end
index_len=length(x_indices);
y_indices=x_indices(index_len:-1:1); % Creating reverse of the array as "y_indices".
for p=1:index_len
if I_Trsfrm(a,b).block(x_indices(p),y_indices(p))<0
bin_eq=dec2bin(bitxor(2^n-1,abs(I_Trsfrm(a,b).block(x_indices(p),y_indices(p)))),n);
else
bin_eq=dec2bin(I_Trsfrm(a,b).block(x_indices(p),y_indices(p)),n);
end
I_zigzag(a,b).block=[I_zigzag(a,b).block,bin_eq(1:m)];
end
end
end
end
end
% Clearing unused variables from Memory space
clear I_Trsfrm prod;
clear x_indices y_indices counter;
% Run-Length Encoding the resulting code.
- 90 -
for a=1:I_dim(1)/N
for b=1:I_dim(2)/M
% Computing the Count values for the corresponding symbols and
% savin them in "I_run" structure.
count=0;
run=zeros(1,0);
sym=I_zigzag(a,b).block(1);
j=1;
block_len=length(I_zigzag(a,b).block);
for i=1:block_len
if I_zigzag(a,b).block(i)==sym
count=count+1;
else
run.count(j)=count;
run.sym(j)=sym;
j=j+1;
sym=I_zigzag(a,b).block(i);
count=1;
end
if i==block_len
run.count(j)=count;
run.sym(j)=sym;
end
end
% Computing the codelength needed for the count values.
dim=length(run.count); % calculates number of symbols being encoded.
maxvalue=max(run.count); % finds the maximum count value in the count array of run structure.
codelength=log2(maxvalue)+1;
codelength=floor(codelength);
% Encoding the count values along with their symbols.
I_runcode(a,b).code=zeros(1,0);
for i=1:dim
I_runcode(a,b).code=[I_runcode(a,b).code,dec2bin(run.count(i),codelength),run.sym(i)];
end
end
end
% Saving the Compressed Code to Disk.
save ('LenaCompressed.txt','I_runcode');
% Clearing unused variables from Memory Space.
clear I_zigzag run;
%% PART-2: DECOMPRESSION TECHNIQUE.
% Run-Length Decoding of the compressed image.
for a=1:I_dim(1)/N
for b=1:I_dim(2)/M
enc_str=I_runcode(a,b).code;
% Computing the length of the encoded string.
enc_len=length(enc_str);
% Since Max. Count is unknown at the receiver, Number of bits used for each
% count value is unknown and hence cannot be decoded directly. Number of bits
% used for each count can be found out by trial and error method for all
% the possible lengths => factors of encoded string length.
% Computing the non-trivial factors of the "enc_len" (length of encoded
% string) i.e., factors other than 1 & itself.
- 91 -
factors_mat=zeros(1,0);
if enc_len<=(n+1)
realfact=enc_len;
else
for i=2:enc_len-2 % "enc_len-1" is always not a divisor of "enc_len".
if(rem(enc_len,i)==0)
factors_mat=[factors_mat,i];
end
end
% Trial and Error Method to Find the Exact count value.
for i=1:length(factors_mat)
flagcntr=0;
temp_dim=enc_len/factors_mat(i);
for j=1:temp_dim
if strcmp(enc_str(1+(j-1)*factors_mat(i):j*factors_mat(i)),dec2bin(0,factors_mat(i)))==0
if j==1
flagcntr=flagcntr+1;
else
if enc_str((j-1)*factors_mat(i))~=enc_str(j*factors_mat(i))
flagcntr=flagcntr+1;
else
break;
end
end
else
break;
end
end
if flagcntr==temp_dim
realfact=factors_mat(i);
break;
end
end
end
% Clearing unused variables from Memory space
clear factors_mat flagcntr j
% Finding out the count values of corresponding symbols in the encoded
% string and then decoding it accordingly.
dec_str=zeros(1,0);
temp_dim=enc_len/realfact;
for i=1:temp_dim
count_str=enc_str(1+(i-1)*realfact:(i*realfact)-1);
countval=bin2dec(count_str);
for j=1:countval
dec_str=[dec_str,enc_str(i*realfact)];
end
end
I_runcode(a,b).code=dec_str;
end
end
% Clearing unused variables from Memory space
clear enc_str dec_str temp_dim realfact enc_len
clear countval count_str
% Reconstructing the 8 X 8 blocks in Zig-Zag fashion.
I_rec_Trnsfm.block=zeros(N,M);
for a=1:I_dim(1)/N
for b=1:I_dim(2)/M
- 92 -
bpp=length(I_runcode(a,b).code)/(N*M); % "bpp" is the bits-per-pixel in reconstruction of image.
bpp_diff=n-bpp;
freq_sum=2:(N+M);
counter=1;
c_indx=1;
for i=1:length(freq_sum)
if i<=((length(freq_sum)+1)/2)
if rem(i,2)~=0
x_indices=counter:freq_sum(i)-counter;
else
x_indices=freq_sum(i)-counter:-1:counter;
end
index_len=length(x_indices);
y_indices=x_indices(index_len:-1:1); % Creating reverse of the array as "y_indices".
for p=1:index_len
decm_eq=bin2dec([I_runcode(a,b).code(1+m*(c_indx-1):m*c_indx),dec2bin(0,bpp_diff)]);
if decm_eq>(2^(n-1))-1
decm_eq=decm_eq-(2^n-1);
end
I_rec_Trnsfm(a,b).block(x_indices(p),y_indices(p))=decm_eq;
c_indx=c_indx+1;
end
else
counter=counter+1;
if rem(i,2)~=0
x_indices=counter:freq_sum(i)-counter;
else
x_indices=freq_sum(i)-counter:-1:counter;
end
index_len=length(x_indices);
y_indices=x_indices(index_len:-1:1); % Creating reverse of the array as "y_indices".
for p=1:index_len
decm_eq=bin2dec([I_runcode(a,b).code(1+m*(c_indx-1):m*c_indx),dec2bin(0,bpp_diff)]);
if decm_eq>(2^(n-1))-1
decm_eq=decm_eq-(2^n-1);
end
I_rec_Trnsfm(a,b).block(x_indices(p),y_indices(p))=decm_eq;
c_indx=c_indx+1;
end
end
end
end
end
% Clearing unused variables from Memory space
clear I_runcode x_indices y_indices
clear c_indx freq_sum
% Denormalizing the Reconstructed Tranform matrix using the same
% Normalization matrix.
for a=1:I_dim(1)/N
for b=1:I_dim(2)/M
I_rec_Trnsfm(a,b).block=(I_rec_Trnsfm(a,b).block).*Norm_Mat;
end
end
% Inverse-Discrete Cosine Transform on the reconstructed Matrix.
% y(i,j)=(2/root(NM))*sigma(i=0:N-1)sigma(j=0:M-1) Y(k,l)c(k)*c(l)*cos(pi(2i+1)k/(2N))cos(pi(2j+1)l/(2M))
% where c(u)=1/root(2) if u=0
% = 1 if u>0
for a=1:I_dim(1)/N
- 93 -
for b=1:I_dim(2)/M
for i=1:N
for j=1:M
prod=0;
for k=1:N
for l=1:M
if k==1
temp=double(sqrt(1/2)*I_rec_Trnsfm(a,b).block(k,l))*cos(pi*(k-1)*(2*i-1)/(2*N))*cos(pi*(l-1)*(2*j-1)/(2*M));
else
temp=double(I_rec_Trnsfm(a,b).block(k,l))*cos(pi*(k-1)*(2*i-1)/(2*N))*cos(pi*(l-1)*(2*j-1)/(2*M));
end
if l==1
temp=temp*sqrt(1/2);
end
prod=prod+temp;
end
end
prod=prod*(2/sqrt(M*N));
I_rec((a-1)*N+i,(b-1)*M+j)=prod;
end
end
end
end
% Clearing unused variables from Memory Space.
clear I_rec_Trnsfm
% Displaying the Reconstructed Image.
diff=im2double(I)*255-I_rec;
diff=diff/max(max(diff));
diff=im2uint8(diff);
I_rec=I_rec/max(max(I_rec));
I_rec=im2uint8(I_rec);
% figure,imshow(I_rec,[0,2^n-1]);
% figure,imshow(diff,[0 2^n-1])
figure, imhist(I_rec);
figure, imhist(diff);
- 94 -
제 6 장 MPEG-7
6.1 서론
MPEG-7 은 멀티미디어 데이터의 검색 및 인덱싱을 효과적으로 하기 위해 개발
된 Multimedia Content Description Interface 이다. MPEG-1, MPEG-2, MPEG-4,
H.264, HEVC 등의 비디오와 오디오 데이터의 인코딩을 위한 표준이 아니라 XML
기반으로 멀티미디어 데이터의 메타데이터를 저장하기 위한 표준이다.
MPEG-7은 멀티미디어 데이터 컨텐츠를 기술하기 위해 다음의 내용을 포함하고
있으며 표준에서 다루는 범위는 그림 6.1과 같다.
- Description Schemes (DS) 과 디스크립터 (Descriptors)
- 이것을 기술하기 위한 디스크립션 정의 언어
(Description Definition Language)
- 디스크립션을 코딩하기 위한 방법
그림 6.1 MPEG-7 표준의 범위
6장에서는 MPEG-7에서 정의된 디스크립터에 대해서 자세히 알아본다.
- 95 -
6.2 MPEG-7 비주얼 디스크립터 분석
MPEG-7에서 정의된 비주얼 디스크립터에는 컬러 디스크립터, 형태 디스크립터,
텍스처 디스크립터 등이 있다.
6.2.1 컬러 디스크립터
컬러정보는 영상과 비디오의 검색을 위해서 가장 많이 사용되는 특징이다. 컬러
특징은 배경 변화나 영상의 크기와 회전 등의 변환에 상대적으로 강인한 특성을 갖
고 있으며 정지 영상이나 비디오의 내용을 기술하는데 사용될 수 있다. 컬러 디스
크립터의 구성을 자세히 보면 그림 6.2와 같다. 컬러 디스크립터는 Color Space,
Color Quantization, Dominant Colors, Scalable Color, Color Layout,
Color-Structure, and GoF/GoP Color 등 7개로 구성되어 있다.
그림 6.2. MPEG-7 컬러 디스크립터 개요
Scalable 컬러 디스크립터(SCD)는 Hue-Saturation-Value(HSV) 컬러 공간에서 정
의되고 고정된 컬러 공간 양자화 값을 가지며 Haar 변환 인코딩 기법을 이용하고
있다. Haar 변환을 기반으로 하고 있어 디스크립터의 Scalable 한 표현 및 특징 추
출과 매칭과정에서의 복잡성에 있어서도 Scalablilty를 제공한다.
컬러 구조 히스토그램(Color Structure Histogram: CSD)은 작은 구조 윈도우
(Structure Window)를 이용하여 지역적인 컬러 분포(local color distribution)를 찾
기위해 사용된다. 상호 호환성을 위해 컬러 구조 히스토그램은
hue-min-max-difference(HMMD) 컬러 공간에서 구성된다.
Dominant Color Descriptor(DCD)는 영상에서의 주된 컬러성분의 분포 정보를
- 96 -
제공한다.
Color Layout Descriptor(CLD) 는 관심영역에 중첩된 격자 위에서의 지배적인
컬러의 공간적인 분포 정보를 제공한다. CLD는 고속의 영상 검색 및 브라우징에
효과적으로 활용이 가능한 작은 크기의 디스크립터이다.
6.2.1.1 컬러 공간
MPEG-7 에서는 다양한 컬러 공간을 제공한다. 현재 제공되는 컬러 모델은 다음
과 같다 :
- R, G, B
- Y, Cr, Cb
- H, S, V
- HMMD
- Monochrome 등
Monochrome 컬러 공간은 YCrCb 공간에서의 Y 컴포넌트를 의미한다. RGB 컬러
공간에서 다른 컬러 공간으로의 변환은 다음과 같다.
- RGB to YCbCr 컬러 변환
Y = 0.299*R + 0.587*G + 0.114B
Cb = -0.169*R - 0.331*G + 0.500*B
Cr = 0.500*R - 0.419*G - 0.081*B
- RGB to HMMD 컬러 변환
Diff = Max - Min
Sum = (max+min)/2
Hue = HSV에서 정의된 Hue와 동일
HMMD 컬러 공간은 그림 6.3과 같은 형태로 표현되며 컬러 구조 디스크립터(CSD)
에서 사용된다.
- 97 -
그림 6.3 HMMD 컬러 공간 구성도
호환성을 확보하기 위해 컬러 디스크립터를 위한 컬러 공간 사용은 표준에 의해서
규정된다. Dominant 컬러 디스크립터는 MPEG-7에서 정의된 어떠한 컬러 공간으로
도 정의가 가능하다. RGB 컬러 공간은 영상 검색에 효과적이지 못하여 어떠한 컬
러 디스크립터에서도 잘 사용되지 않는다. Scalable 컬러 디스크립터는 HSV 컬러
공간을 이용하여 기술되며 컬러 구조 히스토그램은 HMMD 컬러 공간을 이용하여
기술된다. 그리고 CLD 는 YCrCb 공간에서 기술된다.
6.2.1.2 Scalable 컬러 디스크립터 (SCD)
SCD 에서는 상호 호환을 위해 컬러 공간을 HSV로 제한한다. 이때 HSV 컬러
공간은 256개로 나뉘어지고 각각의 공간(bin) 값은 11 비트로 비 균일(nonuniform)
하게 양자화 되어 사용된다. 이때 H는 16 레벨, S와 V는 각각 4개의 레벨로 구성된
다. 효과적인 코딩을 위해 11비트 정수값은 4비트의 비선형 함수를 이용해 4비트로
변환된다. 4비트로 변환된 256-bin HSV 히스토그램은 전체 1024비트를 필요로 한
다. 이 값은 Haar 변환을 이용해 추가적으로 압축된다. Haar 변환은 그림 6.4와 같
이 더하기와 빼기 연산을 이용해 구성된다.
그림 6.4 Haar 변환
SCD 생성을 위한 전체 시스템 블록도가 그림 6.5와 같다. 계수값의 수를 다르게 선
택하거나 컬러 bin 의 수를 조정하여 Scalable한 디스크립터를 얻게 된다.
- 98 -
그림 6.5 SCD 생성을 위한 전체 시스템 블록도
6.2.1.3 컬러 Structure 디스크립터
컬러 Structure 디스크립터는 영상에서의 로컬 컬러 구조를 기술하는데 사용된
다. 컬러 구조를 기술하기 위해 8x8 형태의 구조 윈도우를 이용한다. 구조 윈도우
내에 포함된 특정 컬러의 개수를 카운트 하게 된다. 예를 들어 M개의 양자화된 컬
러가 있다고 하면 (C0, C1, C2, ..., CM-1), 컬러 Structure 히스토그램은 h(m)으로 표
현되며 (여기서, m=0, 1, 2, ..., M-1) 하나 혹은 그 이상의 컬러값 Cm을 포함하는
구조 윈도우의 개수를 의미한다. CSD 값은 HMMD 컬러 공간에서 기술되며 4개의
컬러공간 양자화 레벨에서 정의된다. 즉, 184, 120, 64, 32개의 bin으로 구성된 양자
화 공간에서 기술된다. HMMD 컬러 공간은 다음과 같이 5개의 서브공간으로 나누
어 진다.
- 99 -
CSD를 계산하기 위해서 8x8 구조 윈도우를 이용하지만 구조 윈도우의 크기는 영상
의 크기까지 커질 수 있다. 단, 총 샘플의 수는 64개로 고정된다. 다음의 룰에 의해
서 영상의 크기에 따른 구조 윈도우의 크기가 결정된다:
p = max { 0, round( 0.5log2WH - 8 ) }
K = 2P, E = 8K
여기서 W, H 는 영상의 폭과 높이 이며, K 는 서브 샘플링 팩터이고 E x E 값이
구조 윈도우의 크기가 된다. 영상의 크기가 256x256 보다 작은 경우에는 서브 샘플
링이 사용되지 않는다. 또 다른 예로, 영상의 크기가 640x480 인 경우에는 p = 1, K
= 2, E = 16 이다. 이 경우 16x16의 구조 윈도우가 사용되며 행과 열을 하나씩 건
너서 영상 샘플을 추출하여 히스토그램을 계산하게 된다.
Hue는 0~360도, S는 0~255, D는 0~255의 값을 갖는 3차원 정보를 quantize시켜
서 1개의 값으로 만들고 있다. 매번 같은 값에 대해서도 계속 연산 처리가 이루어
지기 때문에 QuantTable을 만들도록 하고 특징추출을 진행하도록 했으며,
CreateQuantTable의 경우 디스크립터 사용에 앞서서 초기화 과정에 포함하였다.
6.2.1.4 Dominant 컬러
영상이나 영상내의 관심 영역에서의 Dominant 컬러 집합 정보를 이용하여 영상
을 간략히 기술할 수 있다. 주어진 영역의 컬러값 들이 작은수의 대표적인 컬러값
을 이용하여 클러스터링 된다. Dominant 컬러 디스크립터는 대표 컬러값들, 각 컬
러값의 영역내에서의 퍼센티지, 공간적인 Coherency, 각 Dominant 컬러의 분산값
으로 구성된다.
F = { { ci, pi, vi }, s}, (i = 1, 2, ..., N)
여기서 ci 는 I-번째 Dominant 컬러, pi 는 해당 컬러의 퍼센티지, vi 는 분산을 각
각 의미한다. 컬러 분산값은 옵션이며 공간 Coherency s 는 영상 전체에서 도미넌
트 컬러의 공간적인 균일성을 언급하는 값이다. 도미넌트 컬러의 수는 영상에 따라
다른 값을 가지며 최대 8개의 도미넌트 컬러값이 영역을 표현하기 위해 사용될 수
있다. 주된 모듈의 예는 다음과 같다.
- centroid : 각 그룹에 속하는 모든 픽셀을 더한 후에 평균을 구해서 중심색을 찾
- 100 -
는 모듈
- cluster : 픽셀과 그룹들과의 거리를 구하고 최소 distance를 갖는 그룹에 그룹화
시키는 모듈
6.2.1.5 컬러 레이아웃 디스크립터(CLD)
CLD 는 영상 내에서 혹은 임의 형태의 영역 내에서의 컬러의 공간적인 분포를
표현하기 위해 사용된다. CLD는 스케치 기반의 영상 검색을 위한 효과적인 디스크
립터이다. 영상은 8x8 블록으로 나누어진다. 각각의 블록에 대해서 대표 영상 값을
구하게 되는데 이때 각 블록의 평균을 계산해서 이용하게 된다. 각 블록에서 구해
진 평균값을 이용하여 8x8 DCT 변환을 수행하게 된다.
그림 6.6 영상을 8x8블록으로 분할한 예
지그-재그 스캔을 이용해서 저주파 영역의 계수를 선택하며 이들을 양자화해서
CLD를 구성하게 된다. CLD 검출에 사용되는 컬러 모델은 YCrCb 이다. 구해진
CLD를 이용하여 매칭을 수행하는 방법으로 다음의 거리 계산식을 이용한다. 두 개
의 CLDs 즉, {DY, DCr, DCb) 와 {DY', DCr', DCb'}를 매칭하기 위해 식:
- 101 -
여기서 (DYi, DCri, DCbi)는 I-번째 DCT 계수를 의미한다. 거리는 일정 가중치를
곱하게 되며 가중치는 저주파에 높게 고주파에 적게 설정된다.
6.2.2 텍스처 디스크립터
텍스처 정보는 컬러와 함께 영상 검색 및 색인을 위한 강력한 로우레벨디스크립
터의 하나이다. MPEG-7 에는 3개의 텍스처 디스크립터가 정의되어 있다. 첫 번째
는 “텍스처 브라우징 디스크립터”로 텍스처의 방향성(Directionality), 규칙성
(Regularity), 거침(Coarseness) 정도를 기술한다. 두 번째 기술자로는
“Homogeneous 텍스처 디스크립터(HTD)”로 영역의 양적인 특성을 기술하며 텍스
처의 지역적인 공간-주파수 특성을 계산한다. 세 번째 기술자로 “로컬 에지 히스토
그램 디스크립터”가 있다. 선택된 영역이 균질하지 않은 경우에 사용될 수 있다.
6.2.2.1 텍스처 브라우징 디스크립터
텍스처 브라우징 디스크립터는 텍스처의 규칙성을 위해 2 비트, 방향성을 위해
6비트(3비트 x 2), 거침정도 기술을 위해 4비트(2비트 x 2)를 이용한다. 텍스처는 한
개 이상의 Dominant 방향 성분을 가질수 있어, 표준에서는 최대 2개의 방향성과
거침정도 값을 이용하여 기술된다. 텍스처의 규칙성 정도는 0에서 3의 값으로 표현
된다. 규칙성이 0 이라는 것은 규칙성이 없는 랜덤한 텍스처를 의미하며 규칙성이
3 이라는 것은 잘 정의된 방향성과 거침정도를 가진 주기적인 패턴을 의미한다. 그
림 6.7은 규칙성 정도값을 보여주는 예이다.
- 102 -
그림 6.7 규칙성(Regularity) 값의 예
텍스처의 방향성 값은 6개로 양자화 되어 기술된다. 0도를 시작으로 30도 간격으로
150까지로 구성된다. 그림 6.7 제일 왼쪽의 영상은 수평 방향과 수직 방향에 강력한
방향성분을 가지고 있다. 3비트를 이용하여 서로 다른 방향을 표현한다. 값이 0 인
경우에는 텍스처가 방향성분을 가지고 있지 않음을 의미한다. 나머지 값 0 - 6 은
각 방향을 기술하기 위해 사용된다. 텍스처의 Coarseness 값은 4개의 레벨로 기술
되며 0 은 부드러운 텍스처를 3은 거친 텍스처를 의미한다. 텍스처 브라우징 디스
크립터를 구하기 위해서는 영상이 밴드-패스 필터를 이용하여 필터링 되고 필터링
된 결과를 기반으로 디스크립터를 구하게 된다. 밴드 패스 필텅링을 위한 주파수
공간 분할 방법은 HTD에서 사용하는 방법과 유사한 방법을 사용한다. Regularity,
Directionality, Coarseness 의 조합을 이용하여 영상을 브라우징 할 수 있다. 예를
들어, 텍스처가 규칙적이고 각도를 30도 정도 갖는 텍스처를 검색할 수 있다.
6.2.2.2 Homogeneous Texture Descriptor(HTD)
HTD를 구하는 과정은 다음과 같다. 우선, 주파수 공간을 30개의 채널로 구분한
다. 그림 6.8에서와 같이 중심점에서 외부 방향으로 5개의 단계로 그리고 회전 방향
에서 각도를 30도 간격으로 나누어 채널을 구성한다. 그림 6.8에서처럼 특징 채널의
중심 주파수는 균일하게 30도 간격을 이룬다.
바깥방향(Radial)으로는 특징 채널의 중심 주파수는 한 옥타브
ws = w0*2-s, s ∈{0,1,2,3,4}
만큼 떨어져 있게 된다. 여기서 s 는 Radial 방향으로의 인덱스를 의미하고 W0 =
3/4 는 최대 중심 주파수를 의미한다.
- 103 -
그림 6.8 텍스처 정보 추출을 위한 주파수 영역 분할
각각의 채널은 2-D Gabor 함수를 이용하여 변환 된다. 2차원 Gabor 함수는 극좌표
에서 다음과 같다.
Gabor 필터링된 결과값을 이용하여 각 채널의 에너지를 계산하고 계산된 에너지의
편차값을 계산한다. 이렇게 계산된 HTD 값은 다음과 같다:
TD = [ fDC, fSD, e1, e2, ..., e30, d1, d2, ..., d30]
fDC 는 밝기값의 평균을 fSD, 는 표준편차 값을 의미한다.
6.2.2.3 에지 히스토그램 디스크립터
에지 히스토그램 디스크립터는 에지의 공간적인 분포를 기술한다. 그림 6.9에 디
스크립터 값을 구하는 과정이 나타나 있다. 전체 영상을 4x4의 16개 부분 영상으
로 분할하고 분할된 각각의 영상을 다시 임의의 개수로 나누어 이미지 블록을 생성
한다. 이미지 블록의 개수가 1100가량일 때 실험 결과가 가장 좋음이 알려져 있다.
( ). 각 서브 블록에서의 에지 히스토그램을 계산한
다. 이때, 나누어진 블록을 2x2 블록으로 다시 나누고 각각의 블록에서의 평균값을
- 104 -
구해서 그 값을 해당 블록의 대표 값으로 정한다.
그림 6.9 에지 히스토그램 디스크립터 계산과정
그림 6.10 에지의 방향 성분
에지 정보는 그림 6.10의 수직, 수평, 45도 대각선 방향, 135도 대각선 방향, 그리
고 정해진 방향 없음 등의 5개의 카테고리로 나누어진다. 즉, 각각의 지역 히스토그
램이 위의 5가지 방향에 해당하는 히스토그램 bin을 가지게 된다. 입력 영상이 16개
의 서브 영역으로 구성되므로 전체적으로는 80개의 히스토그램 빈을 가진다. 이들
각각의 빈은 3 비트로 양자화 된다. 그림 6.9의 2x2 블록에서 구한 대푯값에 그림
6.10의 필터를 적용하여 에지 정보를 추출한다.
그림 6.10 에지 마스크
- 105 -
그림 6.11 빈(Bin)에 저장되는 에지정보
이와 같이 구한 80개의 빈에 저장된 에지정보는 각 3 비트 정수로 표현되며 L1 거
리를 이용해서 매칭을 진행하게 된다.
6.2.3 Shape 디스크립터
Shape 정보는 객체의 인식을 위한 강력한 특징정보를 제공하고 있어 객체 인식
을 위해 효과적으로 사용이 가능하다. 사람의 경우 객체의 형태정보 만을 이용하여
객체가 무엇인지 인식이 가능하다. 즉, Shape 정보는 컬러, 모션, 텍스처 등과는 차
별화된 정보를 제공한다고 볼 수 있다. MPEG에서는 3차원 객체의 Shape 정보 기
술을 위해 3D-Shape 기술자를 정의하며 3차원 객체의 2-D 투영된 정보를 기술하기
위한 툴들도 지원한다.
2D 영상의 경우에도 영상의 유사도 측면에서 보면 두 가지의 다른 설명이 가능
하다. 그림 6.12를 이용하여 구체적으로 알아보자.
그림 6.12 윤곽선(contour)과 영역(region)기반의 Shape 유사 예 (IEEE-CSVT, 2001)
그림 6.12에서 영역 기반으로 유사도를 판정한다고 하면 첫 번째 줄의 객체들은
상당히 유사하다고 할 수 있다. 그러나 이들은 윤곽선을 기준으로 본다면 상당히
- 106 -
다른 값을 가지고 있음을 알 수 있다. 윤곽선 기반으로 유사도를 판정한다고 한다
면 각 컬럼 내의 영상들이 서로 유사한 값을 가질 것이다. 만일, 첫 번째 줄 두번째
컬럼의 영상을 이용하여 영상 검색을 시도하는 경우에는 첫 번째 줄의 영상들이나
(영역 기반의 검색 엔진을 이용하는 경우) 두 번째 컬럼의 영상들 (윤곽선 기반의
검색 엔진을 이용하는 경우) 이 검색될 것이다. MPEG-7 에서는 이들 영역 기반의
검색과 윤곽선 기반의 검색 기법을 모두 지원한다.
사용자가 검색을 원하는 객체의 3-D 모델에 대한 정보를 알 수 없는 경우가 있
다. 예를 들어, 전자 상거래의 경우에 사용자가 구매하고자 하는 객체의 형태정보는
알 수 있으며 여러 가지 각도에서의 형태를 제시할 수 있다. 이 형태 정보를 합치
면 3차원의 객체정보를 설명한다고 할 수 있다. 이러한 경우에 2-D 정보를 활용하
여 3차원 객체를 검색하는 기능을 제공할 필요가 있다. MPEG-7에서는 2-D/3-D
Shape 기술자를 이용하여 이러한 기능을 지원할 수 있도록 한다. MPEG-7에서 제
공하는 Shape 기술자를 간단히 정리하면 다음과 같다.
6.2.3.1 3-D Shape 기술자
3-D Shape 기술자는 Shape 스펙트럼 개념에 기반을 두고 있으며 Shape 인덱스
의 확장된 형태를 갖고 있다. 3-D 표면(∑)의 한 점 p 에서 Shape 인덱스는 3-D 표
면에서의 지역 볼록함(local convexity) 정도를 표현하며 다음과 같이 정의되어 있
다:
이 식에서 k1(p)와 k2(p)는 점 p 에서의 주 곡률(principle curvature) 값을 의미하며
k1(p) ≤k2(p) 이다. 점 p 에서의 Shape 인덱스는 평면에서는 정의되지 않으며 SIΣ
(p)∈[0,1] 값을 갖는다. Shape 스펙트럼은 Shape 인덱스의 히스토그램을 의미하며
전체 3-D 공간에 대해서 계산된다. 3차원 메쉬(mesh)의 경우에는 각 꼭지점에 대해
서 Shape 인덱스가 계산된다. 3-D Shape 기술자는 100개의 구간(bin)으로 나뉘어
계산되며 각각의 구간 값은 12 비트로 표현된다.
6.2.3.2 영역 기반 Shape 기술자
영역 기반의 Shape 기술자는 2차원 객체의 영역에 대한 화소 분포(pixel
distribution) 정보를 나타낸다. 이 기술자는 중간에 구멍이 있거나 혹은 구멍이 없
는 하나의 영역으로 구성된 단순한 객체에서 여러 개의 분리된 영역으로 구성된 복
- 107 -
잡한 객체까지 기술할 수 있다.
영역 기반 Shape 기술자의 주요 특성은 다음과 같다.
- 서로 구분된 여러 영역에 대한 정보를 효과적으로 기술하는 방법을 제공한다.
- 영역 세그멘테이션 과정에서 객체는 분리되어 서로 다른 두 개의 영역으로 분리
될 수도 있다. 이 경우에는 어떤 영역이 두 개로 분리되었는지 정보를 함께 기술하
여 해당 객체의 검색을 가능하게 한다.
- 영역 기반 기술자는 세그멘테이션 노이즈(e.g., salt and pepper noise)에 강인하
다.
영역 기반 Shape 기술자는 모멘트 기반의 Shape 해석 기술에 속하며 2-D
ART(Angular Radial Transformation)을 이용한다. 2-D ART는 단위 디스크 상에서
의 극좌표로 정의된다. 각 Shape 에서 ART 계수집합 Fnm이 다음의 식에 의해서 추
출된다:
여기서 f(ρ, θ)는 극좌표계에서의 화소값을 의미하며 Vnm(ρ, θ)는 차수 n, m 에서
의 ART basis 함수를 의미한다. ART basis 함수는 중심에서의 거리 및 각도에 따
라 분리 가능한 함수로 다음과 같이 정의된다:
영역기반 Shape 기술자는 140 비트를 디폴트 값으로 갖고 있으며 n=10, m=10에서
35 개의 계수(각 계수당 4 비트로 양자화 됨) 값을 갖는다.
6.2.3.3 윤곽선 기반의 Shape 기술자
윤곽선 기반의 디스크립터는 객체의 외곽선에 대한 성질을 기술하게 된다.
Feature의 구성요소는 Peak의 개수인 NumberOfPeaks, Circularity와 Eccentricty를
의미하는 GlobalCurvatureVector, 필터링을 거친 후의 Circularity와 Eccentricity를
의미하는 PrototypeCurvatureVector, Peak의 크기가 가장 큰 것인 HighestPeakY,
- 108 -
그리고 Peak의 개수에 따른 Peak정보인 Peaks[]로 이루어져 있다.
추출 과정은 Contour추출과 Peak추출 등 2가지로 나눌 수 있으며, 순차적으로 이뤄
진다. peak추출의 경우 Contour추출 부분에서 Contour를 찾게 될 경우에만 수행되
어진다. 여러 개의 영역으로 구성된 객체의 경우에는 각각의 객체에 대한 윤곽선
정보를 개별적으로 기술한다. 윤곽선 기반의 기법으로 기술될 수 있는 영상의 예는
그림 6.13과 같다.
그림 6.13 윤곽선 기반 디스크립터 적용 가능 영상 예 (IEEE-CSVT, 2001)
윤곽선 기반의 기술자는 Curvature Scale-Space(CSS)에서 기술되며 전통적인
CSS 기법에 추가적인 성능 개선을 통해 강인한 윤곽선 기반의 Shape 기술자를 구
성한다. 추가적인 성능개선의 내용은 다음과 같다:
- 전역(global) Shape 파라메터를 추가함
- 영상 검색의 성능 향상을 위해 파라메터 공간에서 특징 벡터의 변환이 추가됨
- 109 -
- 기술자의 크기를 줄이기 위한 새로운 양자화 기법의 도입
윤곽선 기반 Shape 디스크립터의 성질은 다음과 같다:
- 영역 기반의 Shape 디스크립터에서는 유사한 값이 나오는 비슷한 영상이지만 윤
곽선의 형태가 다른 경우에 차별화된 디스크립터 값을 출력함
- 사람에게 유사한 형태로 보이는 그림 6.13 (c) 객체들도 구분할 수 있는 성능을 제
공함
- 그림 6.13 (d)와 같이 nonrigid 한 변형과 그림 6.13 (e) 와 같은 변환에도 강인한
성능을 제공함
다음 그림의 예를 보면 영역의 형태는 유사하지만 윤곽선 기반의 디스크립터가 값
이 다름을 확인할 수 있다.
그림 6.14 유사한 영상에 대한 CSS 이미지의 예 (IEEE-CSVT,2001)
윤곽선 형태를 이용하여 CSS를 기술하기 위한 방법은 다음과 같다. 우선, N 개
의 균일한 간격의 점을 윤곽선에서 선택한다. 시작점의 위치는 임의로 선택되며 반
시계 방향으로 회전을 시킨다. 선택된 N 개의 점에 대한 X 좌표와 Y 좌표를 따로
모아 점들의 시리즈로 구성한다. 이렇게 구성된 윤곽선 정보는 저역통과 필터를 이
용하여 잡음을 제거하게 된다. 저역통과 필터로 사용되는 커널함수는 예를 들어
- 110 -
(0.25, 0.5, 0.25)로 구성될 수 있다. 스무딩을 수행하게 되면 잡음이나 기타 이유에
의해서 존재하는 오목한 영역을 제거하게 되며 점차적으로 윤곽선이 볼록하게 된
다. 이 과정은 그림 1-3과 같은 CSS 이미지로 표현될 수 있다. 제일 아래에 있는 객
체가 원래 객체의 윤곽선을 의미하며 필터링 과정을 통해서 얻어진 새로운 객체의
윤곽선이 그림의 윗부분에 나타나 있다. CSS 이미지의 수평축 값은 선택된 N 개의
포인트의 X 좌표를 의미한다. CSS 이미지의 수직축은 필터링된 횟수를 의미한다.
각각의 수평 라인 들은 필터링된 횟수에 해당하는 스무딩된 윤곽선 정보를 기술한
다. 스무딩된 윤곽선에서 영교차점(zero crossing)을 구한다. 이때, 영교차점은 오목
한 영역과 볼록한 영역을 구분하는 위치가 된다. 그림 6.14에 나타난 것과 같이
CSS 이미지는 최댓값 (CSS peaks)를 갖게 된다. 각각의 피크는 (x_ces, y_ces)값으로
표현되며 이들 피크 값의 y 성분을 정렬하여 양자화 해서 표현하게 된다.
6.2.3.4 2-D/3-D 디스크립터
2-D/3-D 디스크립터는 3-D 객체를 여러 각도에서 바라보고 얻을 수 있는 2-D
특징을 결합하는 방법을 제공한다. 즉, 객체에 대한 view 기반의 3차원적인 표현을
제공한다. 2-D 기반의 비주얼 디스크립터인 컬러, 윤곽선 shape, 영역 shape, 텍스
처 등을 이용하여 기술이 가능하다.
- 111 -
제 7 장 결 론
본 교재는 멀티미디어 시스템 및 설계 교과목을 위한 이론 및 실습 교재를 개발
하여 학생들에게 멀티미디어 시스템 관련 최신 기술에 대한 소개와 멀티미디어 엔
지니어로서 갖추어야 할 실무 능력의 배양을 목적으로 준비 되었다.
멀티미디어 시스템 분야에서 비디오에 관련된 기술에 중점을 두어, 비디오의 압
축에 관련된 핵심 이론을 설명하고, H.264/MPEG4-AVC 및 HEVC 국제 표준에 관
련된 핵심 이론을 다루어 학생들에게 최신 국제표준 기술에 대한 동향 및 전문적인
기술을 학습할 수 있도록 준비 되었다.
산업체에서 요구하는 실무능력을 만족시키기 위해 멀티미디어 데이터의 캡처에
서 처리기술, 압축기술에 대한 다양한 실습을 준비하여 학생들의 프로그래밍 실무
능력을 최대한 높이도록 준비 되었다. HEVC 기술에 대한 실무능력의 확보를 위해
프로그램의 설치에서 코딩 및 디코딩을 위한 모든 실습을 준비하였다.
본 교재는 멀티미디어 시스템과련 교과목에서 이론 및 실무를 위한 교재로 활용
이 가능하도록 준비 되었다.
