Mapowanie tonów w zakresie luminancji HDR do zakresu zgodnego z SDR

Android 13 wprowadza pakiet statyczny, który można skonfigurować przez dostawcę biblioteka o nazwie libtonemap, która definiuje operacje mapowania tonów i jest udostępniana z procesem SurfaceFlinger i implementacjami Hardware Composer (HWC). Ta funkcja umożliwia producentom OEM definiowanie i udostępnianie mapowania tonalnego wyświetlacza między algorytmami platformy a dostawcami, co ogranicza niezgodności w tonach. z mapowaniem.

Przed Androidem 13 mapowanie tonów charakterystyczne dla wyświetlaczy między HWC, SurfaceFlinger i aplikacjami. W zależności na ścieżce renderowania, w przypadku treści HDR, co prowadziło do niedopasowań w jakości obrazu. w których kolor treści HDR był zmapowany na przestrzeń wyjściową na różne sposoby. Ten jest zauważalna w takich sytuacjach, jak obrót ekranu, i zmianach strategii między GPU i DPU oraz z różnicami w renderowaniu między właściwościami TextureView i SurfaceView.

Na tej stronie opisujemy interfejs, a także informacje o dostosowywaniu i szczegółach weryfikacji Biblioteka libtonemap.

Interfejs z biblioteką mapowania tonów

libtonemap zawiera implementacje oparte na CPU i cieniowanie SkSL, został przesłany przez SurfaceFlinger na potrzeby kompozycji backendu dla GPU oraz HWC generując tabelę wyszukiwania mapowania tonów (LUT). Punkt wejścia do: libtonemap to android::tonemap::getToneMapper(), która zwraca obiekt implementuje interfejs ToneMapper.

Interfejs ToneMapper obsługuje te funkcje:

  • Wygeneruj LUT odzwierciedlający ton

    Interfejs ToneMapper::lookupTonemapGain jest procesorem implementacja cieniowania zdefiniowanego w tabeli libtonemap_LookupTonemapGain(). Ten jest używany w testach jednostkowych w ramach platformy. Partnerzy mogą go używać do pomaga wygenerować LUT odwzorowywany w ramach potoku kolorów.

    libtonemap_LookupTonemapGain() przyjmuje wartości koloru bezwzględne, nieznormalizowana przestrzeń liniowa, zarówno w liniowej przestrzeni RGB, jak i w XYZ, zwraca liczbę zmiennoprzecinkową określający, jak bardzo należy mnożyć kolory wejściowe w przestrzeni liniowej.

  • Wygeneruj program do cieniowania SkSL

    Interfejs ToneMapper::generateTonemapGainShaderSkSL() zwraca błąd Ciąg znaków cieniowania SkSL dla źródłowej i docelowej przestrzeni danych. Moduł cieniowania SkSL to w implementacji Skia w RenderEngine. z komponentem komponowania przyspieszanym za pomocą GPU. Działanie cieniowania podłączone do urządzenia libhwui, aby możliwe było wydajne mapowanie tonów z HDR na SDR w TextureView. Wygenerowany ciąg jest wbudowany w inne cieniowanie SkSL używane przez Skia, program do cieniowania musi przestrzegać tych zasad:

    • Ciąg znaków cieniowania musi mieć punkt wejścia z ciągiem float libtonemap_LookupTonemapGain(vec3 linearRGB, vec3 xyz) podpis, gdzie: linearRGB to wartość bezwzględnych nitów pikseli RGB w przestrzeni liniowej a xyz to linearRGB przekształcone w XYZ.
    • Wszystkie metody pomocnicze używane przez ciąg cieniowania muszą mieć prefiks libtonemap_, aby nie kolidowały ze sobą definicje funkcji cieniowania platformy. Analogicznie, określenie uniformy wejściowe musi mieć poprzedzony prefiksem in_libtonemap_.

  • Wygeneruj stroje SkSL

    Interfejs ToneMapper::generateShaderSkSLUniforms() zwraca wartość poniżej, biorąc pod uwagę metadane struct opisujące metadane z różnych formatów HDR standardów wyświetlania i warunków wyświetlania:

    • Lista uniformów objętych cieniowaniem SkSL.

    • Jednolite wartości in_libtonemap_displayMaxLuminance i in_libtonemap_inputMaxLuminance Te wartości są używane przez cieniowanie platformy przy skalowaniu danych wejściowych do funkcji libtonemap i normalizowaniu danych wyjściowych jako mają zastosowanie.

    Obecnie proces generowania uniformów jest niezależny od danych wejściowych wyjściowej przestrzeni danych.

Dostosowywanie

Referencyjna implementacja biblioteki libtonemap daje akceptowalne wyniki. Pamiętaj jednak: bo algorytm mapowania tonów używany przez układ GPU może się różnić stosowane przez kompozycję DPU, użycie implementacji referencyjnej może spowodować, w niektórych sytuacjach, np. podczas animacji obrotu, migania lub migotania. Personalizacja może rozwiązywania takich problemów z jakością zdjęć specyficznych dla danego dostawcy.

Zdecydowanie zalecamy producentom OEM zastąpić implementację libtonemap w definiują własną podklasę ToneMapper, która jest zwracana przez funkcję getToneMapper(). Podczas dostosowywania implementacji partnerzy muszą wykonać jedną z tych czynności: :

  • Bezpośrednio zmień implementację elementu libtonemap.
  • zdefiniować własną bibliotekę statyczną, skompilować ją jako samodzielną i zastąp plik .a biblioteki libtonemap plikiem wygenerowanym na podstawie własnych ustawień bibliotece.

Dostawcy nie muszą modyfikować żadnego kodu jądra, ale wielu z nich musi to robić Podaj szczegółowe informacje o algorytmach mapowania tonów DPU, aby zapewnić implementacji.

Weryfikacja

Aby sprawdzić poprawność implementacji, wykonaj te czynności:

  1. Odtwarzaj filmy HDR na ekranie zgodnie ze standardem HDR, który obsługuje Twój system, takich jak HLG, HDR10, HDR10+ czy DolbyVision.

  2. Włącz lub wyłącz kompozycję GPU, aby mieć pewność, że nie widać migotania.

    Aby włączyć lub wyłączyć kompozycję GPU, użyj tego polecenia adb:

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

Typowe problemy

W przypadku takiej implementacji mogą wystąpić te problemy:

  • Pasy powstają, gdy cel renderowania używany przez kompozycję GPU jest mniejszy bardziej precyzyjną niż typowa dla treści HDR. Na przykład pasy występują wtedy, gdy implementacja HWC obsługuje nieprzezroczyste 10-bitowe formaty HDR, takie jak RGBA1010102 lub P010, ale wymaga zapisywania kompozycji GPU w formacie 8-bitowym np. RGBA8888 z obsługą wersji alfa.

  • Subtelne przesunięcie kolorów jest spowodowane różnicami w kwantyzacji, jeśli DPU działa z inną precyzją niż GPU.

Każdy z tych problemów wiąże się ze względnymi różnicami precyzji bazowego sprzętu. Typowym sposobem obejścia tego problemu jest zapewnienie na ścieżkach o niższej precyzji, przez co różnice w precyzji jest zauważalna.