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.
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.
-------------------------------------------------------
leave the gun take the cannoli
------------------------------------------------------- www.movie-grinder.com
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..
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)
-------------------------------------------------------
leave the gun take the cannoli
------------------------------------------------------- www.movie-grinder.com
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?
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.
-------------------------------------------------------
leave the gun take the cannoli
------------------------------------------------------- www.movie-grinder.com
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..
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.
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.
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.
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.
-------------------------------------------------------
leave the gun take the cannoli
------------------------------------------------------- www.movie-grinder.com
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.
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 ;-)
-------------------------------------------------------
leave the gun take the cannoli
------------------------------------------------------- www.movie-grinder.com
@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??
Die Amerikaner lügen immer!
Die Australier und Chinesen auch.
Nur billiger!
In Brüssel balgt man sich derweilen, wer von den Eurpäern zuerst lügt...
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.
-------------------------------------------------------
leave the gun take the cannoli
------------------------------------------------------- www.movie-grinder.com
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.
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.
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.
-------------------------------------------------------
leave the gun take the cannoli
------------------------------------------------------- www.movie-grinder.com
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.
WoWu hat geschrieben:
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.
WoWu hat geschrieben:
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.
-------------------------------------------------------
leave the gun take the cannoli
------------------------------------------------------- www.movie-grinder.com
WoWu hat geschrieben:
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.
-------------------------------------------------------
leave the gun take the cannoli
------------------------------------------------------- www.movie-grinder.com
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.
WoWu hat geschrieben: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 ;-)
-------------------------------------------------------
leave the gun take the cannoli
------------------------------------------------------- www.movie-grinder.com
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.)
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.
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.
Zuletzt geändert von TheBubble am Do 11 Jun, 2015 23:43, insgesamt 1-mal geändert.
WoWu hat geschrieben:
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.
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,
WoWu hat geschrieben: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.
Rechtliche Notiz: Wir übernehmen keine Verantwortung für den Inhalt der Beiträge
und behalten uns das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
