Seite 14 von 15
Re: BM Pocket Farben
Verfasst: Fr 19 Sep, 2014 20:12
von Reiner M
ruessel hat geschrieben:Was ich auf jeden Fall verkehrt gemacht habe, ich habe die LUT im RGB Modus erstellt - vollkommen verkehrt, damit hat die Luminanz direkt Auswirkung auf die Farben.
Meinst Du die Arbeitsweise oder das Ergebnis, die exportierte LUT?
Die Wahl der Werkzeuge bei der Arbeit beeinflusst nur die Vorgehensweise, um zum Ergebnis zu kommen. Mehr nicht.
Dein Vektorskop zeigt ja in jedem Fall während der Arbeit die Farben der Cb/Cr-Kanäle (nicht die RGB-Kanäle), die Y-Waveform die Luminanz im Y-Kanal. Egal, mit welchen Werkzeugen Du da ran gehst.
Die exportierte LUT enthält schließlich die resultierende Umsetzung Deiner Arbeit in RGB, also die absoluten RGB-Werte je RGB-Kanal.
Beste Grüße,
Reiner
Re: BM Pocket Farben
Verfasst: Sa 20 Sep, 2014 09:30
von ruessel
Meinst Du die Arbeitsweise oder das Ergebnis, die exportierte LUT?
Meine Arbeitsweise, denn die LUT kann doch nur in RGB vorliegen - wenn ich das richtig verstanden habe.
Es geht mir um die Kontrasteinstellung. Hier habe ich einen Fehler gemacht und zuerst die Farben getrimmt dann in einer anderen Software die Kontrasteinstellung im RGB Modus bearbeitet. Ich wusste nicht, das dabei im RGB die Farben auch hoch oder runtergezogen werden und nur im YUV Modus man wirklich sauber Helligkeit von der Farbe getrennt bearbeiten kann - Basics eines Coloristen der ich nicht bin.
Ich glaube auch, das nicht jede Software ein YUV Modus mitbringt, in Premiere CS6 habe ich noch gar nicht geschaut. Es ist ja ein leichtes dies festzustellen, bewege ich die Helligkeit darf das Vectorscop sich kein Haar bewegen. Ja, ich lerne dazu ;-)
Nochmal zum Color Checker, der bietet im DaVinci eine "mach mal schnell die Farben schön" Taste. Im Prinzip funktioniert es auch, nur in der Praxis nicht. Hier wird das Rot der Pocket völlig übersteuert und frisst aus. Das hatte ich auch schon von Hand festgestellt und versucht gefühlvoll zu steuern. Hier bin ich noch am basteln, Gelb und Grün gelingt mit DaVinci wirklich sauber.
Eigentlich wollte ich schon damit fertig sein, aber im Verwandtenkreis gibt es einen Krankheitsfall und ich mache den Fahrer...... ich komme nur Stundenweise dazu eine LUT zu basteln.
Re: BM Pocket Farben
Verfasst: Sa 20 Sep, 2014 10:00
von krokymovie
ruessel ich habe mal mit deiner lut gespielt...deine lut 2.11 trifft die farben gut ;O)
klasse arbeit von dir, danke.
gruß
krokymovie
Re: BM Pocket Farben
Verfasst: Sa 20 Sep, 2014 10:03
von ruessel
Danke, wird vielleicht noch besser ......
Re: BM Pocket Farben
Verfasst: Sa 20 Sep, 2014 11:15
von Reiner M
ruessel hat geschrieben:Ich wusste nicht, das dabei im RGB die Farben auch hoch oder runtergezogen werden und nur im YUV Modus man wirklich sauber Helligkeit von der Farbe getrennt bearbeiten kann - Basics eines Coloristen der ich nicht bin.
Ich glaube auch, das nicht jede Software ein YUV Modus mitbringt, in Premiere CS6 habe ich noch gar nicht geschaut. Es ist ja ein leichtes dies festzustellen, bewege ich die Helligkeit darf das Vectorscop sich kein Haar bewegen. Ja, ich lerne dazu ;-)
Ja, das sind alles sind sehr wichtige Erkenntnisse. Ich hatte deshalb weiter oben schon mal darauf hingewiesen:
Reiner M hat geschrieben:
2. Der erste sinnvolle Schritt ist dann die Gamma-Anpassung im Y-Kanal. Dabei solltest Du darauf achten, dass der mittlere Grauwert immer auf 50% bleibt. Das zeigt Dir Dein Vektorskop nicht.
3. Dann erst gehts an die Farben. Wenn möglich, Cb-Gamma und Cr-Gamma getrennt justieren, ggf. eine Reverse, also ein S-Kurve drauf ausprobieren, um die Verteilung der Tonwerte anzupassen. (Kann man natürlich je nach Werkzeug auch anders machen).
RGB kennt keine dedizierten Kanäle für Luminanz und Sättigung. Helligkeiten und Sättigungen von Farben entstehen allein durch Wertänderungen in allen drei Kanälen R, G, und B, die ja immer gemischt werden.
Der Grauwert ist daher ein wichtiger Indikator bei dieser Arbeit. In reinen Grauwerten (von Schwarz bis Weiß) kommen in YCbCr keine Farben vor. Ein echtes S/W-Bild erzeugt im Vektorskop nur einen Punkt bei 0%, wenn auch in der RGB-Parade drei volle, identisch gefüllte Farbbalken.
Reiner M hat geschrieben:
Doch jede Änderung bedeutet für mich hier:
a) stets den mittleren Grauwert auf 50% halten,
b) bei den "Treppen" aller Grauwerte darauf achten, dass die Farben nicht auseinanderlaufen, sondern zusammengeführt bleiben oder werden. Eine weiße Stufe muss in der Wave weiß sein, nicht bunt gestreift.
Deshalb war es mir weiter oben auch wichtig, den Weißpunkt optimal zu justieren. Zu warrm oder zu kalt bringt insgesamt verdrehte Farben.
Premiere CS6 kennt übrigens unterschiedliche Werkzeuge. Manche arbeiten direkt auf YUV und nur dort, andere auf RGB. "Luminanzkurve" beispielsweise verändert tatsächlich nur die Luminanzwerte im Y-Kanal und fasst die Sättigungswerte in Cb/Cr nicht an. "RGB-Kurve" verhält sich natürlich anders.
Übrigens: In After Effects bietet "SA Color Finesse 3" (Synthetic Aperture) vollständige Werkzeuge für die getrennte Y-, Cb- und Cr-Modifikation. Leider ist dort aber der Export des Ergebnisses als LUT nicht so komfortabel gelöst. Das nur nebenbei. Du hast mit anderen Programmen zzt. genug zu tun, denke ich.
Beste Grüße,
Reiner
Re: BM Pocket Farben
Verfasst: Sa 20 Sep, 2014 17:38
von ruessel
Du hast mit anderen Programmen zzt. genug zu tun, denke ich.
Ja. ;-)
Leider funzt daVinci LUT nicht mit LUT Buddy, hier muss konvertiert werden. Umgekehrt geht es... aber nur die 32er, komisch.... habe auch schon den Header von Hand geändert, nützt aber nix.
Leider bin ich heute wieder zu nix gekommen.
Re: BM Pocket Farben
Verfasst: Sa 20 Sep, 2014 20:25
von Reiner M
ruessel hat geschrieben: habe auch schon den Header von Hand geändert, nützt aber nix.
Im Header alle Zeilen mit # (Kommentare) raus, alles Unnötige raus, nur die Zeile mit der Size-Angabe im Aufbau wie bei LUT Buddy, danach eine Leerzeile. Dann die Tabelle. Geht nicht?
Beste Grüße,
Reiner
Re: BM Pocket Farben
Verfasst: Sa 20 Sep, 2014 20:34
von cantsin
Reiner M hat geschrieben:
Im Header alle Zeilen mit # (Kommentare) raus, alles Unnötige raus, nur die Zeile mit der Size-Angabe im Aufbau wie bei LUT Buddy, danach eine Leerzeile. Dann die Tabelle. Geht nicht?
Bei ruessels BMPCC_LUT64_V2.11.cube : leider nein.
Re: BM Pocket Farben
Verfasst: So 21 Sep, 2014 09:39
von ruessel
Dann die Tabelle. Geht nicht?
Es kann nur noch die Länge der Tabelle das Problem sein - die ausgemessen habe ich nicht. Ich kann sie aber inzwischen problemlos konvertieren.
Später müssen wir uns noch unbedingt über die eigentliche Pocket Belichtung nach Histogramm kümmern. Ich würde schon einmal eine These in den Raum werfen: wenn man das Histogramm in der Mitte teilt, dann ist links davon der Böse Bereich - rechts davon der gute.
Belichte ich einen gedruckten Testchart (Grautreppe) ist der so mit Scheinwerfer beleuchtete Dynamikumfang für die Pocket zu klein, er nimmt ca. 1/3 drittel des Histogrammraumes ein. Ich habe nun die Möglichkeit diesen Testchart 3x unterschiedlich zu belichten, im unteren drittel, in der Mitte und im oberen drittel des Pocket Histogramms.
"Entwickel" ich nun diesen Chartfilm ProRes 10Bit in DaVinci, stellt sich raus, das alles was unterhalb der Mitte belichtet wurde auch sehr deutliches Bildgrieseln besitzt.
Fotografiere ich diesen Chart mit meiner Nikon in JPG, wird das gesamte Histogramm bei der selben Beleuchtung ausgenutzt. Das Bild ist dann super ohne Bildstörungen - wurde praktisch in der Kamera aus RAW so entwickelt. Bei ProRes habe ich diese Möglichkeit nicht mehr, hier sind zwar einige Blenden zum hervorholen noch drin, aber nicht mehr in guter Qualität - sprich für rauschfreie Mittentöne reicht es nicht mehr.
Das ist wichtig zu wissen. In der Natur z.B. hübsches Modell unter der Laterne sieht der Dynamikumfang ganz anders aus. Hier muss ich schon während der Aufnahme die Bildqualität festlegen.
Ich würde sagen, was nützt mir bei diesem Beispiel der Glühfaden in der Strassenlampe, wenn das Modell nachher "grieselt". Also das Modell sollte im Histogramm von der Mitte bis zum oberen drittel der Belichtung liegen, egal was das Histogramm zur Lampe sagt.
Re: BM Pocket Farben
Verfasst: So 21 Sep, 2014 10:08
von cantsin
ruessel hat geschrieben:"Entwickel" ich nun diesen Chartfilm ProRes 10Bit in DaVinci, stellt sich raus, das alles was unterhalb der Mitte belichtet wurde auch sehr deutliches Bildgrieseln besitzt.
Das dürfte auch der Grund sein, weshalb die Kamera nach dem
ETTR-Prinzip belichtet wird (und deshalb anfangs auch nur Zebras und kein Histogramm hatte).
Re: BM Pocket Farben
Verfasst: So 21 Sep, 2014 10:21
von ruessel
(und deshalb anfangs auch nur Zebras und kein Histogramm hatte).
Nur Zebra finde ich aber sehr dürftig, hier kann ich eigentlich gar nix sehen wo mein Objekt der Begierde in der Belichtung steht.
Re: BM Pocket Farben
Verfasst: So 21 Sep, 2014 18:59
von ruessel
http://www.fxsupport.eu/temp/BMPCC_LUT_V32.zip
Neue BMPCC 3D LUT "Neutral" in drei Versionen ohne sichtbaren Unterschied untereinander:
1. LUT für Resolve
2. LUT Size 32 - LUT Buddy
3. LUT Size 64 - LUT Buddy
Ganz wichtig:
Erst die LUT benutzen und danach erst Gamma/Histogramm auf die Szene anpassen. Umgekehrt werden die Farben falsch eingestellt!!!!
LUT wurden unter Benutzung Resolve + Color Checker erstellt.
Re: BM Pocket Farben
Verfasst: So 21 Sep, 2014 19:55
von ruessel
Oben Link erneuert, neue Version 3.1
Jetzt auch inkl. mit etwas wärmeren Look.
ZIP enthält 3x Version 3.1 "neutral" plus 3x Version 3.1 "warm"
Re: BM Pocket Farben
Verfasst: So 21 Sep, 2014 20:34
von Axel
Echt gut geworden deine Resolve LUTs. Muss auch mal so einen Farbchart benutzen. Ist die Anwendung kompliziert? Gibt wohl ein paar, die ihre Schwierigkeiten damit hatten.
Re: BM Pocket Farben
Verfasst: So 21 Sep, 2014 20:47
von ruessel
Ist die Anwendung kompliziert?
Nein. Nur das automatische Ergebnis haut nicht hin..... ;-) Rot frisst Fläche.
Re: BM Pocket Farben
Verfasst: So 21 Sep, 2014 22:24
von cantsin
V3.1-warm für Resolve hat einen Bug - er funktioniert bei mir erst nach Ändern der Titelzeile.
Allgemein fällt mir auf, dass V3 mehr ins Grüne tendiert als V2, weswegen ich bei meinem Testprojekt Magenta/Grün entsprechend korrigieren mußte.
Re: BM Pocket Farben
Verfasst: Mo 22 Sep, 2014 07:11
von ruessel
Allgemein fällt mir auf, dass V3 mehr ins Grüne tendiert als V2,
Werde ich nochmal kontrollieren, Danke für den Hinweis.
Re: BM Pocket Farben
Verfasst: Mo 22 Sep, 2014 12:31
von ruessel
http://www.fxsupport.eu/temp/BMPCC_LUT_V32.zip
Ja, mit DaVinci und Colorchecker ist die Genauigkeit etwas daneben. Ich habe nun noch einmal den teuren DSC Farbchart im Sonnenlicht abgefilmt (Heliopan 103, ND Heliopan 0.9, Nikon 18-55 Optik, Speedbooster, 800ASA, 5600K).
Von Hand justiert scheint genauer, nach Vectorscop stimmen die Farben und sind auch einen Hauch kräftiger - aber extrem genau nach dem Resolve Vectorscop. siehe Anhang.
ZIP enthält wieder 3x neutral, 3x warm LUTs. Je 1x für Resolve und 2x für LUT Buddy in zwei Size Größen.
Ich weise darauf nochmals hin,
zuerst das BMPCC ProRes File mit der LUT versehen,
danach erst Schwarz, Mitte, Weißtöne abgleichen - sonst werden einzelne Farben wieder schief!
Re: BM Pocket Farben
Verfasst: Mo 22 Sep, 2014 12:51
von ruessel
Ich fange nun an einige Filmlooks als LUT zu basteln, aus den Daten meiner chemischen Filme.
Ich muss mir noch Gedanken machen wie ich die Gammakurven darin übertrage. Farbe und Gamma gehen Hand in Hand und können meiner Meinung nach nicht völlig getrennt gesehen werden. Wahrscheinlich kann ich diese nur Ansatzweise in die LUT einbauen, denn das rohe Prores benötigt immer noch eine Feinjustierung von Hand - je nach der Belichtung vom Kameramann/Frau.
Re: BM Pocket Farben
Verfasst: Mo 22 Sep, 2014 13:22
von rainer7u5
ruessel hat geschrieben:
Fotografiere ich diesen Chart mit meiner Nikon in JPG, wird das gesamte Histogramm bei der selben Beleuchtung ausgenutzt.
Bei der Pocket hingegen ...
ruessel hat geschrieben:
ist der so mit Scheinwerfer beleuchtete Dynamikumfang für die Pocket zu klein, er nimmt ca. 1/3 drittel des Histogrammraumes ein. Ich habe nun die Möglichkeit diesen Testchart 3x unterschiedlich zu belichten, im unteren drittel, in der Mitte und im oberen drittel des Pocket Histogramms.
Die Histogramme der Nikon/JPG und Pocket/ProRes-Film kannst du nicht so einfach vergleichen. JPG, sRGB und Rec.709 erlauben ca. 7 Blendenstufen Dynamikumfang, während die Pocket im Film-Modus ca. 13 Blendenstufen aufzeichnen kann. Deshalb ist im Histogramm der Pocket soviel Platz, bei der Nikon aber nicht.
Und während die Nikon wie fast alle Kameras auf 18% Grau belichtet - also in der Mitte des Histogramms normalerweise die meisten Werte liegen, belichtet die Pocket ETTR. Es wird möglichst überbelichtet, ohne die Lichter zu clippen, denn mehr Licht bedeutet mehr Detail und weniger Rauschen. Später im Grading muss man dann zwar die Belichtung herunterregeln, aber die Farbwerte haben eine bessere Qualität als wenn direkt auf 18% Grau belichtet worden wäre.
Über das Rauschen:
ruessel hat geschrieben:
Fotografiere ich diesen Chart mit meiner Nikon in JPG, wird das gesamte Histogramm bei der selben Beleuchtung ausgenutzt. Das Bild ist dann super ohne Bildstörungen - wurde praktisch in der Kamera aus RAW so entwickelt. Bei ProRes habe ich diese Möglichkeit nicht mehr, hier sind zwar einige Blenden zum hervorholen noch drin, aber nicht mehr in guter Qualität - sprich für rauschfreie Mittentöne reicht es nicht mehr.
...
Ich würde sagen, was nützt mir bei diesem Beispiel der Glühfaden in der Strassenlampe, wenn das Modell nachher "grieselt". Also das Modell sollte im Histogramm von der Mitte bis zum oberen drittel der Belichtung liegen, egal was das Histogramm zur Lampe sagt.
Ich stimme dir hier zu, würde es aber anders formulieren:
1. Grundsätzlich muss der (potenziell) 13 Blendenstufen große Dynamikumfang auf die 7 Stufen von Rec.709 zusammengestaucht werden. Ob man da Schatten ins Schwarz gehen läßt oder helle Details ins Weiß, muss man im Einzelfall entscheiden.
2. Überbelichtete Bereiche abzudunkeln bewahrt deren hohe Aufnahmequalität, aber dunkle Bereiche aufzuhellen kann störendes Rauschen hervorbringen.
3. Deshalb würde ich bei der Aufnahme erstmal die Pocket ihre automatische ETTR machen lassen, dann aber prüfen, ob ggf. wichtige Bildbereiche zu dunkel erscheinen. Wenn nicht, ist alles in Ordnung, wenn ja, muss ich manuell abblenden und ausgefressene Lichter (den Glühfaden z.B.) in Kauf nehmen.
Re: BM Pocket Farben
Verfasst: Mo 22 Sep, 2014 13:25
von ruessel
kleiner Eindruck LUT Version 3.2 in der frühen Morgensonne, oben ProRes unbearbeitet, darunter die neutrale LUT inkl. schwarz/weißpunkt gesetzt, ganz unten die wärmere LUT.
![Bild](http://www.fxsupport.eu/temp/LUT32.jpg)
Re: BM Pocket Farben
Verfasst: Mo 22 Sep, 2014 13:33
von ruessel
Deshalb würde ich bei der Aufnahme erstmal die Pocket ihre automatische ETTR machen lassen,
Tja, ich filme mit der Pocket grundsätzlich voll manuell..... hier muss ich mich nochmal mit dem LCD und dem Histogramm der Pocket auseinandersetzen. Denn im LCD habe ich mehr Details wenn ich ein klein wenig unter der Rechten Seite des Histogramms bleibe. Aber das ist nur das LCD was wahrscheinlich völlig nach dem Mond anzeigt.
Ein gutes Histogramm habe ich nun in PP CS6 auch gefunden, bei meinen Matroxeffekten kann ich in Echtzeit und ohne Verzögerung Schwarz/weiß und Mitten nach Histogramm einstellen. Reicht eigentlich zu 99% völlig aus.
JPG, sRGB und Rec.709 erlauben ca. 7 Blendenstufen Dynamikumfang, während die Pocket im Film-Modus ca. 13 Blendenstufen aufzeichnen kann.
Verstehe ich nicht ganz, ich kann doch auch 20 Blenden in einem JPG unterbringen, ist dann zwar optisch etwas seltsam. also 20 Blenden innerhalb von 0-255RGB, klar, dann bleiben wenig stufen pro Blende, aber sollte doch funktionieren.
Wie lange bleibe ich im 10Bit Farbraum? Kappt meine LUT schon die 10Bit auf 8Bit? Ich wüsste im Moment nicht wie ich das in PP CS6 kontrollieren könnte.
Re: BM Pocket Farben
Verfasst: Mo 22 Sep, 2014 13:55
von rainer7u5
ruessel hat geschrieben:Deshalb würde ich bei der Aufnahme erstmal die Pocket ihre automatische ETTR machen lassen,
Tja, ich filme mit der Pocket grundsätzlich voll manuell...
Wie belichtest du denn? Mittig, um die realen Verhältnisse abzubilden oder ETTR, um die "beste" Aufnahmequalität zu erhalten? Klaro, da gibt es nicht die
eine mögliche Lösung.
Die Idee bei ETTR ist ja, möglichst keine Schatten aufhellen zu müssen, um Rauschen zu vermeiden. Ob ETTR manuell oder automatisch, ist dann ja egal.
Für mich ist diese ETTR-Idee ja auch ziemlich neu. Aber ich denke, es ist besser, mehrere Methoden anwenden zu können, je nach Situation.
Und im Prinzip hat ETTR viel mit dem Zonensystem der analogen Fotografie zu tun: Es ist ein Schritt, den Film so zu belichten, dass er den Dynamikumfang der Szene aufnimmt. Aber es ist ein zweiter Schritt, den Film so zu entwickeln, dass das Endresultat die richtige Helligkeit und Kontrast hat.
Erst mit Belichtung auf 18% Grau und automatischem Entwicklungsprozess auf 18% Grau sind wir verwöhnt worden.
Re: BM Pocket Farben
Verfasst: Mo 22 Sep, 2014 14:21
von rainer7u5
ruessel hat geschrieben: JPG, sRGB und Rec.709 erlauben ca. 7 Blendenstufen Dynamikumfang, während die Pocket im Film-Modus ca. 13 Blendenstufen aufzeichnen kann.
Verstehe ich nicht ganz, ich kann doch auch 20 Blenden in einem JPG unterbringen, ist dann zwar optisch etwas seltsam. also 20 Blenden innerhalb von 0-255RGB, klar, dann bleiben wenig stufen pro Blende, aber sollte doch funktionieren.
Eine Kamera, die direkt in JPG speichert, wird vielleicht noch oben und unten eine Blendenstufe unterbringen, indem sie einen weichen Rolloff macht (also technisch gesprochen eine moderate S-Kurve anwendet). Aber irgendwann muss sie die Schatten/Lichter abschneiden, denn JPG, sRGB und Rec.709 sind auf einen bestimmten Kontrast genormt.
Wenn allerdings 13 oder 20 Blendenstufen in Raw gespeichert wird und das auf einem normalen Monitor angezeigt wird, dann sehen wir das typische kontrast- und farbarme Bild, das wir von den BM Kameras kennen. Der Zuschauer wird das als häßlich empfinden, wir als "Grader" wissen aber, da muss jetzt noch der Kontrast erhöht werden, was ggf. Lichter oder Schatten abschneidet.
ruessel hat geschrieben:
Wie lange bleibe ich im 10Bit Farbraum? Kappt meine LUT schon die 10Bit auf 8Bit? Ich wüsste im Moment nicht wie ich das in PP CS6 kontrollieren könnte.
Die .cube LUTs haben normalerweise Fließkomma-Genauigkeit für ihre Werte. Wichtiger sind aber die Knotenpunkte, bei deinen LUTs z.B. 32 oder 64. Das bedeutet, dass PP alles zwischen diesen Knotenpunkten interpolieren muss. PP wird also durch die wenigen Knotenpunkte gezwungen, intern in Fließkommazahlen zu rechnen. Nur schlechte Software würde danach noch alles auf 8 Bit reduzieren.
Re: BM Pocket Farben
Verfasst: Mo 22 Sep, 2014 17:40
von domain
Was mich ja wundert ist, das diese ganzen Umrechnungen überhaupt über Tabellen mit zu interpolierenden Knotenpunkten abgewickelt werden.
Bekanntlich kann jede beliebige Ziel-Kurvenform über eine simple mathematische Funktionen höheren Grades dargestellt werden.
Weiß jemand, warum das nicht in dieser Art gelöst wird?
Muss ja einen Grund haben.
Re: BM Pocket Farben
Verfasst: Mo 22 Sep, 2014 17:43
von WoWu
Weil LUTs nur zwischen den Werten interpolieren und nicht approximieren.
Re: BM Pocket Farben
Verfasst: Mo 22 Sep, 2014 17:46
von domain
Bei Funktionen muss doch weder approximiert noch interpoliert werden, da kann doch genau berechnet werden.
Verstehe ich nicht.
Re: BM Pocket Farben
Verfasst: Mo 22 Sep, 2014 17:58
von ruessel
Wie belichtest du denn?
Zur Zeit richte ich die Pocket auf mein Hauptmotiv aus und belichte nach Histogramm ganz rechts und drehe dann etwas "Headroom" noch dazu ein. Man erkennt es gut im Pocket LCD, erst wird es ganz flau mit etwas Raum zum rechten Histogrammrand kommt plötzlich Kontrast in die Anzeige.
Die .cube LUTs haben normalerweise Fließkomma-Genauigkeit für ihre Werte. Wichtiger sind aber die Knotenpunkte, bei deinen LUTs z.B. 32 oder 64.
Zur Zeit erstelle ich die LUTs mit 64 Samples (bei der 32+64LUT Pattern Size), reicht das aus? Bei 128 Samples habe ich schon mal Abstürze im LUT Buddy.
Re: BM Pocket Farben
Verfasst: Mo 22 Sep, 2014 18:16
von ruessel
dann erkläre doch mal warum man überhaupt über LUT-Tabellen gehen muss
Ich bin zwar der andere wolfgang.....
Ich finde LUTs nun richtig g..., wenn ich von Hand nach Vectorscop die Farbe drehen muss, ist das gar nicht so einfach.
Zum Beispiel ist die Farbe Grün bei der Pocket zu weit am Gelb angelegt, weder stimmt der Farbwinkel noch die Farbstärke gegenüber den anderen Farben. In DaVinci gibt es so umfangreiche Einstellungen, damit kann ich ganz gezielt und begrenzt einzelne Farbbereiche in allen Richtungen auf dem Vectorscop bewegen. Daraus kann dann direkt eine LUT generiert werden. Diese LUT ist keine einfache Lineare oder logarithmische Tabelle, sondern ein Konstrukt aus engen Haltepunkte im 3D Farbraum, mit Spitzen-, Spline und Glockenförmigen Kurven in der RGB Tabelle.
Diese erzeugte LUT kann nun in alle anderen Softwareprodukten sogar Plattformunabhängig die Farben identisch herstellen. Was wäre dazu die Alternative?
Re: BM Pocket Farben
Verfasst: Mo 22 Sep, 2014 18:29
von domain
Ruessel ,
im Grunde ist ja uninteressant, auf welche Art und Weise ein LUT erstellt wird, Hauptsache es funktioniert. Eindeutig ist aber, dass sie aufgrund von Funktionen erstellt wird.
Und nur darum drehte sich meine grundsätzliche Frage: warum eine LUT und nicht eine Funktion für die Umrechnung.
Wenn mir jemand sagen würde, dass die mathematische Umrechnung für jeden Pixel über eine Funktion wesentlich mehr Computerpower erfordern würde als eine Tabellenumrechnung, dann wäre ja schon alles geklärt.
Aber nicht mal WoWu kann es beantworten, er ist fixiert auf die gängige LUT-Praxis.
Re: BM Pocket Farben
Verfasst: Mo 22 Sep, 2014 18:30
von WoWu
@ Ruessel
Das was fehlt ist die Umwandlung bzw, die Approximation.
Wenn Du beispielsweise in einem ARRI LOOK maker so ein LUT erzeugst, um es in die Kamera zu laden (um die Vorschau zu haben) dann kannst Du es hinterher in den Look-maker zurück laden (ggf. mit Veränderungen). Dort wird dann aus den (wenigen) Stützstellen die entsprechende Funktion Approximiert (weil Punkte innerhalb der Stützstellen -s.B. Sattenpunkte) mit einbezogen werden müsse.
Daraus ergibt sich dann ein solches File, in dem Du, wenn Du an einem Punkt abfasst, die logischen Veränderungen an andern Stellen stattfinden.
Wenn Du z.B. nur eine Stützstelle in Grün veränderst, passiert sowas wie im Bild.
Änderst Du aber die Approximation, verändern sich alle Punkte auf dem Kurvengebilde mit. Funktionen hast Du nur selten. meistens sind es ja solche relativ willkürlichen Punktesammlungen, solange der Hersteller nicht die exakte Kurve rausgibt, die aber bei solchen "selbst gebaute" Kurven ohnehin nicht vorliegt.
@Domain, mit so wenig Ahnung würde ich mich einwenig zurückhalten. Es wirkt mittlerweile lächerlich.
Re: BM Pocket Farben
Verfasst: Mo 22 Sep, 2014 18:49
von rainer7u5
ruessel hat geschrieben:Wie belichtest du denn?
Zur Zeit richte ich die Pocket auf mein Hauptmotiv aus und belichte nach Histogramm ganz rechts und drehe dann etwas "Headroom" noch dazu ein.
Ich merke, beim Thema Belichtung sind wir ganz auf einer Linie...
ruessel hat geschrieben:
Zur Zeit erstelle ich die LUTs mit 64 Samples (bei der 32+64LUT Pattern Size), reicht das aus? Bei 128 Samples habe ich schon mal Abstürze im LUT Buddy.
Üblich sind eher kleinere Werte, da der Speicherbedarf exponentiell ansteigt. Das zeigen auch die Probleme bei LUTBuddy.
32 bzw. 64 Samples sollten reichen. Dem fertigen Bild sieht man es ja sowieso nicht an, da die meisten Interpolationsmethoden sehr homogen sind.
Re: BM Pocket Farben
Verfasst: Mo 22 Sep, 2014 21:49
von cantsin
Sehr gut, der Grünstich von V3.1 ist jetzt weg.
Allerdings schluckt Resolve (10) den warmen LUT wieder nicht. An der Titelzeile kann's diesmal nicht liegen...
Re: BM Pocket Farben
Verfasst: Mo 22 Sep, 2014 23:20
von Reiner M
domain hat geschrieben:
Wenn mir jemand sagen würde, dass die mathematische Umrechnung für jeden Pixel über eine Funktion wesentlich mehr Computerpower erfordern würde als eine Tabellenumrechnung, dann wäre ja schon alles geklärt.
Das ist der wesentliche Grund. Rechenleistung einsparen. Und es geht dabei um relativ viel eingesparte Power.
Bedenke bitte: Für eine flüssige Vorschau muss alles, was nötig ist, um einen fertigen Frame zu generieren, innerhalb einer 1/50 Sekunde vom Rechner bewältigt werden. Den Großteil der Zeit fressen bereits I/Os sowie andere aufwendige Algorithmen (bspw. Dekodierung). Da bleibt nicht mehr viel.
LUTs sind Daten pur - guter Ansatz, denn es geht eben in der EDV, also auch in der digitalen Videobearbeitung, um Datenverarbeitung ... ;)
Auch Videoinhalte werden ja nicht über Funktionen erzeugt.
Man benötigt an Funktionen, um die Daten einer LUT zu verarbeiten, im Wesentlichen nur "Lesen" und "Kopieren". Die Daten werden aus der Datei in die RGB-Tabelle übertragen, ggf. mit bereits vorhanden Modifikationen abgemischt. Dazu ein wenig relativ triviale Interpolation für die nicht vorhanden Zwischenwerte. Das macht den Austausch der LUTs leicht, vergrößert die Reichweite (nutzbar in vielen unterschiedlichen Programmen) und vereinfacht die Anwendung für den Benutzer (einfach laden, fertig). Völlig unabhängig von den tatsächlich verfügbaren Videoeffekten zur Farbkorrektur im Zielprogramm.
Ein anderer Grund: Die nötigen Funktionen könnten beliebig komplex werden, denn jeder RGB-Wert kann ja unanhängig von anderen verändert werden, abhängig von den verwendeten Werkzeugen und Funktionen. Du kannst Dich bei der Erstellung quer durch Deine Effekte-Bibliothek wühlen, andere LUTs dazu mischen und vorgefertigte Presets von Drittherstellern draufklatschen - egal. (Ob das Sinn macht, ist eine andere Frage).
Die LUT zeigt quasi in Auszügen einen Schnappschuss der RGB-Tabelle im Speicher zum Zeitpunkt des Exports der LUT aus dem erstellenden Programm. Ganz simpel. Die einzelnen Schritte, die zu diesem Ergebnis geführt haben, sind längst abgearbeitet und aus dieser Tabelle heraus nicht mehr auflösbar.
Ein weiterer Grund: Funktionen sind anders als Daten zwischen Programmen nicht beliebig austauschbar. Das erstellende Programm müsste zunächst diese spezifische Funktion erzeugen und dann ein Plug-In generieren, das die entsprechende Funktion enthält und das dem abarbeitetenden Programm über eine dafür standardisierte API bereitgestellt wird. Das muss es erst mal geben. Denn jede Modifikation, auch mit den selben Werkzeugen, würde eine andere Funktion ergeben, abhängig von den eingestellten Werten.
Diese Lösung - Funktionen statt LUTs - gibt es übrigens. Viele "Looks" sind am Markt für unterschiedliche Programme in dieser Form zu erwerben. Ggf. zusammen mit "Look"-Plug-Ins. Sie speichern Funktionsaufrufe und Parameterwerte und arbeiten sie dann über das vorgesehene API oder über das Plug-in erneut ab. Die nötige Rechenleistung ist oft deutlich zu spüren.
Beste Grüße,
Reiner
Re: BM Pocket Farben
Verfasst: Di 23 Sep, 2014 00:02
von domain
Danke Reiner für deine erklärenwollenden Statements, denn sie unterscheiden sich mal wesentlich von dem nur persönlich treffen wollenden Schäumen von WoWu.
Nach meiner Praxis vom Programmieren stellt sich eigentlich nur mehr die Frage: ist es eigentlich weniger aufwändig, selbst mit indizierten Variablen einer Tabelle die erforderliche Umrechnung durchzuführen, als eine direkte über eine funktionale Rechenvorschrift erfolgende?