Das lässt sich nicht pauschal beantworten, Domain.
Wenn die Wertänderungen in der Tabelle einer festen Regel folgen, wird man wohl immer die Funktion bevorzugen.
Die "RGB-Tabelle" sieht nur zweidimensional aus. Sie repräsentiert tatsächlich einen dreidimensionalen Farbraum. Das meint:
Ein 8Bit-Cube besteht aus 256x256x256 Zellen. In einer Ecke befindet sich der Nullpunkt. Von ihm gehen die drei Index-Achsen aus für R, G, und B. Die Zelle direkt am Nullpunkt hat den Index 0/0/0 und anfänglich den Inhalt RGB 0/0/0, die Zelle diagonal gegenüber den Index 255/255/255.
Jede Zelle enthält ein Werte-Tripel R, G, B, dessen Inhalt durch die Anwendung der Farbkorrekturen verändert wird, wobei der Index gleich bleibt.
Änderst Du beispielsweise die Sättigung, werden die Inhalte aller Zellen verändert. Das gilt bei anderen Modifikationen gleichermaßen. Mal betrifft es die Farbe selbst, mal die Sättigung, mal die Helligkeit. Die Wertänderungen bewegen sich innerhalb des Cubes in unterschiedliche Richtungen bezogen auf die absoluten Werte R, G, und B. Das endgültige Ergebnis folgt also weder einer festen Regel, noch lässt sich eine simple Kurve aus dem Cube ableiten, die in eine einfache Funktion überführt werden könnte.
Gäbe es eine solche Funktion, würde sie m. E. immer alle Daten aller Zellen durchrechnen, auch solche, die gar nicht gebraucht werden. Stell Dir das mal in 32-BIT-Float vor ...
Die LUT vereinfacht das Problem, in dem sie mit einem kleineren Würfel arbeitet, der in den großen projiziert wird, und damit die Stützstellen für die Interpolation der im Frame benötigten Daten einrammt, die immer noch aufwendig genug ist. Es ist also ein Mischkonzept aus Daten und Funktionsberechnung, entwickelt unter dem Aspekt ressourcenschonender Vorgensweise (Rechenleistung, RAM-Bedarf) bei optimalem Ergebnis (marginale, nicht mehr wahrnehmbare Interpolationsfehler bei LUT SIZE 32 und 32Bit Float)
Klingt ziemlich überzeugend, was du schreibst.
Ich habe aber nie nur eine und alles umfassenden Funktion im Sinn gehabt.
Aber eines habe ich schon früh begriffen: die Mathematik ist dazu da, um komplexe funktionale Zusammenhänge in stringent einfachster Form zu formulieren.
Welche Rolle sollen da bitte die unsäglichen Abweichungen und Sonderfälle spielen, die du da erwähnst?
Es gibt nichts, das nicht in Formeln gegossen werden könnte und schon gar nicht bei solch simplen Dingen wie bei der Umrechnung von Werten in andere Werte. Wir befinden uns ja nicht auf dem Gebiet der Relativitäts- oder gar der Quantentheorie.
Vielleicht liegst ja nur am Verständnis und an den Begrifflichkeiten, domain.
Ich will es mal so ausdrücken:
Programme, die LUTs verarbeiten können, benutzen eine "Universalfunktion" dafür, die sich zusätzlich auf die Werte in der LUT stützen, sozusagen als Parameter. Die Werte alleine sind wertlos.
Natürlich kannst Du das Problem mit nahezu beliebig vielen Formeln am Stück lösen. Doch unabhängig davon: Es kann nicht gelingen, wenn sie nicht die variablen Inhalte der RGB-Tabelle berücksichtigen. Du wirst also die konkreten RGB-Werte einer Verabeitung irgendwie als Parameter oder Variablenwerte den Funktionen mitgeben müssen, oder nicht? Und dann wirst Du merken, dass es keinen Sinn macht, den ganzen Cube durchzurechnen, und vermutlich überlegen, wo sich ein gesundes Verhältnis zwischen Genauigkeit, Qualität und Effizienz abzeichnet.
Es könnte sein, dass Du dann die LUTs mit den implizierten Interpolationsverfahren neu erfindest ... ;)
Oder was vergleichbares.
Es ist ein sehr praktisches Problem der Datenverarbeitung, domain. Auf konkreter IT-Technik für den Bereich Videobearbeitung. Kein theoretisches Problem der Mathematik.
Es war mir immer klar, dass Programmierer ja nicht über Jahre solche Vollpfosten sein können, dass sie nicht die effizienteste Lösung für ein Problem gefunden hätten.
Bei mir beginnt sich ein Einsehen breit zu machen :-)
Fehler in der LUT für Resolve gefunden, der Name darf eine bestimmte Namenslänge nicht überschreiten (9 Zeichen ???). Habe die LUT intern nun "hot" statt "warm" benannt und das einladen in meinen Resolve funktioniert.
Um dieses Thema nicht mit weiteren LUTs völlig zu pflastern zu müssen, mache ich für die (film) Looks ein neues Thema auf.
Für die reinen Pocketfarben soll es hier nun genug sein, es sei denn die beiden LUTs erzeugen noch undokumentierte Fehler.
Ich habe tatsächlich eine Szene wo es kleine Artefakte mit der LUT gibt - eine orange LED Anzeige die gepulst wird, kippt bei bestimmten Kamerawinkeln in einigen Segmenten für ein paar Frames zu reinen rot. Habe daran schon mehrere Stunden gebastelt, bekomme es aber nicht weg.
Und nochmals der Hinweis, in jeder Software muss die weitere Verarbeitung aus der LUT erfolgen. Zuerst ProRes auf LUT, danach erst weitere Schritte. Das erreicht man in Premiere und AE in dem die Effekte von oben nach unten durchlaufen werden.
Habe jetzt mal gegogelt, warum bei LUTs nicht „einfach“ drei Funktionen, also eine pro Kanal für die Umrechnung und Verschiebung von Werten verwendet werden.
Wäre prinzipiell zwar möglich, aber es müsste viel zu viel Rechnpower aufgewendet werden. Das geht über referenzierte Tabellen mit Knotenpunkten (also quasi durch gerade Streckenstücke zusammengestoppelter „Kurve“) doch wesentlich schneller, auch wenn zwischen den Stützstellen interpoliert werden muss.
es sind nicht nur schnöde Farben die eine LUT beeinflusst, sondern auch das gesamte Kontrastverhalten - RGB = Farben und Helligkeit.
Das war ja auch mein Anfangsfehler, hatte die erste LUT im RGB Farbraum gestaltet. Die neuen im YUV Farbraum, hier bleiben dann die Farben auch genau erhalten wenn ich vor abspeichern der LUT an den Gammawerten drehe. Die LUT macht natürlich wieder RGB daraus, aber inkl. genau mit meinen gewünschten Kontrastkurven.
Ja aber du sprichst ja selbst von Kontrastkurven
Alles lässt sich in Kurven darstellen, selbst eine Erhöhung der Farbsättigung und das gilt für eine Kontraststeigerung erst recht: runter mit den Schatten und Aufhellen der Lichter.
Da bin ich aber schon gespannt.
Nur mal als Beispiel, wie die selektive Farbsättigung der Farbe Blau in Photoshop erhöht wird: vor der Korrektur RGB 141,153,169 nach der Korrektur 130,153, 183. Einfaches Umrechnungsschema eigentlich und natürlich abhängig vom gewünschten Grad der Sättigung.
Hier in Resolve ist das nun ein kleiner Ausschnitt um die BMPCC Farben nach Vectorscop zu justieren. Siehe den roten Pfeil im Vectorscop und in dem HUE Farbtonmischer, davon gibt es dann noch einige mehr, z.B. für jeden Farbwert eine eigene Helligkeitskurve die genauso zerklüftet ausschaut. Alle Kurven müssen dann in einer reinen RGB Tabelle zusammen geführt werden, das macht resolve zum Glück ganz alleine und völlig automatisch. keine Ahnung wie genau die Kurve im RGB Farbraum sprich LUT im Endeffekt ausschaut, einfacher aber bestimmt nicht. Die fertige LUT ist dann 500 Kb "groß".
Danke für deine Mühe Ruessel.
Sieht ja so zerklüftet wie ein Mittelgebirgsquerschnitt aus. Da glaube ich schon, dass rein mathematische Funktionen ziemlich komplex aussehen würden. Selbst mit den genial einfachen und mathematisch anspruchslosen Bezierkurven würde man ohne Stückelung nicht auskommen.
Ich kann sehr gut nachvollziehen, wie es dir bei der Konstruktion von LUTs ergeht. Ist eine ziemlich anstrengende Langzeitherausforderung, wo man sich richtig reinknieen muss und es viele Miss- aber letzten Endes mehr Erfolgserlebnisse gibt, halt die perfekte Dramaturgie.
Gottseidank können einige viel besser und mit mehr Geduld erklären als der herablassende Herr Doktor, der Antipädagoge, der mit einer Ortsfrequenz arbeitet, die vielen von uns zu hoch ist :-)
Ich habe tatsächlich eine Szene wo es kleine Artefakte mit der LUT gibt - eine orange LED Anzeige die gepulst wird, kippt bei bestimmten Kamerawinkeln in einigen Segmenten für ein paar Frames zu reinen rot. Habe daran schon mehrere Stunden gebastelt, bekomme es aber nicht weg.
Diesen Fehler konnte ich nun beheben, hier war die Kurve im Rotbereich etwas zu breit.
Hier noch ein kleiner Bugreport: Ich kriege (mit 3.2) 'pink highlights', mit anderen alternativ ausprobierten LUTs aber nicht. Es gibt dazu eine Diskussion hier im Blackmagic-Forum. Ich habe aber keine Ahnung, ob sich die dort vorgestellte Lösung auch in einen LUT bauen lässt.
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.
