BR102021006869A2 - Método de transformada hardware-friendly em codecs para nuvens de pontos plenópticos - Google Patents

Método de transformada hardware-friendly em codecs para nuvens de pontos plenópticos Download PDF

Info

Publication number
BR102021006869A2
BR102021006869A2 BR102021006869-8A BR102021006869A BR102021006869A2 BR 102021006869 A2 BR102021006869 A2 BR 102021006869A2 BR 102021006869 A BR102021006869 A BR 102021006869A BR 102021006869 A2 BR102021006869 A2 BR 102021006869A2
Authority
BR
Brazil
Prior art keywords
transform
vector
matrix
plenoptic
point
Prior art date
Application number
BR102021006869-8A
Other languages
English (en)
Inventor
Ismael Seidel
Diogo C. Garcia
Ricardo L. de Queiroz
Camilo C. Dorea
Renan U. B. Ferreira
Davi R. Freitas
Rogério Higa
Vanessa Testoni
Original Assignee
Samsung Eletrônica da Amazônia Ltda.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Samsung Eletrônica da Amazônia Ltda. filed Critical Samsung Eletrônica da Amazônia Ltda.
Priority to BR102021006869-8A priority Critical patent/BR102021006869A2/pt
Priority to US17/405,682 priority patent/US11638035B2/en
Publication of BR102021006869A2 publication Critical patent/BR102021006869A2/pt

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/60Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06TIMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T9/00Image coding
    • G06T9/007Transform coding, e.g. discrete cosine transform
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/42Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by implementation details or hardware specially adapted for video compression or decompression, e.g. dedicated software implementation
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06TIMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T17/00Three dimensional [3D] modelling, e.g. data description of 3D objects
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06TIMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T2207/00Indexing scheme for image analysis or image enhancement
    • G06T2207/10Image acquisition modality
    • G06T2207/10028Range image; Depth image; 3D point clouds
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06TIMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T9/00Image coding
    • G06T9/001Model-based coding, e.g. wire frame

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Discrete Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)
  • Compression, Expansion, Code Conversion, And Decoders (AREA)

Abstract

A presente invenção diz respeito a um método de transformada hardware-friendly em codecs para nuvens de pontos plenópticos. Como o codec de compressão de nuvem de pontos baseado em vídeo existente (V-PCC) se baseia em codecs de vídeo de processadores multimídia incorporados em dispositivos móveis do tipo System-on-Chip (SoC), as etapas restantes do V-PCC devem ser o mais eficientes possível para garantir o consumo justo de energia. Neste sentido, o método busca reduzir a complexidade da transformada, utilizando-se de transformadas inteiras e impondo limites ao número de dimensões de transformada distintos, em que esses limites são concebidos de forma a minimizar as perdas de eficiência de codificação.

Description

MÉTODO DE TRANSFORMADA HARDWARE-FRIENDLY EM CODECS PARA NUVENS DE PONTOS PLENÓPTICOS Campo Técnico
transformada hardware-friendly em codecs para nuvens de pontos plenópticos. Como o codec de compressão de nuvem de pontos baseado em vídeo existente (V-PCC) se baseia em codecs de vídeo de processadores multimídia embarcados em dispositivos móveis do tipo System-on-Chip (SoC), as etapas restantes do V-PCC devem ser o mais eficientes possível para garantir o consumo justo de energia. Um acelerador de hardware dedicado pode ser cerca de 1000× mais energeticamente eficiente do que uma CPU de uso geral. Usando transformadas hardware-friendly, um codec de nuvens de pontos plenópticos pode ser facilmente integrado em dispositivos móveis.
[0002] A presente invenção pode ser implementada em vários dispositivos que utilizam nuvens de pontos, como, displays imersivos, smartphones holográficos, câmeras, dispositivos AR/VR/MR, Smart TV etc.
[0003] O método proposto nesta invenção busca reduzir a complexidade da transformada, utilizando-se de transformadas inteiras e impondo limites ao número de dimensões distintas na transformada. Ainda, essas limitações são concebidas de forma a minimizar as perdas de eficiência de codificação. Apesar de trazer benefícios para qualquer forma de implementação, o uso de um número limitado de transformadas inteiras tem suas vantagens mais significativas ao considerar aceleradores de hardware especialmente projetados para realizar a transformada. Nesses casos, o método proposto prevê transformadas que reduzem o consumo dinâmico de energia e a área de silício ocupada (relacionada à área de chip e, portanto, ao custo final de produção). Ambos os termos influenciam a eficiência energética da transformada sendo de extrema importância nos dispositivos móveis, dada a limitação energética imposta por suas baterias. Portanto, essa invenção garante um bom balanceamento entre eficiência de codificação e complexidade (eficiência energética).
Antecedentes
[0004] Nuvens de pontos têm sido usadas recentemente em aplicações que envolvem captura e renderização em tempo real de objetos 3D, uma vez que esta representação volumétrica permite uma experiência mais imersiva e é adequada para digitalizar objetos do mundo real. A representação mais comum de uma nuvem de pontos usa apenas uma única cor associada a cada ponto ou voxel, o que dá uma boa descrição da geometria e da textura. No entanto, essa representação não consegue capturar as reflexões naturais de luz dinâmica no objeto de forma realista. A luz refletida pode mudar com o ângulo de visualização, mas na representação de cor única todos os ângulos de visualização têm o mesmo valor de cor.
[0005] Uma representação mais completa, chamada nuvem de pontos plenópticos, foi proposta onde cada ponto tem uma cor associada em múltiplas direções. Na representação normal, a nuvem de pontos é descrita como coordenada espacial e uma cor. Para a nuvem de pontos plenópticos múltiplos atributos de cor são adicionados aos parâmetros de nuvens de pontos. Essa representação preserva as informações de cores dependentes da visualização. Todos os materiais que refletem a luz, como metais preciosos em joias, são exemplos de objetos que poderiam ser melhor representados pelas nuvens de pontos plenópticos. Outro exemplo são os objetos iridescentes, como conchas e algumas pinturas de carros.
[0006] No processo regular de geração de nuvem de pontos, as informações são capturadas por um conjunto de câmeras. As cores capturadas por essas câmeras são então combinadas para produzir uma única cor de ponto e as informações de cores dependentes de visualização são perdidas no processo. Portanto, o mesmo processo de captura pode ser usado para gerar as nuvens de pontos plenópticos. As informações de cores dependentes da visualização são então preservadas usando os múltiplos atributos.
[0007] As nuvens de pontos são tipicamente representadas por quantidades extremamente grandes de dados, o que é uma barreira significativa para aplicações de modo geral. No entanto, a relativa facilidade de capturar e tornar informações espaciais de nuvens de pontos em comparação com outras representações volumétricas de vídeo torna as nuvens de pontos cada vez mais populares para apresentar dados volumétricos imersivos. Portanto, o grupo de padronização MPEG 3DG trabalhou por muitos anos para comprimir eficientemente os dados de nuvens de pontos e lançou recentemente seu primeiro padrão, chamado V-PCC (Video-Based Point Clouds Compression).
[0008] A implementação do codificador V-PCC fornece uma compressão na faixa de 100:1 a 300:1 e, portanto, uma nuvem de pontos dinâmico de um milhão de pontos poderia ser codificada em 8 Mbit/s com boa qualidade perceptiva. A decodificação e renderização em tempo real de bitstreams VPCC também foi demonstrada em dispositivos móveis atuais. Devido a esse desempenho, espera-se que o V-PCC seja adotado com sucesso pelo mercado em breve.
[0009] Embora tenha havido algumas tentativas de comprimir nuvens de pontos plenópticos no grupo de padronização, o padrão atual só suporta a compressão das nuvens de pontos plenópticos tratando-as como múltiplos atributos individuais. O problema com essa abordagem é que a correlação entre as cores plenópticas não é explorada, impedindo que uma compressão eficiente seja alcançada. O uso de uma codificação híbrida (diferencial e de transformada) em cima do V-PCC aumenta a eficiência de codificação do VPCC em até 90% (BD-Rate) ao adotar uma Transformada Discreta dos Cossenos (DCT) de ponto flutuante de tamanho arbitrário, em comparação com uma codificação de atributos múltiplos.
[00010] Além disso, a capacidade dos dispositivos móveis de capturar nuvens de pontos plenópticos ainda está amadurecendo e, portanto, a codificação será inicialmente tratada por servidores poderosos. Dessa forma, os dispositivos móveis devem ser capazes de receber e decodificar tais conteúdos com a maior eficiência energética possível. Neste sentido, o foco desta invenção é melhorar a eficiência energética do decodificador, uma vez que a maioria dos conteúdos codificados provavelmente serão decodificados várias vezes.
[00011] O documento de patente US10853973, intitulado “Point cloud compression using fixed-point numbers”, publicada em 1 de dezembro de 2020, por APPLE INC., fornece um sistema para codificar e decodificar nuvens de pontos que usa representação numérica de ponto fixo ao determinar valores de atributos preditos e valores de correção de atributos. A principal diferença é que a presente invenção se concentra na parte de transformada de um codificador de nuvens de pontos plenópticos, enquanto o documento de patente US10853973 usa aritmética de ponto fixo durante a predição e correção de atributos.
[00012] O documento de patente WO2020145689, intitulado “Method and apparatus for improving image padding in video-based point-cloud compression codec”, publicado em 16 de julho de 2020, por SAMSUNG ELECTRONICS CO. LTD., fornece um dispositivo de codificação e método para codificação de nuvens de pontos que reduz e, em seguida, aumenta a resolução de quadros usando preenchimento para modificar pixels nesses quadros que não são dos dados de nuvem de pontos. A principal diferença é que a presente invenção lida com preenchimento na etapa de transformada de uma codificação de nuvem de pontos plenópticos que acontece antes do preenchimento da imagem de atributo. Além disso, enquanto WO145689 melhora o preenchimento 2D, a presente invenção tenta evitar o preenchimento 1D completamente nesta invenção.
[00013] O artigo “Compression of plenoptic point clouds”, publicado em março de 2019 por G. Sandri, R. L. de Queiroz e P. A. Chou apresenta um método onde os coeficientes transformados são codificados usando um codificador baseado na transformada hierárquica adaptativa da região (RAHT). A principal diferença é que a presente invenção aborda a codificação híbrida de nuvem de pontos plenópticos considerando a codificação baseada em vídeo (V-PCC) em vez de uma transformada hierárquica geométrica.
[00014] O artigo “Video-based compression for plenoptic point clouds” publicado em 2019, por L. Li, Z. Li, S. Liu e H. Li, usa a extensão multi-vista do HEVC (MV-HEVC) para codificar os múltiplos atributos de cores como se fossem múltiplas vistas do mesmo objeto. A principal diferença é que a presente invenção avança a tecnologia de codificação de nuvem de pontos plenópticos considerando a compressão de vídeo suportada pelo padrão de compressão de nuvens de pontos baseada em vídeo (V-PCC). Além disso, a presente invenção explora ainda mais as transformadas das vistas em tal escopo.
[00015] O documento de patente BR 102020020345-2, intitulado “Método para compressão de nuvens de pontos”, depositado em 2 de outubro de 2020, por SAMSUNG ELETRÔNICA DA AMAZÔNIA LTDA., fornece um método para comprimir as nuvens de pontos plenópticos usando uma abordagem híbrida (codificação diferencial e de transformada) sobre o codec VPCC. Nessa invenção, as vistas residuais transformadas são representadas como múltiplos atributos. A presente invenção avança a técnica explorando um design de transformada assimétrica no codificador e decodificador para garantir que o decodificador tenha a menor complexidade possível, mantendo a eficiência de codificação o mais próxima possível daquela que adota transformadas de tamanho arbitrário e ponto flutuante tanto no codificador quanto no decodificador. Embora em uma concretização da presente invenção a transformada de Hadamard seja usada no decodificador, o projeto da transformada direta é uma das principais vantagens desta invenção. Uma concretização da presente invenção não explora a assimetria da transformada, mas contém um novo conjunto de coeficientes de transformadas inéditas.
[00016] O documento de patente US20150172718, intitulado “Low complexity large transform” publicado em 18 de junho de 2015, por TEXAS INSTRUMENTS INC., fornece métodos para codificar e decodificar vídeos usando uma grande transformada com baixa complexidade. Nessa invenção, grandes transformadas Hadamard são combinadas com pequenas Transformadas Discretas de Cosseno (DCT) para fornecer uma grande transformada 2D usada em codecs de vídeo para grandes blocos de resíduos 2D. A principal diferença é que a presente invenção se concentra na transformada 1D de vetores contendo amostras de nuvens de pontos plenópticos e aborda a redução da complexidade usando transformadas inteiras e impondo limites ao número de tamanhos de transformada distintos sem comprometer muito a eficiência de codificação.
[00017] O documento de patente US20200226198 intitulado “Unified forward and inverse transform architecture” publicado em 16 de julho de 2020, por TEXAS INSTRUMENTS INC., fornece métodos para uma arquitetura unificada de transformada 2D direta e inversa considerando múltiplos tamanhos, mas apenas potências de dois, que podem compartilhar circuitos de hardware. A principal diferença é que a presente invenção se concentra nas transformadas 1D para codificação de nuvem de pontos plenópticos que podem ser permutados para reordenar as vistas decodificadas para compensar uma possível reordenação das vistas no codificador. Além disso, uma concretização da presente invenção permite o uso de transformadas inteiras de tamanho arbitrário que se aproximam da DCT, que são diferentes dos coeficientes apresentados no documento US20200226198.
[00018] O documento de patente US9179162, intitulado “Image transform zero coefficient selection and zero-skip transmission for arbitrary shape transform coding”, publicado em 3 de novembro de 2015, por FUTUREWEI TECHNOLOGIES INC., fornece métodos e aparelhos para realizar transformadas separáveis 2D com formas arbitrárias sobre blocos de pixels 2D para codificação de vídeo, mascarando pixels e garantindo que pelo menos as posições preenchidas não sejam transmitidas. Assim como no artigo intitulado “Arbitrarily Shaped Transform Coding Based on a New Padding Technique”, publicado em 2001, por G. Shen, B. Zeng, e Ming Lei Liou, a transformada 2D conta com o preenchimento ideal considerando as transformadas de ponto flutuante. Entretanto, a presente invenção foca na transformada 1D sobre uma lista de vistas para codificação em nuvem de pontos plenópticos.
Sumário
[00019] A presente invenção transforma as nuvens de pontos plenópticos de uma forma hardware-friendly sem diminuir muito a eficiência de codificação de uma abordagem de transformada híbrida que não é tão hardware-friendly, compreendendo: um número limitado ou arbitrário de tamanhos de transformada disponíveis no codificador onde os tamanhos podem ser potências de dois; tipo arbitrário de operações no lado do codificador (inteiro, ponto fixo, ponto flutuante); o escalonamento correto dos dados transformados a serem codificados por um codec de vídeo; um número limitado de transformadas disponíveis no lado do decodificador em que os tamanhos são potências de dois; operações de inteiro ou ponto fixo no lado do decodificador onde as multiplicações podem ser realizadas por meio de adições e deslocamentos; ordenação correta dos valores transformados inversos em que essa ordem pode ser aplicada na matriz de transformada inversa ou direto no vetor transformado inverso; o descarte de vistas indesejadas.
[00020] De acordo com uma concretização da presente invenção, aplicar a transformada direta e inversa em uma nuvem de pontos plenópticos compreende: determinar uma matriz Hadamard adaptada considerando o número de vistas a serem transformadas; realizar a transformada nos dados de nuvem de pontos usando a matriz Hadamard adaptada; codificar os dados transformados; decodificar os dados transformados; preencher com zero os dados transformados decodificados; realizar a transformada nos dados decodificados preenchidos por zero usando uma matriz Hadamard de ordem natural, de tal forma que o tamanho da transformada é a maior potência de dois mais próxima; descartando as últimas vistas que não fazem parte do conjunto original de vistas.
[00021] De acordo com outra concretização da presente invenção, apresenta-se a transformada direta e inversa de vistas de uma nuvem de pontos plenópticos, compreendendo: determinar uma matriz de transformada de ponto flutuante/ponto fixo considerando o número de vistas a serem transformadas; realizar a transformada dos dados de nuvem de pontos usando a matriz de transformada de ponto flutuante/ponto fixo; codificar os dados transformados; decodificar os dados transformados; preencher com zero os dados transformados decodificados; reordenar a matriz de transformada inversa com tamanho de potência de dois através de permutação de tal forma que, após a transformada, as últimas vistas possam ser descartadas; realizar a transformada das vistas preenchidas usando a matriz de transformada reordenada; descartando as últimas vistas que não fazem parte do conjunto original de vistas; dimensionar os valores restantes de acordo com a matriz inversa que está sendo usada.
[00022] De acordo com mais uma concretização da presente invenção, é fornecida a realização de uma transformada avançada e inversa de visualizações de uma nuvem de pontos plenópticos, compreendendo: determinar uma aproximação inteira da matriz DCT com tamanho arbitrário; realizar a transformada dos dados de nuvens de pontos usando a aproximação inteira adaptada da DCT; codificar os dados transformados; decodificar os dados transformados; realizar a transformada dos dados decodificados usando a aproximação inteira da DCT.
[00023] Concretizações descritas nesta invenção podem ser implementadas em hardware, software ou uma combinação deles. Se implementados em software, os métodos podem ser executados em sistemas de um ou vários núcleos que exploram o paralelismo. Se implementados em hardware, os métodos também podem ser implementados considerando a transformada de um vetor de cada vez ou de forma paralela para processar muitos vetores, já que não há dependência na transformada. Eles podem ser incorporados em um Circuito Integrado de Aplicação Específica (ASIC), programada em um Arranjo de Portas Programáveis em Campo (FPGA) ou em um Processador de Sinais Digital (DSP). Além disso, enquanto essa invenção foi descrita com um número limitado de concretizações, um técnico versado no assunto poderia elaborar outras concretizações que lidam com outras transformadas, tamanhos ou mesmo com um escopo diferente da codificação de nuvens de pontos plenópticos, partindo dos conhecimentos apresentados ao longo da presente invenção.
[00024] A abordagem híbrida (diferencial + transformada) adotada no estado da técnica para a codificação de nuvens de pontos plenópticos que é construída em cima do V-PCC traz benefícios de eficiência de codificação de até 90% em comparação com a codificação convencional de múltiplos atributos, suportada em V-PCC. Tal abordagem se baseia em um Codificador de Atributos Plenópticos e Decodificador de Atributos Plenópticos.
[00025] O problema que está sendo enfrentado pela presente invenção é como reduzir a complexidade da transformada sem comprometer muito a eficiência de codificação. Se um único quadro de nuvem de pontos com N visualizações for projetado em N quadros com resolução 5120×5120, a transformada será executada 26.214.400 vezes. Se a sequência completa tiver apenas 30 segundos e for capturada a 60 quadros/segundo, a transformada será calculada cerca de 47 bilhões de vezes. Além disso, para aumentar a precisão na representação da função plenóptica, mais vistas são desejadas. Com mais vistas, o número de operações na transformada aumenta. Portanto, a complexidade de cada operação deve ser considerada para avaliar toda a complexidade da transformada. Para dispositivos móveis, a eficiência energética é de extrema importância, tal que a eficiência energética pode ser vista como sinônimo de complexidade. Um técnico versado no assunto pode reconhecer que o uso da aritmética inteira é mais vantajoso em termos de eficiência energética do que a aritmética de ponto flutuante. A Tabela 1 mostra uma estimativa de duas operações básicas de 32 bits considerando aritmética de ponto flutuante e inteira:
Figure img0001
[00026] É possível notar que, embora a diferença entre a multiplicação inteira e de ponto flutuante seja pequena, a diferença considerando a adição é significativa (9× mais energia para o ponto flutuante). No entanto, a multiplicação de inteiros consome cerca de 31× mais energia do que adição, por isso será um fator dominante em qualquer transformada que use multiplicação. No entanto, no caso de transformadas inteiras, se os coeficientes da transformada forem conhecidos de antemão, pode-se implementá-los como adições e deslocamentos em vez de usar multiplicações. Adições tem, conforme a Tabela 1, uma baixa demanda de energia, enquanto deslocamentos podem ser implementados eficientemente em hardware, simplesmente reorganizando os fios de interconexão. Por exemplo, o coeficiente 42 pode ser decomposto em 32+8+2=25+23+21, assim, o 42 multiplicado por alguma variável x pode ser realizado como 42×x=(x<<5) +(x<<3) +(x<<1), ou seja, usando apenas 2 adições. Portanto, em vez de utilizar 3.1pJ, é possível realizar a mesma operação usando apenas 0.2pJ de energia, que é 15.5× mais energeticamente eficiente. Nesse caso, a adoção da aritmética inteira tem claras vantagens.
[00027] No entanto, um segundo problema que surge quando se considera aceleradores de hardware é a área de silício ocupada. Uma transformada específica para cada tamanho (ou seja, para cada possível número de vistas) exigiria uma grande área, enquanto apenas uma pequena parte desse circuito, correspondente a um tamanho de transformada, estaria ativa durante a computação da transformada. Uma solução conhecida é adotar apenas transformadas de tamanho em potência de dois. Por exemplo, em vez de ter uma arquitetura de transformadas específicas para os tamanhos 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15 e 16 vistas, apenas os tamanhos 4, 8 e 16 estariam presentes. Isso significa uma redução de 13 para 3 no número de transformadas distintas, considerando apenas a faixa entre 3 e 16.
[00028] Embora o estado da técnica faça uso de uma transformada inteira que, por definição, tem um número limitado de tamanhos (transformada Hadamard), ela exige um esquema de preenchimento. Para evitar o envio das informações extras devido ao preenchimento e consequente redução da eficiência de codificação por conta do aumento da taxa, tais informações são descartadas no lado do codificador (não são transmitidas). O decodificador também precisa realizar preenchimento com zeros no lugar das informações descartadas. Isso também prejudica a eficiência de codificação, desta vez sobre a distorção, já que a reconstrução não será perfeita devido à falta das informações que foram descartadas pelo codificador.
Breve Descrição dos Desenhos
[00029] Os objetivos e vantagens da presente invenção ficarão mais claros através da seguinte descrição detalhada do exemplo e dos desenhos não limitativos apresentados no final deste documento:
[00030] Figura 1 ilustra uma vista expandida do Codificador de Atributos Plenópticos do estado da técnica.
[00031] Figura 2 ilustra uma vista expandida do Decodificador de Atributos Plenópticos do estado da técnica.
[00032] Figura 3 mostra o método comum para realizar uma transformada 1D direta e inversa.
[00033] Figura 4 representa o método para realizar a transformada 1D direta e inversa da presente invenção.
[00034] Figura 5 ilustra o fluxo de transformada direta proposto.
[00035] Figura 6 ilustra o fluxo de transformada inversa proposto.
[00036] Figura 7 mostra a matriz de transformada Hadamard adaptada e usada para o caso em que a próxima potência de dois é 4.
[00037] Figura 8 mostra as matrizes de transformada Hadamard adaptada e utilizadas para o caso em que a próxima potência de 2 é 8.
[00038] Figura 9 mostra as sete matrizes de Hadamard adaptadas para o caso em que a próxima potência de dois é 16.
[00039] Figura 10 ilustra o caminho de dados da transformada de Hadamard 1D com tamanho oito.
[00040] Figura 11 mostra um exemplo de um SoC móvel e algumas de suas interfaces.
[00041] Figura 12 ilustra uma concretização sobre a captura e a visualização de nuvem de pontos.
[00042] Figura 13 ilustra matrizes DCT inteiras para tamanhos até 15.
[00043] Figuras 14 a 16 apresentam gráficos das curvas de taxa-distorção para as nuvens de pontos Longdress, RedAndBlack e Soldier, respectivamente.
[00044] Figura 17 ilustra estimativas de energia de acordo com o número de vistas, considerando transformadas de ponto flutuante e inteiras com multiplicações e adições e deslocamentos.
[00045] Figura 18 mostra as estimativas energéticas das alternativas de baixa complexidade.
[00046] Figura 19 apresenta a vantagem de eficiência energética da concretização 1 em relação a algumas alternativas inteiras.
[00047] Figura 20 apresenta a vantagem de eficiência energética da concretização 1 em relação a uma alternativa de ponto flutuante.
[00048] As Figuras 21 a 23 apresentam a relação entre eficiência de codificação e eficiência energética para nuvens de pontos Longdress, RedAndBlack e Soldier, respectivamente.
Descrição detalhada
[00049] A Figura 1 ilustra uma vista expandida do Codificador de Atributos Plenópticos do estado da técnica. A imagem principal de atributo (101), que é um quadro de vídeo obtido pela projeção de informações coloridas a partir da nuvem de pontos, passa por uma compressão de vídeo (102) gerando o sub-bitstream principal de atributo (103) que é incorporado na bitstream compactada completa. A imagem principal de atributo reconstruída (104) é a imagem equivalente que está sendo recuperada no decodificador. O codificador diferencial (107) dentro do Codificador de Atributos Plenópticos (105) usa a imagem principal de atributo reconstruída (104) e as imagens de atributo de vistas plenópticas (106) para gerar imagens diferenciais. Um preenchimento de vistas (109) pode ser necessário antes da transformada (110), que converte as imagens diferenciais em uma representação compacta. A presente invenção melhora as etapas de preenchimento e transformada. Portanto, eles serão mais detalhados mais tarde. O escalonamento (111) realiza o mapeamento para o intervalo suportado pela compressão de vídeo, de 0 a 255 no caso de um codificador de vídeo de 8 bits. Uma etapa adicional de adição de 128 ou metade da faixa suportada é adicionada ao processo de escalonamento, dependendo do tipo do coeficiente transformado que está sendo gerado. Alguns coeficientes podem ser descartados antes, como os preenchidos (112), ou após o escalonamento. Em seguida, as imagens transformadas restantes passam por um processo de preenchimento de imagem (113) para gerar uma imagem adequada para compressão de vídeo. A compressão de vídeo (114) gera os sub-bitstreams de atributos plenópticos (115). Metadados (114) da transformada e escalonamento também são enviados para o bitstream comprimido. O mapa de ocupação reconstruído (108) pode ser usado pelo codificador diferencial para ignorar os valores em pixels desocupados e é usado pelo preenchimento da imagem.
[00050] Uma vista expandida do Decodificador de Atributos Plenópticos é ilustrada na Figura 2. O subbitstream principal de atributo (201) é decodificado usando a descompressão de vídeo (202) gerando a imagem principal de atributo reconstruída (203). No Decodificador de Atributos Plenópticos (204), a descompressão de vídeo (206) decodifica os sub-bitstreams de atributos (205). O escalonamento inverso (208) utilizando informações dos metadados plenópticos (207) remapeia os valores para a faixa da transformada utilizada. A transformada inversa (209) retorna os dados ao formato de codificador diferencial, que é adicionado à imagem principal de atributo reconstruída (203) gerando as imagens de atributo reconstruídas (211). As vistas plenópticas reconstruídas (212) são passadas para o decodificador de nuvens de pontos baseado em vídeo para a reconstrução completa da nuvem de pontos plenópticos. Se o número de vistas não for compatível com o tamanho da transformada inversa (209), pode ser aplicado o preenchimento com zero (213). Neste caso, as vistas que não fazem parte da nuvem de pontos real são descartadas (214).
[00051] A Figura 3 mostra o método comum para realizar uma transformada 1D direta e inversa, considerando o fluxo de dados de um codec de nuvens de pontos plenópticos, como o das Figuras 1 e 2. No codificador (301), cada vetor v de N amostras plenópticas (302) construído com uma amostra de cada uma das N imagens de atributo (106) ou imagens de atributo residual (107) é transformado (303) utilizando uma matriz de transformada (304). Esse processo é realizado para cada vetor de amostras a partir das imagens de atributos das visualizações plenópticas (106).
[00052] Uma transformada 1D direta sobre um vetor v com N posições usa uma matriz de transformada M com NxN valores, denotada como MN. Assim, o vetor transformado t (305) é o resultado de uma multiplicação da matriz de transformada MN com o vetor de entrada v, ou seja:
t=Mxv
[00053] O vetor transformado obtido (305) é encaminhado para os próximos passos de codificação (306), como o escalonamento (110). No lado do decodificador (307), após as etapas iniciais do Decodificador de Atributos Plenópticos (308) as amostras de transformada já dimensionadas (309) são inversamente transformadas (310), utilizando o inverso da matriz de transformada (304) que foi utilizada no codificador. Em geral, como a matriz de transformada é projetada para ser ortonormal, a matriz de transformada inversa é a transposição da matriz de transformada avançada. Por exemplo, quando a transformada é a DCT de ponto flutuante, a matriz inversa é igual à matriz DCT transposta. O mesmo é válido para a DCT inteira do HEVC. Dada a sua simetria, para o caso em que a matriz de transformada é a Hadamard, a inversa é a própria Hadamard, ou seja, H-1 = H.
[00054] Assumindo um cenário em que nenhuma perda de informação foi imposta a t após a transformada de tal forma que t'=t, a operação executada é:
Figure img0002
[00055] Assim, neste caso, o vetor de saida ν' (311) é igual ao vetor de entrada v (302). Isso significa que as amostras plenópticas reconstruídas (312) foram perfeitamente reconstruídas. É claro que, para alcançar a compressão, espera-se perda de informações e, assim, t'≠ t, resultando em v ' ≠ v.
[00056] Ao restringir o número de transformadas disponíveis, como permitir que o codec use apenas transformadas de tamanho em potências de dois, nem sempre há um MN para todos N possíveis. Portanto, o vetor v deve ser ajustado para se tornar compatível com um dos tamanhos de transformada disponíveis. Para isso, deve ser utilizado um método de preenchimento. Um possível método de preenchimento baseia-se na repetição do último valor disponível em v até que o novo tamanho do vetor preenchido p seja compatível com a transformada. Considerando uma matriz de transformada 02m com tamanho 2M X 2M tal que 2M_1 ≤ 2M, o vetor p requer 2m valores para ser compatível com O. Isso significa que 2M — N valores devem ser incluídos em tal vetor preenchido. O vetor de repetição pode ser representado como:
Figure img0003
onde todas as linhas de L2m_N são iguais à última linha de IN.
[00057] Neste caso, a transformada de v usando O pode ser expressa como:
Figure img0004
[00058] Então, o resultado tem tamanho 2M. Se o inverso for obtido sem perdas, todas as 2M vistas transformadas devem ser transmitidas ao decodificador. Para evitar o envio das informações extras devido ao preenchimento e, assim, reduzir a eficiência de codificação aumentando a taxa, uma possível abordagem é descartar os K = 2M — N atributos extras, transmitindo apenas o número original de N atributos plenópticos. Nesse caso, considerando t' como vetor transformado t com os últimos 2M — N valores descartados, a operação de decodificação pode contar com preenchimento com zeros para garantir que t' seja compatível com a transformada inversa O-i. O uso deste método causa erro nas vistas decodificadas porque v = v' se, e somente se, os 2M — N últimos valores de t forem iguais a 0. Em todos os outros casos ν≠ν', portanto, há erros (e = v-v' ≠ 0). Isso significa que essa abordagem também prejudica a eficiência de codificação, desta vez sobre a distorção, uma vez que a reconstrução não será perfeita devido às informações que faltam uma vez descartadas pelo codificador.
[00059] Esta invenção traz como solução um método que inclui uma transformada com tamanho Nno codificador e N ou 2m no decodificador de tal forma que o inverso seja perfeito, assumindo que t' = t. No caso em que o codificador usa a transformada de tamanho N e o decodificador usa 2M, a matriz de transformada inversa não pode ser obtida pela matriz de transformada direta, tornando a presente invenção diferente do estado da técnica ilustrada na Figura 3.
[00060] A Figura 4 representa o fluxo de transformada da presente invenção. No lado do codificador (401), cada vetor de amostras plenópticas v (402) é transformado (403) utilizando uma matriz direta específica (404) para obter o vetor transformado t (405). As demais operações de codificação (406) do Codificador de Atributos Plenópticos são realizadas nas vistas transformadas para criar o arquivo binário que é enviado a um decodificador (407). Após as operações iniciais de decodificação (408), a transformada deve ser computada. No entanto, para ter baixa complexidade, o decodificador só tem transformadas cujos tamanhos são potências de dois (409), ou seja, as matrizes de transformada estão na forma O 2m . Quando o tamanho do vetor recebido t ' (410) não é compatível com as transformadas disponíveis, K zeros são preenchidos ao final de t' formando o vetor t (411). A transformada inversa (412) prossegue utilizando a matriz de transformada inversa O2m no vetor t, gerando o vetor v (413). Como a nuvem de pontos original tinha N vistas, os K últimos valores do vetor v são descartados (414), gerando o vetor decodificado v' (415). As amostras plenópticas reconstruídas (416) são encaminhadas para os próximos passos de decodificação. Supondo que t =t e que as matrizes inversa e direta sejam projetadas conforme apresentado nos próximos parágrafos, então v =v.
[00061] Para chegar a essa assimetria, é possível partir de uma transformada direta de tamanho em potências de dois (F 2m) conhecida para definir uma matriz direta de tamanho arbitrário (MN), de tal forma que se t' = t, então v = v' ao considerar a transformada usando MN, preenchimento com zeros, realizando o inverso com (F2m)-1 e, em seguida, descartando os K últimos valores do resultado, ou seja:
Figure img0005
[00062] Para garantir que ν' =v, a seguinte equação deve ser verdadeira:
Figure img0006
[00063] Para que a equação acima se mantenha,
Figure img0007
direta MN puder ser encontrada, ela pode ser usada no codificador para evitar transmitir preenchimento, permitindo que o decodificador use (F 2m) -1 para reconstruir perfeitamente o vetor original v usando preenchimento por zero (apenas no decodificador). Em suma, a matriz de transformada direta é obtida pelo inverso da multiplicação da matriz de descarte pela matriz de transformada inversa multiplicada pela matriz de preenchimento.
[00064] No artigo ""Arbitrarily Shaped Transform Coding Based on a New Enchimento Padding Technique", foi proposto um método para realizar a transformada direta de ponto flutuante com tamanho arbitrário, sendo uma técnica de preenchimento ótimo para a transformada 1D. A ideia é usar valores de preenchimento para que os coeficientes resultantes com frequências mais altas sejam zero. Neste caso, os valores podem ser descartados sem perda de informação, como mencionado anteriormente. A proposta mostra que os valores preenchidos poderiam ser entrelaçados no vetor de entrada para minimizar a energia dos coeficientes após a transformada, ajudando na compressão. Ademais, para cada tamanho N e uma transformada direta conhecida O2m , uma matriz direta de ponto flutuante com tamanho MN pode existir para ser usada no codificador de tal forma que a transformada inversa usa (O2m)-1. Os resultados apresentados posteriormente consideram DCT de ponto flutuante 2D. Embora isso resolva as transformadas de tamanho arbitrário no decodificador, evitando também a necessidade de preenchimento no codificador, ainda requer o uso de transformada de ponto flutuante no decodificador.
[00065] Nesta invenção, transformadas de tamanho em potência de dois com coeficientes de transformada inteiras podem ser adotadas no lado do decodificador, enquanto uma transformada de ponto flutuante de tamanho arbitrário pode ser adotada no lado do codificador. Neste caso, usando um escalonamento adequado, a abordagem ideal de preenchimento pode ser usada no codificador com transformada de ponto flutuante de tamanho arbitrário. Isso garante que o decodificador tenha uma pequena complexidade (usando a transformada inversa inteira) e reduz o número de tamanhos disponíveis (apenas potências de dois), reduzindo assim as demandas de área se o decodificador estiver embarcado em um acelerador de hardware.
[00066] Dado que o preenchimento ideal pode ser entrelaçado na entrada, o decodificador deve realizar o desentrelaçamento. A matriz de transformada inversa pode ser pré-multiplicada por uma matriz de permutação de tal forma que, após a operação de transformada inversa, os valores preenchidos "decodificados" estejam no final do vetor decodificado, evitando operações extras. Então os K últimos valores podem ser descartados sem perda de informações. Este caso é representado na Figura 4, onde a matriz de transformada direta (404) é de tamanho arbitrário N, enquanto a matriz de transformada inversa (409) tem tamanho em potências de dois e pode ser pré-multiplicada por uma matriz de deslocamento. Por outro lado, é possível realizar a permutação após a transformada para cada vetor decodificado preenchido.
[00067] Uma opção final é usar uma transformada de tamanho arbitrário inteira ou de ponto fixo para resolver apenas o problema com operações de ponto flutuante. Neste caso, o codec de atributos plenópticos é o mesmo, e a complexidade resultante dependerá dos coeficientes usados. Por outro lado, embora essa abordagem não resolva a questão de transformadas de tamanho arbitrário, ela também não tem o problema de exigir preenchimento e lidar com a redução da eficiência da codificação pelo descarte de valores preenchidos.
[00068] Nos três casos, não há necessidade de preenchimento no lado do codificador, portanto, nenhuma informação extra é enviada ao decodificador. Isso também significa que nenhuma informação é perdida pelo descarte dos valores preenchidos no codificador. A Figura 5 ilustra o fluxo de transformada direta proposta nesta invenção. Primeiro, é recebido um vetor v com N valores de entrada (501). Tal vetor é transformado usando a matriz de transformada direta MN, que pode ser ponto flutuante, uma aproximação de ponto fixo ou uma matriz de transformada inteira (502). Se a transformada for inteira, pode ser necessário um escalonamento por uma constante de ponto fixo ou flutuante (503). O vetor transformado escalonado é então enviado (504) para as próximas etapas do Codificador de Atributos Plenóptico.
[00069] A Figura 6 ilustra o fluxo de transformada inversa proposto nesta invenção. O decodificador deve saber a matriz de transformada inversa 0L de alguma forma (601), onde L≥N. Essas informações podem ser sinalizadas no bitstream usando uma definição implícita de níveis e/ou perfis em um padrão ou outro método. O vetor t' com N valores é obtido (602). O decodificador então verifica se a transformada inversa é compatível com vetor t' (603). Se t' for compatível com a matriz de transformada inversa, então t' é atribuído ao vetor t (604). Caso contrário, se t' não for compatível, o preenchimento com zeros é realizado e o resultado é atribuído a t (605). O vetor t é então transformado (606) usando a matriz inversa, resultando em v. Se uma reordenação for necessária e ainda não tiver sido aplicada na matriz de transformada inversa, v é reordenado (607). Considerando que a reordenação já foi realizada, essa etapa pode ser ignorada, ou a matriz de identidade (I) pode ser usada como matriz de permutação. O decodificador então verifica novamente se a transformada inversa era compatível com vetor t' (608). Se for verdade, v é atribuído a ν' (609), caso contrário os últimos K = L — N valores de D podem ser descartados (610), resultando no vetor ν'. Como no codificador, pode ser necessário um escalonamento por um valor de ponto fixo ou flutuante (611). Por fim, o vetor resultante é encaminhado para as etapas restantes da decodificação de atributos plenópticos (612).
[00070] A conhecida transformada Hadamard é uma forte candidata para garantir a quantidade mínima de operações na transformada. As matrizes Hadamard têm tamanhos que são potências de dois por definição. Além disso, os valores na matriz Hadamard são sempre +1 ou -1. Assim, não é necessária multiplicação. Além disso, o método ideal para calcular a transformada Hadamard usando apenas NX log2 N operações é bem conhecido no estado da técnica, fazendo com que tal transformada seja a melhor candidata para permitir a transformada de vistas com baixa complexidade.
[00071] A matriz Hadamard pode ter diferentes ordens. A ordem obtida pela construção recursiva é conhecida como a matriz Hadamard na ordem natural. A construção recursiva é a seguinte:
Figure img0008
[00072] Assumindo uma matriz de transformada direta F2m = H 2m , e assim (F2m)-1 = H 2m , um conjunto de matrizes de transformada direta pode ser obtido quando N ≠ 2m,VM ∈ N, com K = 2M — N, tal que:
Figure img0009
[00073] As Figuras 7 a 9 mostram as matrizes MN que foram obtidas considerando 2M = 4,8,16. Outros tamanhos para N> 16 podem ser obtidos considerando a equação acima. A Figura 7 mostra a matriz de transformada usada para o caso em que a próxima potência de dois é 4. Há apenas um caso, ou seja, para N = 3 em que o codificador usa M3 (701), enquanto o decodificador usa H4 (702), considerando preenchimento com zero no vetor de entrada (213).
[00074] A Figura 8 mostra as matrizes de transformada utilizadas para o caso em que a próxima potência de 2 é 8. No lado do codificador, para N = 5 o codificador usa M5 (801) , para N = 6 o codificador usa M6 (802), e para N = 7 o codificador usa M7 (803). Por outro lado, em todos esses casos o decodificador usa H8 (804), considerando preenchimento com zeros no vetor de entrada (213). Como H8 está em ordem natural, ela pode ser obtida recursivamente (805) a partir de H4 (702).
[00075] A Figura 9 mostra as sete matrizes de Hadamard adaptadas para o caso onde a próxima potência de dois é 16. No lado do codificador, para N = 9 codificador usa M9 (901), para N = 10 o codificador usa MI0 (902), para N = 11 o codificador usa M11 (903), para N = 12 o codificador usa M12 (904), para N = 13 o codificador usa M13 (905), para N= 14 o codificador usa M14 (906), e para N = 15 o codificador usa M15 (907). Por outro lado, em todos esses casos o decodificador usa H8 (908), considerando preenchimento com zeros no vetor de entrada (213) . Como H16 está em ordem natural, pode ser obtida recursivamente (909) a partir de H8 (805).
[00076] A matriz Hadamard em sua ordem natural também é importante porque tal construção recursiva permite arquiteturas de hardware muito eficientes onde pequenas transformadas podem ser computadas usando o mesmo hardware já presente nas transformadas maiores. A Figura 10 mostra como é simples tal arquitetura para H8 (1001). Como a construção da matriz de transformada é recursiva, tal caminho de dados contém também caminhos de dados para calcular a transformada com H4 (1002) e com H2 (1003).
[00077] Portanto, essa concretização tem o menor custo de transformada possível. Seus requisitos energéticos são pequenos, uma vez que existem apenas algumas operações e nenhum coeficiente de transformada para ser multiplicado. Além disso, o hardware é recursivo por natureza (Figura 10), e assim ocupa uma pequena área de silício se incorporado em um System-on-Chip (SoC) já que um circuito que implementa um determinado tamanho inclui o circuito para executar em paralelo todos os tamanhos menores que o precedem.
[00078] A Figura 11 mostra um exemplo de um SoC móvel e algumas de suas interfaces. Uma bitstream de nuvem de pontos plenópticos pode ser recebida através da antena de rede (1101), e então processada no SoC móvel (1102) inicialmente pelo subsistema Modem (1103), e depois armazenada na memória flash do dispositivo (1104), cartão SD (1105) ou carregada diretamente no sistema principal de memória de acesso aleatório (RAM) (1106) para decodificação sob demanda. O subsistema de memória, contendo um módulo SRAM on-chip (1107), disponibiliza os dados da bitstream para todo o SoC. Para decodificar cada sub-bitstream de atributos (205), o SoC móvel (1102) pode ter um decodificador HEVC incorporado no IP Multimídia (1108). Após o escalonamento inverso (208) e o preenchimento com zeros (213), a transformada inversa (209) pode operar como um software carregado para a CPU (1109) ou GPU (1110) ou até mesmo ser embarcado como um acelerador de hardware sintetizado dentro do IP Multimídia (1108). As vistas não aproveitadas devem ser descartadas (214) e as demais podem ser exibidas em uma tela plenóptica. Mesmo sem uma tela plenóptica, um dispositivo equipado com um decodificador de nuvens de pontos plenópticos pode ser capaz de simular os diferentes ângulos de visualização usando dados dos sensores do dispositivo (1111), como giroscópios e/ou acelerômetro. De acordo com a detecção do sensor de movimento, o display (1112) pode mostrar as cores relacionadas a uma vista específica. A velocidade pela qual o dispositivo pode decodificar as nuvens de pontos plenópticos desempenhará um papel importante na garantia do realismo da mídia exibida.
[00079] Dada a baixa complexidade da concretização proposta, o codificador também pode ser incorporado em um SoC. Uma câmera com múltiplas lentes (1113) e alguns métodos de detecção de profundidade podem capturar diferentes vistas de uma nuvem de pontos. Os dados da imagem serão processados pelo Processador de Sinal de Imagem (ISP) (1114) e podem ser transformados em uma nuvem de pontos. Em seguida, um codificador de nuvem de pontos plenópticos pode ser carregado na CPU (1109), GPU (1110) ou ser habilitado no IP multimídia (1108).
[00080] Como uma segunda concretização, é considerado o caso em que o codificador adota uma transformada DCT 1D de ponto flutuante com preenchimento ótimo, que pode ser implementado como uma DCT adaptada de ponto flutuante de tamanho arbitrário no lado do codificador. No entanto, como explicado, mudar a posição dos valores de preenchimento pode melhorar a eficiência da codificação de transformada e, portanto, a transformada inversa deve ser reordenada. Além disso, uma transformada inteira pode ser uma aproximação suficiente da DCT de ponto flutuante no decodificador. Nesta concretização, como transformada inteira, a DCT inversa do HEVC é adotada para os tamanhos 4, 8 e 16. Assim, os valores devem ser dimensionados por 1.0/(64X √2M).
[00081] No caso da presente concretização, o design de hardware da DCT inversa de um Núcleo IP HEVC pode ser parcialmente reutilizado, dadas as devidas modificações para operar apenas em uma dimensão. Durante a modificação, os coeficientes da transformada podem ser reordenados. É claro que um versado na técnica pode ser capaz de realizar a reordenação (deslocamento) sobre o vetor decodificado ν', em vez de fazer os deslocamentos sobre a matriz de transformada.
[00082] Tal concretização proporciona uma baixa complexidade no decodificador (transformadas inteiras e de tamanho em potências de dois), enquanto mantém uma complexidade considerável no lado do codificador (transformada de tamanho arbitrário de ponto flutuante). A Figura 12 mostra um possível uso dessa concretização, ou seja, para criadores de conteúdo e distribuidores com poderosos recursos de processamento que desejam adotar nuvens de pontos plenópticos, pagando a maior complexidade de seu lado (codificação) ao mesmo tempo em que alivia a carga do lado dos clientes (decodificação) que pode estar em dispositivos móveis. Alguns conteúdos (1201) são capturados através de um conjunto de câmeras (1202). Um servidor poderoso (1203) ou estação de trabalho será capaz de representar o conteúdo capturado por meio de uma nuvem de pontos plenópticos e codificá-lo para distribuição usando o Codificador de Atributos Plenópticos. Esse codificador pode ser executado em CPU ou mesmo em aceleradores FPGA integrados em servidores. A nuvem de pontos plenópticos codificada é transmitida pela rede (1204) para ser decodificada e exibida por dispositivos móveis (1205) com complexidade relativamente baixa devido à transformada inversa adotada.
[00083] Uma terceira concretização desta invenção aborda apenas a questão de ter operações de ponto flutuante na transformada. Para isso, ponto fixo pode ser usado (pois pode ser implementado como uma representação inteira). No entanto, aproximações inteiras da DCT também podem ser usadas. A Figura 13 mostra aproximações inteiras construídas seguindo os mesmos princípios da DCT inteira do HEVC. No entanto, não consistem na mesma transformada usada no HEVC, pois, para esse padrão, a transformada só é definida para tamanhos em potência de dois, sendo 4, 8, 16 e 32.
[00084] Considerando um caso em que o número de vistas N = 3, M3 (1301) será usada tanto no codificador quanto no decodificador. No entanto, para decodificação, a transposta de M3 é usada. De maneira similar, para N = 5, M5 (1302) é usada no codificador e M5 transposta é usada no decodificador. Para os tamanhos N = {6,7,9,10,11,12,13,14,15}, as matrizes de transformada são M6 (1303), M7 (1304), M9 (1305), M10 (1306), M11 (1307), M12 (1308), M13 (1309), M14 (1310) e M15 (1311), respectivamente.
[00085] A mesma estratégia pode ser adotada para projetar transformadas inteiras para tamanhos maiores do que N = 15. Além disso, quando o número de vistas é uma potência de dois, a DCT do HEVC pode ser usada. Existem 61 coeficientes distintos, desconsiderando seu sinal, considerando as 11 matrizes da Figura 13 juntamente com a DCT do HEVC para os tamanhos 4, 8 e 16. A desvantagem dessa concretização é que ela ainda requer uma matriz de transformada específica para cada número de vistas plenópticas. Embora isso evite a necessidade de qualquer estratégia de preenchimento, é caro fabricar uma solução com um IP de hardware dedicado para esta concretização. No entanto, ainda é uma abordagem válida que se baseia na aritmética inteira que pode ser acelerada em software (SIMD ou GPU). Além disso, se, durante um período específico, conteúdos com um determinado número de vistas tiverem maior probabilidade de serem adotados, uma boa solução seria criar um protótipo da transformada para tal tamanho em um FPGA. A vantagem desta solução é que sua eficiência de codificação é equivalente à da DCT de ponto flutuante com tamanho arbitrário, enquanto a eficiência do FPGA será melhor do que a de executar a transformada em dispositivos de uso geral (CPU/GPU).
[00086] A presente invenção propõe métodos alternativos de transformada que podem ser adotados considerando a relação custo-benefício entre a eficiência de codificação e a complexidade. Uma vantagem de ter algumas alternativas com diferentes eficiências de codificação versus complexidade é que elas podem estar relacionadas a níveis específicos (de complexidade) determinados por um padrão internacional. Para mostrar os efeitos das três concretizações desta invenção, primeiro é fornecida uma análise da eficiência de codificação, depois é fornecida uma análise da complexidade empregando estimativas de eficiência energética e, finalmente, os resultados de custo-benefício são fornecidos.
[00087] Para avaliar a eficiência de codificação, três concretizações dessa invenção e cinco transformadas foram implementadas considerando o estado da técnica no TMC2v11.0:
  • • "DCT do estado da técnica (fp, N)", que utiliza DCT de ponto flutuante de tamanho arbitrário tanto no codificador quanto no decodificador;
  • • "DCT do estado da técnica op (fp, N e 2M)", que utiliza DCT de ponto flutuante adaptada e de tamanho arbitrário no codificador e DCT de ponto flutuante de tamanho em potências de dois no decodificador,·
  • • "DCT de estado da técnica (fp, 2M)", que utiliza DCT de ponto flutuante de tamanho em potências de dois tanto no codificador quanto no decodificador;
  • • "DCT do HEVC do estado da técnica (i, 2M)", que utiliza DCT inteira de tamanho em potências de dois do HEVC tanto no codificador quanto no decodificador;
  • • "Hadamard do estado da técnica (i, 2M)", que usa a transformada Hadamard tanto no codificador quanto no decodificador. Tal transformada é inteira e tem tamanho em potências de dois por definição;
[00088] Assim, "Estado da técnica DCT (fp, 2M)", "Estado da técnica HEVC DCT (i, 2M)", e "Estado da técnica Hadamard (i, 2M)", precisam de preenchimento porque a transformada não é compatível com as nuvens de pontos testadas. Nesses casos, o preenchimento com repetição (da última vista válida) foi adotado no codificador, e como as vistas preenchidas transformadas são descartadas no codificador, o decodificador usa preenchimento com zeros.
[00089] Em relação às concretizações desta invenção, em suma:
  • ► "Presente invenção, concretização 1" usa matrizes de Hadamard adaptadas de tamanho arbitrário no codificador e matrizes de Hadamard ordenadas naturais no decodificador;
  • ► "Presente invenção, concretização 2" usa em ponto flutuante adaptada de tamanho arbitrário no codificador e DCT inteira do HEVC no decodificador;
  • ► "Presente invenção, concretização 3" usa, tanto no codificador quanto no decodificador, DCT inteira de tamanho arbitrário construída usando o mesmo método para matrizes de tamanho em potências de dois da DCT do HEVC.
[00090] A Tabela 2 resume as transformadas testadas e suas características. Neste sentido, o codificador foi configurado com os valores de parâmetro padrão do TMC2 da configuração C2-AI, e o codificador de atributo plenópticos foi configurado para que cada imagem de atributo fosse codificada com QP=QPmain. As diferentes transformadas foram testadas ao longo das nuvens de pontos Longdress, RedAndBlack e Soldier do conjunto de dados original 8i Voxelized Surface Light Fields (VSLF), que usa geometria de precisão de 12 bits.
Figure img0010
Figure img0011
[00091] Por si só, a eficiência de codificação é uma relação de custo-benefício entre taxa e distorção. A taxa foi calculada considerando as taxas de bits de todas as vistas (principal e plenóptica). Quanto menor a taxa, melhor. A distorção foi calculada como a Relação de Sinal-Ruído de Pico (PSNR) do canal Y entre as nuvens de pontos original e decodificada, todas tomadas como um único sinal em vez de uma média de PSNR entre as vistas. Quanto maior o PSNR, melhor (menos ruído). Uma forma de avaliar a eficiência de codificação é através de curvas de taxa-distorção, que são apresentadas nas Figuras 14 a 16, para as nuvens de pontos Longdress, RedAndBlack e Soldier, respectivamente.
[00092] A Tabela 3 mostra as BD-rates de cada transformada em relação à codificação de atributos múltiplos (quando nenhuma transformada é usada). Para esses valores de BD-rate, quanto menor o valor, melhor. É possível notar que a concretização 3 não tem perda na eficiência de codificação em comparação com o estado da técnica usando DCT de ponto flutuante de tamanho arbitrário. Além disso, não há perda na eficiência de codificação da concretização 2 em relação ao estado da técnica usando preenchimento ótimo, mostrando assim que as transformadas inteiras com tamanhos limitados do HEVC no decodificador não afetam a eficiência de codificação. Finalmente, enquanto a concretização 1 tem uma pequena redução na eficiência de codificação em comparação com as outras duas concretizações, sua eficiência de codificação ainda é melhor do que as das abordagens apresentadas no estado da técnica de baixa complexidade usando transformadas com tamanho 2M tanto no codificador quanto no decodificador e que necessitam preenchimento.
Figure img0012
Figure img0013
[00093] Considerando um sistema onde os métodos alternativos são implementados em hardware, uma maneira de avaliar a complexidade de cada método é pela sua eficiência energética. Para estimar a eficiência energética de cada método, foram utilizadas as estimativas fornecidas na Tabela 1. As estimativas de eficiência energética são obtidas considerando o número de operações necessárias para calcular a transformada em uma amostra.
[00094] Primeiro, para demonstrar que a aritmética inteira é preferida em vez da aritmética de ponto flutuante, as estimativas de energia das transformadas de ponto flutuante foram comparadas com "DCT HEVC do estado da técnica (i, 2m)" e "Presente invenção, concretização 3". Além disso, para mostrar que a multiplicação de constantes inteiras pode ser realizada de forma mais eficiente por adições e deslocamentos, as transformadas inteiras incluídas foram comparadas com ambas as implementações, ou seja, utilizando multiplicadores (X) ou utilizando adições e deslocamentos (+ e <<). A Figura 17 mostra os resultados. Ao usar tamanhos arbitrários, a energia aumenta de acordo com o número de vistas, ou seja, o tamanho da transformada. Ao usar tamanhos em potência de dois, a energia aumenta mais cedo, uma vez que requer o uso da transformada da maior potência de dois mais próxima. Comparando "DCT do estado da técnica (fp), "DCT HEVC do estado da técnica (i, 2M)" (usando X), é possível ver que uma transformada inteira equivalente é mais energeticamente eficiente do que sua correspondente de ponto flutuante. Mas as maiores diferenças são quando se compara a adoção de X versus + e <<. "DCT HEVC do estado da técnica (i, 2m ), usando multiplicação requer 11.16 X mais energia do que o exigido usando apenas adições e deslocamentos. No caso de "Presente invenção, concretização 3", 10.87 X mais energia é necessária na implementação com multiplicadores. Por esses resultados, uma transformada de ponto fixo ou inteiro é muito superior em termos de eficiência energética.
[00095] A Figura 18 mostra as estimativas energéticas das alternativas de baixa complexidade, sendo "Presente invenção, concretização 1" (codificador e decodificador), "Presente invenção, concretização 2" (apenas decodificador), "Presente invenção, concretização 3" (codificador e decodificador são equivalentes), "DCT HEVC do estado da técnica (i, 2M) ", e "Hadamard do estado da técnica (i, 2M)". "Presente invenção, concretização 2" de energia codificada é semelhante à "DCT do estado da técnica (fp, N)", mostrada na Figura 17. Se torna evidente que "Presente invenção, concretização 1" é a melhor alternativa em termos de eficiência energética.
[00096] Para evidenciar a vantagem de eficiência energética de "Presente invenção, concretização 1" em relação a "DCT HEVC do estado da técnica (i, 2M)" e "Presente invenção, concretização 3", a razão entre ambas as alternativas e "Presente invenção, concretização 1" foi calculada, tanto para codificador quanto para decodificador. A Figura 19 mostra os resultados obtidos. No melhor caso, "Presente invenção, concretização 1" é 12 X mais energeticamente eficiente do que a "DCT HEVC do estado da técnica (i, 2M)" tanto para codificador quanto para decodificador. No pior caso, "Presente invenção, concretização 1" é mais do que duas vezes mais energeticamente eficiente do que seus correspondentes. Considerando o decodificador, isso também significa que "Presente invenção, concretização 1" tem quase os mesmos benefícios em comparação com "Presente invenção, concretização 2".
[00097] A Figura 20 mostra a melhoria da adoção de "Presente invenção, concretização 1" em vez de uma transformada de ponto flutuante de tamanho arbitrário, como "DCT do estado da técnica (fp, N)". "Presente invenção, concretização 1" é pelo menos 40X mais energeticamente eficiente e até 180 X mais energeticamente eficiente para o maior número de vistas testadas. Se mais vistas forem usadas, as diferenças aumentam ainda mais.
[00098] A Figura 21 mostra a BD-rate (%) versus Energia (pJ) para cada transformada considerando a nuvem de pontos Longdress. As três opções que são melhores que as outras, tanto em termos de eficiência de codificação e complexidade, são as "Presente invenção, concretização 1", "Presente invenção, concretização 2" e "Presente invenção, concretização 3". Enquanto "DCT do estado da técnica (fp, 2m)" tem praticamente a mesma BD-rate de "Presente invenção, concretização 3", este último usa muito menos energia do que o primeiro. Além disso, "DCT do estado da técnica op (fp, N e 2m )" e "Presente invenção, concretização 2" têm BD-rate semelhante, mas este último também requer muito menos energia no decodificador. "Presente invenção, concretização 2" usa operações de ponto flutuante no codificador, exigindo assim mais energia do que "Presente invenção, concretização 1" e "Presente invenção, concretização 3".
[00099] As figuras 22 e 23 mostram os resultados de custo-benefício (tradeoff) para nuvens de pontos RedandBlack e Soldier, respectivamente. Os resultados são semelhantes aos de Longdress. Uma pequena variação nas estimativas de energia ocorre para Soldier, uma vez que tem 13 visualizações em vez de 12 como em Longdress e RedAndBlack. Embora para Soldier a eficiência de codificação de "Presente invenção, concretização 1" diminua mais do que nas outras duas nuvens de pontos, ainda é melhor do que as opções de estado da técnica em um nível de consumo de energia semelhante.
[000100] Embora a presente invenção tenha sido descrita em conexão com certas concretizações preferenciais, deve-se entender que não se destina a limitar a divulgação a essas concretizações particulares. Em vez disso, pretende-se cobrir todas as alternativas, modificações e equivalentes possíveis dentro do espírito e escopo da invenção, conforme definido pelas reivindicações anexas.

Claims (10)

  1. Método de transformada hardware-friendly em codecs para nuvens de pontos plenópticos caracterizado pelo fato de que compreende as etapas de:
    • - obter o vetor de amostras plenópticas v (402);
    • - transformar o vetor v a partir de uma matriz direta Mn (404);
    • - obter o vetor transformado t (405);
    • - codificar o vetor transformado t (405) em um arquivo binário e enviá-lo ao decodificador (407);
    • - decodificar o arquivo binário em um vetor recebido t' (410);
    • - preencher o vetor recebido t' (410) com K zeros, para formar o vetor t (411);
    • - realizar a transformada inversa (412) com a matriz de transformada inversa OL no vetor t (411), gerando o vetor v (413);
    • - descartar (414) os K últimos valores do vetor v, gerando o vetor reconstruído v', tal que v' = v se t' = t.
  2. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que a matriz de transformada direta MN pode ser ponto flutuante, uma aproximação de ponto fixo ou uma matriz de transformada inteira.
  3. Método, de acordo com a reivindicação 1 ou 2, caracterizado pelo fato de que os K valores descartados seguem a seguinte relação:
    K = L - N
    Onde L é a dimensão da matriz de transformada inversa e N é o tamanho do vetor v.
  4. Método, de acordo com qualquer uma das reivindicações 1 a 3, caracterizado pelo fato de que a matriz de transformada inversa apresenta tamanho em potências de dois.
  5. Método, de acordo com a reivindicação 4, caracterizado pelo fato de que o vetor reconstruído v' deve seguir a seguinte relação, assumindo t' = t:
    Figure img0014
    em que F2M é uma transformada de tamanho em potências de dois, Mn é uma matriz de transformada direta de tamanho arbitrário N.
  6. Método, de acordo com as reivindicações 4 ou 5, caracterizado pelo fato de que a transformada de tamanho em potências de dois F2M é uma matriz de Hadamard em ordem natural, tal que F2M = H2M:
    Figure img0015
    de tal forma que N ≠ 2M,□M □ N, com K = 2M - N, onde a transformada direta MN é uma matriz de Hadamard adaptada construída como:
    Figure img0016
  7. Método, de acordo com qualquer uma das reivindicações 1 a 4, caracterizado pelo fato de que podem ser utilizadas matrizes de DCT adaptadas de tamanho arbitrário no codificador e da DCT inteira do HEVC no decodificador.
  8. Método, de acordo com qualquer uma das reivindicações 1 a 7, caracterizado pelo fato de que a matriz da transformada inversa pode ser pré-multiplicada por uma matriz de permutação de tal forma que os valores preenchidos na etapa de preenchimento estejam ao final do vetor decodificado.
  9. Método, de acordo com qualquer uma das reivindicações 1 a 3, caracterizado pelo fato de que podem ser utilizadas matrizes de DCT inteiras de tamanho arbitrário, tanto no codificador quanto no decodificador.
  10. Método, de acordo com qualquer uma das reivindicações 1 a 9, caracterizado pelo fato de que pode ser necessário multiplicar os valores do vetor transformado t ou reconstruído v', por constantes de ponto fixo ou ponto flutuante para manter seus valores corretamente escalonados.
BR102021006869-8A 2021-04-09 2021-04-09 Método de transformada hardware-friendly em codecs para nuvens de pontos plenópticos BR102021006869A2 (pt)

Priority Applications (2)

Application Number Priority Date Filing Date Title
BR102021006869-8A BR102021006869A2 (pt) 2021-04-09 2021-04-09 Método de transformada hardware-friendly em codecs para nuvens de pontos plenópticos
US17/405,682 US11638035B2 (en) 2021-04-09 2021-08-18 Hardware-friendly transform method in codecs for plenoptic point clouds

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
BR102021006869-8A BR102021006869A2 (pt) 2021-04-09 2021-04-09 Método de transformada hardware-friendly em codecs para nuvens de pontos plenópticos

Publications (1)

Publication Number Publication Date
BR102021006869A2 true BR102021006869A2 (pt) 2022-10-18

Family

ID=83602804

Family Applications (1)

Application Number Title Priority Date Filing Date
BR102021006869-8A BR102021006869A2 (pt) 2021-04-09 2021-04-09 Método de transformada hardware-friendly em codecs para nuvens de pontos plenópticos

Country Status (2)

Country Link
US (1) US11638035B2 (pt)
BR (1) BR102021006869A2 (pt)

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7296045B2 (en) * 2004-06-10 2007-11-13 Hasan Sehitoglu Matrix-valued methods and apparatus for signal processing
US8995532B2 (en) 2010-09-30 2015-03-31 Texas Instruments Incorporated Low complexity large transform
US10642921B2 (en) 2011-11-03 2020-05-05 Texas Instruments Incorporated Unified forward and inverse transform architecture
US9179162B2 (en) 2011-12-02 2015-11-03 Futurewei Technologies, Inc. Image transform zero coefficient selection and zero-skip transmission for arbitrary shape transform coding
US10853973B2 (en) 2018-10-03 2020-12-01 Apple Inc. Point cloud compression using fixed-point numbers
US11373338B2 (en) 2019-01-09 2022-06-28 Samsung Electronics Co., Ltd. Image padding in video-based point-cloud compression CODEC
WO2021194069A1 (ko) * 2020-03-23 2021-09-30 엘지전자 주식회사 포인트 클라우드 데이터 송신 장치, 포인트 클라우드 데이터 송신 방법, 포인트 클라우드 데이터 수신 장치 및 포인트 클라우드 데이터 수신 방법

Also Published As

Publication number Publication date
US20220337874A1 (en) 2022-10-20
US11638035B2 (en) 2023-04-25

Similar Documents

Publication Publication Date Title
US10528004B2 (en) Methods and apparatus for full parallax light field display systems
Hou et al. Light field image compression based on bi-level view compensation with rate-distortion optimization
EP2096870A2 (en) Systems and methods for processing multiple projections of video data in a single video file
US20230050860A1 (en) An apparatus, a method and a computer program for volumetric video
CN115152224A (zh) 使用分层分级编码进行点云压缩
US11711535B2 (en) Video-based point cloud compression model to world signaling information
BR102020020345A2 (pt) Método para compressão de nuvens de pontos
EP4154531A1 (en) Decoded tile hash sei message for v3c/v-pcc
US10904579B2 (en) Method and apparatus for annealing iterative geometry smoothing
WO2021176133A1 (en) An apparatus, a method and a computer program for volumetric video
BR102021006869A2 (pt) Método de transformada hardware-friendly em codecs para nuvens de pontos plenópticos
CN113228665A (zh) 用于处理配置数据的方法、设备、计算机程序和计算机可读介质
US11308584B2 (en) Method and apparatus for denoising video content
US20210400295A1 (en) Null tile coding in video coding
US11250594B2 (en) Method and apparatus for geometry smoothing by local geometry projection
US20230379495A1 (en) A method and apparatus for encoding mpi-based volumetric video
US11683523B2 (en) Group of pictures based patch packing for video based point cloud coding
US11979606B2 (en) Conditional recolor for video based point cloud coding
US11956478B2 (en) Method and apparatus for point cloud chunking for improved patch packing and coding efficiency
US20220394295A1 (en) Fast recolor for video based point cloud coding
US20240214534A1 (en) Low complexity multilayer images with depth
EP4199516A1 (en) Reduction of redundant data in immersive video coding
JP2024519659A (ja) 奥行きを持つ低複雑度マルチレイヤ画像
CN116188682A (zh) 一种基于动态感知机图的实时渲染方法及装置
CN116235497A (zh) 一种用于用信号通知基于多平面图像的体积视频的深度的方法和装置

Legal Events

Date Code Title Description
B03A Publication of a patent application or of a certificate of addition of invention [chapter 3.1 patent gazette]