CINELOVE.NET
   휴대폰토론 | 휴대폰상품기획실 | 휴대폰자료실 | 영화토론 | 영화작품실 | 영화자료실 | CONTACT
" 압축 " <-- 각 파트별 개요


 PROFILE
 CREATIVE
 CELLULAR


 CDMA
 GSM
 IMT2000
 Bluetooth
 IPv6
 VPN/PKI
 GPS
 TFT-LCD
 Camera
 OLED
 Antenna
 Battery
 Plastic
 Nano
 Compression
 Image Process
 Media Format
 Streaming
 LBS
 Virtual Machine
 Voice Recognition

 전화문의

HP : 011)9491-7906

Tel :   02)908-0540

  담당자 : 강완신

 

 압축의 개요

파일 압축이란?

파일의 내용 중 반복되거나, 필요없는 정보를 제거하여 파일의 크기를 줄이는 것을 말함.
압축시킨다는 뜻으로, compress, freeze(얼리다) 등의 용어를 사용하며, 압축을 해제 시킨다는 뜻으로 uncompress, extract(추출하다), expand(확장하다) 등의 용어를 사용한다.

파일 압축의 종류.

크게 파일 압축은 무손실(lossless) 압축과 손실(lossy) 압축으로 나눌 수 있다.
일반적인 실행 파일, 데이타 파일들은 무손실 압축 알고리즘을 이용하여 파일의 용량을 줄이나, 그래픽, 동영상 파일, 사운드 파일등은 손실 압축 방법을 사용하게 된다.

무손실 압축은 말 그대로, 압축 해제시 압축전의 데이타를 그대로 복구할 수 있다는 장점이 있지만, 압축율에는 한계가 있다.
그리고, 무손실 압축의 경우, 한번 압축한 파일을 다시 압축할 경우 더 이상 파일의 크기가 줄지 않고, 압축 해제를 위한 추가적인 정보가 덧붙여 지기 때문에 오히려 파일 크기가 증가하게 된다.

손실 압축은 데이타 중 크게 중요하지 않은 정보를 완전히 제거 시킴으로 파일 용량을 감소 시킨다.
압축 효율은 무손실 압축과 비교할 수 없을 정도로 높지만, 한번 압축된 파일이라면 이것을 가지고는 원래의 데이타를 복구 시킬 방법이 전혀 없다.
그리고, 무손실 압축과 다르게 압축을 반복할 수록 파일의 크기가 줄어든다. 즉, 파일의 정보 중 중요성이 낮은 정보를 계속 반복하여 제거 시키기 때문에 이미지 파일의 경우 그림의 질이 점점 더 나빠지게 된다.
그러나, 뛰어난 알고리즘을 이용하기 때문에 일반적으로 한번 압축으로는 보통 사람들이 질(Quality)의 손실 정도를 잘 느끼지 못한다.
손실 압축의 대표적인 예는 jpg( JPEG - Joint Picture Expert Group ), MPEG( Moving Picture Expert Group ), MP3, MP4, RA, ... 등이 있다

파일 압축의 필요성.

바이러스나, 실수, 기타 여러 가지 불의의 사고로 인한 자료의 손실을 입을 경우가 많다.
이럴 경우를 대비하기 위해 데이타를 안전한 저장 매체에 백업(Back up)해 두게 되는데, 가능하면 파일의 크기를 줄여서 저장해두는 것이 경제적일 것이다.
그리고, 컴퓨터 통신은 아직도 많은 트래픽을 발생하고 있다.
특히, LAN이 아닌 전화선을 이용한 통신이라면, 시간이 곧 돈과 직접적으로 연관되기 때문에 가능하면 짧은 시간의 통신을 원하게 된다.
그래서 통신상에 주고 받은 데이타는 압축하여 전송하는 것이 네티켓으로 받아 들여질 정도로 파일 압축은 일반적인 것이다.

무손실 압축의 종류

손실 압축은 특성상 한개 파일을 대상으로 하고, 특수 목적의 파일에 한정해서 이용하고 있다.
그러므로, 여기서는 손실 압축은 이 정도의 소개로 마무리하고, 무손실 압축을 위주로 설명한다.

압축의 종류에는 알고리즘에 따라 Crunching 방식, Squashing 방식, Lempel-ziv 방식, RLE(Run Length Encoding) 방식, 비트 패턴의 단순화 기법, dynamic Huffman 방식, static Huffman coding 방식, ...등의 다양한 방법이 있다.
확장자 별 분류로는 zip, arj, rar, ace, jar, lzh, zoo, arc, cab, ...등이 있고, 페이지를 바꿔서, 확장자별 압축 분류에서 설명하였다.
그리고, SFX, 실행 파일 압축, 파일 묶음, 플로피 디스크 백업, ... 기타 분류 방법을 들 수 있다.

알고리즘 방식에 따른 분류는 전문적인 내용이므로 생략하고, 여기서는 기타 분류 방법을 대략 설명하고, 페이지를 바꿔서 확장자 별, 프로그램 별로 분류하여 설명 하겠다.

SFX( Self Extracting File )

압축된 파일( zip, arj, rar, ace, ... )을 실행 파일( exe )로 전환함으로써 파일의 실행과 동시에 자동으로 압축이 해제되도록 한 것.
별도의 압축 해제 프로그램이 없어도 사용자가 쉽게 그 파일을 실행시킴으로서 압축을 해제할 수 있다는 장점이 있다.
그렇지만, 압축 해제를 위한 여분의 코드가 추가되어야하고, 파일 관리에 제한이 있다는 몇가지의 단점이 있다.

실행 파일 압축

주로 실행 파일중 확장자가 exe인 것만을 대상으로 하며, 압축된 실행 파일을 실행시키면 메모리에 Loading됨과 동시에 압축이 해제되어 실행되는 형태이다.
DOS용으로 pklite, diet, lzexe, exepack, 등이 있으며, 윈도우 용으로 개발된 것도 있다.

파일 묶음

유닉스의 tar과 같은 형태로, 압축은 하지 않고 여러개의 파일을 한개로 묶기만한 형태이다.
디스크 저장시, 작은 여러개의 파일이 저장되는 것보다 한개의 큰 파일이 저장되는 것이 적은 공간을 차지한다는 장점을 살릴 수 있다.
반면에 한개 파일을 지정한 크기의 여러개 파일로 자르는 유틸리티(spilit)도 있다.

플로피 디스크 백업

플로피 디스크에 저장된 모든 정보를 한개 파일로 저장하는 형태.
DOS용으로 DiskDupe, Disk Copy Fast, image등이 있고, Window 용으로 WinImant등이 있다.
Disk Copy를 Disk 대 Disk가 아니라 Disk 대 File로 복사할 수 있게 해 준다.

.손실압축

사람들이 즐기는 것중 "마술"이라는 것이 있다. 대부분의 마술이 사람의 눈속임을 하는 것임에도 불구하고 대부분의 사람들은 마술이 눈속임이라는 사실을 잊어 버리게 된다. 손실압축도 마술과 유사하다. 바로 사람의 정확하지 못한 감각을 속임하는 것이다. 즉, 내용을 인식하는데 별로 영향을 주지 않는 범위 내에서 정보들을 삭제함으로써 압축률을 높이고자 하는 기법이 손실압축이다.

손실압축은 크게 변화기법, 예측기법, 양자화 기법, 보간기법등이 있다.

A.변환기법

변환기법은 데이타의 영역을 적당한 변환을 통해 다른 영역으로 옮김으로써 데이타를 구성하는 단위 정보의 개수를 줄이는 기법이다.

.PCM변환: 이해를 돕기 위해 우선 아나로그를 디지털 파형으로 바꾸는 PCM방식에 대한 소개부터 하겠다. PCM변환은 변환기법의 가장기본으로 사용되는 기법으로 아나로그 신호로 들어오는 데이터를 표본화(Sampling), 양자화(Quantization)를 거쳐 디지털 신호로 변형하는 기법을 말한다. 이 PCM변환은 데이터 통신과 멀티미디어에서 광범위 하게 사용되고 있다. 우리가 가장 흔하게 보는 PCM변환은 모뎀과 음성압축일 것이다.

위 그림에서 보듯이 아나로그 신호는 (a)에서처럼 사인 파형을 그리고 있다. 이 사인파형은 연속된(Continous)파형이다. 하지만 이 사인파형을 미분해 보자. 이 연속된 파형은 그림(b)와 같이 이산된 형태의 파형을 얻을 수 있을 것이다. 그림(c)는 이산된 파형을 복잡한 기준값과 유사한 단순한 근사화 수치로 바꾸는 작업이다. 이렇게 변경된 파형과 데이터는 컴퓨터에서 이용될 수 있을 것이다.

 

·         영상신호는 각 데이터간의 연관성이 매우 큰 특성을 가지고 있어 변화가 적은 비슷한 값의 나열로 이루어져 있다. 영상이란 비슷한 밝기와 색상을 가진 점(화소 또는 픽셀)들이 부분적으로 모여 이루어진 집합체이다.

·         이것을 데이터의 중복성(Redundancy)이라고 하는데, 이 중복성을 제거함으로써 전체 데이터의 량을 상당히 줄이고도 충분한 정보를 전달할 수 있다. 이렇게 영상 데이터의 중복성을 제거하는 일을 영상압축(Compression) 또는 부호화(Encoding)라고 한다.

·         비디오 압축의 필요성은 비디오 파일 용량의 최소화 요구, 인터넷의 발달에 따른 비디오 자료의 활용 시 네트웍 데이터 전송속도, 그리고 기타 주변기기(CPU, 그래픽, 시스템 버스, ...)의 부하 감소의 필요에서 이다.

·         비디오의 압축방법은 데이터의 완전한 복원 가능 여부에 따라 무손실압축(Lossless Compression) 기법과 손실압축(Lossy Compression) 기법으로 구분되며, 소프트웨어에 의한 압축(Indeo, Cinepak,...)과 하드웨어에 의한 압축(JPEG, MPEG, P*64,...)으로 구분할 수 있다.

·         무손실압축 기법은 원래 영상으로의 완전한 복구가 가능하도록 압축시 미세한 데이터를 중요시하는 기법으로, X-ray, 단층촬영(CT) 등의 의료용 영상과 같은 응용분야에서 활용되며, 따라서 압축율은 비교적 낮은 2:1 ~ 3:1 정도이다.

·         비디오를 압축할 때 고려사항으로 초당 필요 frame 수, 압축율에 따른 화질의 변화, 압축 및 복원 속도, 부가적인 HW / SW 소요 여부, 통신체널의 전송 속도의 한계 등을 고려해야 한다.

(1) 전처리 (Preprocessing)

·         압축을 하기위한 준비작업을 수행하는 과정으로 컬러 스페이스(Color Space) 변환, 필터링(Filtering), 컬러 서브 샘플링(Color Subsampling) 등이 행해진다.

·         컬러 스페이스 변환은 R,G,B의 세 가지 성분으로 이루어진 컬러영상의 명도(Luminance)를 위한 Y 성분과 색상(Chrominance)을 위한 I 와 Q 성분으로 변환하는 과정으로, 이는 압축율을 높이기 위한 필수 과정이다. 즉 컬러 스페이스 변환은 RGB 영상 데이터를 YIQ 영상데이터로 변환하는 과정이다.

·         필터링은 잡음을 제거하여 압축율을 높이기 위한 과정이다.

·         컬러 서브샘플링은 사람들의 눈으로 미세한 색의 변화를 감지할 수 없다는 점을 이용하여, 덜 민감한 색 성분을 가지고 있는 I와 Q성분에서 한 화소씩(데이터 양을 1/2로 줄임) 또는 세 화소씩(데이터 양을 1/4로 줄임) 뛰어넘어 하나의 화소만을 취하여 본래의 영상 데이터의 크기를 1/2 또는 1/4로 줄이는 과정이다.

(2) 변형 (Transformation)

·         이 과정은 영상이 가지고 있는 정보의 중복성을 찾아내는 과정으로 영상신호 자체에서 처리하는 파형(Waveform)방식과 새로운 영역에서 처리하는 변환(Transform)방식이 있다.

·         파형방식은 인접한 화소의 영상 값의 차이만을 표시하는 가장 대표적인 방식으로는 DPCM(Differential Pulse Code Modulation)이 있다. DPCM으로 처리된 데이터의 복원은 앞 화소값에 그 차이 값을 더하여 구한다. 보다 높은 압축효과를 얻기 위하여 이를 변형한 ADPCM(Adaptive Differential Pulse Code Modulation) 변환법도 사용되고 있다.

·         변환방식은 영상데이터의 중복성을 제거하기 위해 여러 종류의 수학적인 변환방법을 통해 영상을 공간영역(Spatial Domain)으로부터 다른 영역으로 변환하여 분석함으로써 압축하는 방법으로 DCT(Discrete Cosine Transform) 방법이 널리 사용되고 있다.

(3) 양자화 (Quantization)

·         이 과정은 앞의 DPCM이나 DCT과정을 통하여 얻은 영상값을 어떤 상수값으로 나누어 유효자리의 비트수를 줄이는 과정이다.

·         이과정을 걸치면 데이터가 변이되어 원래 데이터를 상실하는 데이터의 손실이 발생한다. 모든 손실 압축 기법은 이 과정을 거친다.

(4) 가변길이 부호화 (Variable Length Coding)

·         이 과정은 데이터의 출현 빈도에 따라 자주 등장하는 데이터의 표현은 적은 비트수로 표현하고, 반대로 자주 등장하지 않는 데이터는 상대적으로 큰 비트수로 표현하여 전체적인 파일의 크기를 줄이는 방법이다.

·         컴퓨터에서는 영문자 A부터 Z까지의 모든 문자의 코드를 8비트로 표현하고 있다. 따라서 문자열의 크기는 전체 문자수에 의해 정해진다. 그러나 만일 영문자 26개 중 에서 출현빈도가 높은 A, E에는 2~3 비트의 코드를 할당하고, 상대적으로 출현빈도가 낮은 Q, Z에는 10~16비트의 코드를 할당하되, 서로 구분이 되도록 문자코드를 부여한다면 결과적으로 전체 파일의 크기를 줄일 수 있다.

·         이렇게 빈도수에 따른 처리방법으로 허프만(Huffman) 부호화 방법등이 사용된다.

 

·         가장 대표적인 압축방법에는 픽셀당 컬러 비트 수(Color Bit Depth)의 축소, 프레임 크기(Number of Pixels)의 축소, 그리고 프레임 수(fps)의 축소에 의한 방법이 있다.

·         아래는 15초 길이의 비디오 파일을 Frame수(15, 25, 30)에 따른 비교 자료이다

 

 

 

 

 

15 FPS (1,342 KB)

 

25 FPS (2,017 KB)

 

30 FPS (2,355 KB)

 

·         비디오의 부호화는 프레임 간의 정보를 이용하여 시각적 영향이 적은 부분의 정보량을 줄이는 방법을 사용한다. 이러한 방법에는 전프레임의 동일 위치의 화소 값을 이용하여 차이값만을 기록하는 프레임간 예측 부호화, 전˙후 프레임에서 물체의 움직임을 검출하여 그 움직임 성분만큼 앞 프레임에서 예측에 이용하여 화소의 위치를 보정 하는 움직임 보상 프레임간 예측 부호화법 등이 있다.

 

(1) JPEG (Joint Photographic Experts Group)

·         Gray scale 및 Color 영상을 포함한 모든 정지영상 압축전송기술의 국제표준 규정안 이다.

·         1992 IS 10918-1 (ITU-T T.81) 국제 표준으로 인정 되었다.

·         알고리즘으로 9 * 8 DCT를 사용하는 손실 압축과 예측 코딩을 사용하는 무손실 알고리즘 두가지 알고리즘을 사용한다.

·         JPEG의 주요 처리 절차는 아래와 같다

1. RGB 컬러모델을 YIQ 컬러모델로 변환
2. YIQ 메크로 블럭화
3. 매크로 블럭을 8 * 8 블럭화
4. DCT (Discrete Cosine Transform) 변환
5. 양자화 (Quantization)
6. 지그 - 재그 스캐닝 (Zigzag Scaing)
7. DPCM (Differential Pulse Code Modulation) 또는 RLE (Run Length Encode)
8. 엔트로피 코딩 (Entropy Coding)

 

·         20:1 정도의 압축율에서 화질에 거의 영향을 주지 않는다고 평가되고 있다.

·         MPEG과는 달리 Data의 저장을 Frame간 독립적으로 실행, 압축율은 MPEG의 1/4 정도이나 Frame간의 편집이 자유롭다

·         C-Cube사의 CL-550B chip은 초당 30 Frame의 영상을 실시간 압축한다

픽셀당 비트 수

압축율

영 상 품 질 평 가

0. 25 ~ 0.5

48 : 1

보통 수준의 화질 제공

0.5 ~ 0.75

32 : 1

일반 응용 프러그램에 사용할 수준의 화질 제공

0.75 ~ 1.5

16 : 1

모든 응용 프로그램에서 사용될 수준의 양호한 화질 제공

1.5 ~ 2.0

12 : 1

압축 이전의 화질과 구분할 수 없을 정도의 거의 동일한 화질 제공

  • 압축율에 따른 영상품질 비교

 

(2) MPEG (Moving Picture Experts Group)

·         비디오 전화용과 디지털 저장매체로 사용하기 위한 두가지 압축방식으로 구분 된다.

·         Movie와 CD수준의 sound와 동기화에 대한 표준안으로 구성되어 있다.

·         ISO / IEC JTC1/SC29/WG11로 공식화 되었다.(1996. 6)

·         MPEG 단체에서 제안하고 있는 동영상 압축기법은 크게 나누어 시간적 중복 및 공간적 중복을 제거하는 기법에 기반하고 있다. MPEG 압축 기법은 이동보상 압축 기법을 이용하여 시간적 중복(Temporal Redundancy)을 제거하고, 정지화상의 DCT 압축기술을 결합하여 공간적 중복(Spatial Redundancy)을 제거하는 방법이다..

 

MPEG의 동영상 압축 절차

·         MPEG의 압축기술은 아래 그림과 같이 화면을 I(Intra coded) Picture, P(Predictive coded) Picture, B(Bidirectional predictive coded) Picture로 구분하여 부호화 한다. I Picture는 예측부호화를 행하지 않고 독립적으로 부호화한다. P Picture는 직전의 I 또는 B로부터 추정한 예측신호와의 차를 부호화한다. B Picture는 화면의 전/후에 위치한 I 또는 P로부터 추정한 예측신호와의 차를 부호화한다.

 

I, P, B Picture 부호화

 

  • MPEG - 1

o        MPEG-1은 VHS 수준의 영상을 CD-ROM에 저장할 목적(데이터 전송속도 1.5Mbps 이하)으로 제정되었다.

o        주로 가정용 TV 수준의 비디오와 CD 수준의 스테레오 음향을 CD-ROM에 저장하고 재생하기 위해 만들어졌으며, 1993년 국제표준으로 채택되었다.

 

  • MPEG - 2

o        MPEG-2는 디지털 TV 와 DVD 수준의 영상을 목적(데이터 전송속도 15Mbps 이상)으로 제정되었으며, 순차주사(Noninterlace)방식과 격행주사(Interlace)방식 모두를 지원한다.

o        광범위한 신호 형식에 대응하기 위해 프로파일(Profile)과 레벨(Level)에 따라 복수개의 사양이 정해져 있다.

o        프로파일은 부호화의 방식과 기능에 의한 분류로 5 종류가 있으며, 레벨은 부호화 대상인 영상신호 형식으로 표준 TV로부터 HDTV까지 4종류가 있다.

구 분

MPEG-1

MPEG-2

주요 응용 분야

디지탈 저장 매체

디지탈 저장 매체, 방송, 통신

전송로 특성

오류가 없는 환경

요류가 큰 분야 포함

목표 전송율

1.5 Mbits/sec 이하

2 ~ 45Mbits/sec

영상의 해상도

360 * 240 * 30

720 * 480 * 30
1,920 * 1,080 * 60

주사 방식

순차 주사

순차 주사, 격행 주사

동작 모드

단일 모드

프로 파일 및 레벨에 따른 11가지 동작모드의 지원

호환성

-

MPEG-1에 대한 순방향 호환성 지원

    • MPEG - 1과 MPEG - 2의 비교
    •  

o        MPEG-3은 HDTV를 목표로 출발하였으나, MPEG-2의 적용 범위가 확장되면서 MPEG-2로 통합되었다.

 

  • MPEG - 4

o        MPEG-4는 1994년 음성과 비디오 합성을 목표로 출발한 영상압축 표준이다.

o        고성능 멀티미디어 통신 서비스를 고려하여 기존 방식뿐만 아니라 새로운 기능을 지원하기 위한 부호화를 목표로 하고 있다.

o        1994년 1차 제안서가 제출되었고, 1997년 11월 CD(Committee Draft), 1998년 3월 DIS(Draft International Standard)에 이어 1998년 11월에 국제표준으로 인정되었다.

o        MPEG-4 부호화에서는 기존 영상데이터의 화소값에 대한 압축방식에서 벗어나 영상에 담긴 객체(Object)들을 객체 기반 부호화(Object-based Coding)시키는 방법에 대한 연구가 포함되어 있다.

 

(4) H.261 (P*64)

·         1988~1990년 CCITT(International Telegraph and Telephone Consultative Committee)에서 정한 원격 화상회의를 위한 표준안

·         ISDN 전화선을 이용한 국제 Video-Conferencing, Video-Telephone을 용도로 한 통신계열에 있어서 동화상의 압축 및 부호화 방식의 국제표준안이다.

·         부호화 알고리즘은 MPEG방식과 기본적으로 같으며 I 및 P picture의 부호화 형식을 이용하여 64kbps ~ 2Mbps로 압축하며, H.261은 높은 압축율(100:1∼200:1)로 실시간 압축을 지원한다.

·         H.261은 시간적 중복성을 제거하기 위해 프레임간의 예측기법을 사용하고, 공간적 중복성을 제거하기 위해 DCT 변환기법을 사용하며, 동작보상 기법도 옵션으로 추가할 수 있다.

H.261 부호화 알고리즘

 

·         데이터를 아날로그에서 디지털로 또는 디지털에서 아날로그로 변환 시켜주는 회로(Circuits), 칩(Chips), 또는 알고리즘(Algorithm)을 의미.

·         압축(Compression, Encoding)과 복원(Decompression, Decoding)을 동시에 지원한다.

·         앞에서 설명한 JPEG, MPEG, H.261 등이 하드웨어에 의한 비디오 데이터의 압축이라면, 코덱은 소프트웨어에 의한 비디오 데이터의 압축이라고 할 수 있다.

 

 

Compression

 

Chapter 1 Multimedia Systems Design:An Introduction

An Introdution & Multimedia Elements

Multimedia란

  • Multimedia는 두개 이상의 개별 매체를 통합하여 사용하는 것.

예) Slider와 음성정보를 통합, 사용하거나 여러 개의 Slider를 함께 사용하여 복합영상을 만드는 것

  • CD수준의 사운드와 빠른 속도의 활발한 이미지, Fullmotion, HDTV를 이용한 풍부한 정보의 세계를 경험하는 것.
  • 각 매체를 구조화, 체계화된 정보제시를 위해 통합한다는 의미가 포함됨

예) TV에서 볼 수 있는 정보들과 동시에 Text,Video, Image animation, Sound등을 통합.

  • Slider Projection과 영사기는 교육면에 보다 중요한 매체.
  • Electonic mail과 Groupware 기술과 더불어 Report and Memos와 같은 Paper Flow 감소
  • LAN,WAN을 통해 Interactive한 Sound,Text,Image들의 결정체를 어디든 이용자들에게 보내는 Multimedia Networking의 발전
  • 80's는 Business 증대로 인한 정보를 FAX와 Mail형태로써 교류
  • 90's 특징

Electonic Mail & Electronic Meeting

Real Time의 Electonic Mail

Race to face회의에 따른 계획과 여행의 시간을 줄여줌

Multimedia Elements

  • Facsimile

전화선을 이용한 문서이미지전달의 첫번째 특징. 기본적인 기술로써 고해상도로 아직까지광범위하게 사용.

  • Document images

수많은 사람들에 의해서 access가 되거나, 오랜 시간동안 유지되어야 하는 business 문서를 저장하기위해 사용됨.

  • Photographic images

Multimedia Application에 있어서 중요한 자리를 차지하고 있음.
3차원효과를 내기 위해 가장 기본이 되는 장면. 이미지파일의 size가 커므로 JPEG이나 PIC같은 압축 기술을 사용

  • Geographic information system maps

GIS시스템이라 알려져 있다. 또 다른 GUL 응용프로그램과 같이 Geographic Maps의 화면표시와 저장을 위하여 사용되어 지는 기술. GIS 응용프로그램은 인간이 만든 구조물과 지도안에서의 그 좌표를 연결하는 것과 관련이 있다.

  • Voice command and voice synthesis

computer program에서 hands-free조작을 위하여 사용되어진다.
voice synthesis은 voice합성안에서 행동의 결과를 표현하기 위하여 사용되어진다.
voice command는 spoken 명령어로써 바로 computer를 조작할 수 있게 한다.

  • Audio message

text message를 대치한것이다. microphones를 갖춘 computer는 audio message를 기록하고, electronic mail메세지안에 첨부 / 삽입할 수 있다. 아주 큰 저장용량이 요구된다. compression기술은 보다 효율적인 저장용량을 관리하는데 이용됨.

  • video message

오디오메세지와 비슷함. 전자메일메세지에 파일첨부/삽입할 수 있다. 비디오메세지란 사진 한장에서부터 full-motion video clip의 까지를 말함.

  • Full-motion stored and live video

 

  • Holographic images

3차원의 물체를 광학기술과 비디오 프로젝션 기술을 통해서 공중에 구현하는 기술. 가상현실과 hologram을 합성해서 만든 3차원 가상극장도 가능해짐.

  • Fractals

1980년대초에 이 기술이 시작되었지만 최근에 관심분야이다. 이 기술은 정보기술의 저장 algorithms과 synthesise를 기본으로 한다.

 

Multimedia Systems Architecture

Document imaging

  • 멀티미디어 시스템의 가장 중요한 단계가 바로 문서 이미지 관리(DIM)
  • SOUND, VIDEO, TEXT등을 효과적으로 조합하여 발전하는 응용program에서는 불가결한 요소.
  • 많은 양의 복잡한 문서나 설계 도면을 보내거나 교환할 경우 많은 이익.
  • 고해상도의 표준화를 갖춘 pc,desktop workstation의 처리능력으로부터 영향.
  • A크기(8-1/2inch X 11 inch)의 문서는 최소 100dpi의 해상도가 필요하며, 300dpi의 해상도라면 75Kbyte의 저장용량이 필요.
  • 1280 X 1024 pixel의 모니터는 문서의 이미징화하는데 있어 최소한 갖춰져야한다.
  • PC,Workstations을 이용한 Processor능력의 증가로 압축기술과 모니터의 관리방법을 갖춘 SYSTEM에서는 문서 이미징화하는데 효과적.
  • 응용범위는 이미 매우 넓고 의료용, 건강 보조기구, 컴퓨터DATABASE등에 사용.
  • IMAGING화를 위해서는 300 ~ 600dpi정도의 고해상도가, DISPLAY를 위해서는 100 ~ 200dpi가 필요.

Image Processing and Image Recognition

※ Image Processing

Image recognition
Image enhancenent
Image synthesis
Image reconstruction

 

※압축/압축해제기술 그리고 object인식을 위한 algorithm을 사용

 

이미지를 비교
깨끗한
edge를 보기위해 위해 세밀하게 측정
gray-scale균형 / gray-scale과 color 조절

Image Animation

Image Annotarion

Optical Character Reognition

  • 타이프 or 문서에서 출력된 자필 단어들을 scaning한것을 입력자료로 이용
  • OCR의 기술은 많은 문서이미지 응용program안에서 사용되는 많은 희미한 출력글자를 판독할 수 있다.

Handwriting Recognition

  • CAD/CAM system의 명령어 인식을 위해 연구
  • Pen-Base System을 기반
  • 육필기록의 메일메시지나 복잡한 문서의 일부분을 읽고 번역.
  • 성능이 뛰어난 H/W,S/W를 가진 멀티미디어기술이 요구

Non-Textual Image Recognition

  • 디자인, 의학, 제조분야의 주된 기술적인 요소
  • 의학, 제조,보안system의 실용응용분야에 관심이 증대
  • Image recognition의 기본적인 구조 3단계

① Object의 경계나 선과 같은 기본적인 특징을 추출. 512 X 512배열로 처리

② 추출된 특징을 DSP 배열에 의해서 기록

③ AI알로리즘을 정교하게 하여 Object Scene인식을 수행.

  • 얼굴인식은 멀티미디어애플리케이션의 상호작용과 보다 직관적인 중요한 기술이 요구

)COMPUTER는 다른 명령어없이 사람의 얼굴에서 불명확한부분을 인식하는 것

Full-Motion Digital Video Application

&ltfig. 1-1>

  • Groupware기술은 사진,영상,다양한 복잡한 문서로 삽입된 메세지를 서로 교환하게 디자인한 것
  • 문서이미지와 같이 압축/해제 기술을 사용하여 대용량의 서로 다른 data를 각각 SERVER에 분포저장.
  • Full-Motion Video는 복잡하고 멀티미디어application의 요소를 다 갖고 있음.
  • GAME사업, 훈련,Business분야에 응용

) simulation의 기법을 통해서 세로운 제품사용법을 익힘.

) 제품, 서비스정보, 일의 진척도,데모, 멀티미디어 카탈로그등을 온라인으로

직접 연결하여 홍보 판매

Electronic Messaging

  • 첫번째 - 문자기반의 메일 시스템.(memos중심)
  • 두번째 - Eelectroic Mail System
  • Cross-Platform / Cross-Network상의 전자메일Message안에 Text file,표준형태의 graphic을 삽입하고 실행Program과 비트맵그래픽, 편집한 text file에서부터 서로 다른영역까지 첨부가능
  • 지리적인 경우, 매우 긴급한 정보를 교환해야할 경우 전자메일은 매우 유용
  • Audio 압축/해제, Full-Motion Video와 같은 기술의 사용하여 전자메일의 새로운 형태로 발전.
  • Communication Media에서 Workgroup Application까지 발전되어짐
  • Images, Video Frame, Audio 메세지, Full-Motion Video Clip과 같은 멀티미디어요소를 위한 저장공간이 필요

A Universal Miltimedia Application

  • Mail-Enabled Multimedia Application이라 부른다.
  • Sound,Image, Video와 같은 Data type을 위한 서버에 분리저장
  • 언제 어디서나 data를 압축/해제할 수 있어야 함
  • 입력은 어느 시점에 이루어지는가?
  • Server로부터 정보를 어떻게 Load하고 Display하기 위한 조작?
  • User의 특별한 조작없이 프린터 or 모니터에 출력되고 문서안에서 결합되어지는 Data형태의 Application조작
  • Phonebook,사진과 그림을 가진 컬러 팜프렛, 메모, Phone Message, Video Phone message, 실시간 텔테비젼회의등
  • 고려할 점:저장형태와 Network상에서 정보전달을 위한 방법론
  • &ltfig. 1-2>은 still video, document image, 실시간 화상회의, 화상회의의 참석자가 조작하는 Remote Desktop을 보여주는 윈도우화면의 복합적인 형태
  • 고성능 CPU와 JPEG/MPEG/CCITT Group4/Windows META File과 같이 동시다발적 해제,관리를 위해 DSP는 사용
  • FULL-MOTION Video Message와 VIEWER-INTERACTIVE Video애플리케이션에 의해 자연스럽게 복합되어짐

Full-Motion Video Message

  • Textual and Nontextual 정보를 MEMO로써 첨부
  •  

OLE Link된 data가

표준형태의 bitstreams은 main memo안에 삽입되고 첨부,

표준형태가 아니면 실행을 위해 또다른 application이 실행됨.

  • textual message, electronic mail와 더불어 video message, video message 또한 삽입
  • video message는 video snapshots 혹은 full-motion picture and sound의 Live video로 구성

Viewer interactive Live Video

  • entertainment 사업의 viewer-interactive 비디오게임이 선두주자.
  • Live Camera로 장면을 찍고, 현실적으로 만들기 위해 interactive한 가상현실 장면을 만들어 이 기술과 결합

full-motion video

  

viewer-interactive video

저장된 video clip을 재생.

Live

저장된 video clip의 출력,
압축해제관리

Live video 사용

message, 정보보급에 유용

direct interaction, 의학, 공장분야의
다양한 pross를 조작처리

압축해제를 위해 full-motion video를 사용

이 기술은 같은 Level,규정이 필요없다.

이미지는 같은 방법으로 capture

Audio and video indexing

  • indexing은 대부분 VCRs사용.
  • Tape안에서 marking위치를 의미
  • 프로그램의 시작위치, 어떤 장면을 다시 선택하여 rewinding하는데 필요
  • indexing은 비디오를 저장하는 데 유용
  • CD-ROM는 media안에서는 electronic marker이 주어지지 않음.
  • CD-ROM Player에 의해서 유지되어짐.
  • sound와 video를 압축해제하고 개별적으로 관리할 때 동기화는 매우 중요함.
  • sound and video가

같은 file안에서 혹은 서버안에서 분리 저장되었다면 PLAYBACK하기전에 동기화.

  • application에 속해 있는 video clip의 요소인 sound, video를 위해 indexing의 정보는 필요함

 

Multimedia Systems Architecture

Multimedia Workstation Architecture

  • 매우 다양한 기술을 포함하고 실시간에 interactive하는 다중 구조를 통합.
  • 모든 multimedia의 능력을 가진 멀티미디어시스템은 Microsoft windows, X windows와 같은 표준 User interface를 통합.
  • Application Software의 변화나 DSPs와 같은 H/W필요없이 시스템을 조작할수 있도록 디자인해야함.
  • 표준화는 Video animation과 압축보드를 위해 수많은 H/W interface를 대상으로 함.
  • API(Application Processing Interface)는 Device-Independent라고 부름.
  • Interface는 H/W로부터 Application과 독립적.
  • Application API를 기반으로하는 Operate환경과 H/W를 조작하도록 디자인하도록 함.
  • Common file format은 서로다른 H/W구조와 Operating환경에 변화할수 있도록 Data File을 작성.
  • 수많은 Drive를 지원하는 Application도 API적용
  • network interface, H/W요소를 대치하도록 디자인한 S/W나 주변장치보드를 가지고 해결
  • board-level 기술은 microcode logic로 사용된 수많은 서로다른 표준화를 적용하는데 사용되는 board
    <fig1-3>
  • 왼쪽 : Non-multimedia System
  • 오른쪽은 multimidea application을 지원하기 위한 새로운 구조
  • Add-on multimedia 장치와 주변장치에는 Scanners, video cameras,VCRs 그리고 DVI-JPEG-MPEG-enable board와 같은 encoding hardware를 포함

High Resolution Display

  • Interactive Application과 Image기술을 위하여 필요
  • 그래픽과 이미지가 결합된 application은 세가지 레벨을 기본으로 함

▶VGA Mixing

▶VGA Mixing with Scaling

▶Dual-buferd VGA Mixing/Scaling

The IMA Architecture Framework

  • IMA는 desktop과 Server을 연결하기 위한 Group
  • Interchage Format을 따르는 multimedia object를 일반 PC에서 display하게하는 것
  • IMA를 기반으로하는 구조는 multimedia Interface Bus는 System과 multimedia soㄴurce사이의 interface

)stream I/O 서버, filter와 translators를 포함함

Networking Standards

▶ATM(AsynchtonousTrasfer Mode)

  • 사운드, 이미지, 비디오를 단일 네트워크를 통해서 고속으로 전송하기 위해 만들어진

표준을 바탕으로 개발된 네트워크의 기술

(그래픽이나 음성, 비디오의 전송에 가장 탁월한 선택)

  • 매우 큰 대역폭을 가진 네트워크 기술로서 25 ~ 255Mbps사이에서 작동
  • 이러한 스피드에 도달하기 위해서 셀(Cell)이라 불리는 고정된 크기의 패킷을 이용
  • Cell들은 53Byte의 길이
  • virtual Circuit routing정보를 담고 있는 5Byte의 HEAD
  • 데이터는 48Byte로 된 셀이라 불리우는 패킷같은 상자에 담겨짐
  • 53바이트의 고정된 크기를 가지는 각각의 셀을 전송할 때 적은 오버헤드를 요구하므로

빠른 속도로 라우팅

  • 허브들은 다양한 크기의 패킷의 처리가 해결됨으로 데이터를 부드럽게 흐르도록 해줌
  • Intractive 멀티미디어 Application과 협동 작업환경, 대형 데이터파일전송, 화상회의등을

위해서 ATM이 등장

  • 전화선이나 동축케이블, 광섬유, 무선 기술 모든 매체를 이용

▶FDDI

  • Fiber Distributed data Interface
  • Dual-ring 토폴로지를 따르는 광섬유 케이블을 통해 100Mbps의 속도로 운영
  • 최대 100Km의 거라, 500노드까지 지원이 가능
  • FDDI네트워크는 Token-ring 네트워크처럼 작동하는데, 토큰 패싱을 사용하는

RING토폴로지를 가짐.중요한 차이는 DUALING이라는 점

  • Token들은 전송이 실패하는 경우를 방지하기 위해 RING을 따라서 반대로 돌도록 재구성
  • 광섬유케이블을 사용하기 때문에 신호가 새어나가지 않아 보안문제가 해결
  • 패킷단위로레이저 광섬유 기술을 이용해서 데이터를 보내는 토큰 링 LAN기술
  • 125MBps의 속도로 전송, 100킬로미터의 범위를 가짐
  • 이 표준은 SONET을 지원하기 위해서 점점 강력해짐

▶FDDI-II

  • 아이소크로너스 데이터를 운반하기 위한 가능 주파수대를 허용하기 위해서

FDDI를 확장시킴

  • FDDI-II는 광섬유망 LAN을 실시간 오디오나 비디오 등을 지연없이 연속적으로

전송할 수 있게 해줌

 

Evolving Technologies For Multimedia System

Hypermedia Document

  • 사용자로 하여금 멀티미디어 application에서 비선형적인 방법으로 정보에 접근하게 해주는 소프트웨어.
  • Interaction은 보장
  • 모든 종류의 자료, 즉 이미지라든지 영화, 음향효과, 텍스트등을 연결시키는 포괄적인 도구라 할 수 있다.
  • 멀티미디어의 자료제공자와 제공자를 이어주는 역할을한는 하이퍼링크에 의해서 형성
    ▶Hypertext
    ▶Hyperspeech

HDTV and UDTV

3-D Technologies and Holography

Fuzzy Logic

Digital Signal Processing(DSP)

 

Defining objects for Multimedia system

Text

  • 글자크기, 글자체 선택, 글자형식, 줄간격조정, 글자탐색, 글자수입, 파일저장방식의 선택, Hypertext, 한글이용.
  • 그래픽이나 오디오, 비디오파일형식을 지원하는 비디오, 애니메이션과 같은 멀티미디어를 작동시키는데 있어서 시작점의 기능을 담당.
  • OLE나 OpenDoc을 이용하여, 텍스트문서를 다른문서나 dynamic그래픽,비디오, 실시간 information 실행에 HyperLink를 제공.
  • 입력해야 할 정보가 인쇄된 형태로 되어 있고 양이 많을 때는 OCR프로그램이 설치되어 있는 Scander를 이용하여 컴퓨터에 읽어들이는 방법

Images

  • Hypermedia 문서의 subobject.
  • code text(ASCii text)가 아닌 모든 DataType를 Image Object라 함.
  • 컴퓨터의 이미지는 스캐너와 팩시밀리등으로 캡처된 사진을 말함.

<fig. 1-6>

▶Visible

  • Drawig - Blueprints,engineering 저작도구, town layout등
  • Document - 이미지로써 스캔된 것
  • Painting - 그림판프로그램에서 만들어진것/scan
  • Photographs - electronic camera에 의해 찍힌사진/스캔
  • Video camera로 부터 정지framesㅇ르 캡쳐
  • 스캐너, 팩시밀리, 카메라, 페인트프로그램으로 만들어져 컴퓨터메모리에 가로 세로의 비트로 저장.
  • 비트맵 그림으로 색깔 정보를 가진 도트들
  • 각각의 픽셀마다 설명을 해야 되기 때문에 많은 용량을 차지하며 Pixel graphic이라 함.

▶Non-Visible

  • 이미지를 저장하지 않고 Display한다.
  • Pressure gauges(표준압축)/temperature gauges(고밀도압축)

▶Abstract

  • 수학적 계산의 결과로 화면에 제시하는 그림

Audio and Voice

  • 디지털화된 아날로그 사운드 웨이브를 저장
  • 녹음/편집, 압축률과 압축크기의 조정, 다양한 소리파일ㅇ르 수입, 소리파일통제
  • 파장형태/redbook 소리정보 및 MIDI
  • 대부분 특허 프로그램이라 서로 다른 하드웨어나 소프트웨어의 작동이 문제가 됨

Full-Motion and Live Video

 

Multimedia Data Interface Standare

File Formats for Multimedia Systems

Video Processing Standards

▶ Intel'S DVI

  • The Digital Video Interface
  • 빠른 멀티미디어 display를 위하여 대부분 video interface 압축알고리즘 사용.
  • processor-independent
  • 개인용 PC에서 full-motion video 와 image, audio를 제공
  • processors는 DVI를 지원할 수 있도록 H/W적으로 설계되어져야함

▶Apple's QuickTime

  • Apple Computer에 의해 개발
  • multimedia application을 지원하도록 개발
  • windows와 unix용으로 개발, PC파일로 변환
  • 가장 널리 쓰이는 비디오파일형식으로 자리잡았다.

▶Microsoft's AVI

  • Microsoft's Audio Video Interleave
  • Video processing : Low-cost,low-resolution.
  • Windows라는 Operating System과 통합되어 설치된다.
  • Software에 의해 해결되어짐

 

Need For Compression

◈ 압축의 필요성
· 화상 정보의 특성

① 해상도를 높이면 디지털화된 멀티미디어 데이터는 기하급수적으로 증가

② 예를 들어 8-1/2×11인치의 이미지는 수 메가비트로 표현됨

· 대용량 데이터 객체의 문제가 되는 측면 : 저장, 전송
·저장량 증가에 따른 문제

① 데이터 검색, 추출에 걸리는 시간 증가

② 네트웍의 온라인상에서 전송 시간 증가

· 멀티미디어 데이터 객체의 효율적 관리를 위해 압축이 필요
· 저장비용과 전송비용을 줄임

◈ 압축 알고리즘
· 데이터 패턴에서 리던던시를 제거→저장과 전송 비용을 줄임

예) 검은 픽셀 하나 뒤에 하얀 픽셀 20개가 온다면, 하얀픽셀 20개를 모두 저장하지 않고

             하얀 픽셀의 수만 저장

◈ Compression Standards
·표준안의 필요성

어떤 기술에서든지 다수의 제조업체에서 지원되는 표준안은 필수적인 요구사항이 되고 있다.

·참여하는 제조업체의 장비가 바르게 연동하는 것이 더 쉬워짐
·각 제조업체의 하드웨어나 소프트웨어를 위한 기본적인 드라이버들을 주문에 따라 맞출 필요가
       없어짐
·표준화의 이익을 보여주는 예 : 팩시밀리 기술의 빠른 성장
·이미지를 위한 압축 표준은 CCITT에 의해 정의됨
·팩시밀리 전송을 위해 정의된 원본 표준안 → 고해상도 이미지를 위한 새로운 표준안 → 멀티미디어
      객체의 압축 표준 [Lossy와 Non-lossy가 있음]

◈Non-Lossy Compression for Images
·멀티미디어 객체(이미지, 목소리/오디오 또는 비디오)에 있는 모든 정보를 복원하기 위해 고안됨
·종류 : CCITT 그룹 2, 3, 4
· CCITT Group2

100dpi급 해상도를 가진 팩시밀리 기계를 위해 개발됨

매우 초기단계의 압축 안(Scheme)

고수준의 압축을 제공하지 않음

일반적으로 더 이상 쓸모가 없음

· CCITT Group3 1D compression : run-lenth encoding

전형적인 스캔 선은 같은 색상의 픽셀의 연속적인 등장이라는 가정에 근거

Gray scale이나 Color image가 아니라 black과 white image 두 색만을 위해 고안되었음에 주의

주 응용은 팩시밀리와 매우 초기단계의 문서 이미지 시스템

그것의 단순성과 낮은 팩시밀리의 해상도 때문에 계속적으로 팩시밀리를 위해 사용되고 있음

일련의 문서 이미징 시스템에서, 압축후에도 커다란 이미지 크기 때문에, 빠르게 퇴조하고 있음

· CCITT Group3 2D compression : modified run-length encoding

소프트웨어 기반의 문서 이미징 시스템에서 보다 공통적으로 사용되는 안(scheme)

꽤 좋은 압축을 제공하는 한편, CCITT 그룹 4보다 소프트웨어에 있어서 압축해제가 더 쉬움

압축률은 10∼25로 CCITT 그룹 3 1D와 CCITT 그룹 4의 중간쯤

수정된 READ(Relative Element Address Designated) 알고리즘을 사용

일차원 코딩 안과 2차원 코딩 안을 혼합한 것

이미지의 통계적 본성(근접한 스캔 선을 통과하는 이미지 데이터는 리던던트하다)에 기초

예) 검정과 흰색 전환이 주어진 스캔 선에서 일어난다면, 그 다음 스캔 선에서 +/- 3 픽셀 안에서 또한 일어날 수 있다. text의 한 줄은 스캔 해상도에 따라 20에서 30 스캔 선 만큼이나 많을 지도 모른다. 많은 이러한 선들이 글자들의 외곽선들에 따라 검정 픽셀과 하얀 픽셀의 공 통영역을 가진다. 저장될 필요가 있는 정보는 글자의 외곽선에서의 변화, 즉 연속되는 줄에서의 변화를 기술하는 정보뿐이다.

CCITT 그룹 4 인코딩과 비교 : 압축율은 떨어지지만, 훨씬 빨리 디코딩됨

· CCITT 그룹 4 compression

2차원 코딩 안(scheme) : 수직적, 수평적 압축을 제공

첫번째 참조 줄은 이미지의 꼭대기 위의 가상적인 모두 하얀 한 줄

같은 픽셀들의 첫 번째 그룹은 가상적인 하얀선을 사용하여 인코드되어지고

이것은 다음 스캔 선(현재 코딩 라인)을 위한 참조가 됨

새로운 코드 줄은 다음 코드 줄의 참조가 되고 각각의 연속적인 줄은 그 다음줄의 참조가 됨

end-of-line marker는 없음

소프트웨어적으로 인코딩과 디코딩이 가능

좋은 실행효율을 얻기 위해, 전형적으로 하드웨어 기반

장점 인코딩의 결과는 35만큼 높은 압축률을 가지며 매우 좋음

단점 한 줄에서의 한 비트 에러가 전체 이미지의 칼라가 반전되게 할 수도 있음

그 픽셀의 그림자나 color image에서 그 픽셀의 color를 표현하지 않음

예) 64단계의 명암을 가진 이미지는 각 픽셀을 위한 명암 정보를 필요로 한다. 한 픽셀에서 다음 픽셀로 명암이나 색상의 변화(동일한 명암이나 색상의 픽셀 그룹에서 다음 픽셀 그룹으로)에 따라, 압축의 정도도 줄어든다. 왜냐하면 그러한 각각의 변화에 대하여 새로운 명암 정보가 저장되어야만 하기 때문 이다. 더욱이, 반대로 검정에서 흰색으로의 변화보다 훨씬 더 자주 명암의 변화가 발생한다.

· CCITT 그룹 5 compression

칼라와 명암정보를 표현하는 효율적인 내용기반 인코딩 방법론

◈ Lossy Compression for Photographs and Video

사진의 경우 인치당 1000개의 픽셀을 표현할 정도의 고해상도가 필요

고해상도의 경우, 압축한 파일도 너무 클 경우가 있음

해상도가 너무 높아서 해상도의 약간의 손실이 눈치챌 수 없는 경우 데이터를 조금 버리는 방법

· Joint photographic Experts Group(Parts 1 and 2)

ISO와 CCITT가 협력하여 만든 워킹그룹

정지영상 압축에 주안점을 둠

MPEG(Motion Picture Experts Group) 즉 full-motion video 표준 의 근거가 되는 것이 JPEG

color fax나 full-color(24-bit) 탁상 축판, 스캐너, 프린터간의 어플리케이션을 위한 압축 표준

CCITT 그룹 3과 4표준의 단점

        image의 gray scale이나 color 구성요소를 위해 고안되지는 않음

        있을 수 있는 연산들에 대해 충분히 이미지를 압축할 수도 없음

☞ 다양한 기능을 가진 확장 JPEG 표준이라는 결과를 낳음

정지 color image와 gray scale image 다시 말해 연속적-톤 image를 위해 고안됨

· JPEG의 구성

Parts 1: 연산 모드, 구현 가이드라인, 교환 형식, codec

Parts 2: JPEG 표준에 적합한가, 호환성이 보장되는가를 테스트함.

· MPEG(Motion Picture Experts Group)

CCIR(Consultative Committee for Radio) : TV 신호의 전송을 위한 표준 비디오 압축 기술을 제정

CCITT, ISO와 함께 디지털 저장매체에 기록된 비디오나 오디오를 위한 표준안을 만들려는

노력이 MPEG을 만듬

ISO-TEC/JTC1/SC2/WG11의 부분

정지영상과는 달리 full-motion 영상은 시간요소가 고려됨

압축수준은 특정 해상도를 위한 압축율로서 서술됨

예) 64,128 또는 192Kbits/sec) ATM이나 FDDI가 이 스피드를 견딜 수 있는 그런 네트워크 라는 가정을 할 때 1.5Mbits/sec수준의 비디오와 오디오 질(quality)로 압축할 수 있을 것이다.

예) 1.5 Mbits /sec에서 압축되지 않은 비디오 프레임이 초당 15프레임이 전송될 수 있으며 각 프 레임은 100Kbits(100,000픽셀)을 가질 수 있다. 이것은 프레임당 400×250의 해상도가 되어진다. 진보된 기술은 이것을 실제적으로 초당 30프레임으로 보여지게 만들 수 있다.

MPEG표준은 다양한 어플리케이션을 지원하는 일반적인 표준

모든 어플리케이션이 똑같은 기본적인 표준에 의해서 지원되어야 한다면 일반성은 특별한

    부담이 됨

☞ 이 문제를 해결하기 위해 표준은 toolkit 형식으로 제공됨

· MPEG-2

3-10 Mbits/sec를 4-60Mbits/sec로 업그레이드

HDTV 표준으로도 사용되어질 수 있음을 의미

1993.11월에 ISO Draft MPEG-2가 release 됨

MPEG이 대용량 매체들에 1.5Mbits/sec를 보장하는 것이 목적이라면,

MPG-2는 더 많은 어플리케이션을 지원하도록 설계됨

HDTV, CATV, direct-broadcast 위성, VCR, Video disk player 등을 지원

MPEG-2에서 제공하는 60Mbits/sec는 디지털 HDTV 압축 알고리즘(MPEG++)에 대응 가능

포괄적이고 어플리케이션 독립적인 표준

· MPEG-4

수십 키로비트의 비트율을 목표로한 표준

디지털로 코드화된 동영상과 그에 따르는 소리들을 낮은 비트율에서 다양한

    어플리케이션을 제공할 수 있다고 생각하여 만들어 냄.

예) 비디오 폰, 전자비디오 뉴스, 비디오텍스같은 비디오 데 이터베이스로의 원격 접근, 원격 감지와 감시, 게임, 전자문서의 주석, 비디오메일, 청각장애를 가 진 사람을 위한 자막

· Fractals Group

정보의 내용과 정보의 통계적 특성에 기초하여 압축과 해제를 함

이미지의 핵심요소를 재생산할 수 있는 수학공식을 만들려는 접근방식

다수의 반복을 피하기 위해 사용되어지는 접근방식

    ☞ 반복수를 정의함으로써 적절한 인코딩을 하는 것

수학공식의 외곽선 사이의 영역들에 대하여 압축된 영상의 형태로 자세한 정보를 저장함으로써

    코드화된 결과를 잘 조정하는 것

장점 인코딩과 디코딩 알고리즘의 성능이 인코딩 시기에 사용가능한 하드웨어에 맞춰질 수 있다

· Hardware versus Software Compression

압축을 H/W 또는 S/W로 처리할 것인가에 대한 논쟁이 있어왔음

고려해야할 요인 : 성능과 비용

성능이 높을수록 비용이 많이 든다.

예)1.5Mbits/sec의 전송율을 가진 압축해제라는 비디오의 질 요구사항은 특수한 DSP가 필요한지 아닌지, 또는 처리기가 적당한 필요를 충족시킬정도 로 충분한 성능을 가지고 있는지 아닌지를 결정한다.

80386, 80387: 그룹 2와 3만이 소프트웨어로 구현될 수 있도록 제한되었음

80486DX와 팬티엄 프로세서: 이미지 시스템에 관한 등식을 상당히 변화시킴

         Apple의 퀵타임이나 Microsoft사의 AVI 표준을 사용하는 display system을 지원함

대부분의 어플리케이션에 대한 압축을 위해 CPU를 사용하는 것이 가능한 반면, 고해상도

    이미지 어플리케이션과 JPEG 이나 MPEG 표준 구성요소들을 사용하는 문서들은 적당한 성능을

    제공하기 위해 계속해서 DSP(Digital Signal Processing)들과 특수 구성요소들을 필요로 할 것

· Asymmetric Application

한번 압축되면 여러번 읽혀지는 어플리케이션들

예)도움말 파일

비대칭 이미지와 비디오 클립

    ☞ 압축을 위해 하드웨어 도움을 받는 것과 하드웨어 도움 없이 더 빠른 압축해제를

          수행하는 것이 가능

하드웨어 도움을 받는 것이 좋은가

    ☞코딩-디코딩 scheme와 CPU의 처리 능력에 따라 다름

 

Multimedia Databases

◈멀티미디어 작업 관리 시스템의 원칙 :
·사용자가 멀티미디어 능력이 그들의 표준 컴퓨터 플랫폼의 확장이기를 원함
·단체들은 현존하는 워크스테이션을 계속 사용하기를 원함
·현존하는 시스템과 어플리케이션에 완전히 통합된 add-on 능력으로써 멀티미디어 어플리케이션과
      문서 관리를 덧붙이기를 원함


◈멀티미디어 시스템의 장점
·문서들을 파일하고, 저장하고 검색하는데 필요한 시간과 공간 절약
·DMS에 의해 제공되는, 자동적으로 유지되는 인덱싱을 사용하여 손상되거나 잃어버린 파일
     조건을 제거함에 따라 생산성 향상
·다중 사용자에게 동시적 문서 접근을 제공
·다차원의 정보흐름의 향상
·사진 복사에 드는 시간과 돈의 절약
·저장된 시각적 상호작용을 통한 정보에 대한 요청에 빠르고 정확한 응답 가능
·종이 기반 정보의 관리가능한 전략적 자원으로의 변환


◈ Multimedia Storage and Retrieval
· 멀티미디어 저장의 고려사항
      ☞ 대량 저장 용량, 큰 객체 크기, 다중 관련 객체, 검색을 위한 임시 요구사항 등

· Massive Data Volumes
      ☞ 종이 문서, 필름, 오디오, 비디오 테입을 저장
      ☞복잡한 인덱싱 시스템, 대량 저장 파일을 통한 검색을 필요로 함
      ☞한 멀티미디어 문서에 여러 매체가 결합된 경우엔 더 복잡해짐

· Storage technologies
      ☞ 종이, 필름, 오디오, 비디오테입, 직접 카메라 입력에 의한 정보는 텍 스트나 데이터, 그래픽을
           다루었던 것과 똑같은 컴퓨터화된 정보 시스템을 사용하여 관리되 어질 수 있다.
      ☞ Microfiche와 microfilm을 많이 사용함 광학매체로 많이 바꾸어가고 있음

· Multimedia Object storage
      ☞ 검색속도가 관건임 - 자동적으로 빠르게 위치되어질 수 있을 때 효과가 있다.
      ☞ storage latency - 저장매체로부터 테이터 를 검색하는 데 걸린 시간
      ☞압축 latency - 디스플레이 해상도에 따른 데이터의 크기
      ☞전송 latency  - 전송매체와 속도
      ☞압축해제 latency
      ☞ 정보의 빠른 검색을 위해서 인덱싱이 필수적

· Multimedia Document Retrieval
      ☞ 멀티미디어 문서를 확인하는 가장 간단한 형식 :  저장 플 래터와 플래터 상의 상대적 위치(file
           number)의 인식에 의해서이다.
      ☞ 멀티미디어 객체 디렉토리 함수 사용

◈멀티미디어 시스템을 위한 DBMS  
·
다른 형식의 정보를 상호연동하는 것이 중요하다.
·
압축된 멀티미디어 객체도 아주 클 수가 있다.
·
이런 객체들 중의 몇몇의 재생은 고정된 비율에서 현실적으로 발생해야만 한다.
·
데이터베이스 시스템은 반드시 완전히 distributed여야 한다.
·
데이터 베이스 접근방식은 전체 solution의 유연성과 성능을 결정한다.
·
사용 가능한 선택들....
      ☞ 이진 객체로서 다양한 멀티미디어 객체를 지원하기 위해 현존하는 관계형 DBMS를 확장
      ☞ 상속과 계층의 개념에 대한 기본적인 이진 객체외의 RDBMS를 확장
      ☞ 완전히 보호된(full-fledged) 객체지향 데이터베이스로의 변환
      ☞ 데이터 베이스와 어플리케이션을 객체지향 데이터베이스로 변환
·RDB가 멀티미디어 데이터베이스로 부적격한 이유 두 가지 : 관계형 데이터 모델, 관계형 계산 모델

·멀티미디어를 위한 RDBMS 확장
    ☞ 대부분의 RDBMS는 이진과 자유형식의 text
    ☞ 이런 제한에 대한 workaround로서 BLOB(binary large object)로 알려진 공통 데이터 형태를 채용
    ☞ BLOB는 이진 데이터형이나 이미지같은 객체를 위해 사용된다.

·객체지향 데이터베이스: 캡슐화 와 상속을 지원
    ☞ 캡슐화 : 단위로서 소프트웨어 개체들을 취급하는 능력
    ☞ 상     속 : 존재하는 객체 클래스로부터 유추된 새로운 객체를 창조하는 능력


◈멀티미디어를 위한 OPbject-oriented Databases
·
멀티미디어 지원을 위한 가장 빠른 경로를 제공할 수 있다.
·
재사용 코드와 묘듈성의 원칙을 실현하는 객체 프로그래밍
    ☞ 클래스가 한번 정의되면 그 안의 모든 객체들에게 클래스의 특성이 주어진다.
    ☞ 클래스 선언은 어플리케이션이 개발되는 속도의 측면에서 장점이 있고
    ☞ 복잡한 멀티미디어 어플리케이션을 개발하고 유지하기 위해 제공되어질 수 있다.
·
Object database는 확장가능하고 데이터베이스 어플리케이션에 증가하는 변화들을 허용한다.
    ☞ Massage passing : 객체가 어플리케이션의 한 구성요소로부터 다른 것으로 데이터를 넘겨주는
         과정과 서로서로 각자 방법들을 제시함에 의한 상호 접촉을 객체에게 허용한다.
    ☞ Extensibility : 연산과 집합과 그 연산에 유용한 구조와 제한들이 고정되어 있지 않고, 개발자 는
          새로운 연산을 정의할 수 있다.
·객체지향 주요 세 개념과 그로부터 나온 강점
    ☞ Encapsulation
     ☆ 소프트웨어 개체들을 이전에 정의되어진, 제어가능한 방법으로 상호의사소통하는 단위로서
           취급하는 능력.

     ☆ 개체와 통합성이 있는 제어루틴들이 있는 소프트웨어 개체들을 단위 로서 취급하는 능력
    ☞ Association : 다른 개체와의 차이점의 측면에서 소프트웨어 개체를 정의하는 능력
    ☞ Classification

     ☆ 단일 소프트웨어 개체를 가지고 모두 같은 행동을 가지고 같은 상태
     ☆ attribute를 가지는 많은 데이터 항목들을 표현하는 능력
    ☞ 객체지향의 장점: 좀더 모듈적이고 재사용가능한 방법으로 소프트웨어를 조직하는 능력
    ☞ 캡슐화의 다른 장점

     ☆ 어플리케이션의 한쪽부분이 다른 부분의 기능을 알 필요가 없는 개방형 시스템의 개발을
           고려한다.
     ☆ 성공적인 캡슐화는 상호 접촉의 수단으로서 인터페이스만 남긴 채, 각 구성요소의 내부 기능들을
           숨긴다.
     ☆ 캡슐화는 자동성을 제공한다; 다양한 외부 프로그램으로의 인터페이스가 한 클래스의 객체들
           내에 구축될 수 있고 다른 클래스 객체속에 그 데이터의 저장을 구축할 수 있다.
    ☞ 상속 메카니즘 부모와 비슷한 특성을 가진 객체들을 빨리 구축할 수 있게 해준다.

) 상속은 많은 다양한 디스플레이 객체들이 워크스테이션 요구사항에 적합하도록 개발하기 위해 사 용되어질 수 있다. 디스플레이 객체들의 특성들의 기본 집합을 상속하고 디스플레이 방식을 실 행시에 동적으로 재정의함(dynamic bounding)으로써 사용되어질 수 있다. 새로운 객체 클래스들 은 존재하는 클래스들의 attribute와 method를 상속받음으로써 생성될 수 있다.

◈멀티미디어 Application을 위한 Object-oriented Database Organization
·멀티미디어 시스템을 위한 데이터 조직의 현안들 :
        
1. Data Independence
        
2. Common distributed database architecture
        
3. Distributed database servers
        
4. Multimedia object management Data Independence

·Data Independence 설계시 고려해야할 특성들
           1. 특정 어플리케이션에 독립적으로 저장구조를 설계
        
2. 어플리케이션 프로그램에 독립적으로 Explicit data를 정의
        
3. 사용자가 데이터 형식이나 물리적인 저장구조를 몰라도 된다.
           4. Integrity 보장이 어플리케이션 프로그램에 독립적이다.
        
5. Recovery가 어플리케이션 프로그램에 독립적이다.
    ☞ 어플리케이션과 데이터간의 이런 종류의 격리는, RDB에서는 자동적으로 제공되어지는데,
          멀티 미디어 문서기반의 데이터의 긴 생명주기가 주어진 멀티미디어 데이터베이스에서는
          특히 중요하다.

◈Common Distributed Database Architecture
·
어플리케이션으로부터 데이터의 격리와 분산
    ☞ 어플리케이션의 접근은 common distributed 데이터베이스 구조를 채용할 기회를 제공한다.
    ☞ 주요 특성
        1. 시스템(서버) 내의 다중 독립 데이터구조
        2. client들에 의한 유일한 다중 접근
        3. 각 데이터베이스 서버의 하나의 recovery 지점
        4. 요구사항을 만족시키기 위한 편리한 데이터의 재조직
        5. 객체 클래스의 조율가능성과 생성
        6. 확장가능성
   Note : 데이터베이스와 어플리케이션 간의 기능의 구조적 분리의 관련

 Distributed Database Servers
·
다수의 어플리케이션들에 접근 가능한 네트웍상의 지정된 자원
·
데이터베이스 서버는 성장과 향상을 위해 구축된다.
·
네트웍 은 어플리케이션의 성장과 데이터에 대한 분산 접근의 기회를 제공한다.
·
Multimedia Object Management
      ☞ 멀티미디어 객체들을 인덱싱, 그룹핑, 소팅
      ☞ 키의 근거에 따라 이러한 객체들을 접근

·Transaction Management for Multimedia Systems
      ☞ 사용자가 하이퍼미디어 문서를 표시, 편집, 프린트하려는 요청을 할 때 시작되는 일련의 사건들
      ☞ 사용자가 하이퍼미디어 문서를 release할 때 , 편집된 버전을 다시 저장할 때, 또는 메모리 또는
            지역 기억장치상의 복사본을 버릴 때 수행
      ☞ 다수의 사용자들에 의해 통시에 접근되어질 수 있는 다중 데이터 서버들로부터 데이터가 검색  
            되어져야 할 때 트랜잭션들은 복잡해진다.
            예)   두 사용자가 같은 데이터 레코드를 읽으려고 할 때나 써넣으려고 할 때 충돌이 일어난다.
                     다단계 커미트 방법이 RDB에서 이런 문제들을 해결하기 위 해 사용되어진다.
       ☞ 하이퍼미디어 문서나 다수의 멀티미디어 객체들이 연관된 데이터베이스 레코드의 갱신의 경
             우에 있어서 더욱 복잡해진다.
      ☞ 전송되어지는 데이터객체의 수나 크기에 의해 필요되어지는 협상 단계는 트랜잭션 관리의
             현안에 완전한 새로운 차원을 더한다.
      ☞ 하이퍼미디어 문서의 모든 구성요소들이 attributes로써 객체내에서 참조되어질 수 있다면, 우리
             는 객체개념의 3차원 트랜잭션 관리 문제에 대한 해답을 알 수 있을 것이다.

 

Types of Compression

※ 통신의 세 클래스
·Unsolicited or unexpected 통신
     ☞ 사용자에게 그들의 정상적인 일들을 수행하는 것을 막고 오퍼 레이션에서 잠깐의 지연을 야기

           하는 정도로만 영향을 미친다.
·두 번째 통신 클래스 : 사용자가 통신이 다음 작업을 수행하기 전에 완료되어 지기를 기다리는 것
·세 번째 클래스 : 적당한 속도가 작업이 완료되어질 때까지 유지되어지는 것
·관심의 대상은 뒤의 두가지 형태
      ☞ 압축과 압축해제 개발의 추진력


◈ 멀티미디어 객체의 특성
·
비디오 재생에 있어 연속적인 프레임들을 위한 성능 요구사항은 정지영상을 retrieve 하는 것보다
      수행되기가 더 어렵다.
·이미지나 사운드나 full-motion video clips를 위해 중요한 요인은 저장장소이다.
·멀티미디어 데이터 객체들이 디지털화 되어질 때 많은 양의 디지털 데이터가 생성된다.
·데이터의 정확한 양은 스캐닝의 해상도에 달려있다.
       ☞ 해상도가 증가할수록 객체의 크기는 기하급수적으로 증가한다.
       ☞ 8-1/2×11인치의 이미지를 표현하는데 수 메가비트가 필요
       ☞ 커다란 데이터 객체는 저장과 전송의 두가지 측면에 있어 문제를 갖게 된다.
       ☞ 데이터 저장량이 증가할수록 데이터 검색·추출에 걸리는 시간도 증가한다.
       ☞ 많은 데이터를 적은 공간에 저장할 수 있는 광매체가 자기매체보다 느린 것으로 알려져있다.
       ☞ 네트웍의 온라인 상에 대량데이터를 유지하는 것은 더 심한 문제를 일으킬 수 있다.

◈압축의 필요성
·
대량 멀디미디어 데이터 객체를 효율적으로 관리하기 위해서, 이 데이터 객체들은 이 객체들의
      저장을 위해 파일크기를 줄이도록 압축되어질 필요가 있다.
·
압축 알고리즘 : 데이터 패턴에서 리던던시들을 제거한다.
       ☞ 적은 기억공간, 빠른 전송시간을 보장
       ☞ 저장비용과 전송비용 절약
        
) 검은 픽셀 하나 뒤에 하얀 색 20개의 픽셀이 온다면, 20개의 하얀색 픽셀 모두를 저장할 필요는

                  없다. 코딩 메카니즘은 하얀색 픽셀의 수만 저장하도록 사용 되어 질 수 있다.

◈TYPES OF COMPRESSION
       ☞ 그림 2-1  압축 표준안들의 발전사
·
압축의 종류 : Lossy와 Lossless Compression

·Lossy compression의 종류

       ☞ Packbits encoding (Run-length encoding)
       ☞ CCITT Group 3 1D
       ☞ CCITT Group 3 2D
       ☞ CCITT Group 4
       ☞ Lempel-Ziv and Whelch algorithm LZW

 

◈압축 알고리즘
·
Lossy Compression
       ☞ 사람의 눈은 끊기는 영상을 재생되는 것으로 만들 수 있는 감각이 있다.
       ☞ 손실된 정보를 사람의 눈이 채워줄 수가 있다.
       ☞ 사람의 눈과 귀가 정보의 간격을 메울 수 없게 되기 전에 얼마나 많은 정보를 버릴 수가 있는지가
             주요 고려대상이다.
       ☞ 프레임 단위로 압축되고 해제된다

       ☞ 한 프레임내에서 손실된 정보는 눈에 의해 인식되지 않을 것이다.
       ☞ 연속적인 프레임들이 한 프레임내의 이미지의 다른 부분을 채우기 때문에 받아들일만 하다.
·
lossy compression 의 응용분야

       ☞ 의학 스크리닝 시스템, 비디오 원격회의, 멀티미디어 전자 메시징 시스템 등

·JPEG
       ☞ 두드러진 압축 방식은 연속적인 톤의 정지영상의 디지털 압축
       ☞ JPEG은 ISO 와 CCITT 의 연합
       ☞ JTC1/SC2/WG10에 할당된 ISO의 위원회로서 역할을 하고 있고,
       ☞ CCITT 의 SGVIII와도 긴밀한 협력관계에 있다.


◈ Lossy Compression mechanism
       ☞ JPEG(Point Photographic Experts Group)
       ☞ MPEG(Moving Picture Experts Group)
       ☞ Intel DVI
       ☞ CCITT H.261(P×64) Video Coding Algorithm
       ☞ Fractals

 

BINARY IMAGE COMPRESSION SCHEME

◈BINARY IMAGE COMPRESSION SCHEME
·
연속적인-톤의 정보를 가지지 않은 문서에 사용될 수 있는 개념
·
오직 검정과 흰색만으로 구성된 것
       ☞ 사무실 문서, 손으로 쓴 글자, 선, 공학 그림 등 스캐너가 문서를 순차적 스캔라인을 따라 스캔
         
한다.
       ☞ 페이지의 처음부터 아래쪽으로 스캔하며 각 스캔라인에서는 왼쪽에서 오른쪽으로 픽셀의 색을
             읽어들인다.
       ☞ 1은 검정픽셀, 0은 하얀픽셀로 표시.
       ☞ 이미지 자체가 통계적 특성을 지닌 것으로 알려졌는데, 이미지들은 많은 양의 하얀 공간과 여기
            저기 흩뿌려진 검정픽셀로 구성된다.
       ☞ 이러한 검정픽셀들은 text, 선, 또는 채워진 영역을 표시한다.
       ☞ 이미지 그 자체로 보면 정보의 관점에서 상당히 redundant 하다는 것을 의미한다.
       ☞ 이미지 압축의 목적 : 저장공간과 전송비용을 줄이는 것
·
Packbits Encoding(Run-length Encoding)
       ☞ 개발된 데이터 압축 표준안들 중 가장 간단하고 가장 오래된 것
       ☞ 표준이 필요없을 정도로 간단한 것
       ☞ CCITT 3 1D 같은 다른 압축 표준안들의 토대를 형성
       ☞ 연속적인 반복되는 문자열은 두바이트로 치환된다.
             첫 번째 바이트 : 문자가 반복되는 횟수
             두 번째 바이트 : 문자 자체
       ☞  예
       ☞ 몇몇 경우에 있어서 한 바이트가 픽셀의 값과 길이를 표현하기 위해 사용된다.
       ☞ 한 비트가 픽셀의 값을 나타내기 위해서, 다른 7비트가 Run-length를 위해 사용된다.
       ☞ 비교적 짧은 Run-length를 위해 한 바이트를 저장한다.
       ☞ Run-length를 위해 최대 128bit까지 표현할 수도 있다.
       ☞ Run-length Encoding은 일차원 표준안이다.
       ☞ 전형적인 압축 상수는 1/2에서 1/5 정도이다.
       ☞ 이 안은 baseline TIFF 6.0 specification에 포함되어진다.
       ☞ TIFF에서 압축 형태를 위한 식별자는 32772이다.
             TIFF : Tagged Image File Format
       ☞ 장점 : 구현이 쉽다
       ☞ 단점 :  busy image에서는 압축의 역효과가 나서 원래 이미지보다 압축한 것이 크기가 더 클
               수가 있다는 것이다.
           busy image란 인접한 픽셀이 빠르게 바뀌는 것으로 이 경우 검정 픽셀이 나 하얀 픽셀의
  
                   Run-length를 표현하기 위한 코드가 더많이 필요할 것이다. 이런 경우를 negative
                     compression 이라 한다. 압축 알고리즘은 이런 효과를 조심해야 하며 run length의 압축을
                     피할 수 있도록 알고리즘이 체크되어져야 한다.

◈CCITT 3-1D 압축
       ☞ 검정과 하양의 두가지 픽셀만을 표현하는 안
       ☞ Run-length Encoding에 기초하고 있다.
       ☞ gray-scale, color이미지를 위한 압축이 아니다.
       ☞ 주로 팩시밀리나 초기 문서 이미징 시스템에서 사용된다.
       ☞ 수정된 Run-length Encoding인 Huffman encoding방법이 사용된다.

·
Huffman Encoding
       ☞ CCITT Group 3과 Group 4에서 픽셀 run length를 인코딩하 는데 사용되는 방식이다.
       ☞ 자주 나타나는 run length에는 짧은 길이의 코드를, 드물게 나타 나는 run length에는 긴 code를
            할당하는 가변길이 인코딩방식
       ☞ 검정 이미지와 하얀 이미지에서의 수행방식이 다른 것이 보통 :   왜냐하면 검정 픽셀이 나타나는              확률하고 하얀 픽셀이 나타나는 확률이 다르기 때문

·Huffman Encoding을 위한 수학적 알고리즘
       ☞coding tree에 근거: run length나 bit stream에서 하얀 픽셀이나 검정 픽셀의 출현 가능성에
            기초하여 만들어짐

       ☞ P(Rn)  :  Rn 길이의 비트스트림이 나타날 가능성
       ☞ 짧은 코드들이 자주 나타나는 run length가 자주 발생하는 것들에 대해서 개발되었고
       ☞ 덜 자주 나타나는 run length에 대해서는 더 긴 코드들이 개발되었다

          표 2-1 CCITT Goup 3 하얀 run length와 검정 run length를 위한 코드들

       예) 16개의 하얀 픽셀들의 Run-length code는 101010이고 16개의 검은 픽셀은 0000010111이다.
           -  통계적으로 16개의 하얀 픽셀은 16개의 검은 픽셀보다 자주 나타난다.
           -  따라서 생성된 코드가 하얀 16개 픽셀에 대한 코드가 검은 것보다 더 짧다.
      예) 그림 2-2  : tree 구조

       ☞ 주어진 비트 스트림에 대한 make-up code, terminate code를 생성하기 위해 Huffman 코딩을 사용
       ☞ Make-up code : 다중 64 픽셀들에서 run length를 표현하기 위 해 사용됨
       ☞ Terminating code :  64픽셀보다 작은 run length를 표현하기 위해 사용됨
      예) 132개의 하얀 픽셀들
          ㉠ 128개의 하얀 픽셀을 위한 Makeup code: 10010
          ㉡ 4개의 하얀 픽셀을 위한 Terminating code : 1011
          ㉢ 132개의 하얀 픽셀을 위한 압축된 비트열 :   100101011  (9비트)
          ㉣ 압축율(14) = 비트의 총수(132)/ 코드화하는데 사용된 비트수(9) 

       표 2-3 CCITT Group 3 1D

·Advantages of CCITT Group 3 1D
       ☞ 하드웨어로든 소프트웨어로든 구현이 쉽다
       ☞ 팩시밀리에서 전세계적인 표준 → 문서 이미징 어플리케이션과 팩시밀리 문서와 연동이 쉽다
·Disadvantages of CCITT Group 3 1D
       ☞ 인접한 몇 개의 스캔라인에서는 거의 변화가 없으며 변화가 근처에서 있다라는 연구가 있어왔고
            따라서 위 아래 줄의 정보를 이용하여 더 압축할 수 있지만 이것은 1차원 압축개념이라서 위 아래
            줄의 정보를 읽어올 수가 없다.
       ☞ 신뢰성있는 통신 선로를 가정하고 어떤 에러 감지 메카니즘도 없다.
       ☞ 만일 이전 정보에서 변화가 생기면 이미지의 나머지부분의 색이 반전된다.


◈CCITT Group 3 2D 압축 (Modified run-length encoding)
       ☞ 압축율은 10-20사이로 CCITT Group 3 1D와 CCITT Group 4의 중간쯤

       ☞ 이차원 압축안 으로 더 높은 압축을 제공
       ☞ 통계적으로 많은 줄이 위나 아래의 줄과 많이 다르진 않다라 는 사실을 이용하여 압축한다.
       ☞ K라인만큼 그룹을 지어서 그 맨 윗줄이랑 현 스캔라인을 비교하 여 인코딩을 한다.
       ☞ 만일 주어진 스캔라인에서 검정과 하양의 변환이 일어났다면 다음에 오는 스캔라인에서
              +/- 3픽셀안에서 같은 변환이 일어난다.
       ☞ text의 경우에 있어서 해상도에 따라 20-30 스캔라인일 수도 있다.
       ☞ 많은 이런 선들은 이미지 객체의 윤곽선을 따라 검정 픽셀과 하얀 픽셀의 공통영역을 갖는다.

·Why K factor?
       ☞ 알고리즘은 매 K 그룹의 Group 3 2D 코딩사이에 Group 3 1D 코딩을 포함
       ☞ Group 3 1D 코딩은 전송 오류의 경우에 있어서 동기화 선이 된다.
       ☞ 에러 예방은 Group 3 2D 안을 사용하는 팩시밀리 어플리케이션에서만 사용된다.
       ☞ 디스크 기반의 멀티미디어 어플리케이션에 있어서 K 인수는 무한대로 설정되기도 하는데
             신뢰성이 높은 저장매체이기 때문이다.

·Data Formatting For CCITT Group 3 2D
       ☞ Vertical code, pass code, horizontal code를 사용
       ☞ pass code :    0001 <하나뿐>
       ☞ horizontal code :   001<하나뿐>
       ☞ vertical code< 7가지> : 코딩 라인에서 변화하는 픽셀과 참조 라인에서 변화하는 픽셀의 위치사이
            의 차이를 나타내는 코드
             표 2-4  Vertical code
       ☞ 사 용 예

·CCITT Group 3 2D 안의 장점
       ☞ K인수의 구현이 error-free 전송을 가능케한다
       ☞ 전세계적인 팩시밀리 표준이고 문서 이미징 어플리케이션에서도 수용된다
       ☞ 자체의 2차원적 특성 때문에 압축율은 CCITT Group 3 1D보다 훨씬 좋다
       ☞ 주로 소프트웨어적으로 구현된다.

·CCITT Group 3 2D안의 단점
       ☞ 높은 압축을 제공하지 못한다
       ☞ 소프트웨어적으로 구현하기가 복잡하고 어렵다

 

COLOR, GRAY SCALE, AND STILL-VIDEO IMAGE COMPRESSION

◈ 칼라와 그레이 스케일
       ☞ 우리가 당연하게 여기는 생의 부분이다; 우리는 일상적으로 칼라 서술을 문장내에 포함한다.
       ☞ "저사람은 빨간 재킷을 입고있다"등 칼라는 다른 차원이 객체에 더 붙게 된다.
       ☞ 예) 빨간 색 : "정지"나 "위험"을 표시

◈칼라의 물리학
       ☞ 가시광선은 x-레이나 라디오파같은 전자기적 방출과 방출에너지의 형태이다.
        표 2-6 칼라의 파장과 주파수 칼라 모델들

◈칼라 모델
·
Chromacity model
       ☞ the Commission International de L'Eclairage(CIE)에서 제정
       ☞ 칼라를 나타내는 x, y의 이차원외 + 광도 (3번째 차원)

·RGB model
       ☞ TV, 모니터, 카메라 하드웨어 제조업체들이 개발한 모델
       ☞ 이미지 캡쳐 장비나 TV, 칼라 모니터에 주로 사용
       ☞ 빨강(Red) , 녹색(Green)과 파랑(Blue)을 섞어 색을 표현
       ☞ 이미지 프로세싱에 적합하게 제공지 않음

·HSI model
       ☞ Hue, Saturation, Intensity모델

       ☞ 색상, 채도, 명도의 미술전문가 용어를 사용하여 표현
       ☞ 이미지를 필터링하고 smoothing하기 위한 처리를 하는데 있어서 사용
       ☞하드웨어에 맞는 것이 없다.

·CMYK 모델
       ☞Cyan(청록색), Magenta, Yellow, Black 모델
       ☞ 탁상출판 프린트 장치에서 사용
       ☞color-subtractive(칼라를 빼는)모델이고 칼라 프린터 장치에서만 잘 사용된다

·YUV 표현
       ☞ NTSC(National Television Standard Committee)에서 개발한 것

       ☞ Y : luminance, U: 빨강 - 청록색, V:분홍 - 녹색
       ☞ full-motion video를 표현하는 데 사용 → 가장 관심의 대상이 된다
       ☞ 1940년 대 중반에 개발된 흑백 모델을 기반으로 1950년대 중반에 개발되었다

·B/W TV and Color Image Composition
       ☞ NTSC에서 40년대 중반에 RS170을 TV 신호의 표준으로 정했다.
       ☞ 1953년 NTSC는 RS170-A를 흑백과 연동할 수 있는 칼라 표준으로 정했다.
       ☞ Luminance와 Chrominance 두가지 칼라 코드화된 신호를 보내면 adder가 받아서 두 신호를
            결합하고 color burst와 synchronization을 더해준다. color burst는 텔레비젼에서 칼라신호를
            분리할 수 있도록 한다.
                표 2-7                                표 2-8
       ☞ YUV 표현에서 NTSC는 6MHz의 대역폭을 사용하는데 그 대역폭은 다음 신호들로 이루어진다.
             ▷FM 스테레오 소리
             ▷luminance 신호 (스캔할 때의 스캔라인에서 각 픽셀의 밝기)
             ▷두가지 chrominance 신호 (color와 그 intensity)

◈JPEG (Joint Photographic Experts Group Compression)
·정지영상이나 연속적인 톤의 이미지를 표현하기 위한 압축표준이다.
       ☞ part 1 : 연산모드와 상호교환 형식, codec을 기술
       ☞ part 2 : part1에서 기술된 표준에 따라 만든 codec의 구현과 test에 관한 표준

·JPEG Requirements
       ☞ 사용자가 요구한 압축과 화질에 있어서 가시적으로 똑같은 정도의 이미지 질을 표현해야 한다.
       ☞ 압축 표준은 실제적으로 어떤 연속적인-톤의 디지털 원본 이미지에도 적용할 수 있어야 한다.
       ☞ lossless에서 lossy까지 scalable해야 한다.
       ☞ 순차 인코딩을 제공해야 한다.
       ☞ 점진적(progressive) 인코딩을 제공해야 한다.
       ☞ 계층적 인코딩을 제공해야 한다.
       ☞ lossless 인코딩을 제공해야 한다.

·Definition in JPEG Standard
       ☞ Baseline system : 4-16bits/pixel의 압축율을 제공하는 압축방법, 가장 기본적
       ☞ Extended system : 가변길이 인코딩을 할 수 있는 시스템
                     progressive 인코딩과 계층적 인코딩이 가능한 시스템
       ☞ Special lossless function : predictive lossless 코딩
                     표현 가능한 해상도에서 스캔에서의 데이 터 손실은 있더라도 압축에서의 데이터
                     손실은 없는 시스템

·Overview of JPEG Components
        ① Baseline sequential codec : 기본적이고 대부분의 응용프로그램에서 사용된다.

        ② DCT progressive mode
        ③ Predictive lossless encoding
        ④ Hierarchical mode
   
       ☞ 3,4는 각기 다른 목적이긴 하지만 baseline 표준안의 성능을 향상시키기 위한 것들이다.

   용어정리

◈Discrete Cosine Transform(DCT)
·2차원 소리 신호를 표현하는 데 사용되는 푸리에 변환에 관련
·
그래프로 나타낼 때 소리신호는 y축을 진폭으로, x축을 주파수로 구성된다.
·
이런 방법으로 표현한다면, 신호는 많은 데이터 점으로 구성되어진다.
·
푸리에 변환을 사용하면 일련의 방정식으로 줄여질 수 있다.
·
이 방정식들은 사인 곡선을 표현하거나 각각의 점들에서 이어 붙이면 소리 신호의 윤곽선을       형성하면서 사인곡선의 집합을 표현한다.
·
DCT는 진폭을 위치시키는 아주 작은 점들을 필요로 하는 방정식으로 그레이-스케일이나 칼라
      신호를 줄여주는데 비슷한 개념을 사용한다.

◈DCT 계수
·
64 orthogonal basis 신호의 출력 진폭
·
64포인트 입력 신호에 의해 유일하게 정의되어지고 64포인트 입력 신호에 들어있는 2D 공간 주파수의 비례량으로 간주 된다.
·
양쪽 차원 모두에서 0주파수를 갖는 계수를 DC계수라 하고, 나머지 것들을 AC계수라 한 다.

◈양자화(Quantization)
·사람보기에는 이상이 없도록 하면서 어떤 정보를 버릴 것인지를 결정하려고 하는 과정
·DCT 계수를 사용하고 다대일 사상을 제공 → lossy과정

◈역양자화(Dequantization)
·
양자화 과정의 역과정
·양자화에서 다대일 사상을 사용→ 사상에서 손실된 정보는 완전히 복구될 수는 없다.

◈Encoder/Decoder 엔트로피
·엔트로피: 동시적 변화를 수행하는 시스템의 능력의 척도 뿐 만아니라 임의성, 혼동성, 무질서의 척도
·엔트로피 인코더 압축:  DCT계수를 좀더 작게 양자화한다.

◈Huffman Coding
·하나 또는 그 이상의 Huffman code 표를 필요로 한다.
·Huffman code표:   decoding 뿐만 아니라 encoding을 위한 어플리케이션에 의해 기술됨
·Huffman 표는 디폴트로서 어플리케이션 내에서 미리 정의되어지고 사용되거나 주어진 이미지를 위해 상세히 계산되어져야 한다.

◈JPEG의 네 구성요소의 동작 목적

·Baseline Sequential Codec
       ☞ DCT 계수의 생성→양자화→엔트로피 encoding의 세단계로 구성된다.
       ☞ 엔트로피 encoding을 위해 Huffman coding을 사용한다.

·DCT Progressive Mode
       ☞ DCT 계수 생성과 양자화의 핵심단계는 Baseline sequential codec 에서와 같다.
       ☞ 차이점: 각 이미지 구성요소가 단일 스캔에 의해서가 아니라 다중 스캔에 의해서 코드화됨
       ☞ 각각의 연속적인 스캔은 양자화 표에 의해 설정된 화질에 이를 때까지 이미지를 깨끗하게 한다.

·Predictive Lossless Encoding
       ☞ DCT 처리와 독립적으로 간단한 예측 방법으로 설정되어졌다.
       ☞ 손실없는 연속적인 톤의 압축을 접근하는 방법을 정의하도록.
       ☞ predictor는 샘플영역을 조합하고 샘플영역을 기초로 하여 이웃 영역을 예측한다.
       ☞ 예측된 영역은 각각 영역에 대한 손실없는 샘플에 대비하여 체크되어지고
               그 차이점이 Huffman이나 수학적 엔트로피 인코딩을 사용하여 손실없이 인코드되어진다.
       ☞ 전형적으로, 2:1압축이 좋은 재생산을 위해 이루어진다.

·Hierarchical Mode
       ☞ 계층적 모드는 다중 해상도를 수행하기 위한 방법들을 제공한다.
       ☞ 각각의 연속적인 이미지의 인코딩은 수평적으로, 수직적으로 두가지 요인에 의해 줄여진다.
       ☞ 낮은 해상도의 장치에 의해 높은 해상도의 이미지가 액세스되어질 경우에 유용하다.
       ☞ 제공되는 가장 낮은 해상도를 수행하고 완전 해상도에로 되돌리는 디코딩을 위해 다중

             2단계에서 이미지를 위한 충분한 차이정보를 제공한다.

◈JPEG Methodology
       ☞ JPEG은 lossy compression

       ☞ forward discrete cosine transform, 단일 양자화기, 엔트로피 인코딩을 사용한다.
       ☞ DCT 함수는 공간 정보를 주파수 정보로 변환하여 데이터 리던던시를 제거
       ☞ 대칭적 알고리즘:   압축의 바로 역과정이 압축해제이기 때문이다.

                    그림 2-3 DCT 인코더와 디코더                         

   JPEG 압축 알고리즘 주요 단계

※ JPEG 압축 알고리즘 주요 단계
영상 → 색상 변환표 → 다운 샘플링 → DCT → 양자화 → 허프만 코딩

◈ 색상 변환표
· 색상정보와 명암 정보를 분리
· 그림 2-4. 색상 변환

◈ 다운 샘플링
· 색상 정보만 다운 샘플(2x2 →1x1)
· 명암정보는 눈에 민감함으로 다운 샘플 하지 않는다
· 그림 2-5. DownSampling

◈ DCT(Discrete Cosine Transform)
· 수학적인 동작은 푸리에 변환(시간함수 -> 주파수 함수)과 관계가 있다.
· 신호(Signal)는 시간(X축)에 대해서 진폭(Y축)으로 표현(Table 2-9)할수 있으 며이 값은 푸리에 변환를 사용하여 Frequency domain(주파수(X축)에 대한 크 기(Y축))로 변환 되어 같은 신호에 대해서 작은수의 데이터로 표현 가능하다 (Table 2-10 참조)
· spatial domain --> DCT --> frequency domain
· Transform하는 이유 : easy implementation to remove noise from the Signal
· DCT transformation 의 이점(특징)

- Large class 의 이미지에 대해서 Optimal transform 되었음이 증명

- orthogonal transform ; 8x8 이미지의 spatial representation을 frequency domain 으로 변환을 허용

- 좋은 압축을 성취하기위해 쉽게 양자화 되어 질수 있도록 계수를 생성한다.

- 효과적으로 계산되어 질수있어서 하드웨어와 소프트웨이로 구현이 용이하다.

- 대칭적(symmetrical)이고 Inverse DCT algorithm 이 그 이미지를 복원하는 데 이용되어 질수 있다.
· DCT Calculations

- discrete cosine transform 공식

DCT(i,j) =

- Inverse cosie transform 공식

pixel(i,j) =
· gray-scale image 압축의 예

(1) 8-pixel-by 8-pixel block 으로 분할

(2) 8x8 block 은 block 에 대해서 8x8 matrix 의 gray value 로 표현

Table 2-9 Input Matrix of DCT Coefficients

  132    136    138    140    144    145    147    155

  136    140    140    147    140    148    155    156

  140    143    144    135    155    155    140    156

  140    143    144    148    150    152    154    155

  144    144    146    145    149    150    153    160

  150    152    153    153    145    132    160    153

  150    156    157    156    140    146    156    145

  148    145    146    148    156    160    140    145

★ Table 2-9 는 분할한 8x8 matrix 에 대한 spatial domain을 표현

★ Table 2-9 에 있는 각각의 숫자는 8x8 matrix 에 있는 각 pixel의 gray-scale 진폭을

의미한다

(3) DCT 계수 생성

Table 2-10 Output Matrix Showing DCT Coefficients

  172    -18    15     -8     23     -9    -14      19

   21    -34    24     -8    -10     11     14       7

   10    -8     -4     -6     -5      4      3      -1

  -10     6     -5      4     -4      4      2       1

  -8     -2     -3      5     -3      5      4       6

   4     -2     -4      6     -4      4      4       2

   4     -3     -4      5      6      3      1       1

   0     -8     -4      3      2      1      4       0

(4) frequency domain DCT components

- DC coefficient

Row 0, Column 0 인 값(172)

ㆍ 다른 63개의 계수보다 크다.

8x8 Input matrix 의 전체값의 평균을 표현 (에너지)

ㆍ고주파 성분

- AC coefficient

DC 계수를 제외한 나머지 계수

DC 계수로부터 멀어 질수록 점점 값이 작아진다.

ㆍ 저주파 성분

★ DCT transform 8x8 block image는 matrix 의 Upper left 에있는 frequency domain 값과 관계가 있다.

◈ Quamtization(양자화)
· 어떤 정보가 시각적 충실도(적합도)의 손실없이 폐기될지를 결정하기 위한 처리
· 계수(integer)의 정밀도를 감소 --> 계수(integer)을 저장하기 위해 요구되는 bit 의 수를 감소 --> 압축률 증가
· DC 계수로부터 멀리 떨어져 있을수록 점점 값이 떨어진다.
· 목적 : disired image quality을 성취하기 위해 필요한 정밀도 보다 더 좋은 정밀도로 표현되어지는 계수 없이

DCT 계수를 표현
· Quantization table

- 많은 실험을 통해서 생성(JPEG baseline 알고리즘에 포함)

- 여러가지 공간 주파수(spatial frequency)에 대해서 사람의 눈의 민감도를 결정한 후 코드화

- higer frequency 보다 low frequency가 정밀도가 높다

- implementor가 자신의 양자화 테이블을 생성하여 사용할수도 있다

- QuantizedCoefficient(i,j)=DCT(i,j)/Quantum(i,j)

Table 2-11 Quantization Coefficient Matrix

   4     7    10    13    16    19    22    25

   7    10    13    16    19    22    25    28

  10    13    16    19    22    25    28    31

  13    16    19    22    25    28    31    34

  16    19    22    25    28    31    34    37

  19    22    25    28    31    34    37    40

  22    25    28    31    34    37    40    43

  25    28    31    34    37    40    43    46

Table 2-12 DCT Coefficient After Quantization

   43     3     2     0     0     0     0     0

    3     3     2     0     0     0     0     0

    1     0     0     0     0     0     0     0

    1     0     0     0     0     0     0     0

    0     0     0     0     0     0     0     0

    0     0     0     0     0     0     0     0

    0     0     0     0     0     0     0     0

    0     0     0     0     0     0     0     0

◈ Zigzag Sequence
· 2차원 배열 --> 1차원 계수열
· RLC coding을 용이
· 그림 2-6. Zigzag Sequence

◈ Entropy Encoding
· Entropy

ㆍ 열역학에서 상태 함수 - 정보의 Entropy 크기

ㆍ 문자 데이터 내의 정보가 갖는 자유도 혹은 정보의 내용을 추정할 때 발생하는 부정확의 정도
· Entropy in number of bits = -log2(probabilityofobject)
· Entropy Encoding

ㆍ발생확률이 높은 문자는 짧은 Code를 할당하고 발생확률이 낮은 문자는 긴Code를 할당 함으로써

평균 Code 길이를 줄일수 있다(발생확률의 편중을 이용하는방식)
· Entropy encoding schemes
- Huffman coding

Coding , Decoding을 위해서 이미 설정된 하나 또는 그이상의 Huffman Code table을 사용한다
- arithmetic coding

Coding table을 사용하지 않는다

· DC Coefficient Coding

- 그림 2-7. Differential DC Coefficient

- differential DC coefficient is delta D = DCx-DCx-1

- Each differential DC coefficient 는 두 개의 Symbol(symbol-1,symbol2)를 이용하여 코드화

symbol-1 : 계수의 차분치를 코드화 하기위해 사용된 bit의 수

symbol-2 : 차분치을 표현

Table 2-13 DC Coefficient Encoding

  Bit Length     BCD  Differential DC Coefficient Value

  0              0000   0

  1              0001   -1 , 1

  2              0010   -3 ,-2 , 2, 3

  3              0100   -7 .. -4 , 4 .. 7

  4              0100   -15 .. -8 , 8 .. 15

  5              0101   -31 ..-16 , 16 .. 31

  6              0110   -63 ..-32 , 32 .. 63

  7              0111   -127 .. -33 , 33 .. 127

  8              1000   -255 .. -128 , 128 .. 255

  9              1001   -511 .. -256 , 256 .. 511

  10             1010   -1023 .. -512 , 512 .. 1023

- Example

D = 9 인 경우

DC Coefficient Coding → 0100 1001
· AC Coefficient Coding

- 두 개의 Symbol(Symbol-1,Symbol-2)를 사용하여 표현

Symbol-1 : run length , size 정보로 표현

run length : Nonzero-value AC 계수를 만나기 전에 연속적인 zero-value AC계수의 수

size : AC 계수값을 코드화 하기 위해서 사용되는 bit 의 수

Symbol-2 : AC 계수값을 표현

- Symbol-1

Table 2-12 DCT Coefficient After Quantization

 

N

N

N

N

S

S

S

S

NNNN : run length(0-15)

SSSS : size

- Example

ZiaZag Sequence → 0000 0000 0000 0000 0000 0000 9

AC Coefficient Coding → 1111 0100 0100 1001

 

Video Image Compression

컴퓨터 , 전화 , TV 등 대중매체가 통합된 멀티미디어 시대가 도래
→ 방대한 정보를 빠른 속도로 주고 받을 수 있어야 하기 때문에 고속의 전송로 와 시스템이 요구
→ 제한된 전송로 하에서 만족할만한 성능을 얻기 위해서는 데이터 압축이 필연적이며 특히 디지털 영상 압축기술이 멀티미디어 응용분야에서 중요한 룰로 대두

◈ Multmedia Standards

- 그림 2-8. Multimedia Standards

◈ Requirements for Full_Motion Video Compression
· Symmetric application

- 압축과 복원의 사용을 동일하게 요구

- 예> 영상 회의 , multimedia messaging systems

- Video camers ,scanner 와 같은 On-line input device 가 필요하다.
· Asymmetric application

- 압축은 한번만 행해지며 복원은 종종 요구

- 예> CD-ROM상에 존재하는 video games, 미리 프로그램된 정보 데이터베이스

- On-line input device 가 필요없다
· MPEG기반 application 의 요구 조건

- Random Access

- VCR Paradigm

- Audio-Video Synchronization

- Multiplexing Multiple Compressed Audio and Video Bit Streams

- Editability

- Playback Device Flexibility(재생장치 융통성)

◈ CCITT H.261 Video Coding Algorithm(Px64)
· BT.601

- ITU-R(1982)에서 방송TV 신호의 디지털 표현을 규정

- 비트율: 216Mbps(압축 부호화가 포함되지 않음)
· H.261

- ITU-T(1990)에서 저비트율의 부호화 표준을 목적으로 Px64kbps(p=1-30) audiovisual 통신용

영상부호화 규정

- 영상 포맷 : CIF,QCIF를 채택

- 부호화방식 : 움직임보상 프레임간 부호화와 DCT을 결합한 하이브리드 부호화

- 응용 분야 : N-ISDN 기반의 영상전화 , 영상회의

- MPEG등의 영상부호화 표준화의 기초
★BT.601(1982) → H.261(1990) → MPEG-I(1993) → MPEG-II(1993) → MPEG-Ⅳ
· CIF(Common Intermediate format),QCIF(Quater CIF:CIF의 1/4 pixtel수)

- TV 영상신호

NTSC(미국TV방식, 525라인의 주사선)

SECAM(동유럽TV방식, 625라인의 주사선)

- 이들 신호는 1초당 frame수와 화면의 주사선수등이 각 방식마다 다르므로 영상전화/회의

단말간에 상대 단말의 영상신호방식을 의식하 지않고 통신 할수 있도록 CIF,QCIF를 규정

- 각 영상신호방식을 CIF 나 QCIF로 변환하여 부호화 하고 복호화 한 뒤 자신의 신호 방식에

맞추어 역변환

그림 2-9. 영상신호 공통 포멧

- CIF :352pixtel X 176line ,QCIF : 176pixel X 88line
· H.261 영상 데이터 계층 구조

그림 2-10. H.261 영상데이터 계층 구조
· H.261 데이터 포맷

그림 2-11. H.261 데이터 포멧

◈ Moving Picture Experts Group Compression
· MPEG-I

CD ,DAT(digital audio tape), 하드디스크, 광 저장장치 등 1.5Mpps 정도의 전송율을 갖는 디지털 저장

매체(DSM:digital storage media)에 동영상 데이터를 압축하여 저장하기 위한 국제 표준 규격
· MPEG-II

디지털 저정 매체 뿐아니라 통신, 방송(HDTV)등 다양한 응용분야에 적용 가능한 범용 표준

(generic standard)으로 광범위한 응용분야의 적용을 위해서 Profile 과 level을 정의 하였다.

- Profile

MPEG-II 표준에 포함되어 있는 여러 가지 기능들 중에서 필요한 부 분만 모아서 만든

특정기능들의 집합

- Level

영상크기를 규정

 

   Level  Profile 

Simple

Main

SNR Scalable

High

High [1920x1080x30 or 1920x1152x25]

 

MP@HL

(US ATV)

 

HP@HL

High-1440 [1440x1080x30 or 1440x1152x25]

 

MP@H1440

 

HP@H1440

Main [720x480x29 or 720x576x25]

SP@ML

(digital CATV)

MP@ML

(digital DBC,

video disc)

SNP@ML

HP@ML

Low [352x288x29.97]

 

MP@LL

SNP@ML

 

◈ MPEG Coding Methodology
· 요구 조건

- very high level of compression

보다 높은 압축율 이루기 위해서는 연속적인 frame들 내의 부호화가 이루어 져야 한다

(interframing coding :영상내의 압축)

- access information randomly

랜덤하게 정보를 엑세스 하기 위해서는 특정 frame을 묶어서 부호화 한다

(intraframe coding : 영상간의 압축)
· 기본 개념

동화상은 연속된 한 장면 한 장면의 정지 화상인 프레임들로 구현되는데 초당 30프레임을

이용하여 동화상을 구현하다고 했을 때 동화상이라 해도 상당히 큰 동작이 아닌 이상,

수록하고 그후 몇초동안에는 1/30초후에 변화한 부분만을 차례로 수록해간다. 그리고 몇초 후에

또다시 프레임을 완전히 수록하는 원리다.
· MPEG video compression standard

- 공간적 정보 압축 : DCT

- 시간적 정보 압축(프레임간 예측) : block-based Motion compensation

◈ Moving Picture Types
· GOP(Group Of Picture)

랜덤 액세스가 가능하도록 하기 위해 몇장의 화면 데이터를 한 묶음으로 하는 GOP구조를 정의

하였으며 GOP 는 다음 세가지 Type 로 구성된다.

☆ Intrapictures(I)

☆ Unidirectionally Predicted pictures(P)

☆ Bidirectionally Predicted pictures(B)

· I Picture

ㆍ해당 화면 정보만으로 부호화되는 화면

ㆍ연속적인 어떤 장소에서도 위치시킬수 있으며 연속적인 그림에 대해 랜덤 액세스를 위해

사용(랜덤 액세스 점을 제공)
· P Picture

ㆍ과거의 Picture(I picture 또는 P picture)에 대한 예측을 수행함으로 써 생기는 화면
· B Picture

ㆍ양방향(과거의 Picture와 미래의 Picture)에 대한 예측을 수행함으로 써 생기는 화면
· ★ 부호화 순서 : I,P Picture을 우선 부호화 → B Picture 부호화

그림 2-12. Moving Compensation for Coding MPEG


◈ Motion Compensation(움직임 보상)
· visual telephony , full -motion video 에 대한 기본 압축 알고리즘

ㆍ 이전 화면에서 움직임 벡터(Motion vector) 가 가리키는 곳을 찾아 일정한 영역분의 화면을

가져오는 과정

그림 2-13. Motion Compensation Motion Vector

Picture Coding Method
· 움직임 보상의 단위 : Macroblock(16x16 pixel)
· Macroblock 의 type

Interpicute(I)

-움직임 보상 벡터가 없으므로 해당 화면정보만으로 부호화(JPEG 알 고기즘과 동일)

Predicted Pictures(P)

-부호화를 위해서 움직임 보상 예측 기술을 사용하며 각 MB 움직 입 벡터를 산정하기 위해서

이전의 P ,I Picture을 사용한다.

Bidirectionally predicted Picture(B)

-forward(past) 움직임 보상,backward(next) 움직임 보상,

-interpolative 움직임 보상을 사용하여 부호화

· MPEG encoder

- 공간적 정보 압축: JPEG 알고리즘과 동일

- 시간적 정보 압축: 이전 Frame 과 움직임 보상에 의한 예측 Frame과 혼합하여 Future Frame을

생성하고 부호화 한다.

그림 2-14. MPEG Encoder 구조


◈ MPEG - 2
· 현재 TV 방송 압축과 복원 및 HDTV 방송 압축 복원등에 초점을 맞추어 표준화 ㆍ MPEG - 2 포준은 다음을 지원한다.

1. Viedocoding

2. Audiocoding

3. Multiplexing

◈ MPEG - 2, "The Grand Alliance"
· MPEG-2 위원회와 FCC "The Grand Alliance" 라 불리는 협약을 맺였다.
여기에는 AT&T , MIT , Philips 의 단체들이 포함되며 이들 단체들은 미국과 유럽의 HDTV시스템을
포함하는 advanced digital television system 에 대해서 정의
· advanced digital television system의 개요

1. format - 1080/2:1/60 or 720/1:1/60

2. Video Coding - MPEG-2 main profile and high level

3. Audio Coding - Dolby AC3

4. Multiplexor - As defined in MPEG-2

5. Modulation - 8-VSB for terrestrial and 64-QAM for cable

◈ Vector Quantization
· efficient pattern-matching algorithm
· group별 양자화 → code book 생성 → table lookup(decoder

그림 2-15. Vector Quantization

◈ Intel's Indeo Technology
·4 시간에서 10시간 정도의 압축되지 않은 디지털 비디오 파일의 사이즈를 줄 이는 Software Technology
·여러 종류의 "lossy" 와 "lossless" 압축 기술을 사용
·Analog Viedo을 Video Capture board에 의해서 디지털 포맷으로 변환
· 압축 기법

- YUV sampling

- Pixel differencing and temporal Compression( Pixel 또는 Frame들 간의 변화 정보만을 저장하여

데이터량을 축소)

- Run-length encoding(양자화된 Vector 정보를 압축)

- Variable-content encoding(가변전 정보량을 고정된 bit의 수로 축소)

ㆍ압축된 디지털 Viedo 는 Audio 정보와 묶여서 Macrosoft's AVI 또는

Apple's QuickTime 과 같은 표준 파일 포맷으로 저장


◈ Apple's QuickTime
· 저가 모션 비디오의 지원을 위한 소프트웨어적인 압축/ 복원 기법
· 특별한 하드웨어 없이도 일반 PC에서 비디오 영상을 볼수 있게 해준다.
· 압축 기법 → Vector Quantization(25에서 200 까지의 압축율을 제공)
· 비디오 해상도는 하드웨어의 지원없이 320x240으로 초당 30 프레임까지 가능하다.

◈ Microsoft AVI
· 저가 저해상도 비디오를 위한 파일 형식
· 매체 재생기를 통해서 AVI 파일을 볼수 있다.
· 160x120 크기의 윈도우에서 초당 15프레임의 속도로 비디오 감상 가능

◈ Intel's DVI(Digital Viedo Interface)
·Hardware Standard

 

Audio Compression

· Audio는 여러 주파수의 analog 신호로 구성되어 있다
· Audio 신호는 디지털 형태로 변환되어 처리 , 저장 전송된다
◈ 압축 알고리즘

- linear predictive coding

- adaptive differential pulse code modulation(ADPCM)

◈ CCITT 권고

- G.711:1988 - Coding of analog signals by 64-kbit/sec Pulse Code Modulation(PCM)

- G.721:1988 - 32-kbit/sec ADPCM

- G.723:1988 - Extensions of Rec.G.721 ADPCM to 24 and 40-kbit/sec

◈ Adaptive Differential Pulse Code Modulation

※ PCM(Pulse Code Modulation) : analog 신호 → Digital 신호

- 샘플링된 정보 하나하나를 부호화 하여 0,1을 나타내는 펄스신호 계열로 치환 시키는 것

-그림 2-16. PCM(Pulse Code Modulation)

- ADPCM : data stream에서 연속적인 샘플들의 값 차이만을 저장하고 부호화 함으로써 압축하는

방식

 

Resource Interchange File Format(RIFF)

◈ RIFF란?
· RIFF는 새로운 file format은 아님
· Microsoft windows에 기반한 application을 위한 Multimedia file formats을 위한 outline을 제공한 것.
· 단지 기본적인 형식으로써 사용됨.
· RIFF는 custom file format을 RIFF구조로 둘러쌈으로써 RIFF File Format으로 전환시킴.

예) MIDI File Format : RIFF "chunks(정보의 코드화된 blocks)"의format에 있는 RIFF structure를 MIDI file에 추가함으로 RIFF MIDI로 전환됨.

◈ RIFF화일은 TIFF와 같은 tagged file format이고,tag들을 tag정보로 사용함.
· tagged file format를 쓰면 요구된 tag들을 찾는데 32-bit ASCII strings을 사용하기 때문에 search가 더 빠름.
· change나 update는 tag들을 변환하거나 새 tag들을 추가함으로써 더 쉽게 조작되어짐.
· 간단하게 말하자면, TIFF와 RIFF와 같은 tagged file format은 새 tag의 추가에 의해 확장 가능한 file을 조직화하는 기본적인 방법을 제공한다.
· file에 다른 tagged block을 추가함으로써 새로운 정보를 제공하기 위해 더 많은 공간이 제공됨.

◈ file reader는 interpreting이 가능한 information content를 결정한다.

예) application이 recording format의 높은 주파수 복사본을 조작할 수 없다면 이 tag는 skip되고, 낮은 주파수 복사본 tag들의 나머지를 통해서 조작(작동)된다.

◈ RIFF file format은 "chunks"라고 불리는 data의 Block들로 구성된다.
· chunk는 TIFF file의 image file directory entry와 비슷한 것
· 각 RIFF chunk는 'tag'라 불리는 4개의 character ASCII string을 구성
· 그림 3-4에서 보는 바와 같이 4byte는 chunk data의 크기와 그 이후의 data를 포함한다.
· RIFF specification은 아래 chunk의 종류들로 정의된다.

① RIFF chunk - RIFF file의 내용을 정의함

② List chunk - archival location과 copyright information, creation data등과 같은 추가 file 정보를 내포한다.

③ Sub chunk - primary chunk가 충분치 않을 때 primary chunk에 더 많은 정보를 추가시킴

그림 3-4. RIFF chunk의 조직도

◈ RIFF file에 있는 첫 번째 chunk는 RIFF chunk이어야 함
· 이것은 하나 이상의 sub_chunk를 포함할 것이다.
· RIFF chunk data field의 첫 번째 4byte form type field를 위해 할당되어지고, file에 저장된 data의 형식(AVI, WAV, RMID 등)을 증명할 수 있는 4개의 character를 포함한다.
· 아래 Table 3-14는 Microsoft windows multimedia RIFF file type을 사용한 filename extension을 보여준다.

Table 3-14 Filename Extension for RIFF

File Type

Form Type

File Extension

Waveform Audio File
Audio Video Interleaved File
MIDI File
Device Independent Bitmap File
Palette File

WAVE
AVI
RMID
RDIB
PAL

.WAV
.AVI
.RMI
.RDI
.PAL


◈ subchunk는, data의 type을 증명하는 4 character ASCII string ID와 data 값의 카운트를 포함하는 size의 4 byte와 데이터 그 자체를 포함한다.
· chunk의 data 구조는 RIFF chunk이든, list chunk이든, subchunk이든 아래와 같다.

typedef unsigned long DWORD;
   typedef unsigned char BYTE;
   typedef DWORD FOURCC;        // Data type four-character code representing
                                // 32 bit word containing one to four ASCII
                                // alphanumeric characters
typedef struct {
   FOURCC ckID;                 // Up to 4 character ID, e.g. for WAVE, AVI
   DWORD ckSize;                // the number of bytes in the data
   BYTE ckData[ckSize];         // Array containing the actual data of the
                                // chunk
   } CK;


· 위 예의 첫 번째 part는 tag를 표현하고, 두 번째 파트는 structure CK, chunk에 있는 data를 가진 chunk를 표현한다.

 

RIFF Chunk with Two Subchunks

◈ Figure 3-4에서 나타난 (그리고 structure CK)듯이, RIFF chunk의 첫 번째 4 문자는 "RIFF" ASCII string을 위해 예약되어져 있다.

◈ 다음 4 byte는 총 data size를 정의한다.
· RIFF chunk 자체의 8 byte와 모든 subchunk의 size이다.
· data field에 있는 첫 번째 4개 character는, Form Type을 위해서 예약되어져 있다.

-- 이 경우는 "WAVE" type
· data field의 남은 부분은, 두 개의 subchunks를 포함한다.

-- waveform의 recordy 특성을 정의하는 첫 번째 type은 fmt,

-- 두 번째 type은 waveform의 data를 포함하는 data이다.

◈ 아래 code는 data field 조작을 설명한다.

RIFF ('WAVE'
      { SubChunk1 'fmt' 
        SubChunk2 'data' 
      }
)

◈ Table 3-15는 RIFF File구조를 이해하기 위해 Micrsoft Windows에서 제공하는 TADA.WAV waveform audio file에 대한 chunks를 기술한다.

◈ 이 예에서는 RIFF Form은 2개의 subchunk를 가지는 WAVE type이다.
· subchunk fmt는 audio waveform data의 recording 특성을 표현
· subchunk data는 waveform의 data를 포함
· offset과 code 값을 hex로 나타낸다.

 

List Chunk

◈ list chunks의 목적은?
· list chunks는 archival location, copyright information, creation date, description of the contents of the file등과 같은 추가화일 정보를 내포
· identification을 위한 4개 문자 ASCII string을 가진다.
· data에 의해 부여된 data의 크기를 알기 위한 4byte size field를 가진다.
· data field의 첫 번째 4문자들은 list type field에 위치

- Microsoft는 단지 'INFO'라 불리는 문서화된 하나의 list type를 가진다.

- INFO list는 copyright information, creation date archivla location 등과 같은 추가 file 정보를 위해 subchunks를 포함한다,

 

RIFF waveform Audio file format with INFO list chunk

◈ INFO list chunks를 가진 RIFF Waveform file format
· 첫 번째 subchunk는 company name을 표현한 "INAM"
· 두 번째 subvhunk는 copyright information을 표현할 "ICOP"
· 세 번째 subchunk는 파일을 생성한 날짜를 나타내기 우한 "ICRD"

◈ INFO list chunks를 가진 RIFF Waveform file format의 psedo code

RIFF ('WAVE''
    LIST ('INFO'
      { SubChunk   'INAM'   
        SubChunk   'ICOP'    
        SubChunk   'ICRD'    
      }
    )
    { SubChunk   'fmt' 
      SubChunk   'data' 
    }
)


◈ subchunk "fmt"는 아래 data structure를 포함.

typedef struct tagwaveformat {
   WORD   wFormatTag;    //Waveform format type
   WORD   nChannels;       // Number of channels
   WORD   nSamplesPerSec;  //Sampling rate
   WORD   nAvgBytesPerSec; //Average transfer rate for buffering
   WORD   nBlockAlign;       //Block alignments
   UNIT    nBitsPerSample;    //Number of bits per sample
) WAVEFORMAT;

 

RIFF MIDI File Format

◈ RIFF MIDI File format은 MIDI format주위를 둘러싼 RIFF wrapper를 칭한다.
· RIFF MIDI는 "RMID" form type를 가진 RIFF chunk와 MIDI data데 대해 "data"라 불리는 subchunk를 포함
· 기본 MIDI File은 아래 sample colde에서 보는 것과 같이 data subchunk내에 포함

RIFF( 'RMID'
        {subchunk 'data'   
        }
  )

 

RIFF DIBS(Device-Independent Bitmaps)

◈ DIBs는 JPEG DIB를 표현하는데 사용되어지고, motion images에 사용되어진다.

◈ DIB(Device-Independent Bitmap)은 device와는 독립된 bitmap의 color atributes와 bitmap을 정의하는 마이크로소프트 윈도우의 standard format
· 이 format은 다른 device에서 display되고 print되어지는 DIB를 쓸수 있다.
· DIBs는 windows내의 .WMF metafile과 clipboard 또는 DIBs는 정상적으로 BMP file에 내포되어진다.
· DIB구조는 BITMAPINFOHEADER라 불리는 bitmap information header와 RGBQUAD라 불리는 color table structure와 pixel bitmap에 대한 bytes의 배열로 구성
· 구조는 아래와 같다.

BITMAPINFOHEADER

RGBQUAD

PIXELS


◈ DIB구조에 추가적으로 DIB file은 DIB 구조전에 기술된 BITMAPFILE HEADER라 불리는 bitmap file header구조를 포함한다.
· 아래는 DIB file format(BMP format이라 알려진)을 보여준다.

BITMAPFILEHEADER

BITMAPINFO = BITMAPINFOHEADER + RGBQUAD

PIXELS

◈ 위의 이 DIB File format은 아래 구조로서 표현됨

BITMAPFILEHEADER: 
      bmFileHeader;                 //file header
BITMAPINFO:
      bmInfo;                     //containing a BITMAPINFOHEADER structure
                                  //with header information and RGBQUAD
                                  // structure containing the array of colors
BYTE:
      bBitmapBits[ ];             //array of bitmap bits

· BINTMAPFILEHEADER 구조에서는 Bitmap file의 type와 크기를 포함
· BITMAPINFO구조는 BITMAPINFOHEADER구조와 RGBQUAD구조로서 구성됨
· BITMAPINFOHEADER구조는 dimensions, compression type와 bitmap을 위한 color format을 기술

◈ DIB file format은 RGBQUAD structures의 배열을 포함
· 이 배열에 있는 구성요소들의 수는 bitmap에 있는 color의 총 수를 나타낸다.
· 이 color table은 pixel당 24 color bits를 포함한 bitmap에 대해 사용되어진다.
· 이 경우 24bit값 자체는 RGB color값을 포함한다. RGBQUAD 구조는 아래 code segment와 같다.

typedef struct tagRGBQUAD {
   BYTE  rgbBlue;    //the intensity of blue color
   BYTE  rgbGreen;  // the intensity of green color
   BYTE  rgbRed;    // the intensity of red color
   BYTE  rgbReserved;  // must be zero
} RGBQUAD;

 

RIFF DIB File Format

◈ ·RIFF DIB File Format은 form type "RDIB"와 DIB data를 위한 "data"라 불리는 subchunk를 가진 RIFF chunk를 포함한다.
· DIB data는 단지 우리가 표현한 DIB File Format이다.
· 아래코드 segment는 RIFF chunk에 DIB file을 내포한 것을 보여준다

RIFF ('RDIB'
     { SubChunk 'data' 
     }
)

 

RIFF PALETTE File Format

◈ RIFF palette file format은 Form type "RPAL"을 가진 RIFF chunk와 palette data를 위한 "data"라 불리는 subchunk를 포함한다.
· Microsoft windows 논리적 palette 구조는 RIFF data subchunk에 내포되어 있다.

RIFF ('RPAL'
     { SubChunk    'data' 
     }
)

· palette 구조는 palette version number, palette entry의 number, red, green, blue colors의 intensity와 palette usage에 대한 flag들을 포함한다.
· 이 palette 구조는 아래 code segment에 의해 표현

type struct tagLOGPALETTE {
   WORD     palVersion;  //Windows version number for the structure
   WORD     palNumEntries;  //Number of palette color entries
   PALETTEENTRY palPalEntry[ ];
} LOGPALETTE;

· PALETTEENTRY data구조는 red, green, blue color와 palette usage에 대한 flage들을 기술한다.
· 이 PALETTENTRY 구조는 아래 code segment에서 구현된다.

               
type struct tagPALETTENENTRY {
   BYTE  peRed;      // Intensity of red color
   BYTE  peGreen;    // Intensity of green color
   BYTE  peBlue;     // Intensity of blue color
   BYTE  peFlags;    // Defines the usage of the palette entry
} PALETTEENTRY;

 

RIFF Audio Video Interleaved(AVI) File Format

◈ AVI file은 RIFF AVI file format을 생성할 RIFF Format내에 내포될 수 있다.
· RIFF AVI File은 Form type "AVI"를 가지는 RIFF chunk를 포함하고, 2개의 위임된 LIST chunks인 "hdr1"과 "movi"를 포함
· 이 list chunka "hdr1"은 data의 형식을 정의하고, "movi"는 audio-video stream을 위한 data를 포함
· "idx1"이라 불리는 세 번째 list chunk는 임의의 index chunk
· "hdr1"과 "movi" list chunks들은 임의의 subchunks를 포함할 수 있음.
· 이 list chunk "hdr1"은 main AVI header와 stream header "strh" subchunk, stream format chunk "strf" subchunk와 임의적으로 추가될 data chunk "strd"를 포함

◈ "movi" chunk
· LIST chunk "movi"는 data chunk라 불리는 subchunk에서 audio-video stream에 대한 실제 data를 포함한다.
· movie chunk는 "rec" chunk라 불리는 하나이상의 subchunks를 포함한다.
· "rec" chunk는 group을 형성할 data subchunk로 group화된다.
· data chunk는 실제 data에 의해 따라오는 "##nn"의 4개 문자 string을 포함

- 첫 번째 두 문자는 stream 수(number)를 정의하고, 두 번째 두 문자는 data chunk에 포함된 data의 type를 정의한다.

 

INDEX "idx1" Chunk

◈ index chunk는 AVI file에 대한 임의적인 chunk이고, 이것은 LIST "mov"chunk후에 위치되어진다.
· 각 movi chunk는 하나의 index chunk를 포함
· 인덱스 chunk는 data chunks의 entries에 대한 indexing 정보를 포함하는데 사용되어지고, file에서 이들 data chunks의 실제 위치의 entry에 대한 인덱싱 정보를 포함함.

◈ Index chunks은 무엇에 사용되어지는가?
· audio와 video stream의 playback이 삽입하고, "rec" chunk와 data chunks를 함께 group화하는데 사용된다.
· index chunk는 large interleaved AVI file에 audio segment나 video frame에 random access할 각 rec chunk에 대한 entries를 포함
· Index chunk는 entry를 포함하는 AVIINDEXENTRY구조에 의해 따라나오는 4개 문자스트링인 identifier "idx1"으로 시작한다.
· rec chunks에 대한 multiple entries를 가진 index chunks는 AVIINDEXENTRY구조들의 배열을 포함한다.
· AVIINDEXENTRY 구조는 아래 code segment에 의해 표현된다.

typedef struct {
    DWORD ckid;
    DWORD  dwFlags;
    DWORD  dwChunkoffset;
    DWORD  dwChunkLength;
} AVIINDEXENTRY;

 

MIDI File Format

◈ RIFF File Format과 같이 MIDI file format은 data의 chunks(blocks)를 포함한다.
· MIDI는 header chunks와 track chunks라는 두 타입의 chunks를 기록한다.

◈ Header chunk
· header chunk는 아래와 같은 것으로서 14byte로 구성되어 있다.

① 첫 번째 4개 문자 string은 identifier string이다. "MThd."

② 두 번째 4byte는 header chunk에 대한 data size를 포함한다, : 이것은 6byte의 고정된 값의 집합이다.

③ 나머지 6byte는 header chunk에 대한 data를 포함한다.

◈ Track chunk
· track chunk는 아래와 같이 조직화된다.

① 첫 번째 4개 문자열은 "MTrk"라는 인식자

② 두 번째 4개 문자열은 track의 길이를 포함함

③ chunk의 남은 부분은 MIDI Messages를 포함함.

◈ MIDI message는 MIDI 1.0 specfication에 정의된 MIDI Communications protocol에 기반한다.

 

MIDI Communication Protocol

◈ MIDI communication protocol은 multibyte messages를 사용한다. : 메시지의 타입에 따른 바이트의 수
· 메시지는 channel messages와 system messages 2개의 타입이 있다.

◈ Channel Messages
· channel message는 메시지에 3byte를 사용한다.
· 첫 번째 바이트는 status byte이고 다른 두 개의 바이트는 데이터 바이트라 불린다.
· 16개 채널 중 하나로 주소화된 channel number는 status byte의 낮은 nibble에 의해 encode화 된다.
· 각 MIDI voice는 channel number를 가지고 message는 status byte의 낮은 nibble에 인코드화된 채널 number와 일치하는 channel number에 메시지를 보낸다.
· 채널메세지에는 voice message와 mode message 2가지 타입이 있다.

⊙ voice messages
· voice mesage는 악기(장치)의 소리를 조절할수 있다. : note를 on이나 off로 전화하고 key가 depressed된 표시를 할 key pressure messages를 보내고, vibrato,sustain, tremolo와 같은 효과를 조절할 control message를 보낸다.
· Pitch wheel messages는 모든 노트의 pitch를 변화시키는데 사용된다.
· polyphonic key pressure와 channel key pressure 메시지는 하나이상의 키가 낮춰질 때 짧은 간격사이에 반복적으로 생성된다.
· polyphic 압력(pressure)은 동시에 연주된 특별한 note에 대한 힘의 크기를 제공한다.
· Channel pressure는 특별한 채널(악기)과 연관된 키에 대한 힘의 크기를 제공한다.
· Control change 메시지는 vibrato, tremolo와 pitch와 같은 효과음을 조절하기위해 이용된다.
· pitch change message는 특별한 voice channel에 대한 모든 note의 pitch를 변화시킨다. 이 변화는 다음 pitch change시기까지 영향을 미친다.

⊙ Mode Messages
· Mode messages는 16개 채널에 up될 voice 에 사용된다.

- MODO mode나 POLY mode에 device를 set한다.
· Omni Mode On은 모든 채널에 voice message를 수신할 device를 enable시킴.
· Local Control Off 메시지는 external device는 소리를 조절하게하기 위해 신디사이저로부터 키보드를 disconnect한다.
· Local Control On은 메시지는 키보드 연결을 반환(restore)한다.
· 모든 notes Off 메시지는 모든 notes를 off 시킨다.
· Modno Mode On 메시지는 한 채널에 단 하나의 voice만을 할당한다.
· Poly Mode On인 경우에는 multiple voices가 하나의 voice channel에 할당된다.

◈ System Messages
· systemt message는 여러 채널 number를 포함하지 않고 특별한 채널들에 한해서 완전한 system에 적용된다.
· 시스템 메시지는 common message, real-time message와 exclusive message라는 3가지 타입이다.

⊙ Common Messages
· 이 메시지는 complete system에 공통적으로 사용된다.
· 이 메시지는 노래를 선택하거나, beats 수를 가진 song position pointer를 setting하고 analog synthesizer에 tune request를 보내는 것과 같은 function을 제공한다.
· song select message는 song number에 의해 노래를 선택할 수 있다.
· song position pointer message는 song에 특별한 position에 position pointer를 setting한다.
· tune request message는 synthesizer에 특별한 tune request를 보낼 때 사용된다.
· system exclusive message는 system-wide message의 끝을 나타내는 flag이다.

⊙ System Real-Time Message
· 이들 메시지는 system의 realtime parameters를 setting하는데 사용된다.
· 이들 파라메타는 timing clock, sequencer의 시작과, 멈춤 stop된 position으로부터 sequencer를 다시 시작하게 하는것과 system reseting을 포함한다. · Timing Clock message는 4분의 1의 note당 24 clocks에 system 동기화 시간 clock을 set한다.
· start와 stop message는 sequence의 시작과 멈춤을 나타낸다.
· continue message는 stop된 position에서 sequencer를 재시작하는데 사용된다.
· Active Sensing message는 sequencer가 현재 operation을 수행중이라면 check값을 보낸다.
· 마지막으로 reset message는 complete system을 reset한다.

⊙ System Exclusive Messages
· 이 메시지는 identification, serial number, model number와 그외의 정보와 같은 manufacturer-specific(제조자에 의해 특별히 만들어진) 데이터를 포함한다.
· 이 메시지그룹에 대한 모든 function은특별히 system exclusive message라는 하나의 메시지에 의해서 수행된다.
· Manufacturer가 제공하기 원하는 Manufacturer serial number, model number와 다른 정보들은 manufacturer-defined byte stream에 포함되어진다

 

JPEG DIB File Format for Still And Motion Images

· Microsoft는 JPEG still과 motion images 2가지에 대한 DIB file format standard를 확장하였다.
· 이 표준당 JPEG still images는 JPEG DIB file format에 내포된다.
· 이것은 대부분 JPEG-compliant codecs에 의해 처리되어진다.
· motion JPEG images에 대한 표준은 표준 JPEG DIB file을 생성할 수 없다.

- 대신, 이것은 AVI file format내에 이미지를 위치시킬 것을 추천한다.

◈ 이들 표준에 대한 중요한 point는?

① slight revision을 가진 BITMAPINFOHEADER 구조가 존재함

② RIFF AVI file format을 가지고 쉽게 사용할 수 있는 JPEG DIB를 제공함

③ JPEG DIB extension은 표준을 다르는 codecs를 제공함.

- 어떤 codec은 JPEG still과 motion images를 create, read, 처리하는 것이 가능함.

 

JPEG Stil Image

· still images에 대한 JPEG DIB들은 연속적인 데이터 stream처럼 JPEG image data를 내포하고 있다.
· 이런 접근으로서, 표준 file format은 platforms과 applications를 통해 움직일 수 있도록 생성된다.
· 한 DIB의 JPEG portion내에 있는 table과 다른 데이터를 indexed access하는 것은 BITMAPINFOHEADER구조에서 새 members를 정의함으로서 제공되어질 것이다.

 

JPEG Motion Image

· motion JPEG DIBs는 완전하지 않으면 혼자서 disk file을 사용할 수가 없다.

-- 대신에 motion JPEG DIBs는 AVI RIFF file format에 포함될 것이다.

◈ JPEG DIBs는
· BITMAPFILEHEADER라 불리는 file header 구조,
· BITMAPINFOHEADER라 불리는 bitmap information header
· RGBQUAD라 칭하는 color table 구조와 bitmap byte의 배열을 포함

◈ Microsoft에 의해 JPEG DIBs의 BITMAPINFOHEADER구조변경은 BITMAPINFOHEADER구조에 대한 확장이다.
· JPEG에대한 확장된 BITMAPINFOHEADER이다.

typedef struct tagEXBMINFOHEADER { 
    BITMAPINFOHEADER bmInfoHeader; //original structure
 
    //extended BITMAPINFOHEADER fields
    DWORD biExtDataOffse;   // Specifies offset to the start of 
                            //the JPEG-specific data.
                            // This field allows expanding 
                            //  the BITMAPINFOHEADER structure.
    // Other members to be defined later by Microsoft.
} EXBMINFOHEADER;

 

JPEG AVI file Format with JPEG DIBs

◈ JPEG AVI file format은 minor changes를 가진 AVI RIFF를 사용한다.
◈ AVI file format과 같이 JPEG AVI file format은 "hdr1","movi" LIST chunks를 사용한다.
· 모든 JPEG DIB frams는 주소화가 가능하고 그래서 모든 JPEG DIB frams는 key frame들이다.
· Index chunks는 큰 AVI file로부터 JPEG DIB video frame들을 찾기위해 random access를 제공할 각 data chunk에 대한 key frames entry를 포함한다.

◈ JPEG AVI file format과 AVI file format의 차이점

① "strf" chunk는 data의 stream fromat을 기술할 EXBMINFOHDADER 구소 member를 포함한다.

② "strh" chunk는 still images를 위해서나 FOURCC code와 적당한 codec을 초기화하기 위해 특별한 data를 가진 motion imgaes를 위한 "MJPG"를 포함한다.

③ "movi" chunk나 "rec" chunk은 JPEG DIB data를 포함한다.

④ "index" chunk는 모든 JPEG DIB frames에 대한 entry를 포함한다. 이는 JPEG DIB frame들을 random access한다.

 

TWAIN

· Multimedia system의 출현으로 이미지(image, real-time video clips, dramatic하게 live로 생성되는 오디오와 voice soundtrack 등)와 같은 object들을 사용할 필요성이 도래되고 있다.
· mage와 그래프롤 동반하고 sound를 가진 video clips를 동작시키는 것과 같은 형태를 가진 text를 display할 복잡한 출력을 가진 document를 생성해 줄 application을 사용한다.
◈ 이같은 장치들은 어떻게 사용되어지는가?
· 첫 번째, application creator는 multimedia objects를 capture하기 위해 input device를 사용하는 전용 application을 써야함.
· 이렇게 독립가능한 application은 하나의 장치로부터 입력 데이터를 요구하기 위해 사용된다. -- 이것은 다른 응용프로그램에 의해 사용되어지기 위해 디스크 파일에 저장된다.

예를 들어 word-processor document는 OCR(Optional Charater Recognition)시스템에 의해 capture된 data를 요구했다면, 디스크로부터 요구된 ASCII text file을 import시킬 import 함수를 사용한다.
· 다른 소스로부터 데이터가 요구될 때와 다른 application이 data를 capturing하기 위해 사용될 때 데이터는 서로 다른 디스크 파일에 저장되어야 함.
· 데이터를 capture하는 것과 더불어 사용자가 capture된 데이터를 edit할 수 있다.
· TWAIN working group는 custom interface의 새로운 장치 추가의 문제를 주소화하는 것으로 input device에 대해 open industry stardard interface를 정의한 것으로 알려져 있다.
· 표준 interface는 디바이스당 특별한 driver의 생성없이 TWAIN interface를 사용하여 scanner, digital camera, video camera들 등과 같은 서로 다른 타입의 input device를 가지고 interface할 application을 설계가능하다.

◈ 이와 같은 접근의 명백한 장점은?

① application developers는 모든 TWAIN-compliant input device에 인터페이스할 application을 허락하는 단일 TWAIN specification을 code화 할 수 있다.

② Device manufacturer는 그들 자신만의 device를 위한 device driver에 쓸 수 있고, TWAIN specification을 따름으로서, 모든 TWAIN-compliant application들에 의해 사용되는 장치를 다 사용할 수 있다.

③ TWAIN-compliant application은 사용자가 동일한 TWAIN driver를 사용하는 다양한 장치중 하나를 선택하는 "Acquire"와 "Select Source"메뉴 pick options들을 사용할 수 있게한다.

 

TWAIN specification Objectives

1. multiple platforms을 지원한다

- Microsoft windows, Apple Machintosh OS system 6.x, 7.x, UNIX, ad IBM OS/2를 포함.
2. Multiple device를 지원한다

- scanner, digital camera, frame grabbers등을 포함.
3. 표준 인터페이스를 가진 광범위한 수용력

- TWAIN은 매우 잘 알려진 표준 Interface.
4. 표준 확장가능성(신장성)과 호환성

- TWAIN구조는 새로운 장치의 타입과 새로운 장치의 기능성에 대해 확장이 가능.
5. Multidata format

- TWAIN은 TIFF,PICT, DIB와 같은 format에서도 data전송이 가능.

- 데이터 format은 이미지 데이터타입을 제한하지 않음
6. 사용이 쉽다.

 

TWAIN Architecture

· TWAIN구조는 입력장치로부터 데이터를 요구하는 프로토콜과 application programming interfaces (APIs)의 집합을 정의한다.
· 이 구조는 application과 device layer들 사이에 있는 protocol layer와 acquisition layer로 구성된 계층화된 구조이다.
· protocol layer는 application acquisition layer들 사이의 통신을 지원한다.
· acquisition layer는 장치를 조절하는 virtual device driver를 포함한다. · virtual layer는 source에 의해 call된다.
· 이들 layer들을 조합하여 사용함으로서, TWAIN은 장치를 통해 session을 set up할 수 있는 application을 사용할 수 있게하고, 데이터 획득 트랜잭션을 수행한다.

◈ Application layer
· TWAIN application은 device를 통한 논리적인 connection을 이룬다.
· TWAIN은 application의 설계에 대한 어떤 rule들을 강요하지는 않는다.
· 장치들에 논리적으로 주어진 list로부터 source를 선택하는 user interface에 대한 지침사항들은, 지정하고, 선택된 source로부터 데이터를 요구하는 user interface 지침사항을 기술한다.

◈ Protocol layer
· application layer는 protocol layer에 의해 interface가 이루어진다.
· protocol layer는 application과 acquisiton layer사이의 통신을 지원한다.
· 이것은 application과 source사이의 모든 session을 관리하고, data 획득 트랜잭션을 감시한다.
· protocal layer의 중점은 source manager라는 것이다.
· source manager의 함수성은 아래와 같다.

① 모든 TWAIN compliant source에 대해 표준 API(Application Programming Inerface)를 제공한다.

② application내에 사용자에 대한 selection source들을 제공한다.

③ application과 source들 사이에 논리적인 session을 설립하고, multiple application과 multiple source사이의 session들을 관리한다.

④ session과 unique session identity들의 track을 지킨다.

⑤ application에 의해 지정된 source들을 load하거나 unload한다.

⑥ source로부터 application의 모든 return code값을 pass한다.

⑦ default source를 유지한다.
· protocol layer는 complex layer이고 이것은 application interfacing function과 device의 가장 중요한 면을 제공한다.

◈ Acquistion layer
· Acquistion layer는 virtual device driver를 포함한다.
· 이 layer는 device driver와 직접적으로 상호작용을 한다.
· source는 지역적일수 있고, 논리적으로 local device에 접속이 가능하거나, remote일 수도 있고, 논리적으로 remote device에 논리적으로 접속이 가능하다.
· source는 아래와 같은 fuction을 수행한다.

① device를 제어

② device로부터 data를 습득

③ 승인된 format에서 data를 전송

④ 장치를 제어할 usre interface를 제공, user interface는 장치에따라 특별하고, device manufacturer에 의해 설계된다.

◈ Device layer
· device driver의 목적은 software명령을 수신하는 것이고, 장치 hardware를 알맞게 제어한다.

 

New WAVE RIFF File Format

◈ RIFF File Format은 새로운 WAVE form은 두 개의 subchunk('fmt', 'data')를 포함한다.
· 위임된 subchunk를 추가함으로서, fact, cue points, play lsit, associated data list.를 포함할 수 있다.
· 새로운 wave form의 일반적인 구조는 아래 segment와 같다.

 
  RIFF( 'WAVE;
         ('fmt'-ck)          //Format
         [(fact-ck)]          //fact chunk
         [(cue-ck)]          // cue points
         [(playlist-ck)]       //Playlist
         [(assoc-data-list)]   //Associated data list
         (wave-data)         //Wave data
)

◈ Fact Chunk

(fact-ck) -> fact ( (dwSampleLength : DWORD) )

· 에는 samples에 있는 데이터의 길이를 표현한다.
· WAVE format header로부터 는 초당 data의 길이를 결정하는 field와 결합하는데 사용됨.
· fact chunk는 모든 새로운 WAVE형식에 대해 요구됨.
· 이 chunk는 표준 WAVE_FORMAT_PCM 파일들을 요구하지 않음.
· fack chunk는 미래의 WAVE format에 의해 요구된 다른 정보를 포함할 수 있게 확장가능하다.
· 추가된 필드들은 field에 나타날 것이다.
· application은 현재 field에서 결정된 chunk size field를 사용할 수 있다.

◈ Cue Points Chunk
· cue point chuk는 wave form data stream에서 위치를 정의한다.

(cue-ck) -> cue( (dwCuePoints:DWORD)  //Count of cue points
                     (cue-point)              //Cue-point table
                      ....
                )

· 구조는 아래와 같다.

struct {
      DWORD    dwName;     //유일한 cue point name
      DWORD    dwPosition;   //play order내의 순서적인 sample number
      FOURCC   fccChunk;    //Chunk ID
      DWORD    dwChunkStart;  //data chunk의 시작
      DWORD    dwBlockStart;   //위치를 포함하는 블록의 시작
      DWORD    dwSampleOffest;  //Relative to the start of the block
}

· cue-point구조는 data chunk의 시작을 지정하는데 사용된다,

◈ Playlist Chunk
· playlist chunk는 cue point의 series를 위한 play 순서를 기술한다.

(playlist-ck) -> plst(
                       (dwSegments:DWORD) //Count of play segments
                       (play-segment) // Play-segment table
                        .....
                    )

· 구조는 아래의 코드 세그먼트와 같다.

struct (
       DWORD dwName;   //Cue point name matching to the name listed
                            // in the cue-pointstructure
       DWORD dwLength;  //Length of the section in samples
       DWORD dwLoops;   // Number of times to play the section
)

· play-segment 구조에서의 변수들은 self-explanatory이다.
· 이들 변수들은 내포된 object에 대한 display/playback parameter들에서 높은 control level을 제공한다.

◈ Associated Data Chunk
· associated data list는 label과 같은 정보를 attach하는 기능을 제공하고, waveform data stream을 구분하는 기능을 제공한다.

(assoc-data-list) -> LIST ('adt1'
    (labl-ck)     //cue point와 연관된 label이나 title
    (note-ck)     // cue point에 대한 note
    (ltxt-ck)      // data length를 가진 텍스트

· 첫 번째 두 구조는 간단하고 아래 code 세그먼트에서 표현된다.

(lab-ck) -> lab1(
     (dwName:DWORD)   //cue point 구조에서 가지는 이름과 match하는 이름
     (data : ZSTR)        //이름을 포함하는 null terminated string
 
(note-ck) - > note(
     (dwName : DWORD) //cue point 구조에서 가지는 이름과 match하는 이름
     (data : ZSTR) )      //이름을 포함하는 null terminated string
     )

· "ltxt" chunk는 특별한 길이의 data segment와 연관된 text를 포함한다.
· "ltxt" chunk 필드는 아래의 코드 세그먼트와 같다.

(ltxt-ck) - ltxt (
    (dwName:DWORD)          //cue point 구조에서 가지는 이름과 match하는 이름
    (dwSampleLength:DWORD)  //waveform data의 segment내에 있는 
                                 //samples의 수를 기술
    (dwPurpose:DWORD)       //text의 목적이나 타입을 기술한다.
    (wCountry:WORD)          //Country code
    (wLanguage:WORD)        //Language
    (wDialect:WORD)           //Dialect
    (data:BYTE)                //data chunk
      . . . . . 
    )

· 'ltxt' chunk는 국제적인 text data를 수용할 수 있게 설계되었고, 사용된 국제적인 문자 집합에 대해 county code, language,사투리와 코드페이지를 기술할 수 있다.

◈ Inst(instrumental) Chunk
· WAVE form은 sampled된 synthesizer의 sample을 저장하는 완벽한 file format이다.
· sample당 bit는 sample rate, channel의 수, 복잡한 looping은 현재 WAVE subchunks를 기술할 수 있다.
· sample의 pitch와 다른 sample들과 연관된 요구되는 volume은 기록되지 않는다.
· 임의의 도구 subchunk가 아래의 parameter에서 정의 된다.

(instrument-ck) -> inst(
    (bUnshiftedNote:BYTE) // MIDI note number that corresponds to 
                          // the unchifted pith of the sample.
    (chFineTune:CHAR)   // The pitch shift adjustment in cents
                        // (or 100ths of a semitone) needed to hit 
                        // bUnshiftedNote
                        // value exactly.
                        // chFineTune can be used to compensate for tunning 
                        // errors in the sampling process. 
                        // Valid values range from -50 to 50
    (chGain:CHAR)       // The suggested volume setting for the sample 
                       // in decibels. A value of zero decibels suggests 
                       // no change in the volume. a vlaue of -6 decibels 
                       //suggests reducing the amplitude of the sample by two.
    (bLowNote:BYTE)     // The suggensted usable MIDI note number range of
                        // the sample. Valid values range from 0 to 127
    (bLowVelocity:BYTE) // The suggested usable MIDI note number range of
                        // the sample. Valid values range from 0 to 127.
    (bHighVelocity:BYTE) //The suggested usable MIDI note number range of the
                        // sample. Valid values range from 0 to 127

 

Setting up New WAVE Types

◈ 새로운 WAVE form type은 두 개의 위임된 chunk(fact, fmt)를 포함해야 한다.
· fmt chunk는 모든 non-PCM-format wave data를 사용하는 확자된 wave format 구조를 사용한다.
· RIFF WAVE WAVE_FORMAT_PCM file format은 fact chunk를 요구하지 않고 확장된 wave format structure를 사용하지도 않는다.
· 확장된 wave format WAVEFORMTEXT구조는 아래와 같다.

typedef struct waveformat_extended_tag {
      WORD  wFormatTag;     // Type of the WAVE file.
      WORD  nChannels;        // Number of channels, mono, stereo
      DWORD nSamplesPerSec;  // Sampling rates of 11025, 22050, 44100
      DWORD nAvgBytesPerSec; //Average data rate to estimate buffer size
      WORD   nBlockAlign;      //Block alignment in bytes
      WORD   wBitPerSample;    // Number of bits per sample
      WORD   cbSize;            // the number of bytes for the extra information
  } WAVEFORMATEXT;

 

 

 

 

 

 

                                                               

최종편집일 2003년 2월 19일 강완신