Noch was unklar? Dann in unserem Forum nachfragen
Zum Original-Thread / Zum Blackmagic DaVinci Resolve / Fusion-Forum

Infoseite // Resolve exr export



Frage von josa:


Gibt es irgendeine Möglichkeiten exr Sequenzen der einzelnen shots aus resolve zu exportieren? Das eingangsmaterial sind dng Sequenzen. Die Szenen werden in Resolve zusammengeschnitten und ich suche jetzt die verlustärmste Möglichkeit noch ungegradete clips zu exportieren, die dann mit 3d Effekten versehen und wieder in Resolve zurück gespielt werden sollen, um dort noch ein finales grading zu erhalten. Vielleicht auch ein Script, das anhand der xml datei aus resolve die einzelnen Frames wandelt.

Grüße josa

Space


Antwort von Peppermintpost:

exr sind kein Problem benutze ich zum Mastern ausschliesslich. Du hast alle Optionen wie Original Shotnames, Timecode etc. Kannst du auch nach Shots plus Handles oder als kompl Sequenz exportieren. Ist alles wie immer, einfach nur exr auswählen.

Space


Antwort von josa:

Tatsache ist ja leichter als gedacht, irgendwie hab ich dasgetrost übersehen.
Wofürsteht dasRGB Half? Das es nur 16 bit sind, wenn das pro Farge ist dürfte das keinen Verlust ergeben..

Grüße josa

Space


Antwort von Peppermintpost:

grundsätzlich ist der Unterschied zwischen 16 und 32 bit ja mehr für das eigene Gewissen als das es irgend einen tatsächlichen Unterschied hätte, beide sind ja floating point. Wenn ich auf Smoke/Flame arbeite benutze ich 16bit weil die ja sowieso nicht mehr können, wenn ich im Nuke arbeite benutze ich 32bit.
Nahezu alle Systeme die aus der Grafik Engine heraus rechnen können nur 16bit, weil die Grafikkarten halt nicht mehr können. (Bezieht sich nur auf die Grafik Engine nicht auf die Rechen Kerne)

Space


Antwort von josa:

Das Ausgangsmaterial ist sowieso nur 14bit pro Kanal, also sollte das locker gehen.
Wie wird das normal gemacht im Workflow? Werden da einfach die unbearbeiteten clips durch die bearbeiteten in der Timeline ausgetauscht oder gibts da ne intelligentere Methode?

Space


Antwort von Peppermintpost:

Da gibts keine feste Vorgehensweise, ich kann dir nur sagen wie ich es mache. Es richtet sich bei mir in erster Linie nach der Länge des Beitrags und der Anzahl der VFX Shots und nach dem System auf dem ich Finish.

Also bei einem Spielfilm wo nur 50 Shots bearbeitet werden würde ich natürlich nur die VFX Shots im Resolve makieren, damit ich danach sortieren kann und die finalen Shots dann im Resolve als Version austauschen.

Wenn es ein 30sec TV Spot ist wo sowieso alle Shots bearbeitet werden, da würde ich natürlich alle Shots exportieren und am Ende auch alle Shots neu conformen (im Resolve, oder gleich im Flame)

Hängt also an deinen Projekten und an deinem bevorzugtem Workflow.

Wo ich immer hin und her gerissen bin ist bei der Frage der Farbkorrektur. Grundsätzlich mag ich es wenn ein Color Grader schon mal einen Look ins Footage Gradet und ich dann am Ende nur noch die Details beim Color Grading mache, auf der anderen Seite mache ich die Effekte lieber auf dem Original Footage ohne jedes Grading. Ich mache meine Vorgehensweise an der Stelle davon abhängig wie der Color Grader so drauf ist.

Space


Antwort von WoWu:

@josa

Warum bringst Du das Material nicht auf den ACES Workflow.
ACES ist exr und wird von Resolve unterstützt.

Space


Antwort von josa:

Weil ich von Farbräumen eine nunja begrenzte Ahnung habe und ich nicht weis, wie ich das in resolve konvertiere oder in andren Programmen damit umgehe.

EDIT:
Gibt's irgendeine Möglichkeit die exrs kleiner zu bekommen? 2,5 mb pro frame davor und 12mb dannach ist schon ein Unterschied..

Space


Antwort von WoWu:



Space



Space


Antwort von josa:

Danke das war sehr aufschlussreich. Muss ich dann noch irgendwas machen, dass Programme, wie Blender und Fusion das dann auch als ACES interpretieren?

Space


Antwort von WoWu:

Soviel ich weiss ist "Tears of steel" mit Blender in ACES gemacht ... müsste also gehen ... Fusion weiss ich nicht.

Die CinemaDNGs haben übrigens nur 12 Bit (nicht 14), weil es über Tiff läuft und Tiff ist bei 12 Bit "festgeklemmt".
Die 16 Bit, von denen immer die Rede ist, ist die Wortbreite (2Byte) .. das hat daher nichts mit der Cintent-Tiefe zu tun.

Space


Antwort von josa:

Ja das habe ich auch gelesen, hab auber nach wie vor noch nie damit gearbeitet. Erkennt das Programm das von selbst anhand von Exif Tags oder muss man das dem noch sagen?

Des sind die dngs von Magic lantern, die haben soweit ich weis schon 14bit.

Space


Antwort von WoWu:

Das Problem ist nicht DNG, das ist ja nur der Container sondern das TIFF Format. Von wo auch immer das Signal kommt, egal ob der Sensor 14 oder 16 Bit macht, TIFF kodiert nur 12 Bit und überträgt es in einer 2 Byte Wortbreite. Es bleiben aber nur 12 kodierte Bits, ob man das nun in 16 - oder was auch immer- überträgt.

Space


Antwort von Peppermintpost:

ich hab mir den Film auch angesehen, danke Wolfgang, jetzt hab ich zumindest mal eine Vorstellung wie der konkrete Umgang mit ACES läuft.
Wir hatten hier ja schon öfter mal über ACES gesprochen, bzw du hast erklärt was der Sinn der Sache ist. Was ich gesehen habe finde ich aber nur bedingt sinnvoll. Was mir gut gefällt ist das ich beim einladen der Rushes nicht darüber nachdenken muss welche Kameraeinstellungen der Kameramann wohl benutzt hat und per trial and error die verschiedenen Optionen durchklicken muss (wenn es wie fast immer keinen Kamera Bericht gibt). Was mir auch sehr gut gefällt ist der eingebaute Display LUT für Rec709, sRGB usw. Sich nach dem einladen der Rushes noch mit ACES zu beschäftigen scheint mir etwas sinnlos. Wenn ich aus dem Resolve EXR exportiere, sie z.B. in Nuke bearbeite (und ich hoffe das ist in anderer Software genau so) und dann wieder zurück ins Resolve importiere, dann sind die Farben 100% identisch (auch die Farbtiefe), ich verschenke nichts.
Nuke, Flame und Smoke haben ebenfalls Display LUTs bei denen ich standart Farbräume wie rec709, sRGB oder Linear wählen kann oder Custom LUTs importieren kann.
Die EXR kann ich aus Resolve linear exportieren, was der übliche Workflow ist, ich kann sie aber auch im sRGB Farbraum exportieren, hab ich bei einem aktuellen Projekt gemacht, das führt zwar zur Verwirrung (ich werde es nie wieder so machen) aber auch das ist technisch vollkommen identisch was die Qualität angeht.

Wenn ich also 100% das zurück gebe was ich bekommen habe, dann ist meiner Meinung nach alles gut, der Sinn von ACES erschliesst sich mir mich an der Stelle dann nicht mehr. Ich spreche jetzt aussschliesslich vom Deliver an die VFX und zurück.

Space


Antwort von WoWu:

Moin Thorsten
Nur da schliesst sich für mich der Kreis. Jeder macht in seinem persönlichen Workflow- wenn er lange genug eingespielt ist- natürlich am Ende korrekte Sachen. empirisch gewachsen ... nur allzu oft wird eben -aus der Übertragungskurve heraus losgegrated.
ACES standardisiert das endlich mal und sorgt so für weniger "random" Ergebnisse.
Dazu kommt noch, dass Du endlich im VFX Dir keine Gedanken mehr um den Arbeitsbereich machen musst und sich das Problem hinterher mit dem Filter erledigt.
Ich halte ACES daher für derzeit den besten Kompromiss, für alle, die nicht RAW oder durchgängig 709 machen wollen oder können und der grauen Sosse, die leider all zu oft dabei herauskommt denn viele halten ein graulastiges Bild immer noch für hoch dynamisch und vergessen, dass sich Dynamik zwischen Schwarz und Weiss abspielt.
Dem kann ACES endlich mal entgegen wirken, weil der Workflow dafür sorgt.
Dennoch ist ACES kein RAW Ersatz, weil man sich wieder an einen -wenn auch grossen- Farbraum bindet und De-Bayering ade sagen muss.
Wem also solche Dinge, wie Gewichtungen oder Aliasing bisher nicht egal waren, wird wohl bei RAW bleiben.
Der würde aber ohnehin nicht aus der Übertragungskurve heraus graden.

Insofern hast Du natürlich Recht, wenn Du einen guten Workflow hast und auch an den Schnittstellen "sauber" bist, gibt es keinen Grund das zu ändern.

Space


Antwort von Peppermintpost:

ich bin gespannt, ich werde mein nächstes Projekt definitiv mal kompl in ACES bearbeiten um praktische Erfahrung zu sammeln. Einige Sachen finde ich gut, andere übertrieben. Mal sehen wie es sich in der Praxis darstellt. In grauer Sosse zu arbeiten finde ich auch ätzend, da bin ich bei dir. ACES könnte sich als gute Alternative erweisen anstatt das Footage zu graden bevor man die VFX angeht, was ich halt auch nicht mag, weil ich in gecrashten Blacks auch nicht gerne arbeite, da ist mir im zweifel grause Sosse lieber weil ich das ja der Display LUT korrigieren kann.

Mal sehen, das nächste mal ACES und dann fange ich an zu nörgeln ;-)

Space


Antwort von Gooerkfish:

@Peppermintpost und @ WouWou!
Danke-das ist einer der besten Threads , die gelesen habe, weil
ich mich gerade in diese Thematik einarbeite, und mir der Kopf
raucht..Ihr habt 100 Fragen gelöst und genau 20 neue aufgeworfen.
Man lernt dazu!

Ich stell einfach mal die Dumpfbackenfrage::
-aus poket kommt 10 bit Raw
-entweder etwas freigestelltes als Modell
-oder Actuer ist in der green gehupft/ gespielt
-die Poket hat Backgrounds in 10 bit Raw gefilmt ( Himmel/ was immer)
:: ertster Kopfknaller - mit der Nikon hab ich zugeordnet zu der Himmels
scene einen Hdri-dome geknipst::
IN was sollte das sein? Im Photoshop 16 bit, in einem 3d-Prog, wenn der des
rechnet plötzlich 12 / 16 / 32.. und so weiter..
-Aus dem 3d Prog halt gerendert was immer-- nächste Kopfnuss::
-auch hier Ausgabe so hoch wie ( je nach) 10 oder 12.???

Und wenn nun alles im NUke landet---nach wem richte sich der?
die 10 bit Raw der Poket? Alle andern sind grösser--- beim Finalen
Rendern----> wer is der Boss? das 10 bit, oder egal weil..

Ungefähr, was ich da in eine Richtung bringen will- danke für Infos, ihr seit
spitze. das ist jetz nach der Arbeit nur schnell hergepinselt-hab ja bisher
nur in der Holzklasse 8 bit geworkt ( dslr) und die restliche Kette auf das
hin runtergedreht.. zum training klar-aber-nun??

Space


Antwort von Peppermintpost:

Nuke arbeitet immer 32bit float. Was auch immer du hinein lädst kommt auch genau so wieder heraus wenn du es willst.
Wenn du weniger Farbtiefe oder Kompression willst, dann stellt du das beim heraus Renders ein. Also wenn du z.B. tga heraus renderst dann ist das natürlich nur 8-bit, aber das liegt dann an dem Format was du wählst.

Verschiedene Auflösungen und Farbtiefen werden im Nuke nicht wie z.B. bei Flame/Smoke erst einmal in ein Format gewandelt und dann benutzt, sondern immer nativ benutzt. Du kannst also 10 bit HD Material mit 4k 16bit float, 8bit SD und was auch immer nach belieben mischen, es wird immer 32bit float weiter behandelt.

Für die Color Spaces gilt das gleiche, verschiedene Import Formate haben default Color Spaces, also ein exr ist default linear und ein jpg default sRGB, aber das kann man umschalten wenn die default Einstellung nicht stimmt.

Man kann die Farbräume auch innerhalb einer Comp nach belieben ändern, was bei manchen Aufgaben auch Sinn macht.

Display LUTs gibts auch verschiedene und es können beliebige geladen werden.

Was das Grading angeht, man kann Color Correction Nodes aus Scratch importieren oder aus dem Baselight, um auf dem Original zu Compen aber schon zu wissen wie das Endergebniss aussehen soll.

Space



Space


Antwort von WoWu:

Die 32 float machen auch für VFX u.U. viel Sinn, weil Material immer aus der Formal generiert wird.
Bei Video aber nicht, weil der Ursprung, also die Formatgenerierung in der Kamera beendet ist und es keine neue "linearisierung" für das Material mehr gibt.
Insofern beschränkt sich der Vorteil auf die Rundungsfehler bei der Bearbeitung und auch nur, wenn mit 32bit Effekten durchgehend gearbeitet wird, Aufgrund der grösseren Wortbreite ist dann aber der Rundungsfehler bezogen auf das letzte Bit im Verhältnis ebenso gross. Vermeintliche Vorteile setzen aber auch voraus, dass alle Effekte 32 bit fähig sind.
Sind sie das ? Ggf. noch beim Nuke o.Ä.
Aber sonst reduzierst man an jedem (nicht 32) Übergandas Formt.

Bei ACES wurde, wenn man den Protokollen der Enteicklungsgruppen folgt, auch solche Themen lange diskutiert worden und genau aus diesen Gründen hat man sich für "half Floating (16 Bit)" entschieden.
Denn 32 ist prima für alle originären Computersignale, aber bringt keine Vorteile -oft sogar Nachteile- für die Videoverarbeitung. (Und ist sehr Rechenintensiv bzw. oft nur in Hardware sinnvoll umzusetzen).
Wenn man 10Bit in mit 32 float vergleicht, sind das 10 Bit zu 96 Bit Verarbeitungsaufwand, die im Original gar nicht vorhanden sind.
Ausserdem machen sich Rundungsfehler am ehesten im Störabstand bemerkbar, was von Vorteil im VFX Signal ist, im Videosignal liegt der Störabstand aber in Form von Rauschen bereits im Bild fest und bis Rechenfehler hier den geringen Störabstand der Kamera "überholen", muss schon eine äusserst intensive Bearbeitung erfolgen.

Insofern haben sich die ACES Leute schon was dabei gedacht, selbst solche hochwertig angelegten Workflows auf 16 Bit zu definieren.

Space


Antwort von WoWu:

@Gooerkfish

Ich bin der derzeitigen "neuen" deutschen Sprache nicht so mächtig. Aber ich will mal versuchen, auf das zu antworten, was ich noch verstanden habe ;-) -aus poket kommt 10 bit Raw Soviel ich weiss ist das nicht RAW. Entweder kommt da ein ProRes mit flacher Übertragungsfunktion raus, oder ein DNG in TIFF.
Beides ist kein RAW, denn beides ist bereits in fixierten Farbräumen. -entweder etwas freigestelltes als Modell
-oder Actuer ist in der green gehupft/ gespielt
-die Poket hat Backgrounds in 10 bit Raw gefilmt ( Himmel/ was immer)
:: ertster Kopfknaller - mit der Nikon hab ich zugeordnet zu der Himmels
scene einen Hdri-dome geknipst::
HMMM hab ich nicht verstanden.
IN was sollte das sein? Im Photoshop 16 bit, in einem 3d-Prog, wenn der des
rechnet plötzlich 12 / 16 / 32.. und so weiter..
-Aus dem 3d Prog halt gerendert was immer-- nächste Kopfnuss::
-auch hier Ausgabe so hoch wie ( je nach) 10 oder 12.???
Hab ich so ungefähr verstanden.
Meine Empfehlung ist : immer in dem Fahrbarem ausgeben, in dem gearbeitet wird ... wenn das mal für Monitore (TV) sein sollte, würde ich immer in sRGB und Deinem Fall 10Bit (REC709 Übertragungsfunktion) YCbCr- bleiben und arbeiten.
-709 gibt es in 8 oder 10 Bit-

Und wenn nun alles im NUke landet---nach wem richte sich der?
die 10 bit Raw der Poket? Alle andern sind grösser--- beim Finalen
Rendern----> wer is der Boss? das 10 bit, oder egal weil..
Die Nuke verändert das nicht durch die Arbeitstiefe. 10 Bit Material bleiben 10 Bit und kein Bit mehr, auch nicht, wenn man die Verarbeitungstiefe wechselt.

Und übrigens ist die "Holzklasse 8Bit" gar nicht so schlecht, man muss nur präziser damit umgehen.
8Bit ist schwerer zu arbeiten, als 10 oder mehr, weil man Fehler, die in der Verarbeitung gemacht werden, viel schneller sieht.

Space


Antwort von Peppermintpost:

ok Nuke wirklich alle Effekte in 32 bit verarbeitet kann ich selbst nicht nachweisen. Ich muss da (leider) auf das Marketing von Foundry vertrauen die das behaupten.

Der Unterschied zwischen 16 und 32 bit ist akademischer Natur, hatte ich oben ja auch schon geschrieben. Auch Kinofilme werden teilweise in 16 bit bearbeitet, gerade bei Stereoscopisch Gedrehtem Material (aus Workflow Gründen)

Flame/Smoke arbeiten ja maximal auch in 16bit float, was zum einen daran liegt das beide die Grafik Engine der Grafikkarte benutzen, die nunmal nicht mehr kann, zum anderen werden diese Systeme ja vorrangig eingesetzt um TV Content zu erzeugen, also Master über 10bit Farbtiefe kommen selten bis fast garnicht vor. Also sind 16bit schon deutlich über dem Ziel.

In einer höheren Farbauflösung zu arbeiten als in der Master Auflösung macht bei den meisten Funktionen nicht sehr viel Sinn, da stimme ich wowu absolut zu. Wo eine höhere Farbauflösung Sinn macht ist wenn man mit Filtern arbeitet, also neuen Content schafft und nicht bemüht ist das Original zu erhalten. Gängigstes Beispiel ist ein Blur ein 10bit Blur auf 10bit Material neigt natürlich schneller zu Banding als ein 16bit Blur auf 10Bit Ausgangsmaterial.

Alle hohen Farbauflösungen erkauft man sich aber immer zweifelsfrei durch längere Rechenzeiten.

Space


Antwort von WoWu:

Wo eine höhere Farbauflösung Sinn macht ist wenn man mit Filtern arbeitet, also neuen Content schafft und nicht bemüht ist das Original zu erhalten. Gängigstes Beispiel ist ein Blur ein 10bit Blur auf 10bit Material neigt natürlich schneller zu Banding als ein 16bit Blur auf 10Bit Ausgangsmaterial.

Alle hohen Farbauflösungen erkauft man sich aber immer zweifelsfrei durch längere Rechenzeiten.
Da bin ich absolut bei Dir.

Vielleicht noch eine Zahl zu 32 Bit zur Veranschaulichung und zur Belustigung:

Ein 32 Bit Signal beinhaltet 2ex32 = 4,294,967,296 Bit Patterns mit 60.310.076.829.696 Werte.
Man brauchen die Zahl nicht zu entziffern, es sind rd. 60 Billionen- mal reduziert auf eine Zahl.
Dort wo in einem 8 Bit System 1 Farbwert übertragen werden kann, können in einem 32 Bit System 39.216 Farbwerte übertragen werden.
Im Computer macht das Sinn, denn der kann die Farbwerte u.U. noch errechnen, aber dass die nicht aus der Kamera kommen, sollte jedem klar sein.
Deswegen ... VFX macht u.U. Sinn.

Space


Antwort von Peppermintpost:

Die Nuke verändert das nicht durch die Arbeitstiefe. 10 Bit Material bleiben 10 Bit und kein Bit mehr, auch nicht, wenn man die Verarbeitungstiefe wechselt. Absolut richtig. Aber wenn man z.B. 8-Bit Footage hat und das ist nur ein Hintergrund Layer der in der Unschärfe durch einen Post Defocus bearbeitet wurde, dann kann (nicht muss) es sinnvoll sein das Nuke das dann zu 32 bit hoch interpoliert, wenn man z.B. erst nachträglich graden möchte. Das ist ja kein ungewöhnlicher oder konstruirter Vorgang.


Und übrigens ist die "Holzklasse 8Bit" gar nicht so schlecht, man muss nur präziser damit umgehen.
8Bit ist schwerer zu arbeiten, als 10 oder mehr, weil man Fehler, die in der Verarbeitung gemacht werden, viel schneller sieht. steht auch ausser Frage, ein sauberes 8Bit Bild mit vollem Kontrast liegt ja schon in der Region die wir überhaupt mit unseren Augen differenzieren können. Wenn man 10bit HD mit 8bit SD vergleicht, dann liegt die Auflösung von Farbe zu Pixeln nicht so weit auseinander.
8bit zu 10bit Master kann man sowieso mit dem Auge nur in extremfällen unterscheiden, und da man heute sowieso fast aussliessich kompremiertes Material zu gesicht bekommt würde ich sogar sagen man kann es nie unterscheiden.

Space


Antwort von Peppermintpost:

Ein 32 Bit Signal beinhaltet 2ex32 = 4,294,967,296 Bit Patterns mit 60.310.076.829.696 Werte.
Man brauchen die Zahl nicht zu entziffern, es sind rd. 60 Billionen- mal reduziert auf eine Zahl.
Dort wo in einem 8 Bit System 1 Farbwert übertragen werden kann, können in einem 32 Bit System 39.216 Farbwerte übertragen werden.
Im Computer macht das Sinn, denn der kann die Farbwerte u.U. noch errechnen, aber dass die nicht aus der Kamera kommen, sollte jedem klar sein.
Deswegen ... VFX macht u.U. Sinn. Der Vorteil von 32bit liegt natürlich nicht unbeding darin das Kamerabild abzubilden, es ist aber sehr praktisch um Computer Daten (Informationen Mathematischer Natur) in einem Bild weiterzugeben.

DeepCompositing, Z-Channel, Normals Map, World Map etc.
Das hat mit Bildern ja nichts mehr zu tuen, ausser das es in einem Bild gespeichert wird.

Space


Antwort von WoWu:

Nur wer, von den Usern hier, wendet das an ?
Die meisten sehen nur 32Bit ... oh, cool.
Differenzieren aber gar nicht, was das eigentlich bedeutet.
Wie gesagt, in einer visual effect pipeline ist das zwar auch noch üppig, aber so what. Keine Frage.

Space


Antwort von Peppermintpost:

Nur wer, von den Usern hier, wendet das an ?
Die meisten sehen nur 32Bit ... oh, cool.
Differenzieren aber gar nicht, was das eigentlich bedeutet. ist doch wie bei den Kameras, mehr ist besser. Ich hoffe da kommt bald eine Nuke Version die endlich mehr als 32k Auflösung kann wenn ich mal 6 Red Dragon Frames nebeneinander legen muss. ;-)
Aber ich bin sicher wenn die endlich 128k können schreiben die es auch auf die Verpackung.

"First Software to handle Mega-Ultra-Giga HD" oder so ;-)

Space


Antwort von WoWu:

:-)

Space



Space


Antwort von TheBubble:

Wenn im Grafikbereich von von 32-Bit pro Farbkanal gesprochen wird, dann ist in der Regel eine Darstellung mit 32-Bit-Fließkommazahlen gemeint, oft (aber nicht immer) ist die Repräsentation linear, also ohne aufgebrachte Gamma-Übertragungsfunktion. Die sichtbaren Informationen weden dabei im Intervall von 0 (dunkel) bis 1 (max. Helligkeit) abgebildet.

Der Vorteil von 32-Bit Floats liegt darin, dass diese von gängigen CPUs verarbeitet werden. 16-Bit-Floats hingegen sind schonender, was den Platzbedarf angeht, eine normale PC-CPU kann mit ihnen jedoch nicht rechnen. (Anmerkung: In der Mathematik würde man aufgrund der Genauigkeit immer versuchen, mit Doubles, also 64-Bit-Floats, zu arbeiten, und 32-Bit-Floats zu meiden.)

Space


Antwort von WoWu:

2008 ist die IEEE 754 mit einem binären und zwei dezimale Datenformate erweitert worden. Darin enthalten ist das 16 Bit Minifloat.(Neben den bisherigen 32/64)
Es ist also eine Frage der Implementierung.
Oder anders ausgedrückt ... die Oldtimer können das noch nicht.

Space


Antwort von TheBubble:

Noch eine Ergänzug: Wenn bei Bitmaps von einer Bitmap mit 16 Bit pro Farbkanal gesprochen wird, dann ist häufig eine Datstellung mit 16-Bit Integern gemeint, es werden also pro Kanal bis zu 2^16 Helligkeiten unterstützt.

Eine Darstellung mit 16-Bit-Floats hat zwar genauso viele Bitmuster zur Verfügung, die repräsentierten Werte haben jedoch keinen gleichmäßigen Abstand voneinander. Außerdem bieten 16-Bit-Floats immer auch negative Zahlen an, d.h. die Hälte aller Bitmuster repräsentiert negative Zahlen.

Space


Antwort von TheBubble:

Es ist also eine Frage der Implementierung.
Oder anders ausgedrückt ... die Oldtimer können das noch nicht. Der Datentyp (binary16) ist nur zum Ablegen von Werten gedacht, bei dem eine geringe Genauigkeit ausrecihend ist. Sinn macht er nur dort, wo man Speicherplatz reduzieren will und mit dem Werteangebot auskommt, zum Rechnen ist immer eine höhere Genauigkeit empfehlenswert.

Space


Antwort von WoWu:

16-Bit-Gleitkommazahlen werden schon reichlich verwendet, und zwar in
3D-Beschleunigern.
Diese unterstützen in der Regel einen solchen Typ direkt in der Hardware.
Genutzt wird er vor allem für die Berechnung der Pixel bei HDR-Rendering.
Früher wurde für die drei Grundfarben immer je ein 8-Bit-Integer verwendet. Bei HDR-Rendering nutzt man Gleitkomma-Zahlen, um einen (nach unten und oben) großen Zahlenbereich abdecken zu können, beschränkt es aber auf 16 Bit, um nicht so viel Speicherbandbreite zu brauchen.wo man Speicherplatz reduzieren will und mit dem Werteangebot auskommt, Aber genau darum geht es ja.

Space


Antwort von TheBubble:

16-Bit-Gleitkommazahlen werden schon reichlich verwendet, und zwar in
3D-Beschleunigern. Richtig, sie kennen diesen (Storage-)Datentyp. Aber womit rechnen sie intern?

Space


Antwort von WoWu:

Ich glaube, wir reden jetzt aneinander vorbei. Es ging darum, dass ACES ein 16 Bit Miniflat Format benutzt, just aus den beschriebenen Gründen.

Space


Antwort von TheBubble:

Ich glaube, wir reden jetzt aneinander vorbei. Es ging darum, dass ACES ein 16 Bit Miniflat Format benutzt, just aus den beschriebenen Gründen. Vielleicht tun wir das.

Mir ist binary16 jedenfalls nur als Storage-Format bekannt, gerechnet (Addition, Multiplikation, ...) wird in der Regel mit (mindestens) binary32, soweit mir bekannt auch von Grafikkarten.

Worauf ich jedoch hinauswollte und was vermutlich etwas unterging: binary16 darf man trotz der 16-Bit nicht nur über die Bit-Anzahl mit einem 16-Bit-Integer-Format vergleichen, da man bei binary16 primär nur Werte zwischen 0 und 1 nutzt, bei Integer-Formaten jedoch häufig alle verfügbaren Werte sichtbaren Helligkeiten zuordnet.

Space


Antwort von Peppermintpost:

16bit int ist natürlich auch eine sehr hohe Farbauflösung, aber der Wertebereich den du bei VFX abbilden willst liegt zwar wie du beschrieben hast in erster Linie zwischen 0 und 1, es ist aber gerade bei Kino Filmen nicht ungewöhnlich mit Wertebereichen deutlich grösser 1 zu arbeiten. Also die höchsten Werte die ich selbst hatte lagen bei 18 und ich kenne Projekte wo sie sogar über 20 hinaus gingen. Superbrights finden also fast immer statt, Super Blacks also Werte kleiner Null möchte man zwar grundsätzlich vermeiden weil die zahlreiche Probleme mit sich bringen, kommen aber dennoch manchmal (wenn auch viel seltener) vor.

Wenn du bedenkst du möchtest die gleiche deatailierte Farbabstufung die du zwischen 0 und 1 hast auch bis 20 haben möchtest, dann wird der Bedarf einer wirklich hohen Farbauflösung schnell klar.

hat 16bit int nicht 32767 Werte? Wenn dem so ist könntest du damit zwar immer noch die von mir beschriebenen Fälle abbilden, du wärst damit dann aber auch beim Maximum. Oder fasel ich da gerade Unsinn?

Space



Space


Antwort von Gooerkfish:

@Pepermintpost!

Du, des ist echt toll, so erklärt. DANKE!!!!
Ich hab mir des Nuke ( mir gefällt Nuke-Mari-Player/ Workflow) geholt
und mir war klar, ds es immer in maximalem Setup intern arbeiten
wird, kommst aber von den älteren Progs ( Combustion, Gott und so weiter
hab ihn selig/ immer noch schönes schnelles Taschenmesser für zwischendrin)-und siehst was da manchmal passiert-staunst.
Das ich bei einzelnen Renderings, wenn des Teil vom Z-brush zum Maya weiter gereicht wird ( Texturen.etz.etz) ( Wie ist der ARNOLD?...........
a,) ja wennst 1000 Rechner hast b.) toll, aber weisst eh a.) :) ) - ich
klarerweise da ebenfalls maximal ausgebe ist klar, solange ein Einzelbild
und des ganze im Photoshop sein Finish bekommt.
Nur mit der 10 bit Poket beginnt für mich so zu sagen alles von neu oder
richtigerweise-Ich will mir den ganzen Tegel einmal straight einstellen.
Würde ich dann mein erstes grössers Projekt angehen-wäre es ja fatal, wenn ( only one singel mans 2 hands and will:))
man da 4 Monate reinhaut und eig. kannst es in die Tonne klopsen...ja.
Ich arbeite mit Modellen, manche sind bewegliche Puppen ( human-animatronics / billigundschnell :))-weil in 3d wiederum ewig und 3 Tage, genug Elemente aus dem Maya/Max ( ich geh dorthin sprengen, ersaufen und zerbrösel..) einges aus dem Blender ( steh immer öfter auf Free open Source--weil ich mir Dinge "basteln" kann oder scripten)-etz.. Kann mir keine teuren Drohen leisten und löse das wiederum derzeit mit kleinen gebauten Hänge-stahl-schienen ( Seile wobbeln und das zu stabi. is mir zu teuer)..
Ich liefere ende nächsten Jahres ein STATEMENT ab zu dem was gerade so
passiert, und mir auf den Senkel geht, und verpacke das in eine Storry
wo ein KIND einfach nur in die Schule gehen will..
In meinem Scenario ist das ein Verbrechen. Die Drohen die es gibt, sind
durch die Bank böse...... mehr will ich net spoilern.
hier schnell hergepinselt- ich sag Danke zu Dir und hab sicher noch duzende Fragen- kann sein dass ich sogar mal vorgeischau...
Man lernt nie aus-und ich bin auf Schwammmodus gestellt..
( zb. 4k Monis und die 10 bit-Angabe = treibt mich zum Wahnsinn, was der
Hersteller da erzählt und...wie prüf ich des?)
GROSSES DANKE!

Space


Antwort von Gooerkfish:

Dir lieber Wolfgang auch ein grosses DANKE!

Ich wusste, wen nich eine Frage etwas in grindigem Deutsch stelle, dann
öffne ich ein Universität aus HUman Skill and Wisdome, und ich greife
gerne auf Dein Wissen zu. Du bist spitze!

Noch ne Schockfrage* ( :) :) :) ) eher an die ganze Industrie gestellt::

WARUM MACHEN WIR NICHT ALLES IN 32 bit?
Kamera-Rechner-alles???

ich glaub jetzt fällt irgend wo in Japan und in Sillicon Valley er tot um..
( wie kann ER diese Frage stellen)( diese wollten sie erst 2044 beantworten)

Schönes Wochenende und lebe laaaaang und erfolgreich :)





* vor 3 Jahren Übergabestflug mitten über der Ostsee::
" DU hast jetz aber net den Mainbus-b für die Überbrückung der Treibstoffpumpen am Auslassventil aktiviert um den Haupttank
ABZULASSEN?????????? "

Space


Antwort von TheBubble:

Wenn du bedenkst du möchtest die gleiche deatailierte Farbabstufung die du zwischen 0 und 1 hast auch bis 20 haben möchtest, dann wird der Bedarf einer wirklich hohen Farbauflösung schnell klar. Eben, aber man sollte genau darum wissen, dass die unterscheidbaren Werte von floats nicht gleichmäßig verteilt sind und die höchste Dichte um 0 herum liegt.

So bietet ein half-float (binary16) zwischen eine Anzahl von 15362 unterschiedlichen Zahlenwerten an, wovon allerdings 11880 im Intervall liegen. Im Intervall befinden sich nur noch 4353 unterscheidbare Werte. Je weiter man sich von 0 entfernt, desto größer werden die Abstände zwischen darstellbaren Zahlen.
hat 16bit int nicht 32767 Werte? Wenn dem so ist könntest du damit zwar immer noch die von mir beschriebenen Fälle abbilden, du wärst damit dann aber auch beim Maximum. Oder fasel ich da gerade Unsinn? Ein 16-Bit-Wert kann 2^16 = 65536 verschiedene Zustände annehmen, d.h. wenn kein Vorzeichen verwendet wird werden von 16-bit Integern ganze Zahlen von 0 bis 65535 repräsentiert. Mit Vorzeichen reicht der Bereich von -32768 bis 32767.

Space


Antwort von Peppermintpost:


So bietet ein half-float (binary16) zwischen eine Anzahl von 15362 unterschiedlichen Zahlenwerten an, wovon allerdings 11880 im Intervall liegen. Im Intervall befinden sich nur noch 4353 unterscheidbare Werte. Je weiter man sich von 0 entfernt, desto größer werden die Abstände zwischen darstellbaren Zahlen.

Ich bin zu wenig Mathematiker um das jetzt genau einschätzen zu können. Ich weis das die 16bit float natürlich im Rechner nicht als Kommazahlen berechnet werden sondern als Bruch. Somit ist es für mich nachvollziehbar was du über die Auflösung sagst. Aber wird es dann tatsächlich auch so benutzt? Man könnte die Werte doch problemlos wieder linearisieren und erst dann benutzen. Ich hatte es so verstanden, das es zunächst erst einmal wichtig ist eine entsprechende Anzahl von Werten zu haben, und die Verteilung ist zweitrangig. Bin ich da schief gewickelt?

Space


Antwort von TheBubble:

Ich bin zu wenig Mathematiker um das jetzt genau einschätzen zu können. Ich weis das die 16bit float natürlich im Rechner nicht als Kommazahlen berechnet werden sondern als Bruch. Nein. Fließkommazahlen werden durch Vorzeichen, Exponent und Mantisse (Signifikand) dargestellt - die Basis wird vorab festgelegt und braucht nicht gespeichert zu werden. Eine vollständige Erklärung ist für das Forum zu umfangreich. Hier zwei Links:

https://de.wikipedia.org/w/index.php?ti ... =141759481
https://de.wikipedia.org/w/index.php?ti ... =142665182
Somit ist es für mich nachvollziehbar was du über die Auflösung sagst. Aber wird es dann tatsächlich auch so benutzt? Man könnte die Werte doch problemlos wieder linearisieren und erst dann benutzen. Ich verstehe jetzt nicht, was Du meinst.
Ich hatte es so verstanden, das es zunächst erst einmal wichtig ist eine entsprechende Anzahl von Werten zu haben, und die Verteilung ist zweitrangig. Bin ich da schief gewickelt? Die Anzahl der Werte ist zwar wichtig, aber auch deren Verwendung und Verteilung, bezogen auf die jeweilige Anwendung. Und blei Fließkommazahlen ist es eben so, dass viele Werte um 0 herum liegen und später die Abstände größer werden. In der Nähe von 0 hat man also eine besonders hohe Auflösung, insbesondere im Vergleich zu z.B. 20.

16-Bit-Floats reichen zur Speicherung in der Regel aus (darum verwendet man sie ja auch), aber man sollte die Grenzen kennen und sich nicht über Artefakte wundern, wenn man z.B. eine Bitmap mit einem sanften Gradienten erst mit einer großen Zahl multipliziert, als 16-Bit-Float speichert, und später wieder durch die gleiche große Zahl teilt.

Space


Antwort von Peppermintpost:

wenn ich das richtig verstehe was du sagst dann ist ja der Wertebereich mit sehr hohem Schwarzwert und irrwitzigen Superbrights wie heute meist gearbeitet wird total kontraproduktiv zu unserer Farbauflösung.

Also sollte man für die Intermediates nach möglichkeit im Schwarz aufsetzen lassen um die Farbauflösung auch tatsächlich zu nutzen.

Hab ich das richtig verstanden? Wenn ja muss ich meinen Workflow ändern.

Space


Antwort von WoWu:

WARUM MACHEN WIR NICHT ALLES IN 32 bit?
Kamera-Rechner-alles???
Ich glaube, wir müssen zwei Dinge mal wieder voneinander trennen:
Die Tiefe des Kamerasignals und die Verarbeitungstiefe im Rechner.
Dazwischen liegt ein Übertragungskanal mit einer bestimmten Bandbreite und Rechenkapazität und ein Speichermedium mit einer bestimmten Kapazität.
Selbst im RAW Format bekommt man 14Bit Kameratiefe nur so mit Ach und Krach derzeit über den Workflow und heraus kommt letztlich ein Videosignal, in dem alle Artefakte, und vor allen Dingen ein bestimmter Störabstand "eingebacken" sind und sich nachträglich auch nicht verbessern lassen.
Auch nicht durch den Übergang in andere Farbmodelle oder eine noch so tiefe Art das Signal zu berechnen.
Man kann jetzt über das Dazutun von Dither diskutieren oder eine sonstwie geartete Entrauschung aber es handelt sich meistens um Überdeckung, nicht aber um Verbesserung des Störabstands.

Etwa Anderes ist es bei Computersignale, die bis zum Endprodukt immer neu gerechnet werden und daher bei jedem Renderprozess Signale entstehen, als würde eine Kamera neu aufnehmen.
Auch sind nicht die klassischen Engpässe der Kamera vorhanden.
Es besteht also nur selten Grund, nicht in 32 Bit zu rechnen.
Daraus resultierend hat ACES die 16 Bit festgeschrieben. Es ist der Kompromiss zwischen den (besseren) Computersignalen und noch den (derzeit) besten Kamerasignalen (14 Bit).
An dieser Stelle mit 32Bit zu arbeiten bringt überhaupt nichts, weil es weder dem Störabstand dient, noch das letzte Quäntchen Computersignal sichtbar ist, aber eine ungeheuere Aufblähung des Datenformates bedeutet.
Auch in der angesprochenen Werteverteilung bedeutet das absolut keinen Nachteil, denn von 10,12,14- Bit nach 16 Bit lassen sich die Formate selbst linear -ohne Punktoperation- mappen.
Was die Verarbeitung in 32 Bit angeht, macht es nur insofern Sinn, wenn man hinterher auch ein 16Bit Signal herausstellt -wenn man denn auch den Monitor hat, der das darstellt- und den Menschen, der die Auflösung überhaupt sieht.
ACES geht davon aus, dass man die e6Bit auch nur als Archivierung nutzt, für den Fall, dass es denn mal eine bessere Darstellung gibt.
Selbst für HDR Bearbeitung sind die 16 Bit mehr als "dicke".
Und sowas wie "Superweiss" oder "Superschwarz" gibt es in Kameraverfahen auch nicht denn alle Sensorwerte, also die komplette Dynamik ist gemapped. Also SW und WS des Sensors sind eingeschlossen. Es gibt keine Werte darüber oder darunter.

Space


Antwort von Peppermintpost:

was ich super finden würde wäre in der Tat wenn Kameras 32bit unkompressed aufzeichnen würden. Allerdings nicht wegen der Qualität sondern weil dann dieses ganze 4k Gehampel sofort aufhören würde.
Und weil man wie zu Film Zeiten den Kameramann der die Kamera einfach laufen lässt am nächsten Baum aufhängen würde. Dieser ganze Unsinn mit am Set schneiden und graden würde dann auch aufhören. Das fänd ich gut. Ich denke 32bit Aufzeichung in der Kamera würde die allgemeine Qualität deutlich verbessern, allerdings nicht die Farbwiedergabe. ;-)

Die ersten Versionen der Digitalen Kameras, egal ob Red oder Arri hatten eine super rottige Farbwiedergabe, was die Möglichkeiten in der Post angeht.
Inzwischen finde ich beide aber ausgezeichnet. MX bei Red war schon gut, Dragon ist sehr gut. Arriraw ist sehr gut, selbst das Arri Quicktime ist nicht schlecht. Und was mich am meisten beeindruckt ist was aus den Blackmagic Dingern raus kommt. Die kosten garnix und deren Raw Aufzeichnung ist phantastisch und super beschussfest. Wenn man das in der Post nicht da hin gebogen bekommt wo man hin will dann ist bei der Planung schon was Grundsätzlich schief gelaufen.

Was die Superbrights angeht, die entstehen nur weil alle in der Kamera mit LUT drehen und der hinterher gerade gebogen wird. Die Kamera hat diese Werte niemals aufgenommen, die entstehen Mathematisch in der Post. Den Sinn davon konnte mir die ganze Zeit auch keiner meiner Supervisoren oder Sequence Leads erklären. Der einzige positive Effekt den ich in der Verfahrensweise sehen kann ist das man nach den VFX immer noch das Gain herunter Graden kann.

Ich würde aber sehr gerne nochmal über die Werte Verteilung von 16bit sprechen. Ich habe mal eine Grafik angefügt. Wenn dem so ist das die Werteverteilung um den Nullpunkt sehr hoch ist und mit steigendem Wert stark abnimmt (rote Kurve) dann könnte man doch einfach eine negative Kurve (grüne Kurve) mit den Werten Multiplizieren. Dann käme doch automatisch eine Lineare Verteilung dabei heraus. Ich habe von Mathe null Ahnung, daher kann ich kaum glauben das das nicht auch gemacht wird, jeder Mathematiker sieht das doch sofort.

Ich hab mir mal ein paar Rushes angesehen und Schwarzwerte bei 0.3 sind doch keine Seltenheit. Gerade wo heute alles so ausgewaschen gedreht wird, da wäre linearisiert 16 bit bei der Werteverteilung totaler mist.

Da bitte ich nochmal um Aufklärung.

Space


Antwort von WoWu:

Nochmals zur Verdeutlichung:
32 Bit ist die Wortbreite, also 4Byte, die der Prozessor pro Taktimpuls verarbeiten kann.
Es ist also ein Wert der Speicheraddressierung.
Das hat mit der Signal-Verarbeitungstiefe der Kamera zunächst einmal nichts zu tun.
Dieser Wert repräsentiert die Anzahl der Werte pro Pixel.
Die Rechentiefe hat in diesem Zusammenhang mehr mit adressierbarem Speicherraum und Filegrössen zu tun.
Nicht, dass gleich jemand kommt und sagt ... warum machen wir nicht 64 Bit ... und meint damit Video :-(

Und was das Mapping angeht, so sind die Werte bei SW und WS durchaus nicht errechnet.
Die Kamera mappt die erste Blende immer ins letzte Bit und den Full-Well Wert immer ins erste Bit.
Die Übertragungsfunktion in den nicht linearen Raum verändert das dann und aus den vorhandenen 12 oder 14 Bit werden dann 10, oder 8, je nachdem; und korrektes Grading fängt mit der Revers-Kurve an, um die Übertragungsfunktion wieder zu linarisieren.

Nur die ausgemappeten Werte bekommt man dadurch natürlich nicht wieder.
Daher sieht ACES vor, die 16-Bit Farbraum als Ziel für die Kamerawerte. Das bedeutet aber noch nicht, dass auch 16 Bit benutzt werden. Das kommt nach wie vor auf die Sensoreigenschaften an.
Wenn der Sensor nur 12 Bit kann, sind in den 16 Bit auch nur 12 Bit Sensorinformation enthalten.
Nur in dem 16Bit linearen Farbraum kann man auch die Computerdaten mischen, weil man die Kameradaten VOR der Übertragungsfunktion (und damit Kompression) abspeichert.

Space



Space


Antwort von Peppermintpost:

hey wowu, ich glaube wir sprechen da gerade aneinander vorbei. Was du da ausgeführt hast, das ist mit vollkommen klar. Davon spreche ich auch nicht. Ich spreche von dem was Bubble geschrieben hat, was die Auflösungseigenschaften vom 16bit Farbraum angeht. Da hat er geschrieben das die Informationsdichte in Richtung 0 zunimmt. Oder anders herum die Farbinformation (Bit Tiefe) nimmt in den High ab.

Zitat:
So bietet ein half-float (binary16) zwischen eine Anzahl von 15362 unterschiedlichen Zahlenwerten an, wovon allerdings 11880 im Intervall liegen. Im Intervall befinden sich nur noch 4353 unterscheidbare Werte. Je weiter man sich von 0 entfernt, desto größer werden die Abstände zwischen darstellbaren Zahlen.

wenn ich also ein Bild habe das in einem Farbraum zwischen 0.3 und 0.9 liegt, was ja nicht ungewöhnlich ist, dann kann ich ja froh sein wenn das überhaupt noch 10bit an Informationen sind. Würde also bedeuten das dieses "Ich drehe mal mit flachem Gamma und gelifteten Blacks" bedeutet, lass uns mal 3/4 tel der Farbinformation in den Gulli Treten.
Das kann ich mir einfach nicht vorstellen, das das so ist, zumal es sich Mathematisch ja easy beheben lassen würde.

was die Kamera dabei aufzeichnet ist ja total egal, es geht jetzt nur um Farbtiefen und deren Informationsverteilung. Wenn 80% der Farbinformation zwischen 0 und 0.3 liegt und sich nicht verschieben lassen oder linearisieren lassen würde, dann wäre das ja wohl die dümmste Erfindung seit dem 3-Eckigem Rad. Ich glaub ja an vieles und vor allem an die Macht des Marketing, aber so bescheuert ist doch kein Ingenieur sowas auch nur anzudenken.
Ich kann es nicht nachvollziehen, weil mir das Technische wissen fehlt, ich kann es nur nicht glauben.

Oder das ist ein Schreibfehler - 11880 von 15362 liegen zwischen 0 und 1 und nicht zwischen 0 und 0,1. Das würde für mich Sinn machen.

Space


Antwort von WoWu:

Aber das ist doch immer so im linearen Raum.
Die Kamera belegt Jauch für die letzte Blende bei SW nur noch ein Bit und für die erste Blende bei Weiß 50Prozent aller Werte.
warum soll das hier anders sein ?
Oder sprechen wir jetzt über unterschiedliche Dinge ?

Space


Antwort von rudi:

Ich glaube Ihr redet aneinander vorbei:

Das Half-Float Format speichert eine Zahl als Exponent + Bruch: Das hier ist ein guter Wiki-Eintritt in die Materie:

https://en.wikipedia.org/wiki/Half-prec ... int_format

Die Lücken im Verlauf sind da klar genannt und haben einen mathematischen Hintergrund. Sie werden exponentiell größer, je weiter man sich von 0 entfernt.

Daher ist 16 Bit fp (aka Haflfloat) ziemlich ungeeignet um Bildmaterial zu speichern oder damit zu rechnen. Es war eher eine GPU-Krücke für Spieleentwickler, die schnelle, aber nicht sonderlich genaue Shader-Berechnungen wollten. 32 bit fp ist hinreichend genau, auch für mehrfache Rechenschritte. Aber lineare 16 Bit INT-Werte können eine Sensor-Ausgabe komplett und viel effizienter abspeichern. Und drum wird RAW auch sinnvollerweise in diesem Format gespeichert.
Vergesst fp16, hat keine Relevanz - nirgendwo im Videobereich. Und kein X86 Kern kann damit nativ ohne Umwandlung rechnen.

Space


Antwort von rudi:

was ich super finden würde wäre in der Tat wenn Kameras 32bit unkompressed aufzeichnen würden. Du kannst schon in 16 Bit INT jedes Photon einzeln zählen und speichern, wenn der FullWell unter 65.000 e- liegt (was bei praktisch allen aktuellen Sensoren der Fall ist). ;)

Space


Antwort von WoWu:

Wenn man sich das mal "übersetzt" heisst das, dass das .exf in "half float" linearisiert 1024 Werte pro Farbkomponente und Blende überträgt. Davon 30 Blenden im voller Übertragungsdichte und weitere 10 Blenden am unteren Ende in den "De-Normals", also mit reduzierten Werten.
Warum also soll das Format nicht geeignet sein ?
Selbst wenn man Monitore findet, die die Darstellungsgüte erreichen, muss man den Menschen neu erfinden.

Space


Antwort von rudi:

Warum also soll das Format nicht geeignet sein ?
. Nicht geeignet ist vielleicht auf hohem Niveau gepoltert. Aber es hat aufgrund seiner Speicherform eben schon eine Art Log-Kurve fest eingebacken. Eben eine Exponential-Funktion. und die ist fest.

Space


Antwort von WoWu:

Das ist wohl wahr, nur ist es an der Stelle akademisch, weil es nicht darstellbar ist.
Und selbst ACES (bzw. ILM mit .openEXR) hat "nur" die 30 Blenden berücksichtigt denn "de-normals" sind so klein, dass sie numerisch insignifikant werden.
In den Bereich kommen wir auch gar nicht, wenn .exr nach Spezifikation angewandt wird.

Ich weiss, dass das Thema kontrovers diskutiert wird, aber von den Problem, dass solche De-Normals andere Prozesse beeinflussen, sind wir im Videobereich weit entfernt.

Space


Antwort von TheBubble:

Da bitte ich nochmal um Aufklärung. Ich befürchte, eine vollständige Erklärung, die nicht nur auf ein paar Kernpunkte eingeht und ohne große Vorkenntnisse auskommt, ist für ein Forum zu umfangreich. Zumindest hätte ich den Anspruch es dann auch richtig zu erläutern und ein Forum bietet da einfach nicht die richtigen Möglichkeiten. Das müsste man besser als Artikel veröffentlichen, da man zunächst auch ein paar grundlegendere Dinge einführen/wiederholen müsste, um Leser auf einen gemeinsamen Stand zu bringen.

Du musst bei deinen Überlegungen immer mit unterscheiden, dass die Helligkeitsinformationen in verschiedenen Repräsentationen vorliegen können, z.B. Integer oder Float, und das jeweils linear oder mit Gamma. Und das erst mal unabhängig von der Anzahl an Bits, die verwendet werden.

Ich möchte aber mal Entwarnung geben: Auch ein 16-Bit-OpenEXR bietet zwischen 0 und 1 in den meisten Fällen für Film-/Videodaten genug Genauigkeit an. Einzig, wenn man Informationen in höhere Wertebereiche (d.h. extremes Superweiß und nicht nur etwas außerhalb) verschiebt, sollte man einen möglichen Zusammenfall von Werten berücksichtigen.

Für andere Anwednungen können 16-Bit-Floats aber schnell unzureichend sein. Dann speichert man 32-Bit-Floats oder sogar Doubles. Letztere werden in Normalfall für Berechnungen ohnehin bevorzugt, bei Videodaten spielt die Rechengenauigkeit aber keine so große Rolle und der Performancevorteil von Floats dominiert.

Space


Noch was unklar? Dann in unserem Forum nachfragen
Zum Original-Thread / Zum Blackmagic DaVinci Resolve / Fusion-Forum

Antworten zu ähnlichen Fragen //


Export-Dauer Resolve 16
Grab Still Export Problem Resolve
ProRes Export für Resolve 17 unter Windows - Voukoder macht's bald möglich
Blackmagic DaVinci Resolve 18.0.2 Update behebt unter anderem Probleme beim Export zu YouTube
Resolve ändert Farben vom Iphone nach export
Workaround für ProRes Export in Resolve unter Windows gesucht
Probleme mit Audio-Export in DaVinci Resolve – Ton fehlt bei Wiedergabe über WhatsApp oder Nextcloud!
MXF Export ... aus Stereo wird Mehrkanal
Problem mit Final Cut Pro X beim Export/Hochladen
GoProMaX Inhalte bei Export auf Bluray - Probleme
PP2020 - h.264 Export
"Media offline" nach Export, obwohl Dateien vorhanden sind
Update 10.4.9, Export Bug nur in 1080 obwohl andere Auflösung
Adobe Premiere Pro: Kein Audio nach Video-Export
Blase Farben nach Export
Bild & Ton nach Export nicht synchron / Adobe Premiere Pro
Adobe Premiere Pro Update 14.6 bringt schnellen Export und Medienersetzung in Motion Graphics-Vorlagen
Ruckeln durch unterschiedliche Bildformate nach Export?




slashCAM nutzt Cookies zur Optimierung des Angebots, auch Cookies Dritter. Die Speicherung von Cookies kann in den Browsereinstellungen unterbunden werden. Mehr Informationen erhalten Sie in unserer Datenschutzerklärung. Mehr Infos Verstanden!
RSS Suche YouTube Facebook Twitter slashCAM-Slash