JPEG, MPEG 표준의 영상처리 기법으로 보통 DCT를 많이씁니다.
신경망 중에서도 classification, feature extracting, pattern recognition 등의 분야에서 DCT를 이용한 영상데이터를 자주 접하지요.
관련 레퍼런스를 정리하는중 DCT, wavelet 등에서 왜 8x8의 블록기반 변환을 사용하는지에 대한 내용이 상당히 부실하게, 또는 전혀 언급되지 않은 자료들이 대부분이란걸 발견하고 매우 놀랐습니다.
뭐.. 이렇게 말하면 제가 영상처리는 기본 베이스로 완벽마스터라도 한것처럼 들리겠네요;;
저도 뭐 아직 공부하는 입장에서 알고있는 사실을 간략하게나마 기술해서, 새로이 공부하는 후학분들의 가려운곳을 살짝 긁어드릴까하고 쓰는 포스팅입니다.
그럼 다시 원론으로 넘어가서.. 왜 8x8의 블록처리인가..
십수년을 거슬러 올라가 때는 바야흐로 1992년..
ISO, CCITT에 의해 JPEG 국제 표준 부호화가 권고되었습니다. 그 내용은 이미지 압축/처리에 대한 방식의 표준화로 이미지의 픽셀들을 가로 세로 8픽셀의 윈도우로 묶어 DCT를 한 후, 그 결과로 나온 DC 및 AC 성분들을 좌측 위에서부터 지그재그 스캐닝하여 8x8 행렬의 2차원 데이터를 64x1 행렬의 1차원 데이터로 변환하자는 표준안이었습니다.
왜 블록으로 묶느냐 하면.. 실제로 256x256 사이즈의 이미지를 한방에 DCT 하자면 연산량의 방대함은 이루말할수도없고 어지간한 컴파일러는 DCT 도중 메모리부족 경고가 뜨며 튕겨버립니다.(..라고 누가 그러던데 전 애초에 256x256을 한방에 DCT해보려는 무모한 시도는 하지도 않았습니다;;)
반면 이미지를 8x8 사이즈의 블록으로 나누어 각기 계산하면 계산량은 물론이거니와 사용하는 메모리의 양, 연산 속도면에서 월등하지요.
실로 체감속도면에선 거의 1/1000 정도 빠르다는게 256x256 과 8x8을 비교해본 사람들의 공통된 주장입니다.
그럼 8x8 B-DCT후 지그재그 스캐닝을 왜 하느냐.
DCT 자체가 이미지(B-DCT같은경우엔 블록)을 코사인함수의 시리즈로 나타내는 방법이며, DCT 후 패턴을 보면 가장 중요한 정보를 담고있는 DC가 최상단 왼쪽구석에 붙고, 우측하단으로 갈수록 쓰잘데기없는 AC성분이 배열됩니다.
AC성분은 보통 Quantization을 통해 0으로 날려버리는 노이즈이지요.
굳이 필요없는 AC는 버리고, 중요한 DC와 DC주변의 계수를 앞으로 배치시키기 위한게 지그재그 스캐닝입니다.
256x256의 이미지를 DCT한다면 지그재그 스캐닝만 해도 엄청난 시간이 들어가겠네요;;
뭐 잡설도 많이붙고, 글이 산으로 가는것같으므로 줄이겠습니다.
국제표준보후화에대한 권고사항에 의해 대부분의 JPEG, MPEG 포맷 영상은 8x8 B-DCT(Block-Discrete Cosine Transform)을 기본으로 하며, 신호 또는 영상을 통째로 DCT할때보다 cost가 싸기때문에 8x8의 B-DCT를 행한다는게 이번 포스팅의 주요내용이었습니다.
2009-09-09
신경망 중에서도 classification, feature extracting, pattern recognition 등의 분야에서 DCT를 이용한 영상데이터를 자주 접하지요.
관련 레퍼런스를 정리하는중 DCT, wavelet 등에서 왜 8x8의 블록기반 변환을 사용하는지에 대한 내용이 상당히 부실하게, 또는 전혀 언급되지 않은 자료들이 대부분이란걸 발견하고 매우 놀랐습니다.
뭐.. 이렇게 말하면 제가 영상처리는 기본 베이스로 완벽마스터라도 한것처럼 들리겠네요;;
저도 뭐 아직 공부하는 입장에서 알고있는 사실을 간략하게나마 기술해서, 새로이 공부하는 후학분들의 가려운곳을 살짝 긁어드릴까하고 쓰는 포스팅입니다.
그럼 다시 원론으로 넘어가서.. 왜 8x8의 블록처리인가..
십수년을 거슬러 올라가 때는 바야흐로 1992년..
ISO, CCITT에 의해 JPEG 국제 표준 부호화가 권고되었습니다. 그 내용은 이미지 압축/처리에 대한 방식의 표준화로 이미지의 픽셀들을 가로 세로 8픽셀의 윈도우로 묶어 DCT를 한 후, 그 결과로 나온 DC 및 AC 성분들을 좌측 위에서부터 지그재그 스캐닝하여 8x8 행렬의 2차원 데이터를 64x1 행렬의 1차원 데이터로 변환하자는 표준안이었습니다.
왜 블록으로 묶느냐 하면.. 실제로 256x256 사이즈의 이미지를 한방에 DCT 하자면 연산량의 방대함은 이루말할수도없고 어지간한 컴파일러는 DCT 도중 메모리부족 경고가 뜨며 튕겨버립니다.(..라고 누가 그러던데 전 애초에 256x256을 한방에 DCT해보려는 무모한 시도는 하지도 않았습니다;;)
반면 이미지를 8x8 사이즈의 블록으로 나누어 각기 계산하면 계산량은 물론이거니와 사용하는 메모리의 양, 연산 속도면에서 월등하지요.
실로 체감속도면에선 거의 1/1000 정도 빠르다는게 256x256 과 8x8을 비교해본 사람들의 공통된 주장입니다.
그럼 8x8 B-DCT후 지그재그 스캐닝을 왜 하느냐.
DCT 자체가 이미지(B-DCT같은경우엔 블록)을 코사인함수의 시리즈로 나타내는 방법이며, DCT 후 패턴을 보면 가장 중요한 정보를 담고있는 DC가 최상단 왼쪽구석에 붙고, 우측하단으로 갈수록 쓰잘데기없는 AC성분이 배열됩니다.
AC성분은 보통 Quantization을 통해 0으로 날려버리는 노이즈이지요.
굳이 필요없는 AC는 버리고, 중요한 DC와 DC주변의 계수를 앞으로 배치시키기 위한게 지그재그 스캐닝입니다.
256x256의 이미지를 DCT한다면 지그재그 스캐닝만 해도 엄청난 시간이 들어가겠네요;;
뭐 잡설도 많이붙고, 글이 산으로 가는것같으므로 줄이겠습니다.
국제표준보후화에대한 권고사항에 의해 대부분의 JPEG, MPEG 포맷 영상은 8x8 B-DCT(Block-Discrete Cosine Transform)을 기본으로 하며, 신호 또는 영상을 통째로 DCT할때보다 cost가 싸기때문에 8x8의 B-DCT를 행한다는게 이번 포스팅의 주요내용이었습니다.
2009-09-09