Images HDR linéaires semi-flottantes 16 bits sous forme de textures (diffuses / albédo)?


10

Donc, j'y réfléchissais depuis un moment et j'ai essayé de chercher une réponse sur Google, mais sans succès.

Si toutes vos textures sont des images LDR 8 bits, comme les JPEG, cela ne pourrait pas provoquer de conflits avec le contrôle de l'exposition / la cartographie des tons lors du rendu. C'est si vous ajustez l'exposition de rendu de votre image qui devrait exposer des détails dans les textures qui ne sont pas vraiment là, car ils ont été limités par la faible plage dynamique. Ne serait-il donc pas logique d'avoir également les textures sous forme d'images HDR, enregistrées au format .exr, dans un espace colorimétrique linéaire avec un demi-flottant de 16 bits pour obtenir une bonne représentation des couleurs (un flottant "complet" de 32 bits pourrait être exagéré?). Avoir des valeurs de couleur plus détaillées et correctes pourrait également, je suppose, avoir un effet sur l'IG et comment le fond perdu est-il calculé?

Ou n'est-ce tout simplement pas nécessaire puisque le résultat final du rendu que nous voulons sera probablement similaire au niveau d'exposition de la texture lorsqu'elle a été photographiée? Et puisque l'appareil photo prend principalement en 12-14 bits, vous devrez prendre plusieurs expositions de la texture et faire tout ce travail supplémentaire pour les assembler en un seul HDRI.

Edit: Pour clarifier, cela m'intéresse principalement d'un point de vue de rendu photo-réaliste, avec des rendus de trace de rayons (comme mental ray, V-Ray, Arnold, etc.) avec des simulations en pleine lumière et un éclairage global, plutôt que pour moteurs de jeu en temps réel.

Réponses:


8

Dans la production cinématographique, nous n'utilisons presque jamais de textures 8 bits pour la couleur / l'albédo, à cause des bandes, etc. (JPEG est particulièrement problématique car, par spécification, c'est sRGB plutôt que des valeurs linéaires.) Nous utilisons soit la moitié (flottant 16 bits ) ou des valeurs entières non signées 16 bits pour les textures couleur / albédo.


1
Wow, merci @LarryGritz! Étant donné que vous travaillez pour Sony Pictures Imageworks, je vais vous considérer comme une source très fiable! :) Mais comment capturez-vous ces textures? La plupart des caméras ne tournent que dans des fichiers RAW 14 bits, avez-vous des caméras spéciales avec des capteurs linéaires 16 bits? Ou prenez-vous plusieurs expositions pour les textures, tout comme on le fait pour l'éclairage basé sur l'image HDRI? Ou capturez-vous simplement avec un appareil photo RAW 14 bits et l'enregistrez-vous en "16 bits"? Ow, et quel format de fichier utilisez-vous, .tiff (.tx, .tex) ou .exr? Encore merci pour votre contribution!! :)
Kristoffer Helander

1
@KristofferHelander: La conversion d'une capture 14 bits en une représentation 16 bits de la plage 0-1 est facilement réalisée par multiplication. Mais la plupart de nos textures sont peintes, pas photographiées - parfois elles sont peintes directement au format 16 bits, parfois elles sont peintes en sRGB et ensuite converties en 16 bits lorsqu'elles sont "linéarisées" pour être utilisées comme texture. Il n'y a pas besoin de HDR pour les textures d'albédo.
Larry Gritz

1
@KristofferHelander: Pour les textures d'albédo, nous avons tendance à utiliser TIFF avec des données entières de 16 bits (ce que nous appelons .tx n'est que le format TIFF mais en mosaïque et avec la multirésolution MIP-map stockée sous forme de plusieurs sous-images dans le fichier TIFF). Pour les vraies données HDR, comme les captures d'environnement, nous utilisons OpenEXR. La sortie du rendu a également tendance à être OpenEXR.
Larry Gritz

8

Oui, dans certains cas extrêmes, l'éclairage HDR et le mappage de tonalité peuvent exposer les problèmes de bandes dans les textures de couleur. Dans ces cas, avoir une profondeur de bits plus élevée pour les textures pourrait être utile. Cependant, d'après mon expérience, la majorité des matériaux et des situations d'éclairage ordinaires ne présentent pas ce problème, et la plupart des textures dans un jeu typique sont fines en 8 bits (ou même moins - les jeux utilisent souvent la compression BC1, ce qui les réduit à 5 - 6-5 bits).

Les gens utilisent des cibles de rendu HDR car une seule scène peut contenir des amplitudes de luminosité très différentes, comme une pièce sombre dans laquelle vous pouvez voir à travers une fenêtre un extérieur ensoleillé 10 à 100 fois plus lumineux que la pièce. Cependant, les textures de couleur n'ont pas une telle gamme de magnitudes. Ils représentent des réflectances, qui sont intrinsèquement dans la plage [0, 1], et dans la pratique, peu de matériaux de tous les jours sont inférieurs à une réflectance d'environ 2 à 5%. Ainsi, une image 8 bits (avec codage gamma) peut généralement représenter des couleurs diffuses et spéculaires avec suffisamment de précision.

Il est vrai que la combinaison d'une texture assez sombre avec un éclairage très lumineux ou un réglage de caméra extrêmement surexposé peut montrer des bandes dans la dernière image, mais ce serait un cas plus inhabituel.

Un cas où vous voudriez probablement une texture HDR est des matériaux émissifs, en particulier pour les enseignes au néon et les sources de lumière similaires. La texture apparaîtrait avec sa valeur amplifiée pour apparaître comme une source de lumière vive dans le jeu, donc dans ce cas, une image 8 bits pourrait facilement montrer des bandes.

Enfin, il peut toujours être utile de travailler avec une précision plus élevée (par exemple une précision de 16 bits) si possible lors de la capture et de la création de textures, simplement parce que cela vous donne plus de marge pour traiter l'image sans causer de problèmes de précision. Par exemple, si vous devez ajuster les niveaux ou l'équilibre des couleurs, vous perdez un peu de précision; cela peut introduire des bandes (surtout si vous le faites plusieurs fois) lors du démarrage à partir d'une image source 8 bits. Une source 16 bits serait plus résistante à de tels problèmes. Cependant, la texture finale utilisée dans le jeu serait probablement compressée en 8 bits.


combination of a quite dark texture with very bright lighting or an extremely overexposed camera setting can show banding in the final frametrès bon aperçu. Mais nous pouvons noter que l'encodage gamma est précisément là pour atténuer ce point. S'il a le problème, pourquoi ne pas essayer un exposant gamma supérieur? cela empêcherait cependant l'utilisation d'échantillonneurs sRGB matériels.
v.oddou

Merci pour votre participation. Mais pour clarifier, je m'intéresse principalement à cela d'un point de vue de rendu photo-réaliste, avec des rendus de trace de rayons (comme mental ray, V-Ray, Arnold, etc.) avec des simulations en pleine lumière et un éclairage global, plutôt que pour de vrai moteurs de jeu en temps réel.
Kristoffer Helander

@KristofferHelander Bon à savoir, mais je pense que ce que j'ai écrit s'applique probablement aussi bien au rendu hors ligne. Mais j'avoue que je n'ai pas beaucoup d'expérience directe dans ce domaine.
Nathan Reed

@NathanReed Oui, vous avez certainement fait de très bons points là-bas :)
Kristoffer Helander

5

J'aimerais inviter les lecteurs à lire cet article sur la technologie de rastérisation du moteur Quake 2 expliquée en détail , s'ils ont le temps.

Si TLDR, veuillez faire attention à cette image: entrez la description de l'image ici

Ce que nous voyons, c'est le canal Albedo , c'est ce que vous voulez encoder en 16 bits si je comprends bien votre question.
Je ne vais pas dire " si cela pouvait être encodé en 256 couleurs pour les jeux dans le passé, pourquoi aurions-nous besoin de 281474976710656 (soit 281 billions) dans de nouveaux jeux? " Même si je le veux, mais cela ressemble au gars grincheux de Pixar En haut. Plus constructivement, si vous l'avez remarqué sur cette image, tout est au même niveau d'éclairage . Plus particulièrement, l'intensité maximale possible qui préserve la saturation souhaitée. (ce qui signifie dans l'espace HSV, V est au maximum)

L'accent est essentiel, nous avons à peine besoin de bits car l'albédo n'a de toute façon aucune profondeur à coder. La dynamique provient de l'ombrage, il est logique de travailler f32par composants dans les shaders et de produire des f16rendus de cibles. Mais stocker des textures d'albédo dans f16ce n'est pas seulement une surpuissance, c'est un porc de performances injustifié sévère pour notre précieuse bande passante.


Merci pour votre participation. Mais pour clarifier, je m'intéresse principalement à cela d'un point de vue de rendu photo-réaliste, avec des rendus de trace de rayons (comme mental ray, V-Ray, Arnold, etc.) avec des simulations en pleine lumière et un éclairage global, plutôt que pour de vrai moteurs de jeu en temps réel. J'ai mis à jour mon message d'origine.
Kristoffer Helander
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.