BR112016011471A2 - Solução de codificação de conteúdo de tela avançada - Google Patents

Abstract

MÉTODO PARA CODIFICAR CONTEÚDO DE TELA EM UM FLUXO DE BITS E PROCESSADOR PARA CODIFICAR CONTEÚDO DE TELA EM UM FLUXO DE BITS. A presente invenção se refere a um método e dispositivo para a codificação de conteúdo de tela em um fluxo de bits mediante a seleção de uma tabela de paleta de cores para uma unidade de codificação (CU) de conteúdo de tela, a criação de um mapa de índice de cores que tem índices para a unidade de codificação (CU) e a codificação da tabela de paleta de cores selecionada e do mapa de índice de cores para a CU em um fluxo de bits.

Description

Relatório Descritivo da Patente de Invenção para "MÉTO-

DO E SISTEMA PARA CODIFICAR CONTEÚDO DE TELA EM UM FLUXO DE BITS". CAMPO DA TÉCNICA

[001] A presente revelação refere-se, de maneira geral, a codifi- cação de conteúdo de tela.

ANTECEDENTES

[002] A codificação de conteúdo de tela impõe novos desafios à tecnologia de compressão de vídeo devido às suas características de sinal distintas comparadas a vídeos naturais convencionais. Parece haver umas poucas técnicas promissoras para a codificação de conte- údo de tela avançada, por exemplo, correspondência de pseudocadeia de caracteres, codificação de paleta de cores e compensação intramo- vimento ou cópia intrabloco.

[003] Dentre essas técnicas, a correspondência de pseudoca- deia de caracteres apresenta o ganho mais alto para codificação sem perdas, mas com significativa sobrecarga de complexidade e dificulda- des em modo de codificação com perdas. A codificação de paleta de cores é desenvolvida para conteúdo de tela sob a premissa de que conteúdo capturado não por câmera tipicamente contém umas poucas cores distintas limitadas, ao invés do tom de cor contínuo em vídeos naturais. Embora os métodos de correspondência de pseudocadeia de caracteres e codificação de paleta de cores apresentem grande poten- cial, a compensação intramovimento ou a cópia intrabloco foi adotada no anteprojeto (WD) versão 4 e software de referência de extensão de faixa de HEVC (HEVC RExt) em andamento para a codificação de conteúdo de tela. Isso é principalmente devido ao fato de que a abor- dagem de estimativa e compensação de movimento tem sido estudada extensivamente por décadas, bem como por sua ideia e implantação prática serem bastante fáceis (especialmente para hardware).

[004] No entanto, o desempenho de codificação de cópia intra- bloco é limitado devido às suas partições de estrutura de bloco fixas. Por outro lado, realizar correspondência de bloco, algo similar à esti- mativa de movimento em intraimagem, também eleva a complexidade do codificador significativamente tanto na computação quanto no acesso a memória.

SUMÁRIO

[005] Esta revelação é dirigida a uma solução de codificação de conteúdo de tela avançada.

[006] Em uma modalidade exemplificativa, um método para co- dificação conteúdo de tela em um fluxo de bits seleciona uma tabela de paleta de cores para uma unidade de codificação (CU) de conteúdo de tela. A tabela de paleta de cores criada é para a CU e uma tabela de paleta de cores é criada para uma CU vizinha. É criado um mapa de índice de cores que tem índices para a unidade de codificação (CU) do conteúdo de tela com o uso da tabela de paleta de cores selecio- nada. A tabela de paleta de cores selecionada e o mapa de índice de cores são codificados/comprimidos para cada uma de uma pluralidade de CUs em um fluxo de bits.

BREVE DESCRIÇÃO DAS FIGURAS

[007] Para um entendimento mais completo da presente revela- ção e das vantagens da mesma, agora é feita referência às descrições a seguir, tomadas em conjunto com os desenhos anexos, em que nu- merais semelhantes designam objetos semelhantes, e em que:

[008] A Figura 1 ilustra uma solução de codificação de conteúdo de tela com o uso de modo de tabela de paleta de cores e mapa de índices ou modo de paleta, de acordo com uma modalidade exemplifi- cativa desta revelação;

[009] A Figura 2 ilustra uma solução de decodificação de conte- údo de tela para modo de tabela de paleta de cores e mapa de índices ou modo de paleta;

[010] A Figura 3 ilustra um processo ou fluxo de trabalho da so- lução de conteúdo de tela para esse modo de tabela de paleta de co- res e mapa de índices ou modo de paleta de uma CU;

[011] A Figura 4 ilustra um G, B, R convencional em modo plano (esquerda) para modo compactado (direita);

[012] A Figura 5 ilustra a regeneração de tabela de paleta de cores com o uso de blocos reconstruídos vizinhos;

[013] A Figura 6 ilustra um mapa de índices que é analisado a partir de um conteúdo de tela em palavras real;

[014] A Figura 7 ilustra um pedaço de um segmento para uma pesquisa 1-D após varredura horizontal;

[015] A Figura 8 ilustra um módulo de U_PIXEL;

[016] A Figura 9 ilustra um módulo de U_ROW;

[017] A Figura 10 ilustra um módulo de U_CMP;

[018] A Figura 11 ilustra um módulo de U_COL;

[019] A Figura 12 ilustra um módulo de U_2D_BLOCK;

[020] A Figura 13 é uma ilustração de varredura horizontal e vertical para processamento de mapa de índices de uma CU exempli- ficada;

[021] A Figura 14A é uma ilustração de um formato de amostra- gem de chroma 4:2:0;

[022] A Figura 14B é uma ilustração de um formato de amostra- gem de chroma 4:4:4;

[023] A Figura 15 ilustra uma interpolação entre 4:2:0 e 4:4:4;

[024] A Figura 16 ilustra o processamento de mapa de índices com armazenamento temporário de linha superior/esquerda;

[025] A Figura 17 ilustra o aparelho e métodos/fluxos incorpora- dos ao HEVC atual;

[026] A Figura 18 ilustra um exemplo de um sistema de comuni-

cação; e

[027] A Figura 19A e a Figura 19B ilustram dispositivos exempli- ficativos que podem implantar os métodos e ensinamentos de acordo com esta revelação.

DESCRIÇÃO DETALHADA

[028] Nesta revelação, é descrita uma solução de codificação de conteúdo de tela avançada que supera uma extensão de faixa de Codificação de Vídeo de Alta Eficiência (HEVC) (tal como HEVC Ver- são 2 ou HEVC RExt). Essa nova solução inclui diversos algoritmos que são projetados especificamente para codificar conteúdo de tela. Esses algoritmos incluem representação de pixel com o uso de uma paleta de cores ou de uma tabela de cores, denominada no presente documento como uma tabela de paleta de cores, compressão de pale- ta de cores, compressão de mapa de índice de cores, pesquisa em cadeia de caracteres e compressão residual. Essa tecnologia é desen- volvida, harmonizada e pode ser integrada à extensão de faixa (RExt) de HEVC e a futuras extensões de HEVC para suportar codificação de conteúdo de tela eficiente. No entanto, essa tecnologia poderia ser im- plantada com quaisquer padrões de vídeo existentes. Para simplificar, HEVC RExt é usado como um exemplo na descrição abaixo, e softwa- re de HEVC RExt é usado para descrever e demonstrar a eficiência de compressão. Essa solução é integrada a um modo adicional com o uso de uma tabela de paleta de cores e mapa de índices, definidos no presente documento como um modo de paleta de cores, em HEVC para demonstrar o desempenho.

[029] O conceito e a descrição desta revelação são ilustrados nas Figuras. A Figura 1 mostra um codificador 10 que tem um proces- sador 12 que inclui memória e a Figura 2 mostra um decodificador 14 que tem um processador 16 e memória, que juntas ilustram uma mo- dalidade exemplificativa de uma solução de codificação e decodifica-

ção para o modo de paleta de cores, respectivamente, de acordo com esta revelação. Conforme mostrado, o codificador 10 e o decodificador 14 compreendem, cada um, um processador e uma memória e for- mam uma solução de codec. A solução de codec inclui o processador 12 de codificador 10 que executa novos algoritmos ou métodos que incluem o Processo 1 de criar uma tabela de paleta de cores, o Pro- cesso 2 de classificar valores de cores ou de pixel com o uso de um tabela de paleta de cores derivada anteriormente que corresponde a índices de cor, o Processo 3 de codificar a tabela de paleta de cores, o Processo 4 de codificar o mapa de índice de cores, o Processo 5 de codificar os resíduos e o Processo 6 de gravar novos elementos de sintaxe no fluxo de bits comprimido. O processador 16 de decodifica- dor 14 executa novos algoritmos ou métodos que incluem as etapas inversas. A Figura 3 fornece um processo ou fluxo de trabalho da solu- ção de conteúdo de tela de acordo com esta revelação.

[030] Basicamente, um método de compressão de paleta de cores (CPC) de alta eficiência é realizado em cada unidade de codifi- cação (CU). Uma unidade de codificação é uma unidade operacional básica em HEVC e HEVC RExt, que é um bloco quadrado de pixels que consiste em três componentes (isto é, RGB ou YUV ou XYZ).

[031] Em cada nível de CU, o método de CPC inclui duas eta- pas principais. Primeiro, o processador 12 deriva ou gera uma tabela de paleta de cores na primeira etapa. Essa tabela é ordenada de acor- do com um histograma (isto é, frequência de ocorrência de cada valor de cor) ou sua intensidade de cor real ou qualquer método arbitrário a fim de aumentar a eficiência do processo de codificação a seguir. Com base na tabela de paleta de cores derivada, cada pixel na CU original é convertido para seu índice de cor dentro da tabela de paleta de co- res. Uma contribuição desta revelação é a tecnologia para codificar de forma eficiente, tal como com o uso de compressão, a tabela de paleta de cores e o mapa de índice de cores de cada CU no fluxo. No lado do receptor, o processador 16 analisa o fluxo de bits comprimido para re- construir, para cada CU, a tabela de paleta de cores completa e o ma- pa de índice de cores e, então, deriva adicionalmente o valor de pixel em cada posição combinando-se o índice de cor e a tabela de paleta de cores.

[032] Em um exemplo ilustrativo desta revelação, assume-se uma CU com NxN pixels (N=8, 16, 32, 64 para compatibilidade com HEVC). A CU contém, tipicamente, três componentes de crominância (chroma) (isto é, G, B, R, ou Y, Cb, Cr, ou X, Y Z) em uma razão de amostragem diferente (isto é, 4:4:4, 4:2:2, 4:2:0). Para simplificar, se- quências de 4:4:4 são ilustradas na revelação. Para sequências de vídeos de 4:2:2 e 4:2:0, aumento de amostragem de chroma poderia ser aplicado para obter as sequências 4:4:4, ou cada componente de cor poderia ser processado independentemente. Em seguida, o mes- mo procedimento descrito nesta revelação pode ser aplicado. Para ví- deos de 4:0:0 monocromáticos, isso pode ser tratado como um plano individual de 4:4:4 sem outros dois planos. Todos os métodos para 4:4:4 podem ser aplicados diretamente. Compactado ou Plano

[033] Esse método é mostrado para o Bloco de CTU ou de CU na Figura 1. Antes de tudo, um sinalizador é definido, chamado de enable_packed_component_flag, para cada CU para indicar se a CU atual é processada com o uso de forma compactada ou modo plano convencional (isto é, componentes G, B, R ou Y, U, V são processa- dos independentemente). A Figura 4 ilustra um G, B, R convencional em modo plano (esquerda) para modo compactado (direita). O YUV ou outro formato de cor poderia ser processado da mesma forma que exemplificado para o conteúdo RGB.

[034] Tanto o modo compactado quanto o modo plano têm suas próprias vantagens e desvantagens. Por exemplo, o modo plano su- porta processamento de componente de cor paralelo para G/B/R ou Y/U/V. No entanto, o mesmo poderia sofrer a baixa eficiência de codi- ficação. O modo compactado pode compartilhar as informações de cabeçalho (tal como a tabela de paleta de cores e o mapa de índices nesta revelação) para essa CU dentre componentes de cor diferentes. No entanto, o mesmo poderia quebrar o paralelismo. Uma forma fácil para decidir se a CU atual deve ser codificada na forma compactada é medir custo taxa-distorção (R-D). O enable_packed_component_flag é usado para sinalizar o modo de codificação para o decodificador, ex- plicitamente.

[035] Além disso, para definir o enable_packed_component_flag no nível de CU para tratamento de baixo nível, o mesmo pode ser du- plicado em cabeçalho de fatia ou mesmo em nível de sequência (por exemplo, Conjunto de Parâmetros de Sequência ou Conjunto de Pa- râmetros de Imagem) para permitir tratamento em nível de fatia ou em nível de sequência, dependendo da exigência da aplicação específica. Derivação de Tabela de Paleta de Cores e Mapa de Índices

[036] Conforme mostrado na Figura 1 para os Processos 1 e 3, para cada CU, as localizações pixel são percorridas e a tabela de pale- ta de cores e o mapa de índices para o processamento subsequente são derivados. Cada cor distinta é ordenada na tabela de paleta de cores, dependendo de seu histograma (isto é, frequência de ocorrên- cia) ou de sua intensidade ou de qualquer método arbitrário a fim de aumentar a eficiência do processo de codificação a seguir. Por exem- plo, se o processo de codificação usa um método de modulação por código de pulso diferencial (DPCM) para codificar a diferença entre pixels adjacentes, o resultado de codificação ideal pode ser obtido se os pixels adjacentes forem atribuídos com índice de cor adjacente na tabela de paleta de cores.

[037] Após obter a tabela de paleta de cores, cada pixel é ma- peado para o índice de cor correspondente para formar o mapa de ín- dices da CU atual. O processamento de mapa de índices é descrito na seção subsequente.

[038] Para uma CU plana convencional, cada componente de cor ou de crominância pode ter sua tabela de paleta de cores individu- al, tal como colorTable_Y, colorTable_U, colorTable_V ou colorTa- ble_R, colorTable_G, colorTable_B, enumerando-se apenas algumas aqui como exemplo. Entretanto, a tabela de paleta de cores para um componente principal pode ser derivada, tal como Y em YUV ou G em GBR, e compartilhada para todos os componentes. Normalmente, por esse compartilhamento, outros componentes de cor, além de Y ou G, teriam alguma dissonância em relação a suas cores de pixel originais a partir daquelas compartilhadas na tabela de paleta de cores. O me- canismo de resíduo (tal como métodos de codificação de coeficientes de HEVC) é, então, aplicado para codificar aqueles resíduos dissonan- tes. Por outro lado, para uma CU compactada, uma única tabela de paleta de cores é compartilhada entre todos componentes.

[039] Um pseudocódigo é fornecido para exemplificar a deriva- ção de tabela de paleta de cores e mapa de índices como segue: deriveColorTableIndexMap() { deriveColorTable(); deriveIndexMap(); } deriveColorTable(src, cuWidth, cuHeight, maxColorNum) { // src – input video source in planar or packed mode // cuWidth, cuHeigth – 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 intensi- ty 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, color- Num); /*if maxColorNum >= colorNum, all colors will be picked*/ /*if maxColorNum < colorNum, only maxColorNum col- ors 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 deter- mined 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; } } Processamento de Tabela de Paleta de Cores

[040] Para o Processo 1 na Figura 1, o processamento de tabe- la de paleta de cores envolve a codificação pelo processador 12 do tamanho de uma tabela de paleta de cores (isto é, o número total de cores distintas) e de cada uma das próprias cores. Uma maior parte dos bits é consumida pela codificação de cada cor em uma tabela de paleta de cores. Consequentemente, o enfoque é colocado sobre a codificação de cor (ou codificação de cada entrada na tabela de paleta de cores).

[041] O método mais direto para codificar as cores em uma ta- bela de paleta de cores é com o uso do algoritmo de estilo modulação por código de pulso (PCM), em que cada cor é codificada independen- temente. Alternativamente, a previsão mais próxima para uma cor su- cessiva pode ser aplicada e, então, o delta de previsão pode ser codi- ficado em vez da intensidade de cor padrão, que é estilo DPCM (PCM diferencial). Ambos os métodos podem ser posteriormente codificados por entropia com o uso de modelo de probabilidade igual ou modelo de contexto adaptativo, dependendo do compromisso entre custos de complexidade e eficiência de codificação.

[042] Aqui, outro esquema avançado é revelado, chamado de fusão de tabela de paleta de cores vizinha, em que um co- lor_table_merge_flag é definido para indicar se a CU atual usa a tabela de paleta de cores a partir de sua CU esquerda ou superior. Em caso negativo, a CU atual transportará a sinalização de tabela de paleta de cores explicitamente. Para o processo de fusão, outro co- lor_table_merge_direction indica a direção de fusão a partir da CU su- perior ou a partir da CU esquerda. Naturalmente, os candidatos pode- riam estar além da CU superior ou da CU esquerda atuais, por exem- plo, superior-esquerda, superior-direita, etc. No entanto, a CU superior e a CU esquerda são usadas nesta revelação para exemplificar a ideia. Para qualquer uma das mesmas, cada pixel é comparado às en- tradas em uma tabela de paleta de cores existente e atribuído um índi- ce que produz a diferença de previsão mínima (isto é, o pixel subtrai a cor mais próxima na tabela de paleta de cores) por meio de deriveIdx- Map(). Para o caso em que a diferença de previsão é diferente de ze- ro, todos esses resíduos são codificados com o uso do mecanismo de resíduo de HEVC RExt. Deve ser observado que o uso, ou não, do processo de fusão pode ser decidido pelo custo R-D.

[043] Há diversas formas para gerar as tabelas de paleta de co- res vizinhas a serem usadas no processo de fusão na codificação da CU atual. Dependendo de sua implantação, uma das mesmas exige atualização tanto no codificador quanto no decodificador e a outra é um processo apenas do lado do codificador.

[044] Atualização tanto no codificador quanto no decodificador: nesse método, a tabela de paleta de cores de CUs vizinhas é gerada sobre os pixels reconstruídos disponíveis, independentemente da pro- fundidade, tamanho da CU e etc. Para cada CU, as reconstruções são recuperadas para sua CU vizinha no mesmo tamanho e na mesma profundidade (assumindo-se que a similaridade de cor seria mais alta nesse caso). Por exemplo, se uma CU atual é de 16x16 com profundi- dade = 2, não importa a partição de suas CUs vizinhas (por exemplo, 8x8 com profundidade = 3 para a CU esquerda e 32x32 com profundi- dade =1 para CU superior), o deslocamento de pixel (=16) será locali- zado a partir da origem da CU atual para a esquerda para processar o bloco de 16x16 à esquerda e para cima para o bloco de 16x16 superi- or, conforme mostrado na Figura 5. Deve ser observado que tanto o codificador quanto o decodificador devem manter esse processo.

[045] Processo restrito apenas ao codificador: para esse méto- do, o processo de fusão ocorre quando uma CU atual compartilha o mesmo tamanho e profundidade que sua CU superior e/ou esquerda. As tabelas de paleta de cores das vizinhas disponíveis são usadas pa- ra derivar o mapa de índice de cores da CU atual para operações sub- sequentes. Por exemplo, para uma CU de 16x16 atual, se sua CU vi- zinha, isto é, posicionada acima ou à esquerda, é codificada com o uso do método de tabela de paleta de cores e índice, sua tabela de paleta de cores é usada para a CU atual diretamente para derivar o custo R-D. Esse custo de fusão é comparado ao caso em que a CU atual deriva sua tabela de paleta de cores explicitamente (bem como outros modos convencionais existentes no HEVC ou no HEVC RExt). O que produzir o menor custo R-D é escolhido como o modo final para ser gravado no fluxo de bits de saída. Conforme visto, é exigido ape-

nas que o codificador experimente/simule modos potenciais diferentes. No lado do decodificador, o color_table_merge_flag e o co- lor_table_merge_direction inferem a decisão de fusão e a direção de fusão sem exigir carga de trabalho de processamento adicional. Processamento de Mapa de Índice de Cores

[046] Para o Processo 3 na Figura 1, para codificar o mapa de índice de cores, poucas soluções têm sido estudadas, tais como modo RUN, RUN e COPY_ABOVE, e previsão de índice vizinho adaptativa. Nesta revelação, uma abordagem de correspondência de cadeia de caracteres 1D e sua variação 2D são reveladas para codificar a codifi- cação de mapa de índices. Em cada posição, a mesma encontra seu ponto correspondido e registra a distância e o comprimento corres- pondidos para uma correspondência de cadeia de caracteres 1D, ou largura/altura para uma correspondência de cadeia de caracteres 2D. Para uma posição não correspondida, sua intensidade de índice, ou valor delta entre sua intensidade de índice e a intensidade de índice prevista, é codificada diretamente.

[047] Aqui é revelado é um método de pesquisa 1D direto sobre o mapa de índice de cores. Com referência à Figura 6, um mapa de índices é analisado a partir de um conteúdo de tela em palavras real. A Figura 7 mostra um pedaço de um segmento após uma pesquisa 1D (isto é, apenas o começo desse mapa de índices).

[048] Sobre esse vetor de índice de cor 1D, a correspondência de cadeia de caracteres é aplicada. Um exemplo dessa correspondên- cia de cadeia de caracteres 1D é dado abaixo. Para a primeira posição de cada mapa de índices, tal como 14 conforme mostrado na Figura 7, uma vez que ainda não há nenhuma referência em armazenamento temporário, esse primeiro índice é tratado como o "par não correspon- dido", em que é dado -1 e 1 para sua distância e seu comprimento cor- respondentes, denominado como (dist, len) = (-1, 1). Para o 2o índice,

novamente outro "14", o primeiro índice é codificado como referência, portanto, a dist=1. Devido ao fato de que há outro "14" na 3a posição, o comprimento é 2, isto é, len=2, (dado que todo índice de avanço po- deria servir como a referência imediatamente para o índice subse- quente). Movendo-se para frente para a 4a posição, é encontrado o "17", que não foi visto antes. Consequentemente, o mesmo é codifica- do como um par não correspondido novamente, isto é, (dist, len) = (-1, 1). Para o par não correspondido, o sinalizador é codificado (tal como a "dist == -1") e seguido pelo valor real do índice (tal como o exibido primeiro "14", "17", "6" e etc.). Por outro lado, para os pares corres- pondido, o sinalizador ainda é codificado (tal como a "dist != -1") e se- guido pelo comprimento da cadeia de caracteres correspondida.

[049] Aqui é apresentado um sumário para o procedimento de codificação com o uso do índice exemplificado mostrado na Figura 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*/ ….

[050] Um pseudocódigo é dado para essa derivação de par cor- respondido, isto é, 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 de- cision*/ { maxLen = len; dist = (uiIdx - j );

} } pDist[uiIdx] = dist; pLen[uiIdx] = maxLen; uiIdx = uiIdx + maxLen; } }

[051] As etapas a seguir são feitas quando uma variação de pesquisa 2D é usada:

[052] 1. Identificar a localização do pixel atual e do pixel de refe- rência como ponto de partida,

[053] 2. Aplicar uma correspondência de cadeia de caracteres 1D horizontal para a direção direita do pixel atual e do pixel de refe- rência. O comprimento de pesquisa máximo é restrito pelo fim da fileira horizontal atual. Registrar o comprimento de pesquisa máximo como right_width

[054] 3. Aplicar uma correspondência de cadeia de caracteres 1D horizontal para a direção esquerda do pixel atual e do pixel de refe- rência. O comprimento de pesquisa máximo é restrito pelo começo da fileira horizontal atual. Registrar o comprimento de pesquisa máximo como left_width

[055] 4. Realizar a mesma correspondência de cadeia de carac- teres 1D na próxima fileira, com o uso de pixels abaixo do pixel atual e do pixel de referência como novos pixel atual e pixel de referência

[056] 5. Parar até que right_width == left_width == 0.

[057] 6. Agora, para cada height[n] = {1, 2, 3…}, há uma matriz correspondente de width[n] {{left_width[1], right_width[1]}, {left_width[2], right_width[2]}, {left_width[3], right_width[3]}…}

[058] 7. Definir uma nova matriz min_width {{lwidth[1], rwidth[1]}, {lwidth[2], rwidth[2]}, {lwidth[3], rwidth[3]}…} para cada height[n], em que lwidth[n] = min(left_width[1:n-1]), rwidth[n] = min(right_width[1:n-1])

[059] 8. Uma matriz de tamanho {size[1], size[2], size[3]…} tam- bém é definida, em que size[n] = height[n] x (lwidth[n]+hwidth[n])

[060] 9. Assumir que size[n] contém o valor máximo na matriz de tamanho, em que a largura e a altura de correspondência de cadeia de caracteres 2D são selecionadas com o uso da {lwidth[n], rwidth[n], height[n]} correspondente

[061] Uma forma para otimizar a velocidade da pesquisa 1D ou 2D é usar hash de execução. Uma estrutura hash de execução de 4 pixels é descrita nesta revelação. Um hash de execução é calculado para cada pixel na direção horizontal para gerar uma matriz de hash horizontal running_hash_h[]. Outro hash de execução é calculado so- bre o running_hash_h[] para gerar uma matriz de hash 2D run- ning_hash_hv[]. Cada correspondência de valor nessa matriz de hash 2D representa uma correspondência de bloco de 4x4. Para realizar uma correspondência 2D, o maior número possível de correspondên- cias de bloco de 4x4 deve ser encontrado antes de realizar compara- ção com relação a pixel para seus vizinhos. Uma vez que a compara- ção com relação a pixel é limitada aos pixels 1 a 3, a velocidade de pesquisa pode ser aumentada dramaticamente.

[062] A partir da descrição acima, as larguras correspondidas de cada fileira são diferentes entre si, portanto, cada fileira tem que ser processada separadamente. Para obter eficiência e complexidade bai- xas, é revelado um algoritmo com base em bloco, que pode ser usado em uma implantação tanto de hardware quanto de software. Muito si- milar à estimativa de movimento padrão, esse algoritmo processa um bloco retangular de cada vez.

[063] Tomando-se um bloco de 4x4 como exemplo. A unidade básica nesse projeto é chamada de U_PIXEL, conforme mostrado na Figura 8. O sinal codificado é um sinalizador que indica se o pixel de referência já foi codificado a partir de operação de correspondência de cadeia de caracteres anterior. Opcionalmente, o sinal de entrada Cmp[n-1] pode ser forçado para "0", o que permite a remoção da últi- ma ponte "OU" do módulo de U_PIXEL.

[064] A primeira etapa é para processar cada fileira em paralelo. Cada pixel em uma fileira do retângulo é atribuído a um bloco de U_PIXEL; essa unidade de processamento é chamada U_ROW. Um exemplo da unidade de processamento para a primeira fileira é mos- trado na Figura 9.

[065] Quatro unidades de U_ROW são necessárias para pro- cessar esse bloco de 4x4, conforme mostrado na Figura 10. Sua saída é uma matriz de cmp[4][4].

[066] A próxima etapa é para processar cada coluna da matriz de cmp em paralelo. Cada cmp em uma coluna da matriz de cmp é processado pela unidade de processamento U_COL, conforme mos- trado na Figura 11.

[067] Quatro unidades de U_COL são necessárias para proces- sar esse bloco de 4x4. Sua saída é uma matriz de rw[4][4], conforme mostrado na Figura 12.

[068] O número de zeros em cada fileira de rw[n][0-3] é, então, contado e os 4 resultados são registrados na matriz r_width[n]. É nota- do que r_width[n] é igual a rwidth[n] na etapa #7. l_width[n] é gerado da mesma forma. A matriz de min_width na etapa #7 pode ser obtida como {{l_width[1], r_width[1]}, { l_width[2], r_width[2]}, { l_width[3], r_width[3]}…}

[069] Essa arquitetura de hardware pode ser modificada para se ajustar à estrutura de processamento paralelo de qualquer CPU/DSP/GPU moderna. Um pseudocódigo simplificado para implan- tação de software rápida é listado abaixo. // 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]); }

[070] Não há nenhuma dependência de dados em cada ciclo, assim, um método de processamento paralelo de software tradicional, tal como desdobramento de ciclo, MMX/SSE, pode ser aplicado para aumentar a velocidade de execução.

[071] Esse método também pode ser aplicado a uma pesquisa 1D se o número de fileiras for limitado a um. Um pseudocódigo simpli- ficado para implantação de software rápida de pesquisa 1D com base em comprimento fixo é listado abaixo. // 1. Generate array C[] 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[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 R_width[y] = COUNT_ZERO(RW[0], RW[1], RW[2], RW[3]);

[072] Após tanto a correspondência de 1D quanto a correspon- dência 2D serem concluídas, max (ld length, 2d (width x height)) é es- colhido como o vencedor. Se o lwidth de correspondência 2D for dife- rente de zero, o comprimento da correspondência de 1D anterior (comprimento = comprimento – lwidth) precisa ser ajustado para evitar a sobreposição entre a correspondência de 1D anterior e a correspon- dência 2D atual. Se o comprimento da correspondência de 1D anterior se tornar zero após o ajuste, o mesmo é removido da lista de corres- pondências.

[073] A próxima localização inicial é calculada com o uso de current_location + length se a correspondência anterior for uma cor- respondência de 1D, ou current_location + (lwidth+rwidth) se a corres- pondência anterior for uma correspondência 2D. Quando uma corres- pondência de 1D é realizada, se qualquer pixel a ser correspondido estiver em qualquer região de correspondência 2D anterior em que sua localização já tiver sido coberta por uma correspondência 2D, os próximos pixels serão varridos até ser encontrada uma localização de pixel em que o mesmo não tenha sido codificado por correspondência anterior.

[074] Após obter esses pares correspondidos, um mecanismo de entropia é aplicado para converter esses símbolos no fluxo binário. Aqui é exemplificada a ideia de usar o modo de contexto de probabili- dade igual. Um modo de contexto adaptativo avançado também pode- ria ser aplicado para melhor eficiência de compressão. // 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 simi- lar by-pass entropy coding. if (pDist[uiIdx] == -1 ) { //encode one-bin with equal-probability model to indi- cate 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 col- ors, 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]; } }

[075] É mostrado o procedimento de codificação para cada par correspondido. Correspondentemente, o processo de decodificação para o par correspondido é como segue. // 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 simi- lar 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]; } }

[076] Deve ser observado que apenas pixels em uma posição não correspondida são codificados em um fluxo de bits. Para ter um modelo estatístico mais preciso, usar apenas esses pixels e seus vizi- nhos para Derivação de Tabela de paleta de cores, em vez de usar todos os pixels nessa CU.

[077] Para essas saídas de índice ou delta, as mesmas usual- mente contêm número limitado de valor único sob certo modo de codi- ficação. Esta revelação introduz uma segunda tabela de delta de pale- ta para utilizar essa observação. Essa tabela de delta de paleta pode ser construída após todos os dados literais serem obtidos nessa CU, isso será sinalizado explicitamente no fluxo de bits. Alternativamente, a mesma pode ser construída adaptativamente durante o processo de codificação para que a tabela não tenha que ser incluída no fluxo de bits. Um delta_color_table_adaptive_flag é definido para essa escolha.

[078] Outro esquema avançado é fornecido, chamado Fusão de Tabela de Delta de Paleta de Cores Vizinha. Para geração de delta de paleta adaptativa, um codificador pode usar um delta de paleta a partir da CU superior ou esquerda como o ponto de partida inicial. Para ge- ração de paleta não adaptativa, o codificador também pode usar um delta de paleta a partir da CU superior ou esquerda e comparar o cus- to RD entre a CU superior, esquerda e atual.

[079] Um delta_color_table_merge_flag é definido para indicar se uma CU atual usa a tabela de delta de paleta de cores a partir de sua CU esquerda ou superior. Uma CU atual transporta a sinalização de tabela de delta de paleta de cores explicitamente apenas quando delta_color_table_adaptive_flag==0 e del- ta_color_table_merge_flag==0 ao mesmo tempo.

[080] Para um processo de fusão, se del- ta_color_table_merge_flag é declarado, outro del- ta_color_table_merge_direction é definido para indicar se o candidato à fusão é da CU superior ou esquerda.

[081] Um exemplo de um processo de codificação para uma ge- ração de delta de paleta adaptativa é mostrado como segue. Em um lado de decodificação, sempre que um decodificador recebe um dado literal, o mesmo regera um delta de paleta com base em etapas inver- sas.

[082] 10. Definir palette_table[] e palette_count[]

[083] 11. Inicializar palette_table(n) = n (n = 0…255), alternati- vamente, pode-se usar palette_table[] da CU superior ou esquerda como valor inicial

[084] 12. Inicializar palette_count(n) = 0 (n = 0…255), alternati- vamente, pode-se usar palette_count[] da CU superior ou esquerda como valor inicial

[085] 13. Para qualquer valor de delta c':

[086] 1) Localizar n para que palette_table(n) == delta c'

[087] 2) Usar n como o novo índice de delta c'

[088] 3) ++palette_count(n)

[089] 4) Classificar palette_count[] para que o mesmo fique em ordem descendente

[090] 5) Classificar palette_table[] em conformidade

[091] 14. Voltar para a etapa 1 até que todos os delta c' na LCU atual sejam processados

[092] Para qualquer bloco que inclua tanto texto quanto gráfi- cos, um sinalizador de máscara é usado para separar a seção de texto e a seção de gráficos. A seção de texto é comprimida pelo método descrito acima; a seção de gráficos é comprimida por outro método de compressão.

[093] Deve ser observado que, devido ao fato de que o valor de qualquer pixel coberto pelo sinalizador de máscara foi codificado por uma camada de texto sem perdas, esses pixels na seção de gráficos podem ser como "pixel sem preocupação". Quando a seção de gráfi- cos é comprimida, qualquer valor arbitrário pode ser atribuído a um pixel a fim de obter eficiência de compressão ideal.

[094] Uma vez que a parte com perdas poderia ser tratada pela derivação de tabela de paleta de cores, o mapa de índices tem que ser comprimido sem perdas. Isso permite o processamento eficiente com o uso de uma correspondência de cadeia de caracteres 1D ou 2D. Pa- ra esta revelação, a correspondência de cadeia de caracteres 1D ou 2D é restrita à LCU atual, mas a janela de pesquisa pode se estender além da LCU atual. Também deve ser observado que a distância cor- respondida pode ser codificada com o uso de um par de vetores de movimento nas direções horizontal e vertical, isto é, (MVy=matched_distance/cuWidth, MVy=matched_distance- cuWidth*MVy).

[095] Dado que a imagem teria uma diferente orientação de tex- tura espacial em regiões locais, a pesquisa 1D pode ser permitida nas direções horizontal ou vertical definindo-se o indicador co- lor_idx_map_pred_direction. A direção de varredura de índice ideal pode ser feita com base no custo R-D. A Figura 6 mostra as direções de varredura, que iniciam a partir da primeira posição. É ilustrado adi- cionalmente o padrão de varredura horizontal e vertical na Figura 9. Considera-se uma CU de 8x8 como um exemplo. O derive- MatchPairs() e as etapas de codificação de entropia associadas são realizadas duas vezes para o padrão de varredura tanto horizontal quanto vertical. Desse modo, a direção de varredura final é escolhida com o menor custo RD. Binarização Aprimorada

[096] Conforme mostrado na Figura 13, a tabela de paleta de cores e um par de informações correspondidas para o mapa de índice de cores são codificados. Os mesmos são codificados com o uso de binarização de comprimento fixo. Alternativamente, binarização de comprimento variável pode ser usada.

[097] Por exemplo, para a codificação da tabela de paleta de cores, a tabela pode ter 8 valores de cor diferentes. Portanto, a mesma contém apenas 8 índices diferentes no mapa de índice de cores. Em vez de usar 3 binários fixos para codificar cada valor de índice igual- mente, apenas um bit pode ser usado para representar o pixel antece- dente, por exemplo, 0. Em seguida, os 7 valores de pixel restantes usam uma palavra de código de comprimento fixo, tal como 1000, 1001, 1010, 1011, 1100, 1101 e 1110, para codificar o índice de cor. Isso é baseado no fato de que a cor antecedente pode ocupar o maior percentual e, portanto, uma palavra de código especial para a mesma economiza os binários totais. Esse cenário acontece comumente para conteúdo de tela. Considerando-se uma CU de 16x16, para binariza- ção de 3 binários fixos, a mesma exige 3x16x16=768 binários. Tam- bém, deixar o índice 0 ser cor antecedente, o que ocupa 40%, enquan- to outras cores são distribuídas igualmente. Nesse caso, a mesma exige apenas 2,8x16x16<768 binários.

[098] Para a codificação de par correspondido, o valor máximo pode ser usado para limitar sua binarização, dada a implantação restri- ta dessa abordagem dentro da área da CU atual. Matematicamente, a distância e o comprimento correspondidos poderiam ser tão longos quanto 64x64=4K em cada caso. No entanto, isso não poderia aconte- cer conjuntamente. Para cada posição correspondida, a distância cor- respondida é limitada pela distância entre a posição atual e a primeira posição no armazenamento temporário de referência (tal como a pri- meira posição na CU atual, como um exemplo), por exemplo, L. Por-

tanto, os binários máximos para essa binarização de distância é log2(L)+1 (em vez de comprimento fixo), e os binários máximos para a binarização de comprimento é log2(cuSize-L)+1 com cuSi- ze=cuWidth*cuHeight.

[099] Além disso, para a tabela de paleta de cores e mapa de índices, a codificação de resíduo poderia ser significativamente apri- morada por um método de binarização diferente. Como para a versão de HEVC RExt e HEVC, o coeficiente de transformada é binarização com o uso dos códigos de comprimento variável na premissa de que a magnitude do resíduo deve ser pequena após a previsão, transforma- da e quantização. No entanto, após introduzir o salto de transformada, especialmente para o salto de transformada no conteúdo de tela com cor distinta, comumente existem resíduos com valor maior e aleatório (não próximo ao valor menor relativo "1", "2", "0"). Se a binarização de coeficientes de HEVC atual for usada, a mesma acaba por produzir uma palavra de código muito longa. Alternativamente, o uso da binari- zação de comprimento economiza o comprimento de código para os resíduos produzidos pelo modo de codificação de tabela de paleta de cores e índice. Amostragem de Chroma Adaptativa para Conteúdo Misto

[0100] O exposto acima fornece várias técnicas para codificação de conteúdo de tela de alta eficiência sob a estrutura do HEVC/HEVC- RExt. Na prática, além de conteúdo de tela puro (tal como texto, gráfi- cos) ou vídeo natural puro, também há conteúdo que contém tanto ma- terial de tela quanto vídeo natural capturado por câmera -- chamado conteúdo misto. Atualmente, conteúdo misto é tratado com amostra- gem de chroma de 4:4:4. No entanto, para a porção de vídeo natural capturado por câmera embutida nesse conteúdo misto, a amostragem de chroma de 4:2:0 pode ser suficiente para fornecer qualidade sem perda de percepção. Isso é devido ao fato de que o sistema de visão humano é menos sensível às mudanças espaciais em componentes de chroma comparada àquela dos componentes de luma. Consequen- temente, a subamostragem é realizada tipicamente na parte de chro- ma (por exemplo, o formato de vídeo 4:2:0 popular) para alcançar re- dução de taxa de bits considerável ao mesmo tempo em que manten- do a mesma qualidade reconstruída.

[0101] A presente revelação fornece um sinalizador novo (isto é, enable_chroma_subsampling) que é definido e sinalizado no nível de CU recursivamente. Para cada CU, o codificador determina se a mes- ma está sendo codificada com o uso de 4:2:0 ou 4:4:4 de acordo com o custo taxa-distorção.

[0102] Em A Figura 14A e na Figura 14B são mostrados os for- matos de amostragem de chroma 4:2:0 e 4:4:4.

[0103] No lado do codificador, para cada CU, assumindo-se que a entrada é fonte de 4:4:4 mostrada acima, o custo taxa-distorção é derivado diretamente com o uso do procedimento de codificação de 4:4:4 com enable_chroma_subsampling = 0 ou FALSO. Em seguida, o processo subamostras de 4:4:4 faz amostragem para 4:2:0 para deri- var seu consumo de bits. O formato 4:2:0 reconstruído é interpolado de volta para o formato 4:4:4 para medição de distorção (com o uso de SSE/SAD). Juntamente com o consumo de bits, o custo taxa-distorção é derivado quando se codifica a CU em espaço de 4:2:0 e se compara o mesmo com o custo quando se codifica a CU em 4:4:4. Qualquer codificação que forneça o menor custo taxa-distorção será escolhida para a codificação final.

[0104] Na Figura 15 é ilustrado o processo de interpolação de 4:4:4 para 4:2:0 e vice-versa. Usualmente esse processo conversão de formato de amostragem de cor de vídeo exige um grande número de filtros de interpolação.

[0105] Para reduzir a complexidade da implantação, um filtro de interpolação de HEVC (isto é, DCT-IF) pode ser utilizado. Conforme mostrado na Figura 15, a "caixa quadrada" representa as amostras 4:4:4 originais. De 4:4:4 para 4:2:0, os pixels de meio pel ("círculo") são interpolados com o uso de DCT-IF verticalmente para os compo- nentes de chroma. Também são mostradas as posições de quarto de pel ("diamante") para fins de ilustração. Os "círculos" sombreados de cinza são escolhidos para formar as amostras de 4:2:0. Para a interpo- lação de 4:2:0 para 4:4:4, o processo inicia com os "círculos" cinza nos componentes de chroma, as posições de meio pel são interpoladas horizontalmente para obter todos "círculos", e, então, as "caixas qua- drada" são interpoladas com o uso de DCT-IF verticalmente. Todas as "caixas quadradas" interpoladas são escolhidas para formar a fonte 4:4:4 reconstruída. Controle do Codificador

[0106] Como discutido nas seções anteriores, são revelados si- nalizadores para controlar o processamento de baixo nível. Por exem- plo, enable_packed_component_flag é usado para indicar se a CU atual usa seu formato compactado ou formato plano convencional para codificar o processamento. Se permitir um formato compactado pode- ria depender do custo R-D calculado no codificador. Para uma implan- tação de codificador prática, uma solução de baixa complexidade é obtida analisando-se o histograma da CU e encontrando-se o melhor limiar para a decisão, conforme mostrado na Figura 3.

[0107] O tamanho da tabela de paleta de cores tem um impacto direto sobre a complexidade. maxColorNum é introduzido para contro- lar o compromisso entre complexidade e eficiência de codificação. A forma mais direta é escolher o que produz o menor custo R-D.

[0108] A direção de codificação do mapa de índices poderia ser determinada pela otimização de R-D, ou com o uso da orientação es- pacial local (tal como operador de Sobel com base em estimativa de direção).

[0109] Esta revelação limita o processamento dentro de cada CTU/CU. Na prática, essa restrição pode ser relaxada. Por exemplo, para um processamento de mapa de índice de cores, o armazenamen- to temporário de linha de suas CUs superior e esquerda pode ser usa- do, conforme mostrado na Figura 16. Com um armazenamento tempo- rário superior e esquerdo, a pesquisa pode ser estendida para aprimo- rar adicionalmente a eficiência de codificação. Dado que os armaze- namentos temporários superior/esquerdo são formados com o uso dos pixels reconstruídos a partir de CUs vizinhas, esses pixels (bem como seus índices correspondentes) são disponível para referência antes de processar o mapa de índices da CU atual. Por exemplo, após a reor- denação, o mapa de índices da CU atual poderia ser 14, 14, 14, …. 1, 2, 1 (como apresentação de 1D). Sem uma referência de armazena- mento temporário de linha, o primeiro "14" será codificado como um par não correspondido. No entanto, com um armazenamento temporá- rio de linha vizinha, a correspondência de cadeia de caracteres pode iniciar no primeiro pixel, conforme mostrado abaixo (padrões de varre- dura horizontal e vertical também são mostrados). Sintaxe de Decodificador

[0110] As informações a seguir podem ser usadas para descre- ver o decodificador mostrado na Figura 2. A sintaxe desta revelação é alinhada com um comitê de redação de HEVC RExt.

7.3.5.8 Sintaxe de unidade de codificação:

[0111] A Figura 17 ilustra o aparelho e métodos/fluxos incorpora- do ao HEVC atual.

[0112] Os métodos/fluxos e dispositivos identificados acima po- dem ser incorporados em uma rede de comunicações sem fio ou por fio, ou combinação das mesmas, e implantados em dispositivos, tais como os descritos abaixo, e nos desenhos abaixo:

[0113] A Figura 18 ilustra um sistema de comunicação exemplifi- cativo 100 que usa sinalização para suportar receptores sem fio avan- çados de acordo com esta revelação. Em geral, o sistema 100 permite que múltiplos usuários sem fio transmitam e recebam dados e outro conteúdo. O sistema 100 pode implantar um ou mais métodos acesso ao canal, tais como acesso múltiplo por divisão de código (CDMA), acesso múltiplo por divisão de tempo (TDMA), acesso múltiplo por di- visão de frequência (FDMA), FDMA ortogonal (OFDMA), ou FDMA de portadora única (SC-FDMA).

[0114] Nesse exemplo, o sistema de comunicação 100 inclui equipamento de usuário (UE) 110a a 110c, redes de acesso de rádio (RANs) 120a e 120b, uma rede principal 130, uma rede telefônica co-

mutada pública (PSTN) 140, a Internet 150, e outras redes 160. Embo- ra certos números desses componentes ou elementos sejam mostra- dos na Figura 18, qualquer número desses componentes ou elemen- tos pode ser incluído no sistema 100.

[0115] Os UEs 110a a 110c são configurados para operar e/ou se comunicar no sistema 100. Por exemplo, os UEs 110a a 110c são configurados para transmitir e/ou receber sinais sem fio ou sinais por fio. Cada UE 110a a 110c representa qualquer dispositivo de usuário final adequado e pode incluir esses dispositivos (ou pode ser denomi- nado) como um equipamento/dispositivo de usuário (UE), unidade de transmissão/recepção sem fio (WTRU), estação móvel, unidade de assinante fixa ou móvel, dispositivo de mensagens, telefone celular, assistente digital pessoal (PDA), telefone inteligente, computador do tipo laptop, computador, dispositivo sensível ao toque, sensor sem fio, ou dispositivo eletrônico de consumo.

[0116] As RANs 120a e 120b, aqui, incluem estações base 170a e 170b, respectivamente. Cada estação base 170a e 170b é configu- rada para fazer interface sem fio com um ou mais dos UEs 110a a 110c para permitir acesso à rede principal 130, à PSTN 140, à Internet 150, e/ou à outras redes 160. Por exemplo, as estações base 170a e 170b podem incluir (or ser) um ou mais de diversos dispositivos bem conhecidos, tais como uma estação base de transceptor (BTS), um Nó-B (NodeB), um NodeB evoluído (eNodeB), um NodeB residencial, um eNodeB residencial, um controlador de sítio, um ponto de acesso (AP), ou um roteador sem fio, ou um servidor, roteador, comutador, ou outra entidade de processamento com uma rede por fio ou sem fio.

[0117] Na modalidade mostrada na Figura 18, a estação base 170a faz parte da RAN 120a, que pode incluir outras estações base, elementos e/ou dispositivos. Além disso, a estação base 170b faz par- te da RAN 120b, que pode incluir outras estações base, elementos e/ou dispositivos. Cada estação base 170a e 170b opera para transmi- tir e/ou receber sinais sem fio dentro de uma região ou área geográfica particular, algumas vezes denominada como uma "célula". Em algu- mas modalidades, pode ser empregada tecnologia de múltiplas entra- das e múltiplas saídas (MIMO) que tem múltiplos transceptores para cada célula.

[0118] As estações base 170a e 170b se comunicam com um ou mais dos UEs 110a a 110c por uma ou mais interfaces por ar 190 com o uso de enlaces de comunicação sem fio. As interfaces por ar 190 podem utilizar qualquer tecnologia de acesso de rádio adequada.

[0119] É contemplado que o sistema 100 possa usar funcionali- dade de acesso de múltiplos canais, que inclui esses esquemas como descritos acima. Em modalidades particulares, as estações base e os UEs implantam LTE, LTE-A e/ou LTE-B. Naturalmente, outros esque- mas de acesso múltiplo e protocolos sem fio podem ser utilizados.

[0120] As RANs 120a e 120b ficam em comunicação com a rede principal 130 para fornecer para os UEs 110a a 110c voz, dados, apli- cação, Protocolo de Voz sobre Internet (VoIP), ou outros serviços. Compreensivelmente, as RANs 120a e 120b e/ou a rede principal 130 podem ficar em comunicação direta ou indireta com outras uma ou mais RANs (não mostradas). A rede principal 130 também pode servir como uma porta de acesso para outras redes (tais como PSTN 140, Internet 150 e outras redes 160). Além disso, alguns ou todos os UEs 110a a 110c podem incluir funcionalidade para comunicação com dife- rentes redes sem fio por enlaces sem fio diferentes com o uso de tec- nologias e/ou protocolos sem fio diferentes.

[0121] Embora a Figura 18 ilustre um exemplo de um sistema de comunicação, várias mudanças podem ser feitas à Figura 18. Por exemplo, o sistema de comunicação 100 poderia incluir qualquer nú- mero de UEs, estações base, redes ou outros componentes em qual-

quer configuração adequada, e pode, adicionalmente, incluir o EPC ilustrado em qualquer das Figuras no presente documento.

[0122] As Figuras 19A e 19B ilustram dispositivos exemplificati- vos que podem implantar os métodos e ensinamentos de acordo com esta revelação. Em particular, A Figura 19A ilustra um UE exemplifica- tivo 110, e a Figura 19B ilustra uma estação base exemplificativa 170. Esses componentes poderiam ser usados no sistema 100 ou em qual- quer outro sistema adequado.

[0123] Conforme mostrado na Figura 19A, o UE 110 inclui pelo menos uma unidade de processamento 200. A unidade de processa- mento 200 implanta várias operações de processamento do UE 110. Por exemplo, a unidade de processamento 200 poderia realizar codifi- cação de sinal, processamento de dados, controle de potência, pro- cessamento de entrada/saída ou qualquer outra funcionalidade que permita que o UE 110 opere no sistema 100. A unidade de processa- mento 200 também suporta os métodos e ensinamentos descritos em mais detalhes acima. Cada unidade de processamento 200 inclui qualquer dispositivo de processamento ou de computação adequado configurado para realizar uma ou mais operações. Cada unidade de processamento 200 poderia, por exemplo, incluir um microprocessa- dor, microcontrolador, processador de sinal digital, matriz de portas programáveis no campo, ou circuito integrado de aplicação específica.

[0124] O UE 110 também inclui pelo menos um transceptor 202. O transceptor 202 é configurado para modular dados ou outro conteú- do para transmissão por pelo menos uma antena 204. O transceptor 202 também é configurado para demodular dados ou outro conteúdo recebido pela pelo menos uma antena 204. Cada transceptor 202 in- clui qualquer estrutura adequada para gerar sinais para transmissão sem fio e/ou processamento de sinais recebidos sem fio. Cada antena 204 inclui qualquer estrutura adequada para transmitir e/ou receber sinais sem fio. Um ou múltiplos transceptores 202 poderiam ser usa- dos no UE 110, e uma ou múltiplos antenas 204 poderiam ser usadas no UE 110. Embora mostrado como uma única unidade funcional, um transceptor 202 também poderia ser implantado com o uso de pelo menos um transmissor e pelo menos um receptor separado.

[0125] O UE 110 inclui adicionalmente um ou mais dispositivos de entrada/saída 206. Os dispositivos de entrada/saída 206 facilitam a interação com um usuário. Cada dispositivo de entrada/saída 206 in- clui qualquer estrutura adequada para fornecer informações para ou receber informações de um usuário, tal como um alto-falante, microfo- ne, teclado numérico, teclado, viso, ou tela sensível ao toque.

[0126] Além disso, o UE 110 inclui pelo menos uma memória

208. A memória 208 armazena instruções e dados usados, gerados ou coletados pelo UE 110. Por exemplo, a memória 208 poderia armaze- nar instruções de software ou firmware executadas por a(s) unidade(s) de processamento 200 e dados usados para reduzir ou eliminar inter- ferência em sinais recebidos. Cada memória 208 inclui qual- quer(quaisquer) dispositivo(s) de armazenamento e recuperação volá- til(voláteis) e/ou não volátil(voláteis) adequado(s). Qualquer tipo de memória adequado pode ser usado, tal como memória de acesso aleatório (RAM), memória somente de leitura (ROM), disco rígido, dis- co óptico, cartão de módulo de identidade de assinante (SIM), cartão de memória, cartão de memória digital segura (SD), e similares.

[0127] Conforme mostrado na Figura 19B, a estação base 170 inclui pelo menos uma unidade de processamento 250, pelo menos um transmissor 252, pelo menos um receptor 254, uma ou mais ante- nas 256 e pelo menos uma memória 258. A unidade de processamen- to 250 implanta várias operações de processamento da estação base 170, tais como codificação de sinal, processamento de dados, controle de potência, processamento de entrada/saída ou qualquer outra funci-

onalidade. A unidade de processamento 250 também pode suportar os métodos e ensinamentos descritos em mais detalhes acima. Cada unidade de processamento 250 inclui qualquer dispositivo de proces- samento ou computação adequado configurado para realizar uma ou mais operações. Cada unidade de processamento 250 poderia, por exemplo, incluir um microprocessador, microcontrolador, processador de sinal digital, matriz de portas programáveis no campo ou circuito integrado de aplicação específica.

[0128] Cada transmissor 252 inclui qualquer estrutura adequada para gerar sinais para transmissão sem fio para um ou mais UEs ou outros dispositivos. Cada receptor 254 inclui qualquer estrutura ade- quada para processar sinais recebidos sem fio a partir de um ou mais UEs ou outros dispositivos. Embora mostrado como componentes se- parados, pelo menos um transmissor 252 e pelo menos um receptor 254 poderiam ser combinados em um transceptor. Cada antena 256 inclui qualquer estrutura adequada para transmitir e/ou receber sinais sem fio. Embora uma antena comum 256 seja mostrada aqui como sendo acoplada tanto ao transmissor 252 quanto ao receptor 254, uma ou mais antenas 256 poderiam ser acopladas ao(s) transmissor(es) 252, e uma ou mais antenas separadas 256 poderiam ser acopladas ao(s) receptor(es) 254. Cada memória 258 inclui qualquer(quaisquer) dispositivo(s) de armazenamento e recuperação volátil(voláteis) e/ou não volátil(voláteis) adequado(s).

[0129] Detalhes adicionais com respeito às UEs 110 e estações base 170 são conhecidos das pessoas versadas na técnica. Assim sendo, esses detalhes são omitidos aqui por motivos de clareza.

[0130] Pode ser vantajoso para apresentar definições de certas palavras e expressões usadas nesse documento de patente. Os ter- mos "inclui" e "compreende", bem como derivados dos mesmos, signi- ficam inclusão sem limitação. O termo "ou" é inclusivo e significa e/ou.

As expressões "associado a" e "associado ao mesmo", bem como de- rivados das mesmas, significa incluir, ser incluído dentro de, interco- nectar com, conter, ser contido dentro de, conectar a ou com, acoplar a ou com, ser comunicável com, cooperar com, intercalar, justapor, estar próximo de, ser limitado a ou por, ter, ter uma propriedade de, ou similares.

[0131] Embora esta revelação tenha descrito certas modalidades e métodos associados genéricos, alterações e permutações dessas modalidades e métodos ficarão evidentes para as pessoas versadas na técnica. Consequentemente, a descrição acima de modalidades exemplificativas não define ou limita esta revelação. Outras mudanças, substituições e alterações também são possíveis sem se afastar do espírito e escopo desta revelação, conforme definido pelas concretiza- ções a seguir.

Claims (24)

REIVINDICAÇÕES

1. Método para codificar conteúdo de tela em um fluxo de bits, caracterizado pelo fato de que o método compreende as etapas de: dividir o conteúdo de tela em uma pluralidade de unidades de codificação (CUs), em que cada CU compreende uma pluralidade de pixels e em que cada pixel tem uma valor numérico; criar uma tabela de paleta de cores para uma primeira uni- dade de codificação (CU) da pluralidade de CUs, em que a paleta de cores compreende uma pluralidade de entradas, e em que a pluralida- de de entradas indica os valores numéricos mais frequentes da plurali- dade de pixels da primeira CU; criar um primeiro mapa de índice de cores para a primeira CU, o primeiro mapa de índice de cores compreendendo uma entrada para cada pixel da primeira CU, em que cada entrada no mapa de ín- dice de cores compreende um índice dentro da tabela de paleta de co- res; criar um segundo mapa de índice de cores para uma se- gunda CU da pluralidade de CUs, o segundo mapa de índice de cores compreendendo uma entrada para cada pixel na segunda CU, em que cada entrada no segundo mapa de índice de cores compreende um índice dentro da tabela de paleta de cores; criar uma primeira tabela residual de predição compreen- dendo uma entrada para cada pixel na primeira CU, em que cada en- trada na primeira tabela residual de predição compreende a diferença entre o valor numérico da entrada da tabela paleta de cores corres- pondendo à entrada de primeiro mapa de índice de cores para aquele pixel e o valor numérico daquele pixel; criar uma segunda tabela residual de predição compreen- dendo uma entrada para cada pixel na segunda CU, em que cada en-

trada na segunda tabela residual de predição compreende uma dife- rença entre o valor numérico da entrada de tabela de paleta de cores correspondendo à entrada de segundo mapa de índice de cores para aquele pixel e o valor numérico daquele pixel; e codificar a tabela de paleta de cores, o primeiro mapa de índice de cores, o segundo mapa de índice de cores, a primeira tabela residual de predição, e a segunda tabela residual de predição em um fluxo de bits.

2. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que o método é processado usando um formato de cor plano.

3. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que a tabela de paleta de cores é derivada a partir de uma CU vizinha usando uma CU reconstruída em um domínio de pixel.

4. Método, de acordo com a reivindicação 3, caracterizado pelo fato de que ainda compreende a etapa de gerar uma tabela de paleta de cores da CU vizinha com base em pixels reconstruídos dis- poníveis, em que a CU vizinha tem profundidade e tamanho diferentes do que a primeira CU.

5. Método, de acordo com a reivindicação 3, caracterizado pelo fato de que ainda compreende a etapa de gerar a tabela de pale- ta de cores da CU vizinha com base em pixels reconstruídos disponí- veis, em que a CU vizinha tem mesmos profundidade e tamanho que a primeira CU.

6. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que gerar a tabela de paleta de cores compreende criar um histograma de valores numéricos da pluralidade de pixels na pri- meira CU, ordenar o histograma do valor numérico mais frequente pa- ra o valor numérico menos frequente, e criar uma entrada na tabela de paleta de cores para o valor numérico mais frequente.

7. Método, de acordo com a reivindicação 6, caracterizado pelo fato de que gerar o primeiro mapa de índice de cores compreen- de comparar o valor numérico de cada pixel na primeira CU com cada entrada de tabela de paleta de cores e criar uma entrada no primeiro mapa de índice de cores para cada pixel na primeira CU, em que a en- trada no primeiro mapa de índice de cores corresponde à entrada de tabela de paleta de cores cujo valor mais se aproxima do valor numéri- co daquele pixel, em que gerar o segundo mapa de índice de cores compreende comparar o valor numérico de cada pixel na segunda CU com cada entrada de tabela de paleta de cores e criar uma entrada no segundo mapa de índice de cores para cada pixel na segunda CU, em que a entrada no segundo mapa de índice de cores corresponde à en- trada de tabela de paleta de cores cujo valor mais se aproxima do va- lor numérico daquele pixel.

8. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que ainda compreende a etapa de codificar um tamanho da tabela de paleta de cores no fluxo de bits.

9. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que ainda compreende a etapa de codificar um indicador de uma relação espacial entre a primeira CU e a segunda CU dentro do conteúdo de tela no fluxo de bits.

10. Método, de acordo com a reivindicação 1, caracteriza- do pelo fato de que codificar o primeiro mapa de índice de cores compreende executar uma operação matemática de cadeia de carac- teres de uma dimensão, em que a operação matemática de cadeia de caracteres pesquisa por correspondências em uma única direção, e em que uma correspondência de cadeia de caracteres é sinalizada usando pares correspondentes.

11. Método, de acordo com a reivindicação 10, caracteri- zado pelo fato de que a operação matemática de cadeia de caracte-

res é executada em uma pluralidade de pixels adjacentes usando um método de hash de execução.

12. Método, de acordo com a reivindicação 1, caracteriza- do pelo fato de que o método é processado usando um formato de cor intercalado.

13. Método, de acordo com a reivindicação 1, caracteriza- do pelo fato de que gerar a tabela de paleta de cores ainda compre- ende criar uma entrada de tabela de paleta de cores para cada valor numérico único encontrado na pluralidade de pixel na primeira CU.

14. Método, de acordo com a reivindicação 1, caracteriza- do pelo fato de que codificar o primeiro mapa de índice de cores compreende executar uma operação matemática de cadeia de carac- teres de duas dimensões, em que codificar o segundo mapa de índice de cores compreende executar a operação matemática de cadeia de caracteres de duas dimensões, em que a operação matemática de ca- deia de caracteres de duas dimensões pesquisa por correspondências em uma única direção por dimensão, e em que uma correspondência de cadeia de caracteres é sinalizada usando pares correspondentes.

15. Método, de acordo com a reivindicação 14, caracteri- zado pelo fato de que a operação matemática de cadeia de caracte- res é executada em um bloco retangular de pixels adjacentes usando um método de hash de execução.

16. Método, de acordo com a reivindicação 1, caracteriza- do pelo fato de que codificar o primeiro mapa de índice de cores compreende executar uma operação matemática de cadeia de carac- teres de uma dimensão hibrida, em que codificar o segundo mapa de índice de cores compreende executar a operação matemática de ca- deia de caracteres de uma dimensão hibrida, em que a operação ma- temática de cadeia de caracteres de uma dimensão hibrida pesquisa por correspondências em duas direções por dimensão, e em que uma correspondência de cadeia de caracteres é sinalizada usando pares correspondentes.

17. Método, de acordo com a reivindicação 16, caracteri- zado pelo fato de que a operação matemática de cadeia de caracte- res é executada em um bloco retangular de pixels adjacentes usando um método de hash de execução.

18. Método, de acordo com a reivindicação 1, caracteriza- do pelo fato de que, para uma primeira entrada no primeiro mapa de índice de cores para a primeira CU: executar uma primeira pesquisa em uma direção vertical por uma primeira cadeia de caracteres de entradas no primeiro mapa de índice de cores, em que cada entrada na primeira cadeia de carac- teres tem o mesmo valor que a primeira entrada; executar uma segunda pesquisa em uma direção horizontal por uma segunda cadeia de caracteres de entradas no primeiro mapa de índice de cores, em que cada entrada na segunda cadeia de carac- teres tem o mesmo valor que a primeira entrada; e codificar uma porção do primeiro mapa de índice de cores de acordo com os resultados da primeira pesquisa e da segunda pes- quisa, em que codificar compreende inserção, no fluxo de bits, de um sinalizador de direção de pesquisa, um indicador do valor de índice da primeira entrada, e um indicador do comprimento da cadeia de carac- teres de entradas no primeiro mapa de índice de cores tendo o mesmo valor de índice que a primeira entrada.

19. Método, de acordo com a reivindicação 18, caracteri- zado pelo fato de que codificar uma porção do primeiro mapa de índi- ce de cores de acordo com os resultados da primeira pesquisa e da segunda pesquisa ainda compreende: determinar o custo de taxa-distorção (RD) associado a codi- ficar a primeira cadeia de caracteres; e determinar o custo de RD associado a codificar a segunda cadeia de caracteres, em que, quando o custo de RD associado a codificar a pri- meira cadeira de caracteres é menor do que o custo de RD associado a codificar a segunda cadeira de caracteres, o sinalizador de direção indica a direção vertical e o indicador do comprimento da cadeia de caracteres de entradas no mapa de índice é um indicador do compri- mento da primeira cadeia de caracteres, e em que, quando o custo de RD associado a codificar a se- gunda cadeira de caracteres é menor do que o custo de RD associado a codificar a primeira cadeira de caracteres, o sinalizador de direção indica a direção horizontal e o indicador do comprimento da cadeia de caracteres de entradas no mapa de índice é um indicador do compri- mento da segunda cadeia de caracteres.

20. Sistema para codificar conteúdo de tela em um fluxo de bits, o sistema compreendendo: uma memória compreendendo uma pluralidade de unida- des de codificação (CUs), em que a pluralidade de CUs representa o conteúdo de tela, em que cada CU compreende uma pluralidade de pixels, e em que cada pixel tem uma valor numérico; e um processa- dor (12) acoplado à memória, caracterizado pelo fato de que o pro- cessador (12) é configurado para: criar uma tabela de paleta de cores para uma CU da plura- lidade de CUs, em que a paleta de cores compreende uma pluralidade de entradas, em que a pluralidade de entradas indica os valores numé- ricos mais frequentes da pluralidade de pixels da primeira CU; criar um primeiro mapa de índice de cores para a primeira CU, o primeiro mapa de índice de cores compreendendo uma entrada para cada pixel da primeira CU, em que cada entrada no mapa de ín- dice de cores compreende um índice dentro da tabela de paleta de co-

res; criar um segundo mapa de índice de cores para uma se- gunda CU da pluralidade de CUs, o segundo mapa de índice de cores compreendendo uma entrada para cada pixel na segunda CU, em que cada entrada no segundo mapa de índice de cores compreende um índice dentro da tabela de paleta de cores; criar uma primeira tabela residual de predição, a primeira tabela residual de predição compreendendo uma entrada para cada pixel na primeira CU, em que cada entrada na primeira tabela residual de predição compreende a diferença entre o valor de tabela paleta de cores correspondendo à entrada de primeiro mapa de índice de cores para aquele pixel e o valor numérico daquele pixel; criar uma segunda tabela residual de predição, a segunda tabela residual de predição compreendendo uma entrada para cada pixel na segunda CU, em que cada entrada na segunda tabela residual de predição compreende uma diferença entre o valor de tabela de pa- leta de cores correspondendo à entrada de segundo mapa de índice de cores para aquele pixel e o valor numérico daquele pixel; e codificar a tabela de paleta de cores, o primeiro mapa de índice de cores, a primeira tabela residual de predição, a segunda ta- bela residual de predição, e o segundo mapa de índice de cores em um fluxo de bits.

21. Sistema, de acordo com a reivindicação 20, caracteri- zado pelo fato de que as CUs representam o conteúdo de tela usan- do um formato de cor plano.

22. Sistema, de acordo com a reivindicação 20, caracteri- zado pelo fato de que as CUs representam o conteúdo de tela usan- do um formato de cor intercalado.

23. Sistema, de acordo com a reivindicação 20, caracteri- zado pelo fato de que o processador (12) é ainda configurado para criar a tabela de paleta de cores ao criar um histograma de valores numéricos da pluralidade de pixels na primeira CU, ordenar o histo- grama do valor numérico mais frequente para o valor numérico menos frequente, e criar uma entrada na tabela de paleta de cores para o va- lor numérico mais frequente.

24. Sistema, de acordo com a reivindicação 20, caracteri- zado pelo fato de que o processador (12) é ainda configurado para gerar o primeiro mapa de índice de cores ao comparar o valor numéri- co de cada pixel na primeira CU com cada entrada de tabela de paleta de cores e criar uma entrada no primeiro mapa de índice de cores para cada pixel na primeira CU, em que a entrada no primeiro mapa de ín- dice de cores corresponde à entrada de tabela de paleta de cores cujo valor mais se aproxima do valor numérico daquele pixel, em que o processador (12) é ainda configurado para gerar o segundo mapa de índice de cores compreende comparar o valor numérico de cada pixel na segunda CU com cada entrada de tabela de paleta de cores e criar uma entrada no segundo mapa de índice de cores para cada pixel na segunda CU, em que a entrada no segundo mapa de índice de cores corresponde à entrada de tabela de paleta de cores cujo valor mais se aproxima do valor numérico daquele pixel.