O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.

Mapeamento de tom de luminância HDR para uma faixa compatível com SDR

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

O Android 13 apresenta uma biblioteca estática configurável pelo fornecedor chamada libtonemap , que define as operações de mapeamento de tons e é compartilhada com o processo SurfaceFlinger e as implementações do Hardware Composer (HWC). Esse recurso permite que os OEMs definam e compartilhem seus algoritmos de mapeamento de tom de exibição entre a estrutura e os fornecedores, diminuindo a incompatibilidade no mapeamento de tom.

Antes do Android 13, as operações de mapeamento de tons específicos da tela não eram compartilhadas entre o HWC, SurfaceFlinger e aplicativos. Dependendo do caminho de renderização, para conteúdo HDR, isso levava a incompatibilidades na qualidade da imagem, onde o conteúdo HDR era mapeado em tons para um espaço de saída de diferentes maneiras. Isso foi perceptível em cenários como rotação de tela, onde a estratégia de composição muda entre a GPU e a DPU, e nas diferenças no comportamento de renderização entre TextureView e SurfaceView.

Esta página descreve os detalhes da interface, customização e validação da biblioteca libtonemap .

Interface para a biblioteca de mapeamento de tons

A biblioteca libtonemap contém implementações suportadas por CPU e shaders SkSL, que podem ser conectados pelo SurfaceFlinger para composição de back-end de GPU e pelo HWC para gerar uma tabela de pesquisa de mapeamento de tons (LUT). O ponto de entrada para libtonemap é android::tonemap::getToneMapper() , que retorna um objeto que implementa a interface ToneMapper .

A interface ToneMapper suporta os seguintes recursos:

  • Gerar uma LUT de mapeamento de tom

    A interface ToneMapper::lookupTonemapGain é uma implementação da CPU do shader definido em libtonemap_LookupTonemapGain() . Isso é usado por testes de unidade na estrutura e pode ser usado por parceiros para obter assistência na geração de uma LUT de mapeamento de tom dentro de seu pipeline de cores.

    libtonemap_LookupTonemapGain() recebe valores de cores em espaço linear absoluto e não normalizado, tanto em RGB linear quanto em XYZ, e retorna um float descrevendo quanto multiplicar as cores de entrada no espaço linear.

  • Gerar um sombreador SkSL

    A interface ToneMapper::generateTonemapGainShaderSkSL() retorna uma string de sombreador SkSL, dado um espaço de dados de origem e destino. O shader SkSL está conectado à implementação Skia para RenderEngine , o componente de composição acelerado por GPU para SurfaceFlinger. O shader também é conectado ao libhwui , para que o mapeamento de tom HDR para SDR possa ser executado de forma eficiente para TextureView . Como a string gerada é alinhada em outros sombreadores SkSL usados ​​pelo Skia, o sombreador deve seguir as seguintes regras:

    • A string do sombreador deve ter um ponto de entrada com a float libtonemap_LookupTonemapGain(vec3 linearRGB, vec3 xyz) , onde linearRGB é o valor dos nits absolutos dos pixels RGB no espaço linear e xyz é linearRGB convertido em XYZ.
    • Quaisquer métodos auxiliares usados ​​pela string de sombreador devem ser prefixados com a string libtonemap_ para que as definições de sombreador de estrutura não entrem em conflito. Da mesma forma, os uniformes de entrada devem ser prefixados com in_libtonemap_ .
  • Gerar uniformes SkSL

    A interface ToneMapper::generateShaderSkSLUniforms() retorna o seguinte, dada uma struct de metadados que descreve metadados de diferentes padrões HDR e condições de exibição:

    • Uma lista de uniformes vinculados a um shader SkSL.

    • Os valores uniformes in_libtonemap_displayMaxLuminance e in_libtonemap_inputMaxLuminance . Esses valores são usados ​​por sombreadores de estrutura ao dimensionar a entrada para libtonemap e normalizar a saída conforme aplicável.

    Atualmente o processo de geração de uniformes é agnóstico para o espaço de dados de entrada e saída.

Costumização

A implementação de referência da biblioteca libtonemap produz resultados aceitáveis. No entanto, como o algoritmo de mapeamento de tom usado pela composição da GPU pode ser diferente daquele usado pela composição da DPU, o uso da implementação de referência pode causar cintilação em alguns cenários, como a animação de rotação. A personalização pode resolver esses problemas de qualidade de imagem específicos do fornecedor.

Os OEMs são fortemente encorajados a substituir a implementação de libtonemap para definir sua própria subclasse ToneMapper , que é retornada por getToneMapper() . Ao personalizar a implementação, espera-se que os parceiros façam o seguinte:

  • Modifique a implementação de libtonemap diretamente.
  • Defina sua própria biblioteca estática, compile a biblioteca como independente e substitua o arquivo .a da biblioteca libtonemap por um gerado a partir de sua biblioteca personalizada.

Os fornecedores não precisam modificar nenhum código do kernel, mas vários fornecedores devem comunicar detalhes sobre os algoritmos de mapeamento de tons DPU para implementação adequada.

Validação

Siga estas etapas para validar sua implementação:

  1. Reproduza vídeos HDR na tela de qualquer padrão HDR compatível com seu sistema de exibição , como HLG, HDR10, HDR10+ ou DolbyVision.

  2. Alterne a composição da GPU para garantir que não haja cintilação perceptível pelo usuário.

    Use o seguinte comando adb para alternar a composição da GPU:

    adb shell service call SurfaceFlinger 1008 i32 <0 to enable HWC composition,
    1 to force GPU composition>
    
    

Problemas comuns

Os seguintes problemas podem ocorrer com esta implementação:

  • A formação de faixas é causada quando o destino de renderização usado pela composição da GPU é de menor precisão do que o valor típico para conteúdo HDR. Por exemplo, a formação de faixas pode ocorrer quando uma implementação de HWC oferece suporte a formatos opacos de 10 bits para HDR, como RGBA1010102 ou P010, mas exige que a composição da GPU grave em um formato de 8 bits, como RGBA8888, para oferecer suporte a alfa.

  • Uma mudança sutil de cor é causada por diferenças de quantização se o DPU operar com uma precisão diferente da GPU.

Cada um desses problemas está relacionado às diferenças de precisão relativa do hardware subjacente. Uma solução típica é garantir que haja uma etapa de pontilhamento nos caminhos de precisão mais baixa, tornando as diferenças de precisão menos perceptíveis para humanos.