KR101972936B1

KR101972936B1 - 스크린 콘텐츠 코딩 솔루션

Info

Publication number: KR101972936B1
Application number: KR1020167016238A
Authority: KR
Inventors: 잔 마; 웨이 왕; 하오핑 유; 시안 왕; 징 예
Original assignee: 후아웨이 테크놀러지 컴퍼니 리미티드
Priority date: 2013-11-22
Filing date: 2014-11-24
Publication date: 2019-04-26
Also published as: AU2014352656A1; CN105745671A; MX362406B; EP3063703A4; KR20160085893A; WO2015077720A1; CL2016001224A1; RU2646355C2; CN105745671B; EP3063703A1; CA2931386A1; HK1220531A1; US10291827B2; US20150146976A1; CA2931386C; RU2016124544A; UA118114C2; AU2014352656B2; JP2017502561A; BR112016011471A2

Abstract

스크린 콘텐츠의 코딩 유닛(CU)을 위한 컬러 팔레트 테이블을 선택하고, 코딩 유닛(CU)에 대한 인덱스를 갖는 컬러 인덱스 맵을 생성하며, 선택된 컬러 팔레트 테이블 및 코딩 유닛에 대한 컬러 인덱스 맵을 비트 스트림으로 인코딩하는 것에 의해 스크린 콘텐츠를 비트 스트림으로 코딩하는 방법 및 장치.

Description

스크린 콘텐츠 코딩 솔루션{ADVANCED SCREEN CONTENT CODING SOLUTION}

본 발명은 스크린 콘텐츠 코딩에 관한 것이다.

종래 내추럴 비디오와 비교하여 스크린 콘텐츠 코딩의 독특한 신호 특성 때문에 스크린 콘텐츠 코딩은 비디오 압축 기술에 대하여 새로운 도전을 부과한다. 진보된 스크린 콘텐츠 코딩에 대해, 예를 들어, 슈도 스트링 매치(pseudo string match), 컬러 팔레트 코딩(color palette coding), 및 인트라 모션 보상(intra motion compensation) 또는 인트라 블랙 카피(intra block copy) 등의 유망한 기술이 있다.

이러한 기술들에서, 슈도 스트링 매치는 무손실 코딩에 대해 가장 높은 이득을 보여주지만, 상당한 복잡성과 손실 코딩 모드(lossy coding mode)에 대한 어려움이 있다. 카메라를 이용하지 않고 촬상 된 콘텐츠는 자연 영상에서의 연속적인 컬러 대신 전형적으로 제한된 몇 가지 컬러를 포함한다는 가정하에 컬러 팔레트 코딩이 스크린 콘텐츠를 위해 개발되었다. 슈도 스트링 매치 및 컬러 팔레트 코딩 방식이 큰 잠재력을 보여줬다 하더라도, 인트라 모션 보상 또는 인트라 블랙 카피가 WD(working draft) 버전 4 및 HEVC RExt(HEVC range extension)의 참조 소프트웨어로 채택되었다. 이것은, 움직임 추정과 보정 방법(특히, 하드웨어에 대해)이 실제 구현에서 비교적 용이하고, 수 십년 동안 연구되었다는 사실에 근거한다.

그러나 인트라 블랙 카피의 고정된 블록 구조 파티션 때문에 인트라 블랙 카피의 코딩 성능에 한계가 있다. 한편, 인트라 픽처(intra picture) 내의 모션 추정과 유사한 블록 매칭의 수행은 연산 및 메모리 액세스 모두에서 인코더의 상당한 복잡성을 유발한다.

본 발명은 진보된 스크린 콘텐츠 코딩 방법에 관한 것이다.

일 실시예에서, 스크린 콘텐츠를 비트 스트림으로 코딩하는 방법은, 스크린 콘텐츠의 코딩 유닛(CU)을 위한 컬러 팔레트 테이블을 선택하는 단계를 포함한다. 컬러 팔레트 테이블은 코딩 유닛에 대해 생성되고, 컬러 팔레트 테이블은 인접하는 코딩 유닛에 대해 생성된다. 선택된 컬러 팔레트 테이블을 사용하여, 스크린 콘텐츠의 코딩 유닛에 대한 인덱스(indices)를 포함하는 컬러 인덱스 맵(color index map)이 생성된다. 복수의 코딩 유닛의 각각에 대해, 선택된 컬러 팔레트 테이블 및 컬러 인덱스 맵은 비트스트림(bitstream)으로 인코딩/압축 된다.

본 발명 및 그에 따른 이점의 더욱 완벽한 이해를 위해, 첨부된 도면을 참조한 기준(reference)은 이하의 설명으로 형성되며, 동일한 부호는 동일한 구성요소를 나타낸다.
도 1은 본 발명의 실시예에 따른 컬러 팔레트 테이블(color palette table) 및, 인덱스 맵 모드(index map mode) 또는 팔레트 모드(palette mode)를 사용한 스크린 콘텐츠 인코딩 솔루션을 나타낸 것이다.
도 2는 컬러 팔레트 테이블 및, 인덱스 맵 모드 또는 팔레트 모드에 대한 스크린 콘텐츠 디코딩 솔루션을 나타낸 것이다.
도 3은 코딩 유닛의, 컬러 팔레트 테이블 및, 인덱스 맵 모드 또는 팔레트 모드에 대한 스크린 콘텐츠 솔루션의 프로세스 또는 워크플로우(workflow)를 나타낸 것이다.
도 4는 플래너 모드(planar mode, 왼쪽)에서 종래 G, B, R을 패킹 모드로(packed mode, 오른쪽)로 하는 것을 나타낸 것이다.
도 5는 인접하는 복원된 블록을 사용하여 컬러 팔레트 테이블 재생성을 나타낸 것이다.
도 6은 스크린 콘텐츠 실제 단어로부터 인덱스 맵이 분석되는 것을 나타낸 것이다.
도 7은 수평 스캔 이후의 1차원 검색에 대한 세그먼트(segment)의 일부를 나타낸 것이다.
도 8은 U_PIXEL 모듈을 나타낸 것이다.
도 9는 U_ROW 모듈을 나타낸 것이다.
도 10은 U_CMP 모듈을 나타낸 것이다.
도 11은 U_COL 모듈을 나타낸 것이다.
도 12는 U_D2_BLOCK 모듈을 나타낸 것이다.
도 13은 실시예의 코딩 유닛(CU)의 인덱스 맵 처리(index map processing)에 대한 수평 및 수직 스캔을 나타낸 것이다.
도 14A는 4:2:0 크로마 샘플링 포맷(chroma sampling format)을 나타낸 것이다.
도 14B는 4:4:4 크로마 샘플링 포맷을 나타낸 것이다.
도 15는 4:20 및 4:4:4 사이의 보간(interpolation)을 나타낸 것이다.
도 16은 위쪽/왼쪽 라인 버퍼를 이용한 인덱스 맵 처리(Index Map processing)를 내타낸 것이다.
도 17은 현재 HEVC에 병합된 장치 및 방법/흐름을 나타낸 것이다.
도 18은 통신 시스템의 일 예를 나타낸 것이다.
도 19A 및 도 19B는 본 발명에 따른 방법 및 교시가 구현될 수 있는 예시적 장치를 나타낸 것이다.

본 명세서에서, HEVC 범위 확장(HEVC Version 2 또는 HEVC RExt와 같음)의 성능을 능가하는 진보된 스크린 콘텐츠 코딩 솔루션이 설명된다. 신규의 솔루션은 구체적으로 스크린 콘텐츠 코딩에 대해 디자인된 몇몇 알고리즘을 포함한다. 이러한 알고리즘은, 이하에서 컬러 팔레트 테이블, 컬러 팔레트 압축(color palate compression), 컬러 인덱스 맵 압축(color index map compression), 스트링 검색(string search), 및 레지듀얼 압축(residual compression)으로 지칭되는, 컬러 팔레트 또는 컬러 테이블을 사용한 화소 표현(pixel representation)을 포함한다. 이러한 기술은 개발되고, 조화되며, RExt(HEVC range extension) 및 효율적인 스크린 콘텐츠 코딩을 지원하는 미래의 HEVC 확장과 통합될 수 있다. 그러나 이 기술은 종래 비디오 표준을 구현될 수 있다. 단순화를 위해, HEVC RExt는 이하에서 예로서 사용될 수 있고, HEVC RExt 소프트웨어는 압축 효율을 설명하고 보여주기 위해 사용된다. 이런 솔루션은 HEVC에서 성능을 나타내기 위해, 이하에서 컬러 팔레트 모드로서 정의된, 컬러 팔레트 테이블 및 인덱스 맵을 사용하여 추가 모드로 통합될 수 있다.

본 발명의 개념 및 설명은 도면에 나타나 있다. 도 1은 메모리를 갖는 프로세서(12)를 포함하는 인코더(10)를 나타내고, 도 2는 메모리를 갖는 프로세서(16)를 포함하는 디코더(14)를 나타내며, 도 1 및 도 2는 본 발명에 따른 컬러 팔레트 모드에 대한 인코딩 솔루션 및 디코딩 솔루션을 각각 나타낸다. 도시된 바와 같이, 각 인코더(10) 및 디코더(14)는 프로세서와 메모리를 포함하고 코덱 솔루션(code slolution)을 형성한다. 코덱 솔루션은, 컬러 팔레트 테이블을 생성하는 프로세스(1), 컬러 인덱스(color indices)에 대응하는 이전에 유도된 컬러 팔레트 테이블을 사용하여, 컬러 또는 화소값을 분류하는 프로세스(2), 컬러 팔레트 테이블을 인코딩하는 프로세스(3), 컬러 인덱스 맵을 인코딩하는 프로세스(4), 레지듀얼(residuals)을 인코딩하는 프로세스(5), 및 신규 신택스 요소(syntax element)를 압축된 비트스트림에 기록하는 프로세스(6)를 포함하는 신규 알고리즘 또는 방법을 실행하는 인코더(10)의 프로세서(12)를 포함한다. 디코더(14)의 프로세서(16)는 역방향의 단계를 포함하는 신규 알고리즘 또는 방법을 실행한다. 도 3은 본 발명의 실시예에 따른 스크린 콘텐츠 솔루션의 프로세스 또는 워크플로우를 제공한다.

기본적으로, 고-효율 CPC(color palate)압축 방식은 각 코딩 유닛(coding unit, CU)에 의해 수행된다. 코딩 유닛은 HEVC 및 HEVC RExt에서 기본 동작 유닛이고, 3가지 성분(예를 들어, RGB, YUV, 또는 XYZ)로 구성된 사각 화소 블록이다.

각 코딩 유닛 레벨에서, CPC 방식은 2개의 주된 단계를 포함한다. 먼저, 제1단계에서, 프로세서(12)는 컬러 팔레트 테이블을 유도하거나 생성한다. 컬러 팔레트 테이블은 히스토그램(즉, 각 컬러 값의 출현 빈도), 실제 색 강도(color intensity), 또는 이하의 인코딩 처리 효율을 향상시키기 위한 모든 임의의 방법에 따라 정렬된다. 유도된 컬러 팔레트 테이블에 기초하여 원래 코딩 유닛 내의 각 픽셀은 컬러 팔레트 테이블 내에서 원래 코딩 유닛의 컬러 인덱스로 변환된다. 본 발명은 각 코딩 유닛의 컬러 팔레트 테이블 및 컬러 인덱스 맵을 스트림으로 압축하는 것을 사용하여 효율적 인코딩 기술에 기여한다. 수신 측에서, 프로세서(16)는 각 코딩 유닛에 대해, 완전한 컬러 팔레트 테이블 및 컬러 인덱스 맵으로 복원하기 위해, 압축된 비트 스트림을 분석한다. 그리고 추가로, 컬러 인덱스 및 컬러 팔레트 테이블을 결합하여 각 위치이 화소값을 유도한다.

본 발명의 예시적 실시예에서, NxN 화소의 코딩 유닛을 가정한다. (HEVC와 호환하는 N=8, 16, 32, 64이다.) 코딩 유닛은 상이한 샘플링 비율(즉, 4:4:4, 4:2:2, 4:2:0) 에서, 전형적으로 3가지 크로마(chroma) 성분(즉, G, B, R, 또는 Y, Cb, Cr, 또는 X, Y Z )을 포함한다. 단순화를 위해, 4:4:4의 스퀀스(sequence)가 본 발명에서 예시된다. 4:2:2 및 4:2:0 비디오의 시퀀스에 대해, 크로마 업샘플링 4:4:4 시퀀스 또는 독립적으로 처리될 수 있는 각 컬러 성분(component)을 획득하기 위해 적용된다. 그리고 본 명세서에서 설명된 순서가 적용된다. 4:0:0 단색 비디오에 대해, 이러한 순서는 다른 두 평면(plane) 없는 4:4:4의 개별 플레인(plane)으로 간주될 수 있다.

패킹(Packed) 또는 플래너 (Planar)

이러한 방식은 도 1의 블록 CTU 또는 코딩 유닛(CU)에 대해 도시되어 있다. 먼저, 현재 코딩 유닛이 패킹 방식(packed fashion)을 사용하여 처리되었는지 또는 종래 플래너 모드(planar mode)(즉, G, B, R 또는 Y, U, V 성분이 별도로 처리됨)를 사용하여 처리되었는지를 나타내도록, 인에이블_패킹_요소_플래그(enable_packed_component_flag)로 지칭되는 플래그(flag)가 각 코딩 유닛에 대해 정의된다. 도 4는 플래너 모드(planar mode, 왼쪽)에서 종래 G, B, R을 패킹 모드(packed mode, 오른쪽)로 하는 것을 나타낸 것이다. YUV 또는 다른 컬러 포맷은 RGB 콘텐츠에 대해 예시된 방식과 동일한 방식으로 처리될 수 있다.

패킹 모드(packed mode) 및 플레너 모드(planar mode)는 모두, 장점 및 단점이 있다. 예를 들어, 플래너 모드는 R/G/B 또는 Y/U/V에 대해 병렬 컬러 성분 처리(parallel color component processing)를 지원한다. 하지만, 낮은 코딩 효율을 감수해야 한다. 패킹 모드는 상이한 컬러 성분들 중에서 이러한 코딩 유닛에 대한 헤더 정보(header information, 본 발명에서의 컬러 팔레트 테이블 빛 인덱스 맵)를 공유할 수 있다. 그러나 병렬 처리가 불가하다. 현재 코딩 유닛이 패킹 방식에서 인코딩되어야 하는지를 결정하는 쉬운 방법은 R-D(rate distortion) 비용을 측정하는 것이다. 인에이블_패킹_요소_플래그는 명시적으로 디코더에 인코딩 모드를 시그널링하도록 사용된다.

또한, 저 레벨 처리(low-level handling)에 대해, 코딩 유닛에서 인에이블_패킹_요소_플래그를 정의하기 위해, 구체적 어플리케이션 요구사항에 따라, 슬라이스 레벨(slice level) 또는 시퀀스 레벨(sequence level) 처리를 허용하도록, 슬라이스 헤더(slice header) 또는 이븐 시퀀스 레벨(even sequence level)에서 복사될 수 있다.

컬러 팔레트 테이블 및 인덱스 맵 유도

도 1에 도시된 바와 같이, 프로세스(1) 및 프로세스(3)에서, 각 코딩 유닛에 대해, 화소 위치가 가로 놓이고 다음 프로세스에 대한 컬러 팔레트 테이블 및 인덱스 맵이 유도된다. 각 구분되는 컬러는, 컬러의 히스토그램(즉, 출현 빈도), 강도(intensity), 또는 이하의 인코딩 처리 효율을 향상시키기 위한 모든 임의의 방법에 따라 컬러 팔레트 테이블에서 정렬된다. 예를 들어, 인접 화소들 간의 차를 코딩하기 위해, 인코딩 프로세스는 DPCM(differential pulse-code modulation) 방식을 사용하고, 컬러 팔레트 테이블 내에서, 인접한 화소들이 인접 컬러 인덱스가 할당되면, 최적의 코딩 결과는 획득될 수 있다.

컬러 팔레트 테이블을 획득한 이후, 각 화소는 대응하는 컬러 인덱스에 매핑되어 현재 코딩 유닛의 인덱스 맵을 형성한다. 인덱스 맵의 처리는 이하에서 설명한다.

종래 플래너 코딩 유닛에 대해, 각 컬러 또는 색차(chrominance) 성분은, 본 명세서에서 예로서 명명된, 컬러테이블_Y(colorTable_Y), 컬러테이블_U(colorTable_U), 컬러테이블_V(colorTable_V) 또는 컬러테이블_R(colorTable_R), 컬러테이블_G(colorTable_G), 컬러테이블_B(colorTable_B)와 같은 각각 컬러 팔레트 테이블을 가질 수 있다. 반면, YUV 내의 Y 또는 GBR 내의 G와 같은 주된 성분에 대한 컬러 팔레트 테이블은 유도되고 모든 성분에 대해 공유된다. 통상적으로 이러한 공유에 의해, Y 또는 G 이외의, 다른 컬러 성분은 컬러 팔레트 테이블에서 공유된 것들로부터 원래 화소 색에 상대적으로 불일치가 있을 수 있다. 그때, 레지듀얼 엔진(residual engine, HEVC 계수 코딩 방식과 같음)이 이러한 일치하지 않는 레지듀얼에 적용된다. 한편, 패킹 코딩 유닛에 대해, 단일 컬러 팔레트 테이블은 모든 성분에 대해 공유된다.

슈도 코드(pseudo code)가 이하와 같이 컬러 팔레트 테이블 및 인덱스 맵의 유도를 예시하기 위해 제공된다.

deriveColorTableIndexMap()

{

deriveColorTable();

deriveIndexMap();

}

deriveColorTable(src, cuWidth, cuHeight, maxColorNum)

{

// src - input video source in planar or packed mode

// cuWidth, cuHeight - width and height of current CU

/* maxColorNum - max num of colors allowed in color table*/

/*transverse */

//

// memset(colorHist, 0, (1<<bitDepth)*sizeof(UINT))

pos=0;

cuSize=cuWidth*cuHeight;

while (pos<cuSize) {

colorHist[src[pos++]]++;

}

/*just pick non-zero entry in colorHist[] for color intensity ordered table*/

j=0;

for(i=0;i<(1<<bitDepth);i++)

{

if(colorHist[i]!=0)

colorTableIntensity[j++] = colorHist[i];

}

colorNum=j;

/*quicksort for histgram*/

colorTableHist = quickSort(colorTableIntensity, colorNum);

/*if maxColorNum >= colorNum, all colors will be picked*/

/*if maxColorNum < colorNum, only maxColorNum colors will be picked for colorTableHist. In this case, all pixels will find its best matched color and corresponding index with difference (actual pixel and its corresponding color) coded by the residual engine.*/

/*Best number of colors in color table could be determined by iterative R-D cost derivation!*/

}

deriveIndexMap()

{

pos=0;

cuSize=cuWidth*cuHeight;

while ( pos < cuSize)

{

minErr=MAX_UINT;

for (i=0;i<colorNum;i++)

{

err = abs(src[pos] - colorTable[i]);

if (err<minErr)

{

minErr = err;

idx = i;

}

idxMap[pos] = idx;

}

컬러 팔레트 테이블 처리

도 1의 프로세스(1)에 대해, 컬러 팔레트 처리는 프로세서(12)의 컬러 팔레트 테이블(즉, 다른 컬러의 총계)의 크기의 인코딩 및 각 컬러 자체를 포함한다. 비트의 대두분은 컬러 테이블에서 각 컬러의 인코딩에 의해 사용된다. 따라서, 요점은 컬러 인코딩(또는 컬러 팔레트 테이블에서 각 항목의 인코딩)에 있다.

컬러 팔레트 테이블에서 컬러를 인코딩하는 복잡하지 않은 대부분의 방식은 각 컬러가 별도로 코딩되는 PCM(pulse-code modulation) 스타일 알고리즘을 사용한다. 대안으로서, 연속하는 컬러에 대해 가까운 예측이 적용 가능하고, 디폴트(default) 컬러 강도보다 예측 델타(prediction delta)가 인코딩될 수 있으며, 이는 DPCM(differential PCM) 스타일이다. PCM 및 DPCM 방식은 모두 복잡성 비용 및 코딩 효율 사이의 트레이드-오프(trade-off)에 따라, 동일한 확률 모델 또는 어뎁티브 콘텍스트 모델(adaptive context model)을 사용하여 이후에 엔트로피 코딩될 수 있다.

여기에서, 인접하는 컬러 팔레트 테이블 병합으로 명명되는, 다른 진보된 방식이 개시되고, 현재 코딩 유닛이 왼쪽 또는 위쪽 코딩 유닛의 컬러 팔레트 테이블을 사용하는 지를 나타내도록, 컬러_테이블_병합_플래그(color_table_merge_flag)가 정의된다. 그렇지 않다면, 현재 코딩 유닛은 분명하게 컬러 팔레트 테이블 시그널링을 운반할 것이다. 병합 프로세스에 대해, 다른 컬러_테이블_병합_방향(color_table_merge_direction)은 코딩 유닛의 위쪽으로부터 또는 왼쪽으로부터 중 어느 하나의 병합 방향을 나타낸다. 물론, 후보는 현재 위쪽 또는 왼쪽 코딩 유닛, 예를 들어, 상-좌(upper-left), 상-우(upper-right) 등 이상일 수 있다. 그러나 위쪽 및 왼쪽 코딩 유닛은 본 발명에서 예시적 개념을 개시하기 위해 사용된다. 어떤 화소에 대해서도, 각 화소는 현재 컬러 팔레트 테이블 내의 항목과 비교되고, deriveIdxMap()을 통해 최소 예측 차를 생성하는 인덱스에 할당된다. (즉, 화소가 컬러 팔레트 테이블에서 가장 가까운 색을 뺀다.) 예측 차가 0이 아닌 경우에 대해, 이러한 모든 레지듀얼은 HEVC RExt 레지듀얼 엔진을 사용하여 인코딩된다. 병합 프로세스를 사용할지 안할지는 R-D 비용에 의해 결정된다.

현재 코딩 유닛의 코딩의 병합 프로세스에서 사용되기 위한 인접하는 컬러 팔레트 테이블을 생성하는 방법은 여러 가지가 있고, 그 중 하나는 인코더 및 디코더 모두에서 업데이트가 요구되고, 다른 하나는 인코더 측 프로세스뿐이다.

인코더 및 디코더 모두에서 업데이트: 이러한 방식에서, 코딩 유닛의 깊이 및 크기에 관계없이, 인접한 코딩 유닛의 컬러 팔레트 테이블이 사용 가능한 복원된 화소에 생성된다. 각 코딩 유닛에 대해, 동일한 크기 및 동일한 깊이(depth)에서 인접하는 코딩 유닛에 대해 검색된다. (이런 경우 컬러 유사도는 높은 것으로 가정한다.) 예를 들어, 도 5에 도시된 바와 같이, 현재 코딩 유닛이 깊이=2인 16X16이면 인접하는 코딩 유닛(예를 들어, 왼쪽 코딩 유닛에 대한 깊이=3인 8X8 및 위쪽 코딩 유닛에 대한 깊이=1인 32X32)의 파티션(partition)은 중요하지 않고, 화소 오프셋(offset=16)은 현재 코딩 유닛으로부터, 왼쪽 16X16 블록을 처리하도록 왼쪽으로 위치하고, 위쪽 16X16 블록에 대해 위쪽에 위치될 것이다. 인코더 및 디코더는 이러한 프로세스를 유지해야 한다.

제한된 인코더 프로세스: 이러한 방식에서, 병합 프로세스는, 현재 코딩 유닛이 위쪽 및/또는 왼쪽 유닛과 동일한 크기 및 깊이를 공유할 때 발생한다. 다음 동작을 위해, 사용 가능한 인접한 코딩 유닛의 컬러 팔레트 테이블은 현재 코딩 유닛의 컬러 인덱스 맵을 유도하기 위해 사용된다. 예를 들어, 현재 16X16 코딩 유닛에 대해, 예를 들어, 위쪽 또는 왼쪽에 위치한 인접하는 코딩 유닛은 컬러 팔레트 테이블 및 인덱스 방식을 사용하여 인코딩되고, 인접하는 코딩 유닛의 컬러 팔레트 테이블은 현재 코딩 유닛이 R-D 비용을 직접 유도하도록 사용된다. 이러한 병합 비용은 현재 코딩 유닛이 컬러 팔레트 테이블을 명확하게 유도하는 경우(뿐 아니라 HEVC 또는 HEVC RExt에 존재하는 다른 종래 모드)와 비교된다. 어느 것이든지 가장 낮은 R-D 비용을 생성하는 것이 출력 비트 스트림에 기록될 마지막 모드로서 선택된다. 설명한 바와 같이, 인코더만이 다른 잠재적 모드를 실험/시뮬레이션할 필요가 있다. 디코더 측에서는, 컬러_테이블_병합_플래그 및 컬러_테이블_병합_방법은 추가적인 처리 워크로드(workload)없이, 병합 결정 및 병합 방법을 의미한다.

컬러 인덱스 맵 처리

도 1의 프로세스(3)에 대해, 컬러 인덱스 맵을 코딩하기 위해, RUN 모드, RUN 및 COPY_ABOVE, 및 어뎁티브 인접 인덱스 예측(adaptive neighbor index prediction)과 같은 몇몇 솔루션이 연구되어 왔다. 본 명세서에서, 인덱스 맵 코딩을 인코딩하도록, 1차원 스트링 매칭(1D string matching) 방식 및 2차원 변화가 개시되어 있다. 각 위치에서, 매칭된 지점을 찾고 1차원 스트링 매칭과 매칭된 거리 및 길이를 기록하거나, 2차원 스트링 매칭과 매칭되는 넓이/높이를 기록한다. 매칭되지 않은 지점에 대해서는, 인덱스 강도(index intensity) 또는 인덱스 강도 및 예측된 인덱스 강도 사이의 델타 값이 직접 인코딩된다.

여기에서 개시된 것은 컬러 인덱스 맵의 복잡하지 않은 1차원 검색 방법이다. 도 6을 참조하면, 인덱스 맵은 실제 워드(word) 스크린 콘텐츠로부터 분석된다. 도 7은 1차원 검색(즉, 인덱스 맵의 시작) 이후 세그먼트의 일부를 나타낸다.

이러한 1차원 컬러 인덱스 벡터의 상단에, 스트링 매칭이 적용된다. 이러한 1차원 스트링 매칭의 일례는 이하에서 주어진다. 도 7에서 도시된 "14"와 같이 각 인덱스 맵의 첫 번째 위치는 버퍼링 된 기준이 아직 없기 때문에 이 첫 번째 인덱스는 "매칭되지 않은 쌍(unmatched pair)"으로 간주 되며, 대응하는 거리 및 길이에 대해 주어진 -1 및 1이며, (dist, len) = (-1, 1)으로 기록된다. 두 번째 인덱스에 대해, 다른 "14"가 기준으로서 첫 번째 인덱스 코드이다. 따라서 거리(dist)=1이다. 제 번째 위치에 "14"가 있기 때문에 길이는 2이다. 즉, 거리(len)=2이다.(주어진 모든 나아간(proceeded) 인덱스는 다음 인덱스에 대해 즉시 기준으로 제공될 수 있다.) 네 번째 위치로 나아가면, 전에 없었던 "17"이 나타난다. 따라서, 매칭되지 않은 쌍으로서 인코딩된다. 즉, (dist, len)=(-1,1) 이다. 매칭되지 않은 상에 대해, 플래그는 ("dist=1"과 같이) 인코딩되고 (먼저 나타나는 "14, "17", "6" 등과 같이)인덱스의 실제 값이 뒤따른다. 한편, 매칭된 쌍에 대해서, 플래그는 여전히 ("dist !=-1"과 같이)인코딩되고 매칭된 스트링의 길이가 뒤따른다.

도 7에 나타난 예시적 인덱스를 사용한 인코딩 순서의 요약은 다음과 같다.

dist = -1, len = 1, idx=14 (unmatched)

dist= 1, len = 2 (matched)

dist = -1, len = 1, idx=17 (unmatched)

dist= 1, len = 3 (matched)

dist = -1, len = 1, idx= 6 (unmatched)

dist= 1, len = 25 (matched)

dist= 30, len = 4 (matched) /*for the "17" which appeared before*/

... .

슈도 코드(pseudo code)가 매칭된 쌍 유도에 대해 주어진다. 즉,

Void deriveMatchedPairs ( TComDataCU* pcCU, Pel* pIdx, Pel* pDist, Pel* pLen, UInt uiWidth, UInt uiHeight)

{　　

// pIdx is a idx CU bounded within uiWidth*uiHeight　　

UInt uiTotal = uiWidth*uiHeight;　　

UInt uiIdx　　 = 0;　　

Int j　　 = 0;　　

Int len = 0;　　

// first pixel coded as itself if there isn't left/upper buffer　　

pDist[uiIdx] = -1;　　

pLen[uiIdx]　 =　 0;　　

uiIdx++;　　

while (uiIdx < uiTotal )　　

{　　　　

len　　　 = 0;　　　　

dist　　 = -1;　　　　

for ( j=uiIdx-1; j >= 0; j-- )　　　　

{　　　　　　

// if finding matched pair, currently exhaustive search is applied　　　　　　

// fast string search could be applied　　　　　　

if ( pIdx[j] == pIdx[uiIdx] )　　　　　　

{　　　　　　　　　　　　　　　　　

for (len = 0; len < (uiTotal-uiIdx); len++ )　　　　　　　　

{　　　　　　　　　　

if ( pIdx[j+len] != pIdx[len+uiIdx] )　　　　　　　　　　　　

break;　　　　　　　　

}　　　　　　

if ( len > maxLen ) /*better to change with R-D decision*/　　　　　　　　

{　　　　　　　　　　

maxLen = len;　　　　　　　　　　

dist　　　 = (uiIdx - j );　　　　　　　　

}　　　　

pDist[uiIdx] = dist;　　　　

pLen[uiIdx]　 = maxLen;　　　　

uiIdx = uiIdx + maxLen;　　

}　　

2차원 검색 변형이 사용되는 경우 이하의 단계가 생성된다.

1. 현재 화소 및 기준 화소의 위치를 시작 지점으로서 식별하고,

2. 수평 1차원 스트링 매칭을 현재 화소 및 기준 화소의 오른쪽으로 적용한다. 최대 검색 길이는 현재 수평 행의 끝 부분(end)에 의해 제한된다. 검색 최대 길이가 right_width로서 저장된다.

4. 현재 화소 및 기준 화소 아래 화소를 신규 현재 화소 및 기준 화소로서 사용하여, 동일한 1차원 스트링 매칭이 다음 행에 수행된다.

5. right_width == left_width == 0이 될 때까지 정지한다.

6. 이제 각 height[n] = {1, 2, 3 ...}에 대해, width[n]의 대응하는 어레이 {{left_width[1], right_width[1]}, {left_width[2], right_width[2]}, {left_width[3], right_width[3]}, ...}가 있다.

7. 각 height[n]에 대해, 신규 min_width 어레이 {{lwidth[1], rwidth[1]}, {lwidth[2], rwidth[2]}, {lwidth[3], rwidth[3]}, ...}를 정의하고, lwidth[n] = min(left_width[1:n-1]), rwidth[n] = min(right_width[1:n-1])이다.

8. 크기 어레이 {size[1], size[2], size[3], ...} 또한 정의되고, size[n] = height[n] x (lwidth[n]+hwidth[n])이다.

9. size[n]이 크기 어레이에서 최대값을 갖는다고 가정하면, 2차원 스트링 매칭의 폭 및 높이는 대응하는 {lwidth[n], rwidth[n], height[n]}를 사용하여 선택된다.

1차원 또는 2차원 검색 속도를 최적화하는 한 방법은, 러닝 해쉬(running hash)를 사용하는 것이다. 4-화소 러닝 해쉬 구조가 본 명세서에 개시되어 있다. 러닝 해쉬는 수평 해쉬 어레이 running_hash_h[]가 생성되도록, 수평 방향에서 모든 화소에 대해 계산된다. 다른 러닝 해쉬는 2차원 해쉬 어레이 running_hash_hv[]가 생성되도록, running_hash_h[]의 상단에서 계산된다. 이러한 2차원 해쉬 어레이에서 각 값 매칭은 4X4 블록 매칭을 의미한다. 2차원 매칭을 수행하기 위해, 인접 화소에 화소-와이즈드 비교(pixel-wised comparison)를 수행하기 이전에, 4X4 블록만큼 매칭을 볼 수 있다. 화소 와이즈드 비교는 1 내지 3개 화소에 제한되기 때문에, 검색 속도는 극적으로 증가한다.

상술한 설명으로부터, 매칭된 각 행의 길이는 다른 행의 길이와 다르다. 따라서, 각 행은 따로 처리되어야 한다. 효율 및 낮은 복잡도를 성취하기 위해, 하드웨어 및 소프트웨어 구현 모두에 사용될 수 있는 블록 기반 알고리즘이 개시된다. 표준 모션 추정과 상당히 유사하게, 이러한 알고리즘은 한 번에 하나의 직사각형 블록을 처리한다.

도 8에 도시된 바와 같이, 4X4 블록을 예로 들면, 이런 디자인의 기본 단위는 U_PIXEL로 명명된다. 코딩된 신호는 기준 화소가 이전의 스트링 매칭 동작을 통해 이미 인코딩되었는 지를 나타내는 플래그이다. 선택적으로, 입력 신호(Cmp[n-1]) 는 U_PIXEL 모듈에서 마지막 "OR 게이트"를 제거할 수 있는 "0" 이 되도록 강제될 수 있다.

첫 번째 단계는 각 행을 병렬로 처리하는 것이다. 직사각형의 하나의 행의 각 화소는 U_PIXEL 블록에 할당된다. 이러한 처리 단위는 U_ROW으로 명명된다. 첫 번째 행에 대한 처리 단위의 예가 도 9에 도시되어 있다.

4개의 U_ROW 단위가 4X4 블록 처리를 위해 필요하다. 출력은 도 12에 나타난 바와같이 rw[4][4]의 어레이 이다.

rw[n][0-3]의 각 행 내의 0의 개수가 카운팅 되고 4개의 결과가 어레이 r_width[n]에 기록되다. r_width[n]는 단계 7의 rwidth[n]과 동일하다. l_width[n] 은 동일한 방식으로 생성된다. 단계 7에서 min_width 어레이는 {{l_width[1], r_width[1]}, { l_width[2], r_width[2]}, { l_width[3], r_width[3]} ...}로서 획득된다.

이러한 하드웨어 아키텍처는 모든 현대의 CPU/DSP/GPU의 병렬 처리 프레임 워크에 맞게 수정될 수 있다. 빠른 소프트웨어 구현을 위한 단순화된 슈도-코드가 이하 나열된다.

// 1. Generate array C[][]

For(y = 0; y < height; ++y)

{

For(x = 0; x < width; ++x)

{

tmp1 = cur_pixel ^ ref_pixel;

tmp2 = tmp1[0] | tmp1[1] | tmp1[2] | tmp1[3] | tmp1[4] | tmp1[5] | tmp1[6] | tmp1[7];

C[y][x] = tmp2 & (!coded[y][x]);

}

// 2. Generate array CMP[][]

For(y = 0; y < height; ++y)

{

CMP[y][0] = C[y][0];

}

For(x = 1; x < width; ++x)

{

For(y = 0; y < height; ++y)

{

CMP[y][x] = C[y][x] | CMP[y][x-1]

}

// 3. Generate array RW[][] or LW[][]

For(x = 0; x < width; ++x)

{

RW[0][x] = CMP[0][x];

}

For(y = 1; y < height; ++y)

{

For(x = 0; x < width; ++x)

{

RW[y][x] = CMP[y][x] | RW[y-1][x];

}

// 4. Convert RW[][] to R_WIDTH[]

For(y = 0; y < height; ++y)

{

// count zero, or leading zero detection

R_WIDTH[y] = LZD(RW[y][0], RW[y][1], RW[y][2], RW[y][3]);

}

각 루프에서, 데이터 의존은 없다. 따라서, 루프 언롤링(loop unrolling), MMX/SSE와 같은 전통적인 소프트웨어 병렬 처리는 실행 속도를 증가시키기 위해 적용된다.

이러한 방식은 또한, 행의 수가 하나로 제한되면, 1차원 검색에 적용될 수 있다. 고정 길이에 기초한 1차원 검색의 빠른 소프트웨어 구현을 위한 단순화된 슈도-코드가 이하 나열된다.

// 1. Generate array C[]

For(x = 0; x < width; ++x)

{

tmp1 = cur_pixel ^ ref_pixel;

C[x] = tmp2 & (!coded[x]);

}

// 2. Generate array RW[] or LW[]

If (last "OR" operation in U_PIXEL module is removed)

Assign RW[] = C[]

Else {

RW [0] = C[0];

For(x = 1; x < width; ++x)

{

RW [x] = C[x] | RW [x-1]

}

]

// 3. Convert RW[][] to R_WIDTH[]

// count zero, or leading zero detection

If(last "OR" operation in U_PIXEL module is removed)

R_WIDTH = LZD(RW[0], RW[1], RW[2], RW[3]);

Else

1차원 및 2차원 매칭이 완료된 이후, (ld length, 2d (width x height))가 위너(winner)로서 선택된다. 2차원 매칭의 lwidth 가 0이 아닌 경우, 이전 1차원 매칭 (length = length - lwidth)는 이전 1차원 매칭과 현재 2차원 매칭 사이의 중복을 피하기 위해 조정될 필요가 있다. 조정 이후, 이전 1차원 매칭의 길이(length)가 0이 되면, 매칭 리스트에서 제거된다.

다음 시작 위치는, 이전 매칭이 1차원 매칭이면 current_location + length 를 사용하여 계산되고, 이전 매칭이 2차원 매칭이면 current_location + (lwidth+rwidth) 를 사용하여 계산된다. 1차원 매칭이 수행될 때,

매칭되어야 할 화소가 이미 2차원 매칭에 의해 이미 커버 된 이전 2차원 매칭 영역 위치에 있는 경우, 이전 매칭에 의해 코딩되지 않은 화소 위치가 발견될 때까지 다음 화소가 스캔될 것이다.

매칭된 쌍을 획득한 이후, 엔트로피 엔진(entropy engine)이 이러한 심벌(symbol)을 바이너리 스트림으로 변환하기 위해 적용된다. 예시된 것은 동일한 확률 콘텍스트 모드 사용의 개념이다. 진보된 어뎁티브 콘텍스트 모드는 더 나은 압축 효율을 위해 적용될 수 있다.

// loop for each CU, uiTotal=uiWidth*uiHeight, uiIdx=0;

while ( uiIdx < uiTotal) {

// *pDist: store the distance value for each matched pair

// *pIdx: store the index value for each matched pair

// *pLen: store the length value for each matched pair

// encodeEP() and encodeEPs() are reusing HEVC or similar by-pass entropy coding.

if (pDist[uiIdx] == -1 )

{

//encode one-bin with equal-probability model to indicate the

//whether current pair is matched or not.

unmatchedPairFlag = TRUE;

encodeEP(unmatchedPairFlag);

//uiIndexBits is controlled by the color table size

// i.e., for 24 different colors, we need 5 bits, for 8 colors, 3 bits

encodeEPs(pIdx[uiIdx], uiIndexBits);

uiIdx++;

}

else

{

unmatchedPairFlag= FALSE;

encodeEP(unmatchedPairFlag);

/*bound binarization with max possible value*/

UInt uiDistBits =0;

// offset is used to add additional references from neighboring blocks

// here, we first let offset=0;

while( (1<<uiDistBits)<= (uiIdx+offset))

{

uiDistBits++;

}

encodeEPs(pDist[uiIdx], uiDistBits);

/*bound binarization with max possible value*/

UInt uiLenBits =0;

while( (1<<uiLenBits)<= (uiTotal-uiIdx))

{

uiLenBits++;

}

encodeEPs(pLen[uiIdx], uiLenBits);

uiIdx += pLen[uiIdx];

}

각 매칭 쌍에 대해 인코딩 순서를 나타내었다. 대응하도록, 매칭된 쌍에 대해 디코딩 순서는 이하와 같다.

// loop for each CU, uiTotal=uiWidth*uiHeight, uiIdx=0;

while ( uiIdx < uiTotal) {

// *pDist: store the distance value for each matched pair

// *pIdx: store the index value for each matched pair

// *pLen: store the length value for each matched pair

// parseEP() and parseEPs() are reusing HEVC or similar by-pass entropy coding.

// parse the unmatched pair flag

parseEP(&uiUnmatchedPairFlag);

if (uiUnmatchedPairFlag )

{

parseEPs( uiSymbol, uiIndexBits );

pIdx[uiIdx] = uiSymbol;

uiIdx++;

}

else

{

/*bound binarization with max possible value*/

UInt uiDistBits =0;

// offset is used to add additional references from neighboring blocks

// here, we first let offset=0;

while( (1<<uiDistBits)<= (uiIdx+offset))

uiDistBits++;

UInt uiLenBits =0;

while( (1<<uiLenBits)<= (uiTotal-uiIdx))

uiLenBits++;

parseEPs( uiSymbol, uiDistBits);

pDist[uiIdx] = uiSymbol;

parseEPs( uiSymbol, uiLenBits);

pLen[uiIdx] = uiSymbol;

for(UInt i=0; i< pLen[uiIdx]; i++)

pIdx[i+uiIdx] = pIdx[i+uiIdx- pDist[uiIdx]];

uiIdx += pLen[uiIdx];

}

매칭되지 않은 위치의 화소만 비트스트림으로 인코딩된다. 더욱 정확한 통계 모델을 위해서, 코딩 유닛 내의 모든 화소의 사용 대신, 컬러 팔레트 테이블 유도를 위해 매칭되지 않은 위치의 화소 및 그와 인접한 화소만 사용한다.

이러한, 인덱스 또는 델타 출력에서, 보통 특정 인코딩 모드에서 고유값의 제한된 수를 포함한다. 본 발명에서 이러한 관찰(observation)을 활용하는 두 번째 델타 팔레트 테이블을 개시한다. 이러한 델타 팔레트 테이블은 코딩 유닛 내의 모든 리터럴 데이터(literal data)가 획득된 이후에 구축될 수 있고, 비트스트림에서 명확하게 시그널링된다. 대안으로서, 테이블이 비트스트림 내에 포함될 필요가 없도록, 코딩 프로세스 동안 별도로 구축될 수 있다. 델타_컬러_테이블_어뎁티브_플래그(delta_color_table_adaptive_flag )가 이러한 선택에 대해 정의된다.

인접하는 델타 컬러 팔레트 테이블 병합(Neighboring Delta Color palette table Merge)으로 명명된 다른 진보된 방식이 제공된다. 어뎁티브 델타 팔레트 생성을 위해, 인코더는 위쪽 코딩 유닛 또는 왼쪽 코딩 유닛의 델타 팔레트를 초기 시작 지점으로 사용할 수 있다. 넌-어뎁티브(non-adaptive) 팔레트 생성을 위해, 인코더는 또한 위쪽 코딩 유닛 또는 왼쪽 코딩 유닛을 사용할 수 있고 위쪽, 왼쪽 현재 코딩 유닛 사이의 RD 비용을 비교할 수 있다.

델타_컬러_테이블_병합_플래그는 현재 코딩 유닛이 왼쪽 또는 위쪽 코딩 유닛의 델타 컬러 팔레트 테이블을 사용하는지를 나타내기 위해 정의될 수 있다. 델타_컬러_테이블_어뎁티브_플래그==0이고 동시에 델타_컬러_테이블_병합_플래그==0일 때만 현재 코딩 유닛은 델타 컬러 팔레트 테이블 시그널링을 명확하게 운반한다.

병합 프로세스를 위해, 델타_컬러_테이블_병합_플래그가 주장되면, 병합 후보가 위쪽 또는 왼쪽 코딩 유닛 중 하나인지를 나타내도록, 다른 델타_컬러_테이블_병합_방향이 정의된다.

어뎁티브 델타 팔레트 생성을 위한 인코딩 프로세스의 일례는 이하에서 나타난다. 디코딩 측에서, 디코더가 리터럴 데이터를 수신할 때마다, 역방향 단계에 기초하여 델타 팔레트를 재생성한다.

10. palette_table[] 및 palette_count[]을 정의한다.

11. palette_table(n) = n(n = 0…. 255)으로 초기화한다. 대안으로서, 위쪽 또는 왼쪽 코딩 유닛의 palette_table[]을 초기화 값으로 사용할 수 있다.

12. palette_count(n) = 0(n = 0…. 255)으로 초기화한다. 대안으로서, 위쪽 도는 왼쪽 코딩 유닛의 palette_count[]을 초기화 값으로 사용할 수 있다.

13. 어떤 델타 값 c'에 대해:

1) palette_table(n) == delta c '이 되도록 n을 배치한다.

2) 델타 c'의 신규 인덱스로서 n을 사용한다.

3) ++palette_count(n)

4) 내림 차순이 되도록 palette_count[]를 정렬한다.

5) 대응하여 palette_table[]을 정렬한다.

14. 현재 LCU 내의 모든 델타 c'가 처리될 때까지 단계 1로 되돌아간다.

텍스트 및 그래픽을 모두 포함하는 모든 블록에 대해, 텍스트 섹션 및 그래픽 섹션으로 분리하기 위해 마스크 플래그가 사용된다. 텍스트 섹션은 상술한 방식에 의해 압축되고, 그래픽 섹션은 다른 압축 방식으로 압축된다.

마스크 플래그에 의해 커버 된 모든 화소값은 텍스트 레이어에 의해 손실 없이 코딩되기 때문에, 그래픽 섹션 내의 화소는 "don't-care-pixel"로서 될 수 있다. 그래픽 섹션이 압축되면, 최적 압축 효율을 위해 어떤 임의의 값이 don't-care-pixel에 할당될 수 있다.

손실 부분은 컬러 팔레트 테이블 유도에 의해 처리될 수 있기 때문에, 인덱스 맵은 손실 없이 압축되어야 한다. 이것은 1차원 또는 2차원 스트링 매칭을 사용한 효율적인 처리를 허용한다. 본 발명에서, 1차원 또는 2차원 스트링 매칭은 현재 LCU에서 제한되나, 검색창은 현재 LCU를 넘어 확장될 수 있다. 또한, 매칭된 거리는 수평 및 수직 방향의 모션 벡터의 쌍을 사용하여 인코딩될 수 있다. 즉, (MVy=matched_distance/cuWidth, MVy=matched_distance-cuWidth*MVy).

로컬 영역에서 상이한 공간 텍스쳐 오리엔테이션(spatial texture orientation)을 갖는 이미지를 고려하여, 컬러_인덱스_맵_예측_방향(color_idx_map_pred_direction) 지시자에 의해 정의된 1차원 검색은 수평 또는 수직 방향 중 어느 한 방향으로 허용된다. 죄적 인덱스 스캐닝 방향은 R-D 비용에 기초하여 생성될 수 있다. 도 6은 첫 번째 위치부터 시작하는 스캔 방향을 나타낸다. 추가로, 도 9에 수평 및 수직 스캐닝 패턴이 도시되어 있다. 8X8 코딩 유닛을 예로서 고려한다. deriveMatchPairs() 및 관련된 엔트로피 코딩 단계는 수평 및 수직 스캐닝 패턴 모두에 대해 두 번 실행된다. 그 다음에 마지막 스캐닝 방향이 가장 낮은 R-D 비용으로 설정된다.

개선된 이진화( Binarization )

도 13에 도시된 바와 같이, 컬러 팔레트 테이블 및 컬러 인덱스 맵의 매칭된 쌍의 정보가 인코딩된다. 컬러 팔레트 테이블 및 컬러 인덱스 맵의 매칭된 쌍의 정보는 고정 길이 이진화를 사용하여 인코딩된다. 따라서, 컬러 인덱스 맵 내의 8개의 상이한 인덱스를 포함한다. 모든 인덱스 값을 동일하게 인코딩하기 위해, 고정된 3개의 빈(bin)의 사용 대신, 예를 들어, 0인 하나의 비트가 백그라운드 화소를 나타내기 위해 사용될 수 있다. 그 다음, 7개의 화소값의 나머지가 1000, 1001, 1010, 1011, 1100, 1101, 및 1110과 같은 고정-길이 코드워드(fixed-length codeword)를 사용하여 컬러 인덱스를 인코딩한다. 이것은 배경(background) 컬러가 가장 큰 백분위 수를 차지한다는 사실에 기초하고 따라서 배경 컬러에 대한 특별한 코드워드가 전체 빈(bin)을 절약한다. 이런 시나리오는 대게 스크린 콘텐츠에 대해 발생한다. 3-빈 이진화(3-bin binarization)에 대해, 16X16 코딩 유닛(CU)을 고려하면, 3x16x16=768개의 빈이 필요하다. 또한, 다른 컬러는 동일하게 분포됐지만, 하는 0 인덱스를 배경 컬러로 하면 40%를 차지한다. 이런 경우, 2.8x16x16<768 빈만 필요하다.

현재 코딩 유닛 영역 내에서, 이러한 방식의 제한적 구현을 고려하면, 매칭된 쌍 인코딩을 위해, 최대값은 이진화를 결합하는데 사용될 수 있다. 수학적으로, 각 경우에, 매칭된 거리 및 길이는 64x64=4K만큼 길 수 있다. 그러나 이것이 동시에 발생하지는 않는다. 모든 매칭된 위치에 대해, 매칭된 거리는 기준 버퍼 내에서 현재 위치 및 첫 번째 위치(예를 들어, 현재 코딩 유닛 내의 첫 번째 위치) 사이의 거리, 예를 들어 L에 의해 제한(bounded)된다. 따라서, 이러한 거리 이진화에 대한 최대 빈은 (고정된 길이 대신) log2(L)+1이고, 길이 이진화에 대한 최대 빈은 log2(cuSize-L)+1 이며, cuSize=cuWidth*cuHeight이다.

컬러 팔레트 테이블 및 인덱스 맵에 추가로, 레지듀얼 코딩은 상이한 이진화 방법으로 상당히 개선될 수 있다. HEVC RExt 및 HEVC 버전에 대해, 레지듀얼 크기가 예측, 변환 및 양자화 이후에 작다는 가정하에, 변환 계수는 가변 길이 코드를 사용하여 이진화된다. 그러나 변환 스킵 도입 이후, 특히, 다른 컬러의 스크린 콘텐츠에 대한 변환 스킵에 대해, 큰 레지듀얼 및 (상대적으로 작은 값 "1", "2", "0"에 가깝지 않은) 임의의 값이 존재한다. 현재 HEVC 계수 이진화가 사용되면, 매우 긴 코드 워드가 야기된다는 것이 드러난다. 대안으로서, 고정 길이 이진화를 사용하는 것은 컬러 팔레트 테이블 및 인덱스 코딩 모드에 의해 생성된 레지듀얼의 코드 길이가 짧아진다.

혼합 콘텐츠에 대한 어뎁티브 크로마 샘플링(adaptive chroma sampling )

전술한 설명은 HEVC/HEVE-RExt의 프레임워크에서 고효율 스크린 콘텐츠 코딩에 대해 다양한 기술을 제공한다. 실제로, (텍스트, 그래픽과 같은)퓨어 스크린 콘텐츠 또는 퓨어 내추럴 비디오(pure natural video)에 추가로, 또한, 혼합 콘텐츠로 명명된, 화면 자료 및 카메라-촬상 내추럴 비디오를 포함한 콘텐츠가 있다. 현재 혼합 콘텐츠는 4:4:4 크로마 샘플링으로 처리된다. 하지만, 이러한 혼합 콘텐츠내의 임베디드 카메라-촬상 내추럴 비디오 부분에 대해, 4:2:0 크로마 샘플링은 인지되는 무손실 품질을 제공하는데 충분할 수 있다. 이것은

인간의 시각 시스템은 루마(luma) 성분과 비교하여 크로마 성분에서 공간 변화에 덜 민감하다는 사실에 기인한다. 따라서, 동일한 복원 품질을 유지하면서 인지 가능한 비트 레이트 감소(bit rate reduction)를 달성하도록, 전형적으로 서브-샘플링(예를 들어, 보편적인 4:2:0 비디오 포맷)이 크로마 부분에 수행된다.

본 발명은, 재귀적으로, CU 레벨에서 정의되고 시그널링되는 신규 플래그(즉, 인에이블_크로마_서브샘플링(enable_chroma_subsampling))를 제공한다. 각 코딩 유닛에 대해, 인코더는 레이트-디스토션(rate-distortion) 비용에 따라 4:2:0 또는 4:4:4를 사용하여 코딩되었는지를 결정한다.

도 14A 및 14B는 4:2:0 및 4:4:4 크로마 샘플링 포멧을 나타낸 것이다.

인코더 측에서, 각 코딩 유닛(CU)에 대해, 상술한 바와 같이, 입력은 4:4:4 소스이고, 레이트-디스토션 비용은 enable_chroma_subsampling = 0 또는 FALSE로써, 4:4:4 인코딩 순서를 사용하여 직접 유도된다. 이후에, 프로세스는 서브-샘플 4:4:4를 4:2:0으로 샘플링하여 비트 소비를 유도한다. 복원된 4:2:0 포맷은(SSE/SAD를 사용하여) 디스토션 측정에 대해 4:4:4 포맷으로 다시 보간 된다. 비트 소비와 함께, 코딩 유닛을 4:2:0 공간에서 인코딩할 때 레이트-디스토션 비용이 유도되고, 코딩 유닛을 4:4:4 공간에서 인코딩할 때와 비교한다. 어느 인코딩이든지 적은 레이트-디스토션 비용을 갖는 인코딩이 마지막 인코딩을 위해 선택된다.

도 15는 4:4:4 에서 4:2:4 보간 프로세스 및 그 반대 복간 프로세스를 도시한 것이다. 보통 비디오 컬러 샘플링 포맷 변환 프로세스는 많은 수의 보간 필터가 필요하다.

구현의 복잡성을 줄이기 위해, HEVC 보간 필터(즉, DCT-IF)가 사용될 수 있다. 도 15에 도시된 바와 같이, "사각 박스"는 원래 4:4:4 샘플링을 나타낸다. 4:4:4부터 4:2:0까지, 하프-펠(half-pel) 화소("원")는 DCT-IF를 사용하여 크로마 성분에 대해 수직으로 보간된다. 또한, 예시 목적으로 쿼터-펠(quarter-pel) 위치("다이아몬드")가 도시되었다. 회색 음영 "원"은 4:4:4 샘플에서 선택된다. 4:2:0 에서 4:4:4 보간에 대해, 프로세스는 크로마 성분 내의 음영 "원"으로부터 시작하고, 모든 "원"을 획득하도록, 하프-펠 위치는 수평으로 보간되고, 이후, "사각형 박스"가 DCT-IF를 사용하여 수직으로 보간된다. 모든 보간된 "사각형 박스"는 복원된 4:4:4 소스로부터 선택된다.

인코더 제어

이전 섹션에서 설명한 바와 같이, 저 레벨 처리를 제어하기 위한 플래그가 개시된다. 예를 들어, 저 레벨 처리 인코딩을 위해, 인에이블_패킹_요소_플래그는 현재 코딩 유닛(CU)이 패킹 포맷 또는 종래 플래너 포맷을 사용하는지를 나타내기 위해 사용된다.

패킹 포맷을 사용할지는 인코더에서 계산된 R-D 비용에 따를 수 있다. 실제 인코더 구현에서, 도 3에 나타난 바와 같이, 낮은 복잡성(low-complexity) 솔루션은 코딩 유닛의 히스토그램의 분석 및 결정을 위한 최적의 임계값을 찾는 것에 의해 달성된다.

컬러 팔레트 테이블의 크기는 복잡성이 직접 영향을 미친다. maxColorNum는 복잡성 및 코딩 효율 사이의 트레이드-오프를 제어하기 위해 도입된다. 가장 복잡하지 않은 방식은 가장 낮은 R-D 비용을 생성하는 것을 선택하는 것이다.

인덱스 맵 인코딩 방향은 R-D 최적화에 의해 결정될 수 있거나, 또는 (방향 추정에 기초한 소벨 연산자(sobel operator)와 같은)로컬 공간 오리엔테이션(local spatial orientation)을 사용하여 결정될 수 있다.

본 발명은 모든 CTU/CU 내의 처리를 제한한다. 실제로, 이러한 제한은 완화될 수 있다. 예를 들어, 도 16에 도시된 바와 같이, 컬러 인덱스 맵 처리를 위해, 위쪽 및 왼쪽 코딩 유닛의 라인 버퍼가 사용될 수 있다. 위쪽 및 왼쪽 버퍼로써, 코딩 효율이 추가 개선되도록, 검색은 확장될 수 있다. 주어진 위쪽/왼쪽 버퍼는 인접하는 코딩 유닛의 복원된 화소를 사용하여 형성되고, 복원된 화소(뿐 아니라 대응하는 인덱스)는 현재 코딩 유닛 인덱스 맵 처리 이전에, 기준에 대해 사용 가능하다. 예를 들어, 재정렬 이후, 현재 코딩 유닛 인덱스 맵은 (1차원 프리젠테이션으로서)14, 14, 14,…. 1, 2, 1일 수 있다. 리인 버퍼 기준 없이, 첫 번째 "14"는 매칭되지 않은 쌍으로 코딩될 것이다. 그러나 이하에서 나타난(수평 및 수직 스캐닝 패턴 또한 나타난)바와 같이, 인접하는 라인 버퍼로써, 스트링 매칭은 첫 번째 화소에서 시작할 수 있다.

디코더 신택스 (Syntax)

이하의 [표 1]은 도 2에 도시된 디코더를 설명하기 위해 사용될 수 있다. 본 발명의 신택스는 HEVC RExt의 위원회 초안에 따라 정렬된다.

7.3.5.8 코딩 유닛 신택스(Coding unit syntax):

coding_unit(　x0,　y0,　log2CbSize　) {	Descriptor
if( transquant_bypass_enabled_flag )
cu_transquant_bypass_flag	ae(v)
if( slice_type != I )
cu_skip_flag[　x0　][　y0　]	ae(v)
nCbS = (　1　　<<　　log2CbSize　)
if( cu_skip_flag[　x0　][　y0　] )
prediction_unit(　x0,　y0,　nCbS,　nCbS　)
else {
if( intra_block_copy_enabled_flag )
intra_bc_flag[　x0　][　y0　]	ae(v)
if( color_table_enabled_flag )
color_table_flag[　x0　][　y0　]	ae(v)
if( delta_color_table_enabled_flag )
delta_color_table_flag[　x0　][　y0　]	ae(v)
if( !intra_bc_flag[　x0　][　y0　] ) {
if( slice_type != I )
pred_mode_flag	ae(v)
if( CuPredMode[　x0　][　y0　] != MODE_INTRA \|　\| log2CbSize =　= MinCbLog2SizeY )
part_mode	ae(v)
}
if( CuPredMode[　x0　][　y0　] =　= MODE_INTRA ) {
if( PartMode =　= PART_2Nx2N && pcm_enabled_flag && !intra_bc_flag log2CbSize >= Log2MinIpcmCbSizeY && log2CbSize <= Log2MaxIpcmCbSizeY )
pcm_flag[　x0　][　y0　]	ae(v)
if( pcm_flag[　x0　][　y0　] ) {
while( !byte_aligned(　) )
pcm_alignment_zero_bit	f(1)
pcm_sample(　x0,　y0,　log2CbSize　)
} else if( intra_bc_flag[　x0　][　y0　] ) {
mvd_coding(　x0,　y0,　2)
} else if( color_table_flag[x0][y0] \|\| delta_color_table_flag[x0][y0]) {
enable_packed_component_flag	ae(v)
if(color_table_flag[x0][y0] ) {
color_table_merge_flag	ae(v)
if (color_table_merge_flag){
color_table_merge_idx	ae(v)
}else{
color_table_size	ae(v)
for(i=0;i< color_table_size;i++)
color_table_entry[i]	ae(v)
}
color_idx_map_pred_direction	ae(v)
}
if(delta_color_table_flag[x0][y0] ) {
delta_color_table_adaptive_flag	ae(v)
delta_color_table_merge_flag	ae(v)
if (delta_color_table_merge_flag){
delta_color_table_merge_idx	ae(v)
}else if (!delta_color_table_adaptive_flag){
delta_color_table_size	ae(v)
for(i=0;i< delta_color_table_size;i++)
delta_color_table_entry[i]	ae(v)
}
}
Pos=0; cuWidth=1<<log2CbSize; cuHeight=1<<log2CbSize; while (Pos<cuWidth*cuHeight){
matched_flag	ae(v)
if(matched_flag ) {
matched_distance /MVx, MVy/	ae(v)
matched_length	ae(v)
}else{
index_delta	ae(v)
}
}
} else {
...pbOffset = ( PartMode =　= PART_NxN ) (　nCbS　/　2　) : nCbS

....

도 17은 현재 HEVC에 병합된 장치 및 방법/흐름을 나타낸 것이다.

위에서 식별된 방법/흐름 및 장치는 무선, 유선, 또는 이들의 결합, 통신 네트워크에 병합되거나 또는 이하에서 설명하는 도면의 장치에서 구현될 수 있다.

도 18은 본 본 발명에 따른 진보된 무선 수신기를 지원하는 시그널링을 사용하는 통신 시스템(100)의 일 예를 나타낸 것이다. 대체로, 시스템(100)은 복수의 무선 사용자가 데이터 및 다른 콘텐츠를 송신 및 수신할 수 있도록 한다. 시스템(100)은 CDMA(code division multiple access), TDMA(time division multiple access), FDMA(frequency division multiple access), OFDMA(orthogonal FDMA), 또는 SC-FDMA(single-carrier FDMA)와 같은 하나 이상의 채널 액세스 방식을 구현할 수 있다.

실시예에서, 통신 시스템(100)은 사용자 장비(UE, 110a-110c)) RANs(radio access networks, 120a-120b), 코어 네트워크(130), PSTN(public switched telephone network, 140), 인터넷(150), 및 다른 네트워크(160)를 포함한다. 이러한 구성 요소 또는 요소의 특정 번호는 도 18에 도시되어 있으나, 이러한 구성 요소 또는 요소의 어떤 번호라도 시스템(100)에 포함될 수 있다.

사용자 장비(110a-110c)는 시스템(100)에서 동작 및/또는 통신하도록 구성된다. 예를 들어, 사용자 장비(110a-110c)는 유선 신호 및/또는 유선 신호를 송신 및/또는 수신하도록 구성된다. 각 사용자 장비(110a-110c)는 임의의 적합한 최종 사용자 장비를 나타내고 UE(user equipment/device), WTRU(wireless transmit/receive unit), 이동국, 고정 또는 이동 가입자 유닛, 페이저, 셀룰러 전화, PDA(personal digital assistant), 스마트폰, 노트북, 컴퓨터, 터치 패드, 무선 센서, 또는 사용자 전자 장치와 같은(장치로 언급되거나) 장치를 포함할 수 있다.

여기에서, RANs(120a-120b)는 기지국(170a-170b)을 각각 포함한다. 각 기지국(170a-170b)은 코어 네트워크(130), PSTN(140), 인터넷(150), 및/또는 다른 네트워크(160)에 액세스할 수 있도록 하나 이상의 기지국(11a-110c)과 무선으로 접속하도록 구성된다. 예를 들어, 기지국(170a-170b)는

BTS(base transceiver station ), NodeB(Node-B ), eNodeB(evolved NodeB ), 홈 eNodeB, 사이트 제어기(site controller), AP(access point ), 무선 라우터, 서버, 또는 라우터, 스위치, 또는 유선 또는 무선 네트워크의 다른 처리 실체와 같은, 하나 이상의 몇몇 잘 알려진 장치를 포함할 수 있다.(또는 장치일 수 있다.)

도 18에 도시된 실시예에서, 기지국(170a)은 RAN(120a)의 일부를 형성하고, 다른 기지국, 구성 요소, 및/또는 장치를 포함할 수 있다. 또한, 기지국(170b)은 RAN(120b)의 일부를 형성하고, 다른 기지국, 구성 요소, 및/또는 장치를 포함할 수 있다. 각 기지국(170a-170b)은 때로 "셀"로 지칭되는 특정 지역 또는 영역 내의 무선 신호를 송신 및/또는 수신 동작한다. 일부 실시예에서, 각 셀에 대한 복수의 트랜스시버를 갖는 MIMO(multiple-input multiple-output) 기술이 사용될 수 있다.

기지국(170a-170b)은 하나 이상의 무선 인터페이스(190)를 통해 무선 통신 링크를 사용하여 하나 이상의 사용자 장비(110a-110c)와 통신한다. 무선 인터페이스(190)는 임의의 적합한 액세스 기술을 사용할 수 있다.

시스템(100)은 상술한 바와 같은 방식을 포함한 다중 채널 액세스 기능을 사용할 수 있다는 것이 고려된다. 특정 실시예에서, 기지국 및 사용자 장비는 LTE, LTE-A, 및/또는 LTE-B를 구현한다. 물론, 다른 다중 접속 방식과 무선 프로토콜은 사용될 수 있다.

RANs(120a-120b)는 목소리, 데이터, 어플리케이션, VoIP(Voice over Internet Protocol), 또는 다른 서비스를 사용자 장비(120a-120c)에 제공하도록, 코어 네트워크(130)와 통신한다. 당연히 RANs(120a-120b) 및/또는 코어 네트워크(130)는 하나 이상의 다른 RANs(미도시)와 직접 또는 간접으로 통신할 수 있다. 코어 네트워크(130)는 또한 다른 네트워크(PSTN(140), 인터넷(150), 및 다른 네트워크(160))에 대한 게이트웨이 액세스로서 동작할 수 있다. 또한, 사용자 장비(110a-110c)의 일부 또는 전부는 상이한 무선 기술 및/또는 프로토콜을 사용하는 다른 무선 링크를 통해 다른 무선 네트워크 통신하는 기능을 포함할 수 있다.

도 18은 통신 시스템의 일 실시예를 도시하나, 다양한 변화가 도 18에 이루어질 수 있다. 예를 들어, 통신 시스템(100)은 임의의 사용자 장비, 기지국, 네트워크, 또는 적합한 구성 내의 임의의 다른 구성 요소의 어떠한 번호라도 포함할 수 있고, 추가로, 본 발명의 모든 도면에에 도시된 EPC를 포함할 수 있다.

도 19A 및 도 19B는 본 발명에 따른 방법 및 교시가 구현될 수 있는 예시적 장치를 나타낸 것이다. 도 19A는 사용자 장비(110)의 예를 도시하고 있고, 도 19B는 기지국(170)의 예를 도시하고 있다. 이러한 구성요소는 시스템(100) 또는 다른 적합한 시스템에서 사용될 수 있다.

도 19A에 도시된 바와 같이, 사용자 장비(110)는 적어도, 하나의 처리 유닛(200)을 포함한다. 처리 유닛(200)은 사용자 장비(110)가 다양한 처리 동작을 구현한다. 예를 들어, 처리 유닛(200)은 신호 코딩, 데이터 처리, 파워 제어, 입/출력 처리, 또는 시스템(100) 내에서 사용자 장비(110)가 동작할 수 있는 다른 기능을 수행할 수 있다. 처리 유닛(200)은 또한 위에서 상세히 설명한 방법 또는 교시를 지원한다. 각 처리 유닛(200)은 임의의 적합한 처리 장치 또는 하나 또는 그 이상의 동작을 수행하도록 구성된 컴퓨팅 장치를 포함한다. 예를 들어, 각 처리 유닛(200)은 마이크로프로세서, 마이크로 컨트롤러, 디지털 신호 프로세서, 필드 프로그래머블 게이트 어레이(programmable gate array), 또는 주문형 직접 회로(application specific integrated circuit)를 포함할 수 있다.

사용자 장비(110)는 또한 적어도 하나의 트랜스시버(202)를 포함한다. 트랜스시버(202)는 적어도 하나의 안테나(204)에 의해 송신된 데이터 또는 다른 콘텐츠를 변조하도록 구성된다. 트랜스시버(202)는 또한, 적어도 하나의 안테나(204)에 의해 수신된 데이터 또는 다른 콘텐츠를 복조하도록 구성된다. 각 트랜스시버(202)는 무선 송신 신호 및/또는 무선으로 수신된 신호 생성에 적합한 어떤 구조라도 포함할 수 있다. 각 안테나(204)는 무선 신호 송신 및/또는 수신에 적합한 어떤 구조라도 포함할 수 있다. 하나 이상의 트랜스시버(202)가 사용자 장비(110)에 사용될 수 있고, 하나 이상의 안테나(204)가 사용자 장비(110)에서 사용될 수 있다. 단일 기능 유닛으로서 트랜스시버(202)가 개시되었으나, 트랜스시버(202)는 적어도 하나의 송신기 및 적어도 하나의 별도 수신기를 사용하여 구현될 수 있다.

추가로, 사용자 장비(110)는 하나 이상의 입/출력 장치(206)를 포함한다. 입/출력 장치(206)는 사용자와의 상호 작용을 용이하게 한다. 각 입/출력 장치(206)는 스피커, 마이크, 키패드, 키보드, 디스플레이, 또는 터치 스크린과 같은 정보 제공에 적합한 구조 또는 사용자로부터의 정보 수신에 적합한 어떤 구조라도 포함할 수 있다.

또한, 사용자 장비(110)는 적어도 하나의 메모리(208)를 포함한다. 메모리(208)는 사용자 장비(110)에 의해, 사용되고, 생성되고, 수집된 명령 및 데이터를 저장한다. 예를 들어, 메모리(208)는 처리 유닛(200)에 의해 실행된 소프트웨어 또는 펌웨어 명령 및 수신 신호의 간섭을 줄이거나 제거하는데 사용되는 데이터를 저장할 수 있다. 각 메모리(208)는 적합한 어떠한, 휘발성 및/또는 비휘발성 저장장치 및 검색 장치라도 포함할 수 있다. RAM(random access memory), ROM(read only memory), 하드디스크, 광디스크, SIM(subscriber identity module) 카드, 메모리 스틱, SD(secure digital) 메모리 카드 등과 같은 적합한 유형의 어떠한 메모리가 사용될 수 있다.

도 19B에 도시된 바와 같이, 기지국(170)은 적어도 하나의 처리 유닛(250), 적어도 하나의 송신기(252), 적어도 하나의 수신기(254), 적어도 하나의 안테나(256), 및 적어도 하나의 메모리(258)를 포함한다. 처리 유닛(250)은 신호 코딩, 데이터 처리, 파워 제어, 입/출력 처리, 또는 다른 기능과 같은 기지국(170)의 다양한 처리 동작을 구현한다. 처리 유닛(250)은 또한 위에서 상세히 설명한 방법 또는 교시를 지원한다. 각 처리 유닛(250)은 하나 이상의 동작을 수행하도록 구성된, 적합한 처리 장치 또는 컴퓨팅 장치는 어떠한 것이라도 포함할 수 있다. 예를 들어, 각 처리 유닛(250)은 마이크로프로세서, 마이크로 컨트롤러, 디지털 신호 프로세서, 필드 프로그래머블 게이트 어레이(programmable gate array), 또는 주문형 직접 회로(application specific integrated circuit)를 포함할 수 있다.

각 송신기(252)는 하나 이상의, 사용자 장비 또는 다른 장치에 무선 송신 신호를 생성하는 적합한 구조는 어떤 것이라도 포함한다. 각 수신기(254)는 하나 이상의 사용자 장비 또는 다른 장치로부터 무선으로 수신된 신호 처리에 적합한 구조는 어떠한 것이라도 포함한다. 분리된 구성요소로서 나타났으나, 적어도 하나의 송신기(252) 및 적어도 하나의 수신기(254)는 트랜스시버로 결합 될 수 있다. 여기에서 도시된 각 안테나(256)는 무선 신호를 송신 및/또는 수신하는데 적합한 어떠한 구조라도 포함한다. 공통 안테나(256)가 송신기(252) 및 수신기(254) 모두를 연결하는 것으로 도시되었으나, 하나 이상의 안테나(256)는 송신기(252)에 연결될 수 있고, 하나 이상의 별도 안테나가 수신기(254)에 연결될 수 있다. 각 메모리(258)는 적합한 어떠한, 휘발성 및/또는 비휘발성 저장장치 및 검색 장치라도 포함할 수 있다.

사용자 장비(110) 및 기지국(170)에 관한 추가 세부 사항은 당업자에게 공지되어있다. 따라서, 이러한 세부 사항은 명확성을 위해 생략한다.

이 명세서에서 사용되는 특정 단어와 구문의 정의를 규정하는 것이 유리할 수있다. "포함한다."라는 용어 및 이로부터 파생된 용어는 제한 없이 포함을 의미한다. "또는" 용어는 및/또는의 의미를 포함한다. "이와 관련된" 및 "~와 관련된" 문구 및 이로부터 파생된 문구는, 포함하는, ~내에 포함된, 상호 연결된, ~을 포함하다, ~에 포함되는, ~에 또는 ~으로 연결된, ~과 통신 가능한, ~와 협력하다, 인터리브, 병치하다, ~에 근접한, ~ 내 또는 ~으로 한정된, ~을 갖는, ~의 특성을 포함한, 등이 될 수있다.

본 발명은 특정 실시 예 및 실시예와 대체적으로 관련된 방법을 설명하였으나, 실시예 및 방법의 변경 및 교체는 당업자에게 명확할 것이다. 따라서 본 발명의 실시예의 상술한 설명은 본 발명을 정의하거나 한정하지 않는다. 이하의 청구 범위에 의해 정의된 다른 변화, 대체, 및 변경은 또한 본 발명의 사상 및 범위를 벗어나지 않고 가능하다.

Claims

스크린 콘텐츠를 비트 스트림으로 코딩하는 코딩 방법으로서,
스크린 콘텐츠의 코딩 유닛을 위한 컬러 팔레트 테이블(color palette table)을 선택하는 단계;
상기 선택된 컬러 팔레트 테이블을 사용하여, 상기 코딩 유닛에 대한 인덱스(indices)를 포함하는 컬러 인덱스 맵(color index map)을 생성하는 단계; 및
상기 코딩 유닛에 대한 상기 선택된 컬러 팔레트 테이블 및 상기 컬러 인덱스 맵을 비트스트림(bitstream)으로 인코딩하는 단계
를 포함하는 코딩 방법.
제1항에 있어서,
플래너 컬러 포맷(planar color format) 또는 인터리브 컬러 포맷(nterleaved color format)을 사용하여 처리되는 코딩 방법.
제2항에 있어서,
코딩 유닛 레벨(coding unit level), 슬라이스 레벨(slice level), 픽처 레벨(picture level), 또는 시퀀스 레벨(sequence level)의 그룹에서 선택된 레벨에서 처리되는 코딩 방법.
제1항에 있어서,
상기 컬러 팔레트 테이블은 상기 코딩 유닛 또는 인접하는 코딩 유닛으로부터 유도된, 코딩 방법.
제4항에 있어서,
상기 컬러 팔레트 테이블은 화소 영역 내에서 복원된 코딩 유닛을 사용하여, 인접하는 코딩 유닛으로부터 유도된, 코딩 방법.
제5항에 있어서,
상기 코딩 유닛의 깊이 및 크기에 관계없이, 사용 가능한 복원된 화소에 기초하여 상기 인접하는 코딩 유닛의 컬러 팔레트 테이블을 생성하는 단계
를 더 포함하는 코딩 방법.
제4항에 있어서,
상기 인접하는 코딩 유닛의 컬러 팔레트를 생성하는 단계를 더 포함하고,
상기 인접하는 코딩 유닛은 컬러 팔레트 모드(color palette mode)를 사용하여 인코딩되는, 코딩 방법.
제4항에 있어서,
상기 인접하는 코딩 유닛은 컬러 팔레트 모드를 사용하여 인코딩되지 않고,
인접하는 코딩 유닛 컬러 팔레트 테이블은, 컬러 팔레트 모드를 사용하여 인코딩된 이전 코딩 유닛으로부터 전달되는, 코딩 방법.
제1항에 있어서,
상기 컬러 팔레트 테이블은 디코더에서 화소 영역 내에서 유도되고,
상기 인코딩된 비트스트림은, 상기 코딩 유닛에 대해, 상기 컬러 팔레트 테이블 및 상기 컬러 인덱스 맵을 복원하기 위해 분석되는, 코딩 방법.
제6항에 있어서,
상기 컬러 인덱스 및 상기 컬러 팔레트 테이블을 결합하는 것에 의해 상기 코딩 유닛 내에서 각 위치에서 화소값이 유도되는,, 코딩 방법.
제1항에 있어서,
대응하는 인덱스에 대해 이전에 유도된 컬러 팔레트 테이블에 기초하여, 상기 코딩 유닛의 색 또는 화소값을 분류하는 단계를 더 포함하는 코딩 방법.
제1항에 있어서,
신규 신택스(syntax) 요소를 상기 인코딩된 비트스트림에 기록하는 단계를 더 포함하는 코딩 방법.
제1항에 있어서,
상기 컬러 팔레트 테이블은, 히스토그램 또는 실제 색 강도(color intensity)에 따라 생성되고 정렬되는, 코딩 방법.
제1항에 있어서,
상기 코딩 유닛의 각 화소는, 상기 컬러 팔레트 테이블 내에서 컬러 인덱스로 변환되는, 코딩 방법.
제1항에 있어서,
상기 코딩 유닛이 패킹 방식(packed fashion)을 사용하여 처리되었는지 또는 플래너 모드(planar mode)를 사용하여 처리되었는지를 나타내도록, 플래그(flag)가 상기 코딩 유닛에 대해 정의되는, 코딩 방법.
제1항에 있어서,
상기 컬러 팔레트 테이블은, 상기 컬러 팔레트 테이블의 크기 및 상기 컬러 팔레트 테이블 내의 각 컬러를 인코딩하여 처리되는, 코딩 방법.
제1항에 있어서,
상기 코딩 유닛이 왼쪽 또는 위쪽 코딩 유닛의 상기 컬러 팔레트 테이블을 사용하는 것을 나타내는 플래그(flag)를 생성하는 단계를 더 포함하는 코딩 방법.
제1항에 있어서,
상기 인덱스 맵은, 1차원 스트링 매치(string match), 하이브리드(hybrid) 1차원 스트링 매치, 및 2차원 스트링 매치를 포함하는 그룹으로부터 선택된 스트링 매치를 사용하여 인코딩되고,
상기 스트링 매치는 매칭된 쌍을 사용하여 시그널링되는, 코딩 방법.
제18항에 있어서,
상기 스트링 매치는 러닝 해시(running hash) 방식을 사용하여 수행되는, 코딩 방법.
제1항에 있어서,
상기 코딩 유닛 내에서 현재 화소의 위치 및 기준 화소의 위치를 시작 지점으로서 식별하여, 2차원 탐색 방법이 상기 컬러 인덱스 맵상에 수행되는, 코딩 방법.
제1항에 있어서,
상기 코딩 유닛은, 다운 샘플링된 4:2:0 샘플링 포맷을 사용하여 처리된 4:4:4 포맷을 가지는, 코딩 방법.
제21항에 있어서,
상기 다운 샘플링된 포맷은, 코딩 유닛(coding unit) 레벨, 슬라이스(slice) 레벨, 픽처(picture) 레벨 또는 시퀀스(sequence) 레벨을 포함하는 그룹으로부터 선택된 레벨에서 처리되는, 코딩 방법.
스크린 콘텐츠를 비트 스트림으로 코딩하는 프로세서로서,
스크린 콘텐츠의 코딩 유닛에 대한 컬러 팔레트 테이블을 선택하는 동작;
상기 선택된 컬러 팔레트 테이블을 사용하여, 상기 코딩 유닛에 대한 인덱스를(indices) 포함하는 컬러 인덱스 맵(color index map)을 생성하는 동작; 및
상기 코딩 유닛에 대한 상기 선택된 컬러 팔레트 테이블 및 상기 컬러 인덱스 맵을 비트스트림(bitstream)으로 인코딩하는 동작
을 수행하도록 구성된 프로세서.
제23항에 있어서,
상기 컬러 팔레트 테이블은 상기 코딩 유닛 또는 인접하는 코딩 유닛으로부터 유도된, 프로세서.
제24항에 있어서,
상기 컬러 팔레트 테이블은, 화소 영역 내에서 복원된 코딩 유닛을 사용하여, 인접하는 코딩 유닛으로부터 유도된, 프로세서.