HDR

HDR / HDRI
(High Dynamic Range / High Dynamic Range Imaging)

Für diejenigen die HDR wirklich verstehen wollen und was HDR so anders macht

Ich lehne mich mal aus dem Fenster und behaupte, HDR ist nicht weniger als ein Paradigmenwechsel der bereits in vollem Gange ist.
Für die Nutzung des tatsächlichen Potentials einer PB Rendermaschine ist HDR schlichte Voraussetzung.

Alle hier gezeigten Bilder sind - um sie hier hochladen zu können - komprimierte JPEG Dateien, zeigen also nicht den vollen Farb und Kontrastumfang.
Wer ein Bild zum Vergleich in 100% JPEG oder 16Bit PNG haben möchte, meldet sich einfach.

HDR/I:

Das "I" steht für "Imaging" und bezeichnet damit nicht ein Bild, sondern den gesamten Entstehungs- und Bearbeitungsprozess eines "Hochkontrast Bildes" (HDR), beginnend mit dem Render oder Foto,
über Compositing und Tonemapping, bis hin zum klassischen Postwork.

Im professionellen CGI (Computer Generated Imaging) ist HDR bereits Standard, wo es u.a. für Special Effects, Texture Environments und globale Beleuchtungssysteme (GI / Global Illumination) zuständig ist.
Inzwischen stehen aber auch uns Laiendarstellern die technischen Mittel für HDR zur Verfügung - und zwar kostenlos
Wer eine PB Rendermaschine wie Octane, Iray oder andere verwendet, nutzt auch HDR. Möglicherweise ohne es zu wissen.

HDR kann auch digitaler Impressionismus bzw. Surrealismus sein und für den Hyperrealismus ist HDR eine wahre Goldgrube.
HDR ist nur ein Mittel. In der Hand eines Kreativen kann es auch zu darstellender Kunst werden.

Und HDR ist einfach. Denn erstens liefern physikalisch basierte Rendermaschinen ohnehin HDR Bilder, und zum anderen gibt es inzwischen etliche (teils kostenlose) und selbst für mich Anfänger leicht zu verstehende HDR Tools, mit denen sich beeindruckende Ergebnisse erzielen lassen.

Einleitend ein nur-mal-auf-die-Schnelle Beispiel.
Der Render kommt von Terragen4, welcher als klassisches LDR Bild so aussieht:

Diesmal jedoch speichere ich den Render im linearen 32Bit OpenEXR Format ab und öffne die HDR Datei anschließend in einem Tone Mapper,
wie z.B. Picturenaut, HDR Efecs Pro oder LuminanceHDR. Auch Postworker wie AffinityPhoto oder Photoshop, haben Tone Mapper an Bord.
Mehr dazu weiter unten im zweiten Post.

Jdenfalls, mit zwei drei schnell verstellten Reglern sortiere ich die Lichtwerte Verteilung (Farben sind auch Licht) und den Kontrast neu
und schon entstehen ganz andere bildliche Eindrücke oder sogar völlig andere Szenen.

Etwas Kühlers z.B. ...

...oder kitschige Farbdramatik...

...oder aus dem Sonnenuntergang Szenario mal eben eine Mondnacht gemacht...

...oder kein Foto, denn eher ein Gemälde.

Alles ohne Vorkenntnisse in Sachen Postwork, nur indem ich in den Tone Mappern ganz blauäugig ein par Regler verschiebe
Solche Veränderungen wären mit klassischen 8Bit LDR Formaten (JPG, PNG, TIFF usw.) so nicht möglich.
es wären gute Fachkenntnisse und ein erheblicherAufwand im Postwork erforderlich.

Warum? Weil eine 32Bit HDR Dateien alle Lichtinformationen eines Motivs beinhaltet, wogegen eine klassische LDR Dateien nur über einen Bruchteil davon verfügt.
Und ein Tone Mapper tut eigentlich nichts anderes als mit diesen Lichtinformationen zu spielen. Habe ich mehr davon, kann ich folglich mehr damit machen

Aber fangen wir vorne an...

Christian Bloch schreibt in seinem "HDRI Handbuch", Zitat:
„Licht ist das Wesentliche aller digitaler Bilder. Licht ist immer das zentrale Thema. Und HDRI ist die ultimative digitale Repräsentation von Licht"

Der CGI Artist wird es wissen und ich habe nun auch endlich begriffen, wie umfassend das Thema Licht in der digitalen Bilderstellung und Bearbeitung tatsächlich ist.

Was ist HDR?

Ein sicher nicht allzu korrekter, aber vielleicht verständlicher Erklärungsversuch:

High Dynamic Range bezeichnet einen hohen Dynamik Umfang bzw. Lichtwerte Umfang in einem digitalen Bild - auch Kontrastverhältnis genannt.
Dabei geht es um zwei Dinge. Zum einen um den möglichen maximalen sowie niedrigsten Helligkeitswert in einem Bild und zum anderen um die Anzahl differierender Lichtwerte dazwischen.

Beispiel:
ein ganz mieser Bildschirm kann, zwischen den beiden "Licht Werten" schwarz und weiß, neun weitere Lichtwerte oder Helligkeits- bzw. Graustufen darstellen.
Ungefähr so...

Die "Helligkeitsdifferenz" (Lichtwert Differenz) zwischen den beiden äußeren "Farben" schwarz und weiß wäre damit der höchste darzustellende Kontrast (hell/dunkel) in einem Bild.
Da aber noch 9 weitere Grautöne verfügbar und damit insgesamt 11 verschiedene Kontraststärken (Lichtwert Differenzen) möglich sind,
spricht man im hier vorliegenden Fall von einem Dynamikumfang bzw. einem Kontrastverhältnis von 11:1.

Das ist, wie unschwer zu erraten, nicht HDR. Denn der alleinige Maßstab ist die Wahrnehmungsfähigkeit unserer Augen und die können ein Kontrastverhältnis von rund 10.000:1 auflösen
Beeindruckende 10.000 Helligkeitsstufen zwischen weiß und schwarz können unsere Augen differenzieren. Dieses Kontrastverhältnis und höher bezeichnet man als High Dynamic Range (HDR).

Rechnen wir noch die globale und lokale Adaptionsfähigkeit, sowie die hohe Lichtempfindlichkeit (rund 30 Photonen) unserer Augen hinzu, heißt es mal locker 1.000.000.000:1
Keine Kamera der Welt kann so etwas. Doch, eine. Aber dazu später mehr

HDR ist also nicht irgendeine technische Utopie, sondern das was unsere Augen in der Realität wahrnehmen.

Das erste Probleme mit unseren bisherigen digitalen LDR Bildern, heißt Gamma Korrektur

Logarithmische und lineare Lichtwerteverteilung

Der Knackpunkt ist, dass die für unsere Augen unterschiedlich wahrnehmbaren (10.000+) Lichtwertstufen nicht gleichmäßig (linear) verteilt sind wie in dem Graustufenbild Beispiel oben.
Die Verteilung der einzelnen Lichtwerte in unserem gesamten Wahrnehmungsspektrum variieren oder genauer, sie sind logarithmisch verteilt.

Der Grund ist unsere schlaue Mutter Natur. Sie stellt uns in dem für unser Überleben wichtigsten mittleren bis dunklen Helligkeitsbereich, weit mehr Stufen zur Verfügung als in den sehr hellen Bereichen.
Die Verteilung der Lichtwerte ist grafisch gesehen keine Gerade, sondern eine Kurve. Hier habe ich diese kurzerhand selber zurechtgebogen.

Das Eingangsbild ist ein lineares HDR. Die diagonale Gerade wäre der lineare Lichtwerteverlauf.
Die weiße Linie ist die zurecht gebogene Gamma Kurve, auch Gradationskurve genannt.

Dummer Weise können die Sensoren unserer Consumer Digitalkameras auch dieses logarithmische Dingsbums nicht.
Der Kamera Sensor zeichnet die Lichtwerte (physikalisch durchaus korrekt) linear auf. Der Sensor ist dumm. Er zählt nur Photonen

Gammakorrektur: Zweck

Der Trick, der auf die lineare Lichtwerte Verteilung eines digitalen Fotografie oder eines Renders angewendet wird, heißt also Gammakorrektur.
Hier noch mal ein lineares HDR, also mit linearer Lichtwerteverteilung, wie es der Kamerasensor sieht...

...und hier inklusive Gammakorrektur, also logarhithmischer Lichtwerteverteilung.

Erst nach dieser Korrektur entspricht der Lichtwerteverlauf ungefähr dem wie ihn unsere Augen wahrnehmen und
das Bild wird auch für unseren Ausgabegeräten (z.B. Bildschirm, Drucker usw.) "normal" darstellbar.

Diese pauschale Tonwertkorrektur wirft aber unter anderem dieses Problem auf...

Gammakorrektur: Problem

Noch mal wie oben die lineare Lichtwerte Verteilung im Graustufen Beispiel...

...und hier eine mögliche gammakorrigierte Version.

Wie zu erkennen, wurden die Stufen in Richtung Mitte, also dem mittleren Helligkeitsbereich zusammengestaucht.
Damit sind in diesem Bereich mehr Lichtwerte verfügbar. In einem Bild könnten also dort mehr Details abgebildet werden.
Der Preis dafür ist ein Detailverlust in den hellen und dunklen Bereichen (Lichter/Tiefen) recht und links außen.

Vergleichen wir die lineare und gammakorrigierte Lichtwerteverteilung direkt...

...wird in dem sehr hellen Bereich rechts der roten Linie selbst für uns Laien verständlich, wo hier das "Gamma Problem" liegt.
Im linearen Balken (oben), habe ich dort immerhin 2 Helligkeitswerte zur Verfügung. Ich könnte zwei verschieden helle, also unterscheidbare Pixel darstellen.
Damit wäre immerhin die Zeichnung einer (wenn auch sehr einfachen) Struktur möglich.

Gammakorrigiert jedoch (Balken unten), verliere ich eine der ehemals 2 Lichtstufen in diesem Helligkeitsbereich.
Das bedeutet zwangsläufig, außer weiß, also einer durchgehend weißen Fläche, kann ich an dieser Stelle im Bild gar nichts mehr darstellen

Speicher ich dieses Bild nun im LDR Format, war's das mit den ehemals zwei möglichen Helligkeitswerten im Graustufen Beispiel oben,
bzw. zigtausenden von Lichtwerten in der digitalen Fotografie oder unserer 3D Render-Welt.
Der Verlust von möglichen Lichtwerten ist immer ein Verlust von möglichen Details in einem digitalen Bild.


Dennoch...

Gammakorrektur ist (bisher) bei LDR Bild Formaten (JPG. PNG usw.) notwendig und ein Standard. Auch digitale Kameras wenden (ohne Zutun des Fotografen) automatisch eine Gammakorrektur an,
sobald mit einem LDR Format abgespeichert wird. Einzig RAW ist ein Kamera Dateiformat, welches die Licht- und Farbinformationen "unverbogen" also linear abspeichert. Fotografen nennen das Sensor Rohdaten.

Alles ok soweit. Jedenfalls bis zu dem Zeitpunkt, an dem wir ein LDR Bild nacharbeiten wollen. Dort erst fangen die richtigen Probleme an.

Helle ich ein gammakorrigiertes LDR Bild in einem Bildbearbeitungsprogramm pauschal auf oder dunkle es ab, bekomme ich zwangsläufig Schwierigkeiten in den Lichtern oder Tiefen.
Ein Schwarz wird bestenfalls Grau aber meist eher zu einem Bildrauschen. Helle Bereiche fransen aus und sind irgendwie nur noch weiß, ohne jede Struktur.
Hellen wir ein Bild auf, müssten in den Tiefen eigentlich mehr Details erkennbar werden.
Da dort aber zu wenig Lichtwerte zur Verfügung stehen (um überhaupt mehr Detail zeichnen zu können) funktioniert das nicht.

Die softwaretechnischen Tricks, die professionelle Bildbearbeitungsprogramme drauf haben, um solche Informationslücken doch irgendwie wieder aufzufüllen,
helfen vielleicht die gröbsten Bildfehler (Bildrauschen, Artefakte, Tontrennungseffekte u.a.) zu kaschieren, den Felsbrocken aber,
der in der Realität im tiefen Schatten des Berges lag, können sie auch nicht zurück holen. Dieses Bilddetail wurden durch die Gammakorrektur zerstört,
der Felsen hat für das gammakorrigierte LDR Bild nie existiert. Wir wissen einfach nicht, was die Kamera dort seinerzeit wirklich "gesehen" hat.

Im nächsten Post 2 führe ich das mal vor...

HDR / HDRI

Post 2

Hier ein direkter "Aufhellungsvergleich" zwischen LDR und HDR, bei gleichem Motiv (Octane Render).
Hier geht es nicht um Schönheit, sondern nur darum, welches Bild "bearbeitungsfähig" wäre, um z.B. Tone Mapping Varianten wie bei den Bildern ganz oben zu erschaffen.

Das ist der Ursprungsrender (16Bit PNG), ganz bewusst mit extremer Lichtsituation:

Die dunklen, fast schwarzen Bereiche interessieren mich besonders. Mal sehen was in der Dunkelheit verborgen ist, also was die LDR bzw. das HDR Bild hergeben. Vielleicht ja ein Felsen.

Das Render Ergebnis habe ich zunächst in den drei zu vergleichenden Dateiformaten abgespeichert.

1. 8Bit PNG (LDR / Gammakorrigiert)
2. 16Bit PNG (LDR / Gammakorrigiert)
3. 32Bit OpenEXR (HDR / linear)

Alle drei Bilder habe ich dann in AffinityPhoto einer recht brutalen Aufhellung unterzogen.
Die Belichtung (Helligkeit) wurde bei jedem Bild um 5 Blendenstufen (LW) erhöht. Bei der linearen EXR noch zusätzlich eine Variante mit 10 LW.
Dabei werden die hellen Bereiche natürlich zerrissen. Aber ich will ja nur wissen, was in der Dunkelheit verborgen ist.

Dies sind die Resultate im klassischen 8Bit und 16Bit PNG Format:

Und hier für 32 Bit OpenEXR +5/10 LW

Die Ergebnisse sprechen für sich. In den gammakorrigierten 8 und 16Bit LDR Bildern hat ein grünes Feld nie existiert, obschon alle Bilder dem gleichen Render entstammen. Es stellt sich also immer die Frage, was für ein Bildformat liegt mir vor. Und wurde bereits eine Gammakorrektur angewendet oder nicht.

Es gibt noch ein weiteres digital-historisches Problem.

Denn wie oben schon mal gehört, es geht immer nur um Licht!
Physikalisch definiert sich Licht über seine Helligkeit (Wellenfrequenz) und die Farbe (Wellenlänge). Mehr ist es nicht. Und doch ist es alles.
In der Realität genauso wie in unseren Render Welten. Das zweite Problem bei LDR Bildern ist...

Der 8Bit RGB Farbraum

Der RGB (Rot/Grün/Blau) Farbraum definiert die Farbe und Helligkeit eines Bildpunktes, z.B. auf diesem Bildschirm.
CMYK und andere Farbräume (z.B. für das Druckgewerbe) interessieren zumindest mich eher weniger.

RGB 8Bit / 16Bit / 24Bit / 32Bit ...

Je mehr Bit umso besser. Soviel weiß selbst ich. Mein Betriebssystem rennt inzwischen mit 64Bit. Aber die Bilder wursteln immer noch mit 8 oder maximal 16 Bit pro Farbkanal rum Neben der Gammakorrektur haben wir hier das zweite Problem. Und beide bedingen einander.

Den allgemein gängigen sRGB Farbraum als 24Bit Format zu bezeichnen wäre Schönrederei, denn er besitzt drei Farbkanäle und jeder einzelne verfügt nur über 8Bit,
was nach Adam Riese ganze 256 Helligkeitsstufen je Farbe ermöglicht. Wir reden also über ein Kontrastverhältnis von 256:1 je Farbkanal gegenüber dem unserer Augen von 10.000:1 und mehr. Soviel zum schneidigen Begriff True Color

Dazu kommt, dass das RGB Format zwei klare Grenzen hat. Nichts ist heller als ein RGB weiß (255) und nichts dunkler als ein RGB schwarz (0).
Das bedeutet, unter extremen Lichtsituationen sind dem vielleicht notwendigen Verschieben (Adaption) des Lichtwerteumfangs in die eine oder andere Richtung verlustbringende Grenzen gesetzt. Lichtwerte die ich im Tonemapping über diese Grenze verschiebe und als LDR abspeichere, werden als nicht existent angesehen und einfach abgeschnitten Wir haben wieder Licht- und Farbinformationen verloren

Grundsätzlich gilt, entferne ich Farb- bzw. Lichtwertinformationen, z.B. durch Gammakorrektur, Tonemapping oder Postwork und speichere die Datei als LDR, sind diese zerstört und niemand kann sie wieder herbei zaubern. Deshalb nennt man HDRI auch zerstörungsfreie Bildbearbeitung

Das 32Bit RGBA Format verfügt je Farbe auch nur über 8Bit. Die in dem Fall vierten 8Bit (4x8=32) sind für den Alphakanal (Transparenz Masken) zuständig.
Am schwachen LDR Kontrastverhältnis ändert sich also auch bei diesem "32Bit" Format nichts.

Auch 16Bit PNG Dateien liefern zwar ein par Bit mehr für die möglichen Farbwerte, sind aber ebenfalls nach oben und unten (0 bis 255) begrenzt, sowie Gammakorrektur verseucht und...

Jeder LDR Datei fehlt die Gleitkomma Option!

Gleitkomma?!

Beispiel:
nach dem Helligkeitswert Blau 212 kommt unvermeidlich der Helligkeitswert Blau 213, obwohl wir an dieser Stelle im Bild vielleicht einen Helligkeitswert Blau 212,5 bräuchten Pech gehabt. Wir haben die Wahl zwischen einem falschen Blau 212 oder dem falschen Blau 213. Blau 212,5 oder gar 212,7012 sind nicht lieferbar, weil Gleitkommaarithmetik bei 8Bit RGB nicht vorhanden

Es gibt Gleitkomma TIFFs und auch noch andere Formate mit dieser Option. Jedoch sind das allesamt Speichermonster und somit für uns kaum brauchbar.
Nach Möglichkeit will ich die Veränderungen, z.B. beim Tone Mapping, in Echtzeit sehen, und nicht jedes mal eine Kaffeepause einlegen müssen, wie manche das vom Rendern kennen

HDR durch Belichtungsreihen (Compositing)

Diese Lösung haben Fotografen erfunden und der Trick ist vom Grundsatz her recht simpel.
Ich fotografiere - möglichst auf Stativ - ein Motiv mindestens 3 mal, wobei die zweite und dritte Belichtung mindestens eine Lichtwertstufe (über Verschlusszeit) unter bzw. über der Erstaufnahme liegt. Damit habe ich quasi den Dynamikumfang in beide Richtungen verlängert. Auf dem kürzer belichteten Bild habe ich mehr Lichtinformationen (Details) in den Lichtern, auf dem länger belichteten Bild wiederum mehr davon in den Tiefen.

Dummerweise sind es aber 3 Bilder Die simple Lösung: Compositing Mehr dazu erzählt Euch Tante Wickie und Oma Google

HDR Kamera?

Mittlerweile hat jede bessere DSLR (und sogar Smartphones) eine eingebaute "HDR Funktion", was aber nur bedeutet, dass die Kamera automatisch mehrere (unterschiedliche) Belichtungen vornimmt, wenn dies vorher eingestellt wurde. Eine echte HDR Kamera, also eine Kamera, die mit einer einzigen Belichtung den gesamten verfügbaren Lichtwerteumfang des Motivs aufnehmen und speichern kann, gibt es nicht. Jedenfalls nicht im Consumer Bereich.

....ähhhh doch, eine gibt es!

HDR Rendering

Eine 3D Renderkamera (PBR) kann tatsächlich mit einer "Aufnahme" einem unseren Augen entsprechenden Lichtwerteumfang erfassen und speichern, mit einem Kontrastverhältnis von bis zu 1.000.000:1 Rendermaschinen arbeiten bereits seit Jahren mit 32Bit. Aber erst das physikalisch basierte Rendern (PBR) in Verbindung mit HDR Dateiformaten nutzt dieses Potential und öffnet uns damit Türen zu neuen Gefilden

Die entscheidenden Vorteile des Themas HDR in 3D verteilen sich für mich (bisher) auf vier Bereiche:

1. HDR Bilder rendern (Octane3) Denn das tun PB Rendermaschinen.
2. Echtzeit Imaging (ähnlich Tone Mapping) im laufenden Render (Octane3)
3. 32Bit HDR Ausgabeformat OpenEXR für späteres HDR-Tonemapping, Compositing oder Postwork (AffinityPhoto)
4. HDRI global lighting (Octane3)
5. Rendern sphärischer HDR Bilder für den Einsatz in anderen 3D Szenen als HDR Environments und globale Beleuchtung (Terragen 4 pro)

Jeder wird hier noch andere Bereiche finden und seine eigenen Schwerpunkte setzen.

HDR Dateiformate

Der Unterschied? Na der Dynamikumfang

Man sagt, der Blick auf ein HDR Bild sei wie der Blick durch ein offenes Fenster.

Radiance / .hdr

Der Urvater aller HDR Formate von Greg Ward. Der Witz ist, dass eine Radiance (.hdr) auch nur 3 Farbkanäle besitzt (RGB) und jeder Kanal ebenfalls nur über 8Bit verfügt. Der Trick ist der vierte Kanal, in den Exponenten geschrieben werden, die auf jeden Farbwert in jedem Farbkanal wirken. Es stehen also nicht 255 Helligkeitsstufen pro Farbe zur Verfügung, sondern Ende offen Das ist alles. Und damit sind Kontrastverhältnisse möglich die in die Fantastillionen gehen
Nachteil des .hdr Formates sind Unmengen ungenutzter Werte, welche jedoch durch eine Kompression im Speichervorgang auf einen minimalen Wert geschrumpft werden können.

OpenEXR / .exr

Das Format OpenEXR (.exr) arbeitet mit 16Bit je Farbkanal, was unter Gleitkomma Berücksichtigung über 1 Mrd. Farben ermöglicht, unabhängig von der Lichtwertstufe! Das darstellbare Kontrastverhältnis reicht bis über eine Million:1 und ist damit für alle Zwecke mehr als genug. OpenEXR kann auch verlustfrei als ZIP archiviert werden.

OpenEXR scheint sich zu einem Standard entwickelt zu haben. Auch PIXAR und andere Film- bzw. Special Effects Studios arbeiten mit OpenEXR. Kein Wunder. Schließlich kommt OpenEXR aus dieser Branche. Andere HDR Formate wie z.B. Gleitkomma TIFF oder TIFF logluv sind (wie bereits gesagt) Speichermonster und im Consumer Bereich nur wenig oder gar nicht verbreitet.

Entscheidend ist, dass in einer HDR Datei alle Bildinformationen enthalten sind und die Datei, im Gegensatz zu RAW, keinen Konverter benötigt.

Tone Mapping[ (Tonwert Umsetzung)

Tone Mapper versetzen die Tonwerte in einem Bild. Es sind Operatoren, also mathematische Funktionen, die mit der Lichtwerteverteilung spielen.
Im Gegensatz zum klassischen LDR Postwork jedoch zerstörungsfrei, weil HDR. Man nennt sie auch Dynamik Kompressoren, weil sie am Ende ein LDR ausgeben.

Es gibt sie als globale und lokale Operatoren (vgl. Auge: globale und lokale Adaption). Diese Kontrast Trick Kisten sind echt cool und einige gute auch kostenlos, wie der o.g. Picturenaut oder Luminance HDR. In Affinity Photo und auch Photoshop sind solche Mapper bereits eingebaut. Wer nicht den pauschalen Gammastempel auf sein Bild gedrückt haben will, macht Tone Mapping. Selbst ich selbsterklärter nicht-Postworker Weil's so beeindruckend und so einfach ist Siehe die ersten Bilder ganz oben oder die Folgenden.

Tone Mapper pressen also den Dynamikumfang eines HDR zurück in die klassische, also kapazitiv begrenzte 8/16Bit LDR Kiste, mit dem lächerlichen Kontrastverhältnis von 256:1 pro Kanal, damit wir uns das Ergebnis (auch ohne UHD Bildschirm) ansehen können. Natürlich gehen auch dabei Bildinformationen verloren. Aber im Gegensatz zu automatischer Gammakorrektur, entscheide ich welche Tonwerte rausfliegen und welche drin bleiben.

Noch ein Beispiel dazu: Hier habe ich Octane die automatische Gammakorrektur überlassen...

Und bei diesem Bild habe ich entschieden wie die Tonewerte verteilt werden...

Zu viel Sättigung? Beim Tonemapping (im Gegensatz zum Compositing) gibt es kein richtig oder falsch.
Tonemapping heißt, Krativität ohne Grenzten und allein der Betrachter entscheidet ob es ihm gefällt oder nicht.

Voll die Farben, ey! Weil es einfach Spaß macht Man beachte die Stickerei auf dem Hut.
Dieses Blau oben auf dem Hut z.B., habe ich so auf meinem Bildschirm noch nie gesehen. Ist allerdings auch ein UHD Monitor. Ich weiß nicht ob das bei normalen Monitoren auch so rüber kommt. Die JPEG Komprimierung nach hier hat dem Bild ohnehin schon viel genommen. Glaubt mir einfach, dass es klasse aussieht.

In diesem Fall habe ich übrigens Picturenaut verwendet.
Ein kleines aber geniales Programm incl. 4 verschiedener Tonemapper (Operatoren)

Hier eine kurze...

Picturenaut Einweisung:

Wenn das (lineare) HDR Bild geladen ist und auf Tone Mappen gedrückt wurde, zeigt das Histogramm (3) die Lichtwerteverteilung im 8/16Bit RGB Farbraum (0-255) für das zu erstellende LDR Bild an. Dort zunächst unter Luminance (2) den Schwarz- und Weißpunkt korrekt setzen, also an die ersten nennenswerten Lichtwerte heran schieben. Cool ist, dass ich diese auch für jeden der drei Farbkanäle RGB (2) getrennt setzen kann und Picturenaut mir immer die Veränderungen im Histogramm als auch dem Vollbild in Echtzeit präsentiert. Mit den vier verschiedenen Operatoren (1) lassen sich die dollsten Licht- und Kontrastvarianten zaubern.

Picturenaut ist für HDR Anfänger genau das richtige Programm um auf Anhieb zu verstehen, was da eigentlich abläuft, denn er zeigt es mir in Echtzeit.
Verändere ich z.B. die Belichtungszeit, sehe ich - neben der Veränderung im Vorschau Bild - auch im Historgramm wie sich die Lichtwerte Verteilung ändert, usw. ...

Postwork

Im klassischen 32Bit HDR Postwork, läuft es genauso. Helle ich ein HDR Bild auf oder dunkle es ab, (siehe LDR/HDRVergleichsbilder oben) funktioniert es plötzlich so wie schon immer gewünscht Jetzt tauchen tatsächlich Details in sehr hellen oder sehr dunkeln Bereichen auf, die vorher nicht da waren, weil sie in einem LDR Format auch tatsächlich nicht existierten.

Zauberei? Nein. Nur mehr Lichtinformationen. Zerstörungsfreie Bildbearbeitung eben Heißt weniger Artefakte, kaum noch Bildrauschen, keine Zahnlücken im Histogramm und all die anderen Probleme mit denen Postworker sich bei einer LDR Bildbearbeitungen rumschlagen müssen.

Das Ende der Gammakorrektur?

Nun ja, es wird wohl noch etwas dauern, bis HDR Dateiformate zum "Ausgabe Standard" für alle beteiligten Geräte werden. Aber er wird kommen.
Die ersten bezahlbaren HDR PC Monitore (UHD) stehen bereits in den Läden. Auch HDR TV Screens gibt es bereits, basieren aber auf anderen Techniken und Farbsystemen.

Ich will aber nicht compositen oder postworken. Ich will nur gute Render erstellen!

Tja, der Spruch könnte von mir sein Deshalb werde ich (beizeiten) noch einen dritten Post nachschieben,

wie ich in meiner Renderengine Octane bereits "tone mappe", und zwar während der Render noch läuft

Ok, wie angekündigt, hier der dritte Post...

Nachfolgendes gilt für Octane, iRay, Cycles oder jede andere PB Rendermaschine.
Außerdem arbeite ich mit dem Octane DAZ Studio Plugin. Die Settings und Möglichkeiten sind aber dieselben wir in der Standalone Version.

HDR im PB Rendering

Was wir rendern ist ein HDR Bild Das sollte man zunächst einmal wissen. PB Rendermaschinen arbeiten seit ihrer Erfindung, also seit Radiance aus den 80ern, in einem linearen 32Bit Farbraum (s. Post 2).
Was wir auf unseren Bildschirmen zu sehen bekommen ist natürlich ein gammakorrigierte Version, damit das Bild auf unseren LDR Ausgabegeräten "normal" aussieht.
Tatsächlich handelt es sich aber (innerhalb der Renderengine) um ein HDR Bild, mit all den Licht- bzw. Farbinformationen die ein linearer Workflow (HDRI) so spannend machen.
Speicher ich das Renderergebnis als 32Bit EXR und betrachte das Bild anschließend in einem HDR Viewer, sehe ich das, was Octane tatsächlich gerendert hat.
Ein lineares HDR Bild. Also so ein seltsam dunkles Bild...

...aber eben das ultimative, physikalisch korrekte "Lichtbild", mit dem sich so viele tolle Sachen machen lassen

Drei PBR/HDR Anfänger Erkenntnisse:

1. Echtzeit Tonemapping im Render
2. HDR Environment / Light
3. Texturen und die leidige Gammakorrektur

HDR Echtzeit Tonemapping

Gibt's so was?! Und was soll das überhaupt heißen?

Ich fang mal so rum an. Betrachten ich den "Imager" in Octane...

...erinnert der irgendwie an eine Digitalkamera. Und virtuell ist er auch genau das.

Ganz oben in den Imager Settings (1) kann ich die Belichtungszeit (2) verändern, an meiner Kamera ist das der Knopf für die Verschlusszeit.
High Light Compression (3) gibt's ebenfalls in den Programm Einstellungen meiner DSLR (Digitale Spiegelreflex Kamera).
Verschiedene Filmmaterialien (4) gibt es, bzw. gab es zu Zeiten der analogen Fotografie ebenfalls. Für einen Weißabgleich benutzen Fotografen Graukarten,
für mich geht das komfortabler über die White Point Festlegung (5). Aber ganz nebenbei: ich könnte auch eine virtuelle Graukarte (Plane) im 3D Raum benutzen und auf diese den Weißabgleich machen (Picker).
Vignettierung (6) ist bei realen Kameras die Bildrandabschattung, welche bei Teleobjektiven auftreten kann. ...oder bei Blödmännern wie mir, die vergessen die Sonnenlichtblende abzuschrauben.
Saturation/Sättigung (7) kann ich ebenfalls in meinem DSLR Programm manipulieren. Selbst Hotpixel (8) kennt auch eine Digitalkamera, nur nennt man sie dort "Sensorfehler".
Der Render läuft seit ein par Sekunden (10) aber das Licht scheint soweit zu stimmen. Auf die Gammakorrektur (9) komme ich weiter unten zurück.

Das geniale ist, das ich all die genannten Werte manipulieren kann, ohne dass der Render neu startet, ich also in diesem Fall noch mal 20 Min. Durchlauf abwarten müsste. Der Render im Bild ist zwar durch, aber immer noch aktiv. Würde ich jetzt die Frames erhöhen, würde er einfach weiter rendern.

Das Ergebnis ist mir nun zu dunkel. Ein Fotograf würde jetzt noch ein Bild mit längerer Belichtungszeit schießen müssen oder die RAW Datei nachbearbeiten.
Ich hingegen, verändere die Verschlusszeit ohne Neustart

Ich verlängere einfach die "Belichtungszeit" (1). Außerdem ist das Bild rotstichig, also manipuliere ich den Weißabgleich (2), was über den Picker (3) direkt im Render View möglich wäre oder aber, wie hier getan, über eine Erhöhung der Blau- und Grün Werte im RGB Farbraum (4).

Auch die anderen oben beschriebenen Bild Änderungen sind ohne Neustart möglich. Warum? Weil dem Render der lineare HDR Farbraum zu Grunde liegt
Die Farb- bzw. Lichtinformationen (Thema Tiefen und Lichter s.o. Post 2) sind also alle vorhanden. Der Render muss nicht neu berechnet werden.
Ich mache hier genau das, was ich mit einer EXR Datei in einem Tonemapper ebenfalls machen könnte...

Zerstörungsfreie Bildbearbeitung, oder anders ausgedrückt: HDRI

Jetzt noch die Sättigung ein wenig runter und die High Light Kompression erhöht damit der Rand des rückwärtigen Spot Kegels etwas weicher wird...

Auch dieses nun bereits "getonemappte" HDR Bild kann als EXR Datei gespeichert werden, denn ein externer Vollblut Tonemapper wie in Affinity Photo oder Photomatix kann ja noch viel mehr.
Eine klassische Bildoptimierung ist aber bereits in Octane möglich. Schöne Sache das

Welchen Sinn es hat direkt in der Renderengine zu tonemappen?
Bekanntlich gibt es im 3D Raum etliche Dinge mehr, die das Bild Ergebnis beeinflussen bzw. verändern.

Z.B. das eingesetzte Lichtsystem, die Kameraperspektive (1), die Blendeneinstellung (2) usw.. Diese Veränderungen erfordern dann allerdings einen Render Neustart (3).
Denn nun geht es um eine geometrische Neuberechnung (Perspektive) oder Unschärfendarstellung (Blende/Focus/DOF), die in den ursprünglichen Lichtinformationen natürlich nicht enthalten sein können.
Möglicherweise sehen Licht und Farben aber nun wieder ganz anders aus und ich möchte erneut Veränderungen im Imager/Tonemapper vornehmen.
Also erledige ich gleich beides in der Renderengine, denn genau hier hängt alles zusammen.

HDR Environment / HDR Light

Noch ein PB Rendermaschinen typischer HDR Setting Bereich.

HDR Environment ist das ultimative Licht für jede 3D Szene. Realitätsnaher Anspruch vorausgesetzt. Wer bewusst unrealistische Szenen rendert braucht kein HDR Licht. Genau genommen braucht derjenige nicht mal eine PB Rendermaschine. Denn physikalisch korrekt reagierendes Licht und Material (Reflektionen) sind möglicherweise unerwünscht.

Der Render hier soll aber realistisch wirken, also will ich das bestmögliche Licht. In diesem Fall ein HDR Studio Light.
Denn nicht zu vergessen, ähnlich wie HDR Bilder einen extremen Dynamikumfang besitzen, verfügen logischerweise auch HDR Lichter über einen hohen Dynamikumfang. Ein LDR Licht kann niemals eine so natürliche Beleuchtung liefern wie ein HDR Licht.

Im Octane Environment (1) wähle ich also die Art des Beleuchtungssystems (2), dann die Art der "Licht Textur", hier RGB Images (3) und anschließend eines von vielen
auf meiner Festplatte befindlichen HDR Bildern/Lichtern (4). Das war's schon. Und ich habe nichts an dem Licht manipuliert. Einfacher geht gute Beleuchtung wirklich nicht

Oder ich verwende ein HDRI "Bild" und bekomme neben gutem Licht auch gleich eine Umgebungsszenerie. Ebenfalls nur ein HDR Image, auf demselben Weg geladen.

...und schon steht das Vegas Girl bei bedecktem Himmel am Kölner Rheinufer und friert sich den Hintern weg

Schön schön. Leider heißt das aber nicht, dass es mit HDR in PB Rendermaschinen keine Probleme gäbe

Texturen und die leidige Gammakorrektur

Der ein oder andere wird vielleicht - ähnlich wie ich seinerzeit - an so manchem PB Render verzweifelt sein, weil das Bild irgendwie nicht stimmig sein wollte
Wildes Haare raufen und Rumfuhrwerken in den Material- und/oder Licht- und/oder Rendersettings waren die Folge. Und irgendwann hatte man dann ein mehr oder weniger akzeptables Ergebnis, ohne eigentlich zu wissen warum Bloß schnell abspeichern!

Das Problem ist so simpel wie bekannt. Zumindest für diejenigen, welche Post 1 und 2 aufmerksam gelesen und die Kernaussagen verstanden haben.
Ganz genau, ...die blöde Gammakorrektur und der noch blödere 8Bit RGB Farbraum!

HDR in PB Rendermaschinen ist ja gut und schön, aber was genau laden wir denn in unser Renderprogramm?
Und ich meine jetzt nicht das in Blender gebaute und Cycles gerenderte Auto. Da kann man kaum etwas falsch machen.
Ich meine komplexe Szenen, also die mit Stadt, Wald, Fluss, Raumschiff, Wolkenbruch, Hund und Genesis.
Und was laden wir auf der anderen Seite der Renderengine, also im Environemt?

Im schlimmsten Fall passt da nämlich gar nichts zusammen und ich pfusche den Render nur irgendwie zurecht und bekanntlich kostet genau das die meiste Zeit wenn es um schöne 3D Render geht.

Grund Nr. 1: wir arbeiten mit einer PB Rendermaschine im linearen HDR Raum, laden aber möglicherweise Texturen, die lediglich LDR Bilder sind und damit obendrein...

Grund Nr. 2: ...einer Gammakorrektur unterzogen wurden.

Was passiert jetzt beim rendern auf unserem Bildschirm?
Yop, die bereits gammakorrigierten Texturen bekommen ein zweite Gammakorrektur verpasst. Das kann also nicht gut gehen. Warum? Siehe Post 1 und 2.

Und zur vollständigen Verschlimmbesserung laden wir jetzt noch ein HDR Licht oder Environment Licht, welches ebenfalls (aus welchen Gründen auch immer) einer Gammakorrektur unterzogen wurde Ich habe dann nicht nur ein mieses Hintergrundbild, sondern dieses schleudert auch noch gammakorrigiertes, also falsche Licht in meine Szene. Das Ergebnis ist schlicht eine Katastrophe. Und schon ist der Spaß an HDR vorbei...

Arbeite ich in Octane nur mit den mitgelieferten (aktuell 1.500+) Texturen/Shadern, brauche ich mir bzgl. Gammakorrektur natürlich keine Gedanken machen
Diese Textueren sind Gamma frei. Für iRay z.B. kann man solche Texturen kaufen. Aber... ich habe ja auch noch ältere Objekte, mit älteren und damit gammakorrigierten Texturen.

Weiß ich aber um diese Problematik, kann ich auch damit umgehen.

Nämlich so:

1. ich prüfe welche Textur auf dem möglicherweise so mies aussehenden Objekt liegt, also ob gammakorrigiert oder nicht.
Wenn ja, muss ich den vermutlich eingestellten Wert von 2,2 mindestens auf 1,6 bis 1 runter regeln. Ist die Textur dann zu hell, regle ich sie nur über Diffuse oder Greyscale wieder runter.

2. ein (angebliches) HDRI Bild, welches ich als Background und globales Licht einsetzen will, schaue ich mir vorher (z.B. mit XnView) genauer an.

Z.B. dieses, also eins von den vielen freien HDRI's im Netz.

Nach dem entpacken finde ich (mit XnView) gleich 5 Bilder, wovon das Erste natürlich nur ein Thumbnail ist. Das Letzte (1) interessiert mich sofort,
weil so schön dunkel, also schwerer Verdacht auf echtes, lineares HDR Bild Ruck zuck geladen und schon sehe ich, ok, ganz brauchbar
In den Environment Settings dann den Gammawert 2,2 (von Octane standardmäßig vergeben) auf 1,3 reduziert...

...und weil zu bunt, im Imager noch die Sättigung etwas runter gzogen.

Das Palmenschatten Feeling kommt schon ganz gut

Und das kleine, zweite Bild (2) in der Zip oben, hat keine miese Qualität oder lächerliche Maße, wie der Laie möglicherweise denken könnte.
Nein nein, auch dass ist ein vollwertiges HDR Bild

Wenn ich z.B. nur das im-Palmenschatten-am-Strand Licht will, warum sollte ich dann ein 40MB HDR (1) Environment Bild laden?
Genau, dieser HDR Zwerg liefert mir nur die Beleuchtung, wenn ich nur dieses schöne Licht brauche, ohne dem Strand Gedönskram, weil ich da lieber ein Kirche hinstellen will ...will ich das wirklich? Das sieht dann jedenfalls so aus, passt und spart Arbeitsspeicher

So, das war's zunächst von mir zum Thema HDR.
Hoffe dem ein oder anderen hilft es ein wenig.

Fröhliches Rendern allerseits

Zitat von Ehliasys

...Wie du ja selbst schreibst sind .hdr Dateien üblicherweise lineare Lichtinformationen. Daher also auch den Gamma-Wert des Bildes generell auf 1 setzten für eine lineare Umsetzung. (Erspart auch Verfälschungen durch Sättigungsanpassungen)...Das DAZ-Plugin hat kein glückliches Händchen in der Vorauswahl mancher Einstellungswerte.

Hallo Ehliasys und danke Da stößt Du etwas an, was ich vielleicht noch mal etwas genauer erläutern sollte. Dann is aber wirklich schluss

Genau genommen ist die Octane default Gamma Einstellung 2,2 beides, also richtig und falsch
Je nachdem ob Du ein LDR oder eben HDR Bild lädst. Der Slot hieße besser einfach nur "Texture Environment", dann wäre alles gut.

Und mit dem Gamma Wert 1 hättest Du Recht wenn die HDR Welt perfekt wäre. Leider ist sie es nicht obschon sie das Potential dazu hätte
Ob der von Dir berechtigt angesprochene, theoretische Gamma Wert 1 für das geladene HDR tatsächlich stimmt, wissen wir nämlich nicht.
Dafür müssten wir die EXIF Daten (Belichtungsdaten) des ursprünglichen Fotos kennen, welche bei diesem HDR leider nicht zur Verfügung stehen.

Auch wissen wir nicht ob das Bild in der weiteren HDRI Verarbeitung nicht doch einer leichten Veränderung im Postwork oder Tonemapping oder gar einer Gammakorrektur unterzogen wurde

Und leider - und das ist die eigentliche Krux - haben wir keinen Orientierungspunkt
Zu Beginn des HDRI Zeitalters wurde nämlich schlicht vergessen einen verbindlichen Lichtwerte Bezugspunkt festzulegen, einen Ankerwert, an denen sich alle im HDRI beteiligten Programme und Geräte orientieren. Wir wissen einfach nicht, ob z.B. ein RGB weiß 255, welches die Kamera seinerzeit festgehalten hat, auch von den nachfolgenden, im HDRI Prozess beteiligten Programmen so interpretiert wurde.

In der Fotografie gibt es solche Lichtmengen Standardwerte, namentlich die Lichtwerte Tabellen (LW nach Verschlusszeit+Blende oder auf Neudeutsch: exposure value / EV), welche professionelle Fotografen auswendig im Kopf haben. Diese standardisierten Werte sind uns als ISO bekannt (Lichtempfindlichkeit). Diese Lichtwerte als Ankerpunkt in jede HDRI Software zu programmieren, hat man schlicht und ergreifend verpennt Ein große Chance die HDRI Welt auch theoretisch perfekt und damit noch einfacher zu mache, wurde vertan

Ob also die jeweiligen Helligkeits- bzw. Luminanz Werte (Lichtmengen) jetzt und hier in Octane tatsächlich denen entsprechen wie sie seinerzeit von der Kamera aufgenommen wurden und durch das gesamte HDRI liefen, ist Spekulation.

HDR heißt also in Wirklichkeit: "High Dynamic Rumwursteln"...
Nein, natürlich nicht, all die hier gezeigten Möglichkeiten wären mit einem LDR Bild schlichtweg unmöglich. Das LDR sähe von vorn herein nur mittelmäßig aus.

PB Rendering und die 3 Gamma Dämonen

Ehlyasis Anstoß folgend gehe ich hier noch mal auf die drei Gamma Werte ein, die uns beim physikalischen Rendern (PBR) Ärger machen können
wenn wir sie nicht beachten, sowie die quick and dirty Gegenmaßnahmen, falls ich das Bild bzw. die Textur nicht einfach tauschen kann oder will.

1. Klassische Bild Textur (Gamma korrigiert / s.a. Post 1)

Diesen Gamma Wert (meistens 2,2) finde ich in den Material Settings der jeweilgen Textur und wirkt nur auf diese Textur (hier die Reifen).

Ist kein Gamma Slot vorhanden, handelt es sich um eine korrekt dargestellte Textur und ich muss dieserhalb auch nichts tun.
Existiert aber der Slot, wie hier, ziehe ich den Wert nun möglichst weit runter. Optimal wäre 1...

...und verringere nun Diffuse, falls die Textur (wie oben) zu hell wird.

Wenn ich's genau machen wollte, müsste ich jetzt noch (im Postwork) die Sättigung reduziert und ggf. die Highlight Kompression erhöhen.
Will und brauche ich aber bei diesen "unbunten" Reifen nicht. Letztlich habe ich hier nun 3 Reifen Textur Varianten, die - je nach Szene (Matsch/Wüste/normal) - alle einsetzbar wären. Die Letzte ist halt nur die physikalisch Korrektere für einen ganz normalen Reifen

2. HDRI Texture Environment (Szenen Hintergrund und Licht)

Dieser Gamma Wert (und Power!) finde ich in den Render Settings und er wirkt auf das Hintergrundbild (hier HDRI Wald) und somit auch auf das daraus emittierte globale Licht, folglich indirekt auf die gesamte Szene Die theoretisch korrekte Gamma Einstellung bei einem HDRI ist der Wert 1 (bei LDR 2,2)
Achte ich nicht auf diesen feinen Unterschied, sieht der Render bei Verwendung eines HDRI mit Gamma 2,2 dann meist so aus:

Der (HDR) Hintergrund ist fast schwarz und die 3D Objekte wirken wie unter direktem Sonnenlicht
Erst wenn ich den Gamma Wert (1) nach 1 korrigiere, sind Licht und Farben richtig...

In diesem Fall eine schattige Lichtung im Park. Also nix direktes Sonnenlicht wie auf den ersten Blick angenommen
HINWEIS: Voraussetzung, damit diese Rechungen auf gehen ist natürlich, dass die Lichtintensität in den Rendersettings (2) (Octane = Power) auch auf 1 steht! Immer!

Dieses ganz gut gemachte und kostenlose HDRI findet Ihr übrigens hier: HDRI Waldlichtung

Bei tatsächlich direkter Sonneneinstrahlung, also deutlich härterem Licht, ist die Wirkung noch extremer.


Gamma 2,2 (falsch)

Gamma 1 (richtig)

...aber, wie zu erkennen, irgendwie sehen Licht und Farben blass aus
Jetzt kann ich allerdings problemlos - also ohne etwas falsch zu machen - die Lichtintensität über den Octane Power Regler in den Rendersettings erhöhen.
Damit bringe ich - ganz regulär - mehr Licht in die Szene. So als wenn ich zu Hause im Wohnzimmer den Dimmer hochziehe und die Birnen mehr Licht produziern.

...und schon sieht es halbwegs normal aus, ohne dass ich die Gamma Kurve (Lichtwerte Verteilung / s. Post 1) falsch verbogen oder in den Settings noch sonst wie rum gemurxt hätte Dennoch ist das hier in mehrfacher Hinsicht ein Beispiel für ein weniger gutes HDRI Denn wie der aufmerksame Betrachter erkannt haben dürfte, ist dieses HDR Bild, neben zu schwacher Lichtintensität, auch noch schief aufgenommen. Ich benutze es jedenfalls nicht.

Aber wie oben schon angemerkt, ist der "richtige" Gamma Wert (1?) für ein HDR eigentlich nicht bestimmbar.
D.h. ich muss das einfach austesten. Abgesehen davon ist das "richtige" Licht in der Szene auch noch Geschmackssache.
Dem ein oder anderen wird der Park oben vielleicht mit mehr Licht (Power) noch besser gefallen. Also wie immer: ausprobieren



3. Der Imager im Render View (Tonemapper)

Bei Octane im Render View zu finden.

Diese Gammakorrektur (Grundwert 1) wirkt pauschal auf alles im Render View, also auf das gesamte Renderbild. Und das bedeutet zwangsläufig - möglichst niiiiicht anfassen! Außer alle anderen Mittel haben versagt oder derjenige weiß genau was er tut oder da ist einer kreativ unterwegs.
Wenn im fine tuning mal unumgänglich, ist meine Empfehlung diesen Gamma Wert sehr vorsichtig um max. +/- 0,3 (wie hier getan) und mit Belichtung, Sättigung und Highlight Compression gegensteuern, wenn's denn sein muss.

Gamma Chaos?!

Schön und gut, sagt der HDR Interessierte jetzt vielleicht. Da sich alle drei Gamma Werte auch noch gegenseitig beeinflussen, bringt es ja wohl kaum etwas an allen Dreien gleichzeitig rum zu fuhrwerken und am Ende in lichttechnischem Chaos zu versinken. Mit welchem Gammawert beginne ich also, setzte quasi meinen Referenzpunkt und passe die anderen beiden Gamma Werte an?

Gute Frage, die mich ebenfalls beschäftigte. Mein PBR Workflow verläuft in der Reihenfolge wie oben gesehen. Auf keinen Fall nehme ich ein HDRI als Licht Bezugspunkt und passe diesem meine Texturen an. Denn es gibt auch haufenweise schlechte HDRI's und die ganze Arbeit an den Texturen wäre am Ende umsonst und ich kann den Mist noch mal durchziehen.

Ich betrachte immer zuerst die Objekttexturen und bringe diese, falls nötig, lichttechnisch in Ordnung.
Das dafür erforderliche neutrale Licht bekomme ich indem beim Texture Environment statt einem Bild, die Farbe RGB weiß (255) geladen wird.

Neutraler kann Licht ja eigentlich nicht sein. Das zumindest bei Octane gute Daylight funktioniert aber auch als Referenz

Optimaler Weise packe ich auch eine "Textur Referenz", also ein natürliches und nachweislich Gamma freies Material in die Szene, wie z.B. diesen Octane Holzboden.

WICHTIG: Gamma im Imager und Power in den Rendersettings stehen natürlich auf 1! Nun sehe ich, wo in der Szene eine Textur licht- bzw. farbtechnisch aus der Reihe tanzt und komisch aussieht (Bild 050). Diese korrigiere ich dann wie oben vorgemacht und speichere die Szene samt der Material Settings erst mal ab, weil erledigt.

Erst jetzt lade ich das gewünschte HDRI im Texture Environment als Background und globales Licht. Passt es nicht, muss ich jetzt nur einen Gammawert ändern, nämlich den in den Render Settings. Sieht der Render dann immer noch komisch aus, taugt mit hoher Wahrscheinlichkeit das verwendete HDRI nichts. Da es im Netz bzw. auf meiner Festplatte genug davon gibt, tausche ich einfach das HDRI aus und schon passt es.

Abschließend...

...werden die schlauen Mitleser erkannt haben, dass es in diesem Prozess zwei "Lichtmengen Regler" gibt, die miteinander korrespondieren.
Zum einen ist das der Power Regler in den Octane Render Settings und zum anderen der Exposure Regler im Octane Imager.

Wie bei der realen Fotografie (nichts anderes tun wir beim Rendern) gibt es eben zwei physikalisch korrekte Möglichkeiten die Helligkeit eines zu erstellenden Bildes verlustfrei zu ändern. Entweder ich schicke mehr/weniger Licht in die Szene, indem ich z.B. die Leistung der Lichtquelle (Power) erhöhe/reduziere, oder aber ich lasse mehr/weniger Licht auf meinen Kamerasensor fallen, indem ich die Belichtungszeit (Imager Exposure) verlängere/verkürze, die Blende weiter öffne/schließe, oder einen Film mit höherer/niedrigerer Empfindlichkeit (ISO) einlege.

Bei HDR ohne Licht- und Farbinformationsverluste. Physikalisch basiertes Rendern eben

Das ist HDRI

Zitat von Ehliasys

... der Weg durch das ganze Chaos ist ... besonders in Octane, nicht sonderlich komplex...

So isses
Abgesehen von den anderen Nebensächlichkeiten, wie Shader Datenbank, kongenialer Material und Licht Editor sowie unschlagbaren Renderzeiten ...ist der lineare Workflow in Octane durchaus vorbildlich.
Wobei ich bisher aber auch nur mit iRay und Reality direkt vergleichen konnte. Beides für mich keinerlei Alternativen.
Da vermute ich noch eher Blenders Cycles als ebenfalls bauchbare PB Rendermaschine. Kushanku zaubert da ja auch schon so einiges raus.