Infoseite // Die besten DSLMs für Video 2023: Sony, Canon, Panasonic, Nikon, Blackmagic ...

Newsmeldung von slashCAM:





Mit der Canon EOS R6 Mark II, der Panasonic S5 II sowie der Fujifilm X-H2S sind wichtige neue Vollformat und APS-C DSLMs auf den Markt gekommen. Zeit für ein Update der slashCAM Liste der besten Video-DSLMs. Spannend sind die Neuzugänge unter anderem auch, weil sie ein neues Preis-/Leistungsniveau in der Einstiegsklasse definieren. Das hat auch Auswirkungen auf den Rest unserer Bestenliste ?



Hier geht es zum slashCAM Artikel:
Test: Die besten DSLMs für Video 2023: Sony, Canon, Panasonic, Nikon, Blackmagic ...



Antwort von Skeptiker:

Hab's noch nicht gelesen, aber jetzt schon: Wow! (oder: 'tolle Sache') ;-)



Antwort von Darth Schneider:

@Slashcam, Rob
Beeindruckende Zusammenstellung.
Da bekommt man mal ein Überblick wie viel Arbeit da drin steckt.
Und gerade der letzte Punkt mit, welche Kamera wofür, finde ich ist sehr gut umgesetzt, sehr cool sind auch die Kurzfassungen von den Kamera Tests.
Gruss Boris



Antwort von cantsin:

Bei der Sigma fp vermisse ich einen deutlichen Hinweis, dass sie als Videokamera praktisch nur im CinemaDNG-Raw-Modus (bei Aufzeichnung auf externe SSD, was die Kompaktheit der Kamera wieder relativiert) taugt und die interne 8bit-h264-Aufzeichnung bildqualitativ unbrauchbar ist (und zwar nicht etwa wegen 8bit).

Und auch, dass es bei der Webcam-Nutzung Einschränkungen wegen des fehlenden Videoautofokus und der fehlenden externen Stromversorgung gibt.



Antwort von CineFilm:

Rob & Slashcam (no hate) aber wieso steht bei der Nikon Z9

Die all diejenigen die hohe Bildqualität in Verbindung mit hohem Dynamikumfang für szenische Projekte benötigen.

Sehr hoher Dynamikumfang

Ihr habt die Kamera neulich zum Test raus gegeben. Ich fand die Projekte "naja". Jedoch haben alle Tester sich bzgl Dynamik beschwert sowie es wurde geschrieben NICHT für Szenische Aufnahmen etc...

Wie kommt jetzt sowas zustande?



Antwort von Darth Schneider:

CineFilm
Womöglich schrieb SlashCAM das, weil die Z9 nun mal eine hervorragende Bildqualität und einen sehr hohen Dynamikumfang bietet…

Lies doch die SlashCAM Kamera Tests/Reviews der Z9, ich denke dann ist deine Frage beantwortet.

Ich denke nicht das dabei der zweitägige Kamera Test Wettbewerb( der Forumsmitglider) irgend in einer Form entscheidend war.
Gruss Boris



Antwort von pillepalle:

CineFilm hat geschrieben:
Rob & Slashcam (no hate) aber wieso steht bei der Nikon Z9

Die all diejenigen die hohe Bildqualität in Verbindung mit hohem Dynamikumfang für szenische Projekte benötigen.

Sehr hoher Dynamikumfang

Ihr habt die Kamera neulich zum Test raus gegeben. Ich fand die Projekte "naja". Jedoch haben alle Tester sich bzgl Dynamik beschwert sowie es wurde geschrieben NICHT für Szenische Aufnahmen etc...

Wie kommt jetzt sowas zustande? Die Tester hatten ja mangels passender Speicherkarten kein Nikon RAW verwenden können. Das schnitt beim slashCAM Dynamik-Test deutlich besser ab als das H265/H264. Auch wenn da genau genommen eher die Latitude (Über- und Unterbelichtung) gemessen wird.

https://www.slashcam.de/artikel/Test/Ni ... l#Dynamik_

Danke auch nochmal an die Redaktion für den Artikel, auch wenn ich wenig von 'Bestenlisten' halte. Ist eine ganz gute grobe Systemübersicht für Filmer in dem Segment.

VG



Antwort von holger_1:

Vielen Dank für die großartige Arbeit.

Falls möglich: könntet ihr ganz kurz erläutern, warum es die FX30 - gerade unter dem Aspekt Preis/Leistung - nicht in die Übersicht geschafft hat?

Danke.

h.



Antwort von Darth Schneider:

Nun ja, alle aktuellen Pockets sind ja z.B. auch nicht vertreten…Und die FX30 ist der Fx3 schon sehr ähnlich, mal abgesehen vom etwas kleineren Sensor.
Gruss Boris






Antwort von Urtona:

Ohne Berücksichtigung der Sony A7 IV, die wohl geeignet ist, in einigen der Kategorien auf der letzten Seite oben zu landen, ein recht unvollständiger Vergleich.



Antwort von Alex:

Urtona hat geschrieben:
Ohne Berücksichtigung der Sony A7 IV, die wohl geeignet ist, in einigen der Kategorien auf der letzten Seite oben zu landen, ein recht unvollständiger Vergleich. Dachte ich auch erst, weil ich gerade nach ner (erschwinglichen) dritten Kamera für mein FX3/6 Lineup suche und die A7 IV im Auge hatte. Allerdings kann sie in XAVC S-I 4K bei 50/60FPS nur mit 1,5x Crop aufnehmen. Das war für mich das Ausschlusskriterium. Vielleicht hat das in der Auswahl der Kameras eine Rolle gespielt?

Jedenfalls muss ich überlegen, was es wird, da fällt mir eigentlich nur die A7S III ein oder ich muss mal bei den R-Modellen gucken. Noch ne FX3 ist mir zu teuer und die FX30 hat auch Crop. Ich würde wegen meiner Optiken gerne komplett bei FF bleiben. Dazu soll die 3. Kamera auch auf den Gimbal, sollte also möglichst weitwinklig sein. Mit nem 16er wäre ich bei der FX30 direkt bei 24mm, das ist mir zu wenig und ein 12-24mm will ich mir aktuell eigentlich gar nicht zulegen.



Antwort von CineFilm:

Ich habe die FX3 und Z9 und würde das mit der Dynamik nicht so stehen lassen. Die Z9 hat ein viel besseres Bild. Aber bei der Dynamik ist die FX3 handlicher / besser / einfacher (derzeit)

Ich glaub das Problem ist bei Nikon das LOG Format. Ich hoffe auf ein NLOG2

Weil irgendwie gibt das NLog Format nicht das ganze Potenzial



Antwort von cantsin:

CineFilm hat geschrieben:
Weil irgendwie gibt das NLog Format nicht das ganze Potenzial Das wäre mal ein interessanter Vergleichstest: welche Hersteller die besten (bzw. am besten implementierten) Logprofile haben.

Meiner Erfahrung nach sind nur die Log-Profile der traditionellen Videohersteller (Panasonic, Sony, Canon, Blackmagic) gut und haben die Log-Profile traditioneller Fotokamerahersteller (Fuji, Nikon, Leica, Olympus) alle Probleme - die schon bei der geringen Verbreitung/Unterstützung anfangen, aber nicht aufhören.



Antwort von pillepalle:

@ cantsin

Die Frage ist nur, was bedeutet die Besten bzw. was wären dann die 'Probleme'? Normalerweise sollte ein Logprofil doch nur aus einer logarithmischen Kurve/Bild einen gewissen Bildstandard (S-Kurve) wieder herstellen. Aber keine Log-Kurve/Profil kann jeder Situation gerecht werden.

VG



Antwort von CineFilm:

Ich habe mit FLOG VLOG BRAW NRAW SLOG wirklich gearbeitet, also nicht nur mal 1-2 Projekte gemacht wie mit der RED oder ARRI sondern wirklich mindest 10 Projekte

Und dabei ist NRAW MEGA aber man merkt - das LOG kann nicht das was es sollte

SLOG3 bei der FX3 ist Easy wobei er schnell einen Farbstich bekommt. Aber das ist alles schnell gemacht

Die Z9 würde mit einem NLOG2 sicherlich viel mehr bieten können. Ich hab das Nikon schon paar mal geschrieben da ich Indirekt ein Projekt umgesetzte habe für die. Aber da tut sich nichts.



Antwort von pillepalle:

CineFilm hat geschrieben:
Und dabei ist NRAW MEGA aber man merkt - das LOG kann nicht das was es sollte Aber was sollte es denn können, was es nicht kann? Bei einem Log-Bild geht es doch in erster Linie nur um eine andere Verteilung der 'normalerweise' linearen Bildinformationen. Ich gebe Dir schon recht. Auch ich finde das N-Log Profil nicht besonders gut (ist mir meist zu bunt und zu hart) und muss da immer noch dran drehen, bzw. nutze es in RAW Formaten gar nicht mehr. Da drehe ich mir alles von Hand hin. Wenn man nicht gerade Test-Charts filmt, geht es ja nur darum, dass einem das Bild am Ende gefällt, nicht so sehr ob es der Realität nahe kommt.

VG



Antwort von cantsin:

pillepalle hat geschrieben:

Die Frage ist nur, was bedeutet die Besten bzw. was wären dann die 'Probleme'? - Abschneiden des Dynamikumfangs bzw. keine vollständige Abbildung der Sensordynamik (vor allem ein Problem bei Log-Profilen, die nicht sensorspezifisch sind; scheint bei der Z9 der Fall zu sein, war früher das Problem von Sony-SLog2).
- Log-Profile für Codecs mit zu geringer (8-) Bittiefe, mit resultierenden Color-Banding nach der Umwandlung (alle Sony-Hybridkameras vor der A7sIII).
- Umgekehrt zu Punkt 1: Log-Profil berechnet für den hohen Dynamikumfangs "großer" Kameras, führt dann bei kleineren Kameras mit geringerer Sensor-Dynamik zu nicht ausgefüllten Werten bzw. faktischer Reduktion der Codec-Bittiefe (Problem von VLog bei der GH5/s)
- Entrauschungsalgorithmen, die für herkömmliche (Rec709-) Videoprofile entwickelt wurden und bei Log zu aggressiv entrauschen, vor allem im Chroma-Kanal (Problem von Fuji-FLog)
- Log-Profile, für die es nur (oft noch schlechte) Hersteller-LUTs nach Rec709 gibt, aber keine Umwandlungen in andere Farbräume bzw. Aces-IDTs (Problem u.a. von Leica und Olympus).
- Generell Log-Profile, die "komisch" berechnet sind (also keineswegs nur als simple Umrechnung Linear -> Logaritmisch) und schwierig farbzukorrigieren sind.



Antwort von pillepalle:

@ cantsin

Klingt logisch. Aber demnach müsste man ja auch für 10 Bit und 12Bit CODECs verschiedene Log-Profile haben, denn die höhere Farbtiefe könnte ja auch eine höhere Dynamik erlauben. Scheint aber niemand zu machen.

VG






Antwort von Frank Glencairn:

Die Bittiefe ist nur die Anzahl der möglichen Abstufungen zwischen den beiden Dynamik Brackets, hat aber nix mit der Dynamik selbst zu tun.



Antwort von cantsin:

"Frank Glencairn" hat geschrieben:
Die Bittiefe ist nur die Anzahl der möglichen Abstufungen zwischen den beiden Dynamik Brackets, hat aber nix mit der Dynamik selbst zu tun. Umgekehrt wird aber ein Schuh draus: Für adäquate Log-Aufnahmen von Sensoren mit hoher Dynamik braucht man mehr Bittiefe. Z.B. hat Arri bei LogC4 (dem neuen Log-Format für Arri LF-Kameras) die Bittiefen-Anforderung an den Aufzeichnungscodec von 10bit auf 12bit erhöht. (Quelle: https://www.arri.com/resource/blob/2787 ... n-data.pdf )



Antwort von andieymi:

cantsin hat geschrieben:
"Frank Glencairn" hat geschrieben:
Die Bittiefe ist nur die Anzahl der möglichen Abstufungen zwischen den beiden Dynamik Brackets, hat aber nix mit der Dynamik selbst zu tun. Umgekehrt wird aber ein Schuh draus: Für adäquate Log-Aufnahmen von Sensoren mit hoher Dynamik braucht man mehr Bittiefe. Z.B. hat Arri bei LogC4 (dem neuen Log-Format für Arri LF-Kameras) die Bittiefen-Anforderung an den Aufzeichnungscodec von 10bit auf 12bit erhöht. (Quelle: https://www.arri.com/resource/blob/2787 ... n-data.pdf ) Ja, deshalb wird jeder Hersteller die entsprechenden Log-Kurven auch auf die Sensoren mit der größten Dynamik ausrichten, und nicht nach jenen mit der niedrigsten. Dass Log bei 8-Bit (obwohl die Profile durchaus manchmal verfügbar sind, selbst in den Kameras) nicht die beste Idee ist, sollte sich ja herumgesprochen haben.

Das liegt dann aber an den 8-Bit und nicht an der Logkurve, denn die funktioniert mit 10-12 hervorragend.

Was Frank glaube ich sagen wollte - zumindest habe ich ihn so verstanden: Versteh die 12-Bit nicht als höhere Maximaldynamik. Jetzt meine Worte: Sondern eher als Samplingrate um Audio als Vergleich zu bedienen. Speicher die 12 Blenden vom Sensor in 12Bit und Du hast, 4096 Werte pro Kanal, speicherst du die 10 Bit weg hast Du nur mehr 1024 pro Kanal aber unter Umständen fast die gleiche Dynamik (immer noch 12 Blenden) weil die Minimal und Maximalwerte trotzdem am Ende gleich liegen. Die Hersteller werden unter der Haube schon angepasste Kurven verwenden (müssen) - allein wegen der anderen Wert-"Bennenungen" (256 "Weiß" 8-Bit, 1024 "Weiß" 10-Bit), aber das ändert nichts am Verlauf der Kurve selbst.

Das zeigt quasi jeder synthetische Dynamiktest ganz gut, die Dynamik ist fast immer ein inherentes Merkmal des Sensors (oder des Sensors + der AD/s) und nur an den extremen Randbereichen der Argumentation findest du wirklich größere Dynamikunterschiede: Raw bringt nicht mal eben 1 Blende mehr, nur weil jetzt 12-Bit gespeichert wird statt 10-Bit. Vielleicht eher im Bereich einer halben Blende max. Mit 8 Bit sieht das wieder anders aus (aber da bewegen wir uns eben am untersten Rand der Möglichkeiten), umgekehrt bringt 16 nicht nennenswert mehr Blenden als 12. Die Quantisierung / Log-Kurve / Speicherung generell ist normalerweise nicht mehr der Flaschenhals, sondern eher was vom Sensor kommt - mit Ausnahme der vordersten Dynamikfront: Alexa 35.

Arri hat somit eben wieder am unteren Ende aufgeräumt: Mit LogC4 sollte nicht in 10-Bit weggespeichert werden, weil die Quantisierung seit LogC4 dafür nicht ausgelegt ist. Äquivalent dazu, wie (mittlerweile muss man das ja fast sagen) vor Jahren die gängigen 8-Bit nicht von Log-Profilen generell profitiert haben. Da bewegen wir uns allerdings an der vordersten Front der Sensorentwicklung mit der höchsten Dynamik in einem für Bewegtbildanwendungen tauglichen Sensor (im industriell-wissenschaftlichen Bereich gibt es sicher noch mehr, da kommt aber am Ende kein Kinobild raus) - weswegen sie jetzt auch die Raw-Speicherung von 12 Bit Log auf 13 Bit Log hochgespect haben. Aber das ist ein Bit für angegebene 3 Blenden mehr, welche der neue Sensor vgl mit ALEV3 können soll (in der Praxis sind es wohl auch knapp nur mehr als eine Blende SNR2 als ALEVIII, im CineD Standardtest hat die Mini LF 13.8 SNR2, die Alexa 35 15.1 SNR2).

Deine Argumentation liegt theoretisch sicher richtig und an den untersten Randbereichen zeigt sich das auch in der Praxis, in der breiten Praxis aber sind die Probleme andere: Die meisten Kameras mit denen gedreht wird haben noch nicht mal flächendeckend AD-Konverter, die überhaupt mehr als 12-Bit für Bewegtbildraten auslesen könnten, da steht sehr viel um die "magischen" 12-Blenden und das meiste liegt da noch darunter mit mittlerweile einigen Ausnahmen, die knapp darüber landen - und die schaffen das eher aufgrund des guten Denoisings statt 12-Bit interner Speicherung. In der Klasse zeigt sich eigentlich recht deutlich: Selbst externe 16-Bit (Wo die her kommen sollen ist ein anderes Thema) zeigen meist weniger Dynamik als das herstelleroptimierte, kamerainterne 10-Bit Profil mit Firmware-Level-Denoising.
Da sind solche Argumente einfach nicht das Thema, weil ohnehin dann nur in 10-Bit gespeichert wird, keine 12-Möglich sind und wenn 12 möglich sind oder von 14 auf 10 runter, dann scheitert es eher an der Implementierung als an der Technik (siehe Nikon, Fuji, etc.). Arri hat in den letzten 10 Jahren gezeigt, dass man auch 13.8-Blenden in 10-Bit speichern kann und die Log-Kurve nicht limitiert - mit 15.1 Blenden scheint das nicht mehr möglich zu sein, aber dann gibt es genau eine Kamera, die das "Problem" hat. Also in der Theorie hast Du sicher Recht, in der Praxis gibt es davor noch zig andere Baustellen.

PS: Umgekehrt betrachtet ist auch recht klar, wie wenig Einfluss Quantisierung selbst auf Dynamik hat: Um selbst Highest End HDR zu realisieren hat der Sprung von den (objektiv veralteten) 8-Bit auf 10-Bit mehr als ausgereicht um zukunftssichere HDR-Implementierungen zu ermöglichen. Da limitieren einfach wieder andere Faktoren: Panelhelligkeit, Bandbreite, Kompression. Setzt man das fort: Würde ein 12-Bit Stream/Projektion im momentanen Praxisumfeld irgendwelche Vorteile bieten? Ganz im Gegenteil.



Antwort von CineFilm:

Kein LOG ist Perfekt und klar hat jedes Vor und Nachteile. Aber das NLOG ist unausgewogen und hat bietet nicht die Vorzüge vollwertige wie die anderen Logs.Vor allem was Clipping angeht setzt es zu früh ein. Der Dynamiksspielraum wird nicht voll ausgeschöpft.



Antwort von cantsin:

CineFilm hat geschrieben:
Kein LOG ist Perfekt und klar hat jedes Vor und Nachteile. Aber das NLOG ist unausgewogen und hat bietet nicht die Vorzüge vollwertige wie die anderen Logs.Vor allem was Clipping angeht setzt es zu früh ein. Der Dynamiksspielraum wird nicht voll ausgeschöpft. Die klassischen Fotokamerahersteller scheinen vor allem ein Problem damit zu haben, wo genau in der internen Bildverarbeitungspipeline des Kamerachips das Log-Signal extrahiert wird. Entgegen häufiger Annahmen ist ein Log-Profil nämlich nicht einfach ein flaches bzw. kontrastreduziertes Bildprofil und lässt sich auch nicht übers Tweaken herkömmlicher Kamera-Bildprofile äquivalent herstellen. (Obwohl es ja einschlägig bekannte Blogger/Influencer gibt, die flache Bildprofile kommerziell als "Log" verkaufen... Auch für Nikon-Kameras... Will hier keine Namen nennen...)

Meine starke Vermutung ist, dass die Signalverarbeitung von Kameras (wenn man sie sich mal als Eimerkette vom Debayering bis zur Datenkompression vorstellt) einen eigenen Weg für Log gehen muss und die Kamerachips/-ASICs daher explizit für Log-Aufzeichnung designt sein müssen - und dass die Implementierung guter Log-Profile alles andere als trivial ist, da die klassischen Fotokamerahersteller daran alle scheitern.



Antwort von dienstag_01:

Sind denn Sony mit Slog2 auch "gescheitert", da Slog3 nachgeschoben wurde? Oder sind sie gar mit Slog3 "gescheitert", da weniger Abstufungen im hellen Bereich als Slog2?
Fragen über Fragen stellen sich mir ;)



Antwort von cantsin:

dienstag_01 hat geschrieben:
Sind denn Sony mit Slog2 auch "gescheitert", da Slog3 nachgeschoben wurde? Oder sind sie gar mit Slog3 "gescheitert", da weniger Abstufungen im hellen Bereich als Slog2? Sony ist ja kein klassischer Fotokamerahersteller, und SLog2 lässt sich ja trotz seiner Einschränkungen gut graden und in Postproduktions-Workflows integrieren...

Wenn Du mal z.B. Fuji F-Log unter die Finger bzw. als Material für Resolve & Co. angeliefert bekommst, weisst Du, was ich mit "gescheiterten Implementierungen von Fotokameraherstellern" meine... Sigma hat sein Scheitern übrigens sogar offiziell gemacht, das für die fp-Kameras ursprünglich angekündigte Log-Update zurückgezogen und ein Statement geschrieben, dass mit der fp-Hardware (ich nehme mal an: dem Kamerachip) entgegen der ursprünglichen Planung kein Log-Profil machbar ist.



Antwort von DKPost:

cantsin hat geschrieben:
CineFilm hat geschrieben:
Kein LOG ist Perfekt und klar hat jedes Vor und Nachteile. Aber das NLOG ist unausgewogen und hat bietet nicht die Vorzüge vollwertige wie die anderen Logs.Vor allem was Clipping angeht setzt es zu früh ein. Der Dynamiksspielraum wird nicht voll ausgeschöpft. Die klassischen Fotokamerahersteller scheinen vor allem ein Problem damit zu haben, wo genau in der internen Bildverarbeitungspipeline des Kamerachips das Log-Signal extrahiert wird. Entgegen häufiger Annahmen ist ein Log-Profil nämlich nicht einfach ein flaches bzw. kontrastreduziertes Bildprofil und lässt sich auch nicht übers Tweaken herkömmlicher Kamera-Bildprofile äquivalent herstellen. (Obwohl es ja einschlägig bekannte Blogger/Influencer gibt, die flache Bildprofile kommerziell als "Log" verkaufen... Auch für Nikon-Kameras... Will hier keine Namen nennen...)

Meine starke Vermutung ist, dass die Signalverarbeitung von Kameras (wenn man sie sich mal als Eimerkette vom Debayering bis zur Datenkompression vorstellt) einen eigenen Weg für Log gehen muss und die Kamerachips/-ASICs daher explizit für Log-Aufzeichnung designt sein müssen - und dass die Implementierung guter Log-Profile alles andere als trivial ist, da die klassischen Fotokamerahersteller daran alle scheitern. Ich glaube es ist eher andersherum: Nicht die Sensoren müssen für LOG designt sein, sondern das LOG-Profil muss auf den Sensor abgestimmt werden. In der Theorie bräuchte jede Kamera bze. jeder Sensor ein eigenes LOG-Profil um das Maximum herauszuholen.



Antwort von dienstag_01:

cantsin hat geschrieben:
dienstag_01 hat geschrieben:
Sind denn Sony mit Slog2 auch "gescheitert", da Slog3 nachgeschoben wurde? Oder sind sie gar mit Slog3 "gescheitert", da weniger Abstufungen im hellen Bereich als Slog2? Sony ist ja kein klassischer Fotokamerahersteller, und SLog2 lässt sich ja trotz seiner Einschränkungen gut graden und in Postproduktions-Workflows integrieren...

Wenn Du mal z.B. Fuji F-Log unter die Finger bzw. als Material für Resolve & Co. angeliefert bekommst, weisst Du, was ich mit "gescheiterten Implementierungen von Fotokameraherstellern" meine... Sigma hat sein Scheitern übrigens sogar offiziell gemacht, das für die fp-Kameras ursprünglich angekündigte Log-Update zurückgezogen und ein Statement geschrieben, dass mit der fp-Hardware (ich nehme mal an: dem Kamerachip) entgegen der ursprünglichen Planung kein Log-Profil machbar ist. Ist die Sigma nicht auch diejenige Kamera, deren Raw-Auflösung sich von der Sensorauflösung unterscheidet?
Vielleicht ein bisschen viel Rechnerei für den kleinen Chip?






Antwort von cantsin:

dienstag_01 hat geschrieben:
Ist die Sigma nicht auch diejenige Kamera, deren Raw-Auflösung sich von der Sensorauflösung unterscheidet? Ja. Aber nicht die einzige. Die Nikon Z6 und Z7 haben dieselbe Einschränkung bei externer Video-Raw-Aufzeichnung, ebenso die Fuji X-H2, X-T5 und GFX-100S, die Olympus OM-D E-M1X und OM-D E-M1 Mark III. Tja, auch wieder die klassischen Fotokamera-Hersteller...



Antwort von cantsin:

DKPost hat geschrieben:
cantsin hat geschrieben:


Die klassischen Fotokamerahersteller scheinen vor allem ein Problem damit zu haben, wo genau in der internen Bildverarbeitungspipeline des Kamerachips das Log-Signal extrahiert wird. Entgegen häufiger Annahmen ist ein Log-Profil nämlich nicht einfach ein flaches bzw. kontrastreduziertes Bildprofil und lässt sich auch nicht übers Tweaken herkömmlicher Kamera-Bildprofile äquivalent herstellen. (Obwohl es ja einschlägig bekannte Blogger/Influencer gibt, die flache Bildprofile kommerziell als "Log" verkaufen... Auch für Nikon-Kameras... Will hier keine Namen nennen...)

Meine starke Vermutung ist, dass die Signalverarbeitung von Kameras (wenn man sie sich mal als Eimerkette vom Debayering bis zur Datenkompression vorstellt) einen eigenen Weg für Log gehen muss und die Kamerachips/-ASICs daher explizit für Log-Aufzeichnung designt sein müssen - und dass die Implementierung guter Log-Profile alles andere als trivial ist, da die klassischen Fotokamerahersteller daran alle scheitern. Ich glaube es ist eher andersherum: Nicht die Sensoren müssen für LOG designt sein, sondern das LOG-Profil muss auf den Sensor abgestimmt werden. In der Theorie bräuchte jede Kamera bze. jeder Sensor ein eigenes LOG-Profil um das Maximum herauszuholen. Ich hatte ja nicht von den Sensoren, sondern von den ASICs geschrieben (falls das nicht deutlich ist: den Signalverarbeitungschips der Kameras, also z.B. den DIGIC-Chips von Canon, den Expeed-Chips von Nikon, den Bionz-Chips von Sony etc.).

- Übrigens gibt es Hersteller, die für jeden Sensor ein eigenes bzw. maßgeschneidertes Log-Profil bauen, wie z.B. Blackmagic.

EDIT: Dein Posting bringt mich auf eine Idee. Könnte es sein, dass Log-Profile in Hybridkameras eine komplexe Fallstrick-Angelegenheit sind, weil sie ursprünglich nur in Cinekameras mit FPGAs (also frei programmierbaren, Minicomputer-Signalverarbeitungschips) steckten, und es schwieriger ist, sie in ASICs (=fest programmierten Massenmarkt-Kamerachips) zu implementieren? Denn ASICs können ja nicht nur für eine spezifische Kamera entwickelt und programmiert werden, sondern müssen ganze Kamerafamilien und -generationen eines Herstellers mit verschiedenen Sensoren abdecken. Und es wird ja nicht einfacher, wenn für Log im Chip eine eigene Signalverarbeitungs-Pipeline implementiert (und im Fall von ASICs: fest in die Chip-Hardware eingegossen) werden muss.

Zumindest dürften Blackmagics sensormaßgeschneiderten Log-Profile nur dank der FPGA-Architektur seiner Kameras möglich sein.



Antwort von DKPost:

cantsin hat geschrieben:
DKPost hat geschrieben:


Ich glaube es ist eher andersherum: Nicht die Sensoren müssen für LOG designt sein, sondern das LOG-Profil muss auf den Sensor abgestimmt werden. In der Theorie bräuchte jede Kamera bze. jeder Sensor ein eigenes LOG-Profil um das Maximum herauszuholen. Ich hatte ja nicht von den Sensoren, sondern von den ASICs geschrieben (falls das nicht deutlich ist: den Signalverarbeitungschips der Kameras, also z.B. den DIGIC-Chips von Canon, den Expeed-Chips von Nikon, den Bionz-Chips von Sony etc.).

- Übrigens gibt es Hersteller, die für jeden Sensor ein eigenes bzw. maßgeschneidertes Log-Profil bauen, wie z.B. Blackmagic.

EDIT: Dein Posting bringt mich auf eine Idee. Könnte es sein, dass Log-Profile in Hybridkameras eine komplexe Fallstrick-Angelegenheit sind, weil sie ursprünglich nur in Cinekameras mit FPGAs (also frei programmierbaren, Minicomputer-Signalverarbeitungschips) steckten, und es schwieriger ist, sie in ASICs (=fest programmierten Massenmarkt-Kamerachips) zu implementieren? Denn ASICs können ja nicht nur für eine spezifische Kamera entwickelt und programmiert werden, sondern müssen ganze Kamerafamilien und -generationen eines Herstellers mit verschiedenen Sensoren abdecken. Und es wird ja nicht einfacher, wenn für Log im Chip eine eigene Signalverarbeitungs-Pipeline implementiert (und im Fall von ASICs: fest in die Chip-Hardware eingegossen) werden muss.

Zumindest dürften Blackmagics sensormaßgeschneiderten Log-Profile nur dank der FPGA-Architektur seiner Kameras möglich sein. Kann sein, dass ich da technisch etwas übersehe, aber ich wüsste nicht inwiefern für einen LOG-Workflow bestimmte Anforderungen an die Chips benötigt werden. Es gibt natürlich den Fall, dass sich LOG-Profile nicht lohnen, weil die Dynamic Range an sich oder die Bittiefe dafür nicht ausreicht, aber das bedingt ja der Sensor.



Antwort von cantsin:

DKPost hat geschrieben:
Kann sein, dass ich da technisch etwas übersehe, aber ich wüsste nicht inwiefern für einen LOG-Workflow bestimmte Anforderungen an die Chips benötigt werden. Da wären mindestens:
- Debayering in einen erweiterten Farbraum.
- Umrechnung der Sensorwerte von linear zu logarithmisch, mit einer passenden Formel, die sowohl an die Dynamik, als auch das Rauschverhalten des Sensors angepasst ist.
- Beschränkung des Gains (bzw. der ISO) auf die sensornativen Gains/ISOs, die für das Log-Gamma umgerechnet werden müssen.
- Entrauschung bei komplett anderen/anders verteilten Chroma- und Luma-Daten, mit einem für Log maßgeschneiderten Denoising-Profil.
- Keine Nachschärfung.
- Anpassung der kamerainternen Belichtungsmessung und Belichtungs-Hilfen (Histogramm, Zebras etc.), um das Gamma richtig zu belichten.

Schon für Schritt 1, 2 und 4 müsste das Videosignal Chip- bzw. Pipeline-intern einen anderen Weg gehen. Das kann man sich genauso vorstellen wie einen alternativen Node-Tree in Resolve. Nur dass dieser dann fest in die Signalverarbeitungs-ASICs eingegossen werden muss. Und wenn man dann im Design spart oder schlampt und z.B. in Schritt 2 eine alte Formel verwendet, die die höhere Dynamik eines neueren Sensors nicht mehr adäquat bedient, gibt's abgeschnittenen DR (wie wohl bei der Nikon Z9), und wenn man nur eine pauschale Entrauschungs-Node in die Pipeline setzt, die sowohl sRGB/Rec709- als auch Log-Videosignale entrauscht und dann (wie bei Fuji) in Log den Chroma-Kanal killt, hat man eben ein suboptimales Log-Profil.



Antwort von dienstag_01:

cantsin hat geschrieben:
DKPost hat geschrieben:
Kann sein, dass ich da technisch etwas übersehe, aber ich wüsste nicht inwiefern für einen LOG-Workflow bestimmte Anforderungen an die Chips benötigt werden. Da wären mindestens:
- Debayering in einen erweiterten Farbraum.
- Umrechnung der Sensorwerte von linear zu logarithmisch, mit einer passenden Formel, die sowohl an die Dynamik, als auch das Rauschverhalten des Sensors angepasst ist.
- Beschränkung des Gains (bzw. der ISO) auf die sensornativen Gains/ISOs, die für das Log-Gamma umgerechnet werden müssen.
- Entrauschung bei komplett anderen/anders verteilten Chroma- und Luma-Daten, mit einem für Log maßgeschneiderten Denoising-Profil.
- Keine Nachschärfung.
- Anpassung der kamerainternen Belichtungsmessung und Belichtungs-Hilfen (Histogramm, Zebras etc.), um das Gamma richtig zu belichten.

Schon für Schritt 1, 2 und 4 müsste das Videosignal Chip- bzw. Pipeline-intern einen anderen Weg gehen. Das kann man sich genauso vorstellen wie einen alternativen Node-Tree in Resolve. Nur dass dieser dann fest in die Signalverarbeitungs-ASICs eingegossen werden muss. Und wenn man dann im Design spart oder schlampt und z.B. in Schritt 2 eine alte Formel verwendet, die die höhere Dynamik eines neueren Sensors nicht mehr adäquat bedient, gibt's abgeschnittenen DR (wie wohl bei der Nikon Z9), und wenn man nur eine pauschale Entrauschungs-Node in die Pipeline setzt, die sowohl sRGB/Rec709- als auch Log-Videosignale entrauscht und dann (wie bei Fuji) in Log den Chroma-Kanal killt, hat man eben ein suboptimales Log-Profil. Was soll denn in der "alten" Formel drin stehen? Ich denke, man rechnet mit den Werten, die aus dem A/D-Wandler kommen, das sind halt bei 12bit 4096. Und diese 4096 Werte geben auch den Dynamikumfang des Sensors wieder, es sei denn, man entscheidet sich als Hersteller bewusst dagegen.



Antwort von cantsin:

dienstag_01 hat geschrieben:
Was soll denn in der "alten" Formel drin stehen? Ich denke, man rechnet mit den Werten, die aus dem A/D-Wandler kommen, das sind halt bei 12bit 4096. Und diese 4096 Werte geben auch den Dynamikumfang des Sensors wieder, es sei denn, man entscheidet sich als Hersteller bewusst dagegen. So einfach ist das ja nicht. Wenn Du - um nur einmal ein Beispiel zu nehmen - eine Kleinsensorkamera hast, deren erstes Bit in den Schatten nur aus Rauschen besteht, berechnest Du die logarithmische Verteilung der Sensorwerte so, dass dieses erste Bit ignoriert bzw. abgeschnitten wird, oder - falls da doch ein bisschen Signal drin steckt - mit dem zweiten Bit zusammengefasst wird, um für die Blendenstufen mit mehr Bildinformation mehr Bandbreite übrigzulassen. (So haben das ja z.B. auch SLog2 und die erste Version von CLog gemacht.)

Und wenn's doch so einfach wäre, bräuchte man nur noch ein einziges Log-Gamma (bzw. könnte gleich bei Cineon bleiben...)



Antwort von dienstag_01:

cantsin hat geschrieben:
dienstag_01 hat geschrieben:
Was soll denn in der "alten" Formel drin stehen? Ich denke, man rechnet mit den Werten, die aus dem A/D-Wandler kommen, das sind halt bei 12bit 4096. Und diese 4096 Werte geben auch den Dynamikumfang des Sensors wieder, es sei denn, man entscheidet sich als Hersteller bewusst dagegen. So einfach ist das ja nicht. Wenn Du - um nur einmal ein Beispiel zu nehmen - eine Kleinsensorkamera hast, deren erstes Bit in den Schatten nur aus Rauschen besteht, berechnest Du die logarithmische Verteilung der Sensorwerte so, dass dieses erste Bit ignoriert bzw. abgeschnitten wird, oder - falls da doch ein bisschen Signal drin steckt - mit dem zweiten Bit zusammengefasst wird, um für die Blendenstufen mit mehr Bildinformation mehr Bandbreite übrigzulassen. (So haben das ja z.B. auch SLog2 und die erste Version von CLog gemacht.)

Und wenn's doch so einfach wäre, bräuchte man nur noch ein einziges Log-Gamma (bzw. könnte gleich bei Cineon bleiben...) Die Dynamik steckt in den 4096 Werten. Wenn das nicht so wäre, würde man das auch bei Composite oder RAW-Video sehen.

Wenn man von der Notwendigkeit eigener Profile spricht, kann man nur die Verarbeitung in den dunklen Bereichen meinen. Dynamik gewinnt man nur noch dort. D.h., irgendeine Art von Rauschreduzierung findet dort statt, immer. Auf diese Art der Bildverarbeitung sollte/muss das Log-Profil abgestimmt sein, das verstehe ich. Aber in den Lichtern muss nichts abgestimmt werden, da kann man entscheiden, welche Werte man wie ins Log übernehmen will.



Antwort von CineFilm:

Aus einer einfachen Sache ist eine Wissenschaft geworden. Fehlt noch E=mc2

Ich habe bzgl dem NLOG 12BIT RAW dieser Erfahrung gemacht. Nikon hat das schlecht umgesetzte aber wird das sicherlich deutlich mit LOG2 verbessern

Mehr wollte ich dazu garnicht schreiben, mich hatte nur diese Bestbewertung gewundert



Antwort von DKPost:

cantsin hat geschrieben:
DKPost hat geschrieben:
Kann sein, dass ich da technisch etwas übersehe, aber ich wüsste nicht inwiefern für einen LOG-Workflow bestimmte Anforderungen an die Chips benötigt werden. Da wären mindestens:
- Debayering in einen erweiterten Farbraum.
- Umrechnung der Sensorwerte von linear zu logarithmisch, mit einer passenden Formel, die sowohl an die Dynamik, als auch das Rauschverhalten des Sensors angepasst ist.
- Beschränkung des Gains (bzw. der ISO) auf die sensornativen Gains/ISOs, die für das Log-Gamma umgerechnet werden müssen.
- Entrauschung bei komplett anderen/anders verteilten Chroma- und Luma-Daten, mit einem für Log maßgeschneiderten Denoising-Profil.
- Keine Nachschärfung.
- Anpassung der kamerainternen Belichtungsmessung und Belichtungs-Hilfen (Histogramm, Zebras etc.), um das Gamma richtig zu belichten.

Schon für Schritt 1, 2 und 4 müsste das Videosignal Chip- bzw. Pipeline-intern einen anderen Weg gehen. Das kann man sich genauso vorstellen wie einen alternativen Node-Tree in Resolve. Nur dass dieser dann fest in die Signalverarbeitungs-ASICs eingegossen werden muss. Und wenn man dann im Design spart oder schlampt und z.B. in Schritt 2 eine alte Formel verwendet, die die höhere Dynamik eines neueren Sensors nicht mehr adäquat bedient, gibt's abgeschnittenen DR (wie wohl bei der Nikon Z9), und wenn man nur eine pauschale Entrauschungs-Node in die Pipeline setzt, die sowohl sRGB/Rec709- als auch Log-Videosignale entrauscht und dann (wie bei Fuji) in Log den Chroma-Kanal killt, hat man eben ein suboptimales Log-Profil. Achso, ja das stimmt. Ich bin jetzt von RAW ausgegangen.






Antwort von DKPost:

CineFilm hat geschrieben:
Aus einer einfachen Sache ist eine Wissenschaft geworden. Fehlt noch E=mc2

Ich habe bzgl dem NLOG 12BIT RAW dieser Erfahrung gemacht. Nikon hat das schlecht umgesetzte aber wird das sicherlich deutlich mit LOG2 verbessern

Mehr wollte ich dazu garnicht schreiben, mich hatte nur diese Bestbewertung gewundert So ein LOG-Profil ist ja auch viel Wissenschaft. Die Formel kann man ja in dem ARRI-Sheet sehen :D



Antwort von CineFilm:

Wer hier alles hat eine Z9 um wirklich über das RAW NLOG Problem mitzureden?



Antwort von DKPost:

CineFilm hat geschrieben:
Wer hier alles hat eine Z9 um wirklich über das RAW NLOG Problem mitzureden? Es geht doch garnicht nur um Nikon.



Antwort von pillepalle:

Eben. Außerdem sind die Unterschiede bei den verschiedenen N_Log to REC709 LUTs bei Nikon nicht gerade riesig. Ich habe mal spaßeshalber auf einen Framegrab in ProRes RAW mit der LUT der Z6II (links) und einmal mit der LUT der Z9 (Verion 1) gemacht. Man sieht schon ein paar Unterschiede (z.B. in den Schatten am Boden, usw), aber die Unterschiede scheinen eher gering. Das ist out of the cam, nur mit LUT drauf und dann beim Exportieren in ein JPEG natürlich noch in sRGB gewandelt. Aber die Unterschiede bleiben die gleichen. Das Clipping in den Wolken im Hintergrund ist natürlich schon im Originalmaterial vorhanden, genauso wie die Farbkipper auf der Bank.

Ich bin mir sicher das N-RAW zwar ein besseres Bild liefert (als z.B. ProRes RAW), aber vermutlich ähnlich zu graden ist, wie die anderen Log-Formate bei Nikon.


zum Bild


Spaßeshalber habe ich auch einmal die Panasonic Vlog LUT auf's Material gepackt, um zu sehen inwiefern sie sich von der Nikon LUT unterscheidet.


zum Bild


VG

PS: Das schreibt übrigens Nikon selber zum neuesten LUT-Paket
Änderungen in der Version 1.04 gegenüber Version 1.03

• 3D-LUTs im cube-Format (erkennbar an Dateinamen, die auf »V02-00« enden), die mit der N-Log-Kurve der Z 9 kompatibel sind, wurden hinzugefügt. Farbwiedergabe, Schatten und Lichter wurden überarbeitet, um die Bearbeitung von Videomaterial mit einer Videobearbeitungssoftware zu erleichtern.
• Diese Z 9 N-Log 3D LUTs (cube-Dateien mit Namen, die auf »V02-00« enden) bieten Abhilfe bei:
- »Tonwertsprüngen« und Ähnliches, die in ansonsten sanften Tonübergängen sichtbar sind, und
- übersättigten Farben, die bei Aufnahmen mit High-Chroma-Lichtquellen oder von Motiven, die von diesen beleuchtet werden, sichtbar sind.
Beachten Sie, dass diese LUTs manchmal etwas hellere Ergebnisse liefern als frühere Z 9 N-Log 3D LUTs (cube-Dateien mit Namen, die auf »V01-00« enden). So können beispielsweise die mit der aktuellen Version hinzugefügten Z 9 N-Log 3D LUTs (cube-Dateien mit der Endung »V02-00«) zu »ausgebleichten« (überbelichteten) Lichtern führen, wenn sie auf Videomaterial angewendet werden, das reichlich belichtet aufgenommen oder bei der Bearbeitung aufgehellt wurde, oder wenn sie als Ersatz-3D-LUTs in Projekten verwendet werden, die zuvor mit früheren Z 9 N-Log 3D LUTs (cube-Dateien mit der Endung »V01-00«) farbkorrigiert wurden.

Die früheren Z 9 N-Log 3D LUTs sind im aktuellen Download enthalten und können bei Bedarf weiterhin benutzt werden. Hier die neue Z9 LUT (02-00) mit größeren Änderungen in der Helligkeit. Der Farbkipper in der Bank bleibt aber, wenn auch etwas schwächer.


zum Bild




Antwort von Frank Glencairn:

LUTs sind halt auch nicht wirklich ein optimaler Weg um zu 709 zu kommen.



Antwort von cantsin:

"Frank Glencairn" hat geschrieben:
LUTs sind halt auch nicht wirklich ein optimaler Weg um zu 709 zu kommen. Gibt es eigentlich eine Liste, für welche Log-Formate es IDTs (bzw. zumindest Color Management in Resolve) gibt?

Das wäre mal wirklich ein sinnvolles Auswahlkriterium für eine Hybridkamera...



Antwort von pillepalle:

Ich persönlich mache das ja mittlerweile bei ProRes RAW auch von Hand. Kann es auch direkt in ACES konvertieren (z.B. in Assimilate), aber meist bleibe ich bei ProRes4444 und REC2020. Das ProRes Material in der Nikon wird in REC2020 aufgenommen, deshalb bleibe ich meist auch erstmal in dem Farbraum.

Hier ist eine Liste von 'Wonderlook Pro' von 2020, also nicht sehr aktuell, aber da sind auch Consumer-Kameras wie z.B. die Z6 und Z7 drinnen.
ARRI ALEXA MINI

ARRI ALEXA

ARRI AMIRA

BLACKMAGIC CinemaCamera2.5K

BLACKMAGIC PocketCinemaCamera

BLACKMAGIC ProductionCamera4K

BLACKMAGIC URSA4K

Bypass

CANON (Maker provided) C100

CANON (Maker provided) C300

CANON (Maker provided) C500

CANON C100 Mark2

CANON C100

CANON C300 Mark2

CANON C300

CANON C500

FOR-A FT-ONE-S

FOR-A FT-ONE

FOR-A VFC7000

GOPRO HERO4

JVC GY-LS300CH

Nikon Z6

Nikon Z7

PANASONIC AG-DVX200

PANASONIC AK-HC1500G

PANASONIC AK-HC1800G

PANASONIC AU-EVA1

PANASONIC GH4

PANASONIC POVCAM

PANASONIC VARICAM HS

PANASONIC VARICAM35

RED EPIC DRAGON-LLO

RED EPIC DRAGON-STD

RED EPIC DRAGON-STH

RED EPIC

RED SCARLET

RED WEAPON 8K S35

SONY (Maker provided) F65

SONY (Maker provided) PMW-F55

SONY Alpha6300

SONY Alpha7s

SONY Alpha7s2

SONY F35

SONY F65

SONY FS700

SONY HDC-1500

SONY HDC-1500R

SONY HDC-1600_or_1600R

SONY HDC-2500

SONY HDC-2600

SONY HDC-4300

SONY HDC-950

SONY HDW-790

SONY HDW-F900R

SONY HXR-NX5J

SONY PMW-200

SONY PMW-300K

SONY PMW-400

SONY PMW-EX3

SONY PMW-F3

SONY PMW-F5

SONY PMW-F55

SONY PMW-F55withBPU

SONY PXW-FS5

SONY PXW-FS7

SONY PXW-X500

SONY SRW-9000

SONY SRW-9000PL

SONY VENICE

Various Signals ACESproxy (ACES V1.0)

Various Signals Cineon

Various Signals HSLA

Various Signals Rec2020

Various Signals Rec709

VISION RESEARCH PhantomFlex4K VG



Antwort von Frank Glencairn:

cantsin hat geschrieben:
"Frank Glencairn" hat geschrieben:
LUTs sind halt auch nicht wirklich ein optimaler Weg um zu 709 zu kommen. Gibt es eigentlich eine Liste, für welche Log-Formate es IDTs (bzw. zumindest Color Management in Resolve) gibt?

Das wäre mal wirklich ein sinnvolles Auswahlkriterium für eine Hybridkamera... Einfach bei den Colorwheels of die 3 Punkte klicken, und dann auf color space.



Antwort von Darth Schneider:

@ Frank
Also was meine S5 mit VLog betrifft hab ich mit dem hauseigenen Panasonic Lut und mit einem gekauften Lut von einer Firma namens Gamut sehr gute Erfahrungen gemacht um schön und mit ein paar Klicks auf Rec709 zu kommen.

https://gamut.io/

Viel mehr kreative Optionen hat man natürlich ohne Lut zusammen mit dem Dehancer..
Wobei das natürlich beides auch nur zusammen mit dem Colormanagment in Resolve richtig funktioniert.

Gruss Boris






Antwort von andieymi:

cantsin hat geschrieben:
Ich hatte ja nicht von den Sensoren, sondern von den ASICs geschrieben (falls das nicht deutlich ist: den Signalverarbeitungschips der Kameras, also z.B. den DIGIC-Chips von Canon, den Expeed-Chips von Nikon, den Bionz-Chips von Sony etc.).

- Übrigens gibt es Hersteller, die für jeden Sensor ein eigenes bzw. maßgeschneidertes Log-Profil bauen, wie z.B. Blackmagic.

EDIT: Dein Posting bringt mich auf eine Idee. Könnte es sein, dass Log-Profile in Hybridkameras eine komplexe Fallstrick-Angelegenheit sind, weil sie ursprünglich nur in Cinekameras mit FPGAs (also frei programmierbaren, Minicomputer-Signalverarbeitungschips) steckten, und es schwieriger ist, sie in ASICs (=fest programmierten Massenmarkt-Kamerachips) zu implementieren? Denn ASICs können ja nicht nur für eine spezifische Kamera entwickelt und programmiert werden, sondern müssen ganze Kamerafamilien und -generationen eines Herstellers mit verschiedenen Sensoren abdecken. Und es wird ja nicht einfacher, wenn für Log im Chip eine eigene Signalverarbeitungs-Pipeline implementiert (und im Fall von ASICs: fest in die Chip-Hardware eingegossen) werden muss.

Zumindest dürften Blackmagics sensormaßgeschneiderten Log-Profile nur dank der FPGA-Architektur seiner Kameras möglich sein. Theoretisch sind angepasste ASICs natürlich möglich, aber vermutlich sinnlos teuer. Aber Du bist da sicher was auf der Spur, folgendermaßen:

Ich glaube nicht, dass sich die "Fotohersteller" bisher nennenswert Gedanken über Gamma-Kurven gemacht haben oder wo in der Pipeline diese passieren. Letztendlich sind da eigentlich immer nur lineare Raw-Daten ein Thema gewesen. Die Vorgehensweise, lineare Raw Daten aus dem A/D-Konverter schon bei der Speicherung in Log zu konvertieren und schlussendlich Log-Raw zu speichern ließe sich fix auch in einem ASIC realisieren. Das Problem dabei: Das interessiert 90% der Nutzer, die nur Fotos machen wollen nicht und die Hersteller haben damit eben auch keine Erfahrung. Abgesehen davon, dass es vmtl mehrere ASICs bräuchte um so etwas zu realisieren. Am Ende will jeder in Lightroom/Photoshop aus diesen Kameras ein normalisiertes Foto sehen.

Und warum macht man das ganze eigentlich? Letztendlich hat die Argumentation mit "Dynamik" sehr viel mit "Ich dreh im Profil den Kontrast raus" zu tun. Arri nutzt LogC in erster Linie zur besseren = effizienteren Speicherung des 16-Bit Linear Signals, das die 14-Bit A/D-Konverter errechnen. Was im Linear-Signal nicht da ist, wird es im Log-Signal auch nicht sein, Vorteile bei der Tonwertverteilung ergeben sich schon, nicht aber an der absoluten Dynamik. Die Dynamik bleibt nur trotz geringerer Bittiefe in ähnlichem Maß erhalten, was Vorteile für den Speicherverbrauch bringt, eine bessere Tonwertverteilung und wenig Nachteile.

Ich vermute, dass die meisten Fotohersteller die Log-Konvertierung nicht viel anders behandeln als "Kreativ-Filter", die es immer schon für Preview-Zwecke vom Raw gab (S/W, Portrait, Landschaft, Gesättigt), nur dass diese bei der Speicherung eingebrannt werden. Was ja auch legitim wäre, wenn sie das Know-How wirklich hätten(?) und man das Gefühl hat, das funktioniert ähnlich gut wie bei den Bewegtbildherstellern.
Ist schwer das zu vergleichen, so gesehen beginnt jede Bildinformation am Sensor Linear, selbst bei Arri beginnt die Reise von Analog zu Digital erst in 16-Bit Linear (aus 2x 14 Bit-Linear-Streams), Arri kommt an Kompression vorbei, indem sie die 16-Bit dann statt linear zu speichern in 12-Bit logarithmisch speichern. Das bringt halt in erster Linie etwas, wenn Du wirklich effektiv genutzte 16-Bit Linear als Startpunkt hast. Wie man drauf kommt ist nicht das Thema, Arri hat die 2x 14-Bit DGA auch nur verwendet, weil 16-Bit DGAs zu der Zeit einfach schwierig waren. Aber, sie landen bei 16-Bit Linear (die auch Sinn machen, verglichen mit dem "Externen 16-Bit-Raw" aus einem 12-Bit A/D-Konverter) und kommen um die Komprimierung dessen herum, in dem sie das einfach als 12-Bit Log Speichern, was gut funktioniert. Das hat aber eigentlich nichts mehr mit der Dynamik zu tun, denn was im 16-Bit Linear nicht drin ist - oder davor in den 2x 14-Bit Linear wird es auch im 12-Bit-Log-Raw nicht sein, da geht's nur mehr um die Datenspeicherung.

Aber worauf ich hinauswill: Auch Cine-Kameras sehen eigentlich zuerst Linear, trotzdem glaube ich dass sonst ALLES daran auf die Speicherung von Log-Material ausgelegt ist. Bei den höherpreisigen Modellen mit vielen Möglichkeiten, sieht man das auch ganz gut anhand der Einschränkungen: Die Venice kann zur Preview Normalisierung nicht nur LUTs nutzen, sondern .ART-Files. Damit behaupten sie, das habe ich auch nachvollziehen können - dass es die Output-Darstellung verbessern kann, indem - statt die LUTs nach dem BildProcessing schon währenddessen Implementiert werden:

zum Bild

Das macht jetzt nicht viel für die Diskussion FGPA vs. ASIC, allerdings ist es halt scheinbar eine Wissenschaft, wo selbst High-End-Kameras bestimmte Restriktionen haben wenn nur LUTs am Ende der Pipeline genommen werden. Das sagt jetzt für sich genommen mehr über die Unzulänglichen von LUTs und Venice-Processing aus, nicht aber über Consumer-Fotokameras? Das stimmt schon, aber wieso sollte Sony die Lösung in Consumer-Fotokameras bauen, wenn sie bei Venice das große Feature ist und tatsächlich reproduzierbare Vorteile bringt?

Was es aber auch zeigt: Die Cine-Kameras verarbeiten eigentlich trotz des Linearen-Raw-Anfangs ab einem gewissen Punkt eigentlich Log intern. Die ganze Zeit von der Log-Konvertierung bis zur Speicherung. Previews sind halt dann mit LUTs oder ARTs möglich, allerdings eigentlich nur für Preview-Zwecke. Die können auch gespeichert werden, aber das macht kaum jemand.

Bei Consumerkameras äußert sich Sony (die es besser wüssten, siehe Venice) meines Wissens nicht über solche Details. Die Picture Profiles für Video-Gammas sind zwar von den Foto-Effektfiltern getrennt, weist allerdings bei den ersten PPs undefinierte "Movie Gamma" und "Stills Gamma" aus. Die Log-Profile folgen dann. Das ist jetzt auch nur eine Mutmaßung, aber ich kann mir beim besten Willen nicht vorstellen, dass das, was Sony dann in einer A7XYZ mit Slog macht, viel mit einer Venice zu tun hat, die - das weiß ich auch nicht - aber da ist von einem 16-Bit A/D auszugehen - die ganze Signalverarbeitung hin auf Slog hin macht.

Bei A7XYZ ist das mit an Sicherheit grenzender Wahrscheinlichkeit nicht der Fall. Bei einer FX3 wird man streiten können, aber sonst hat die lineare Foto-Raw-Verarbeitung im ASIC einfach Vorrang. Das wird auch bei einer Z9 nicht viel anders sein und bei einer XH2-S auch nicht. Über die wirkliche Implementierung von Log-Modi schweigen die Hersteller da leider, verglichen mit den Cine-Herstellern (Arri, Sony Pro, etc.). Aber es wird einfach nicht möglich sein, zwei Pipelines gleichrangig prozessierbar zu machen und letztendlich bräuchten sie da wohl 2:

- Eine für die linearen Foto Raws
- Eine für die bald auf so nahe an nativ wie möglich Log-Umgstellte Video-Signalverarbeitung

Da die allerdings beide Endprodukte in einer Kamera realisieren müssen und viel mehr Erfahrung im Fotobereich vorhanden ist und obwohl die Kameras vermehrt für Videos gekauft werden Foto immer noch priorität hat. Und im Endeffekt wird da nicht viel mehr passieren, als den linearen Sensordaten nach der internen Bildverarbeitung noch ein Log-Profil zu verpassen statt währenddessen.



Antwort von pillepalle:

@ andieymi

Sehr schön erklärt, aber eigentlich hatte es Frank schon in einem Satz auf den Punkt gebracht :) LUT drauf und fertig wird bei keiner Kamera immer zu einem idealen Ergebnis führen. Und im Zweifel umgeht man ungeliebte LUTs einfach, indem man sie nicht nutzt. Zu Beginn gab's z.B. von Nikon auch mal ein technisches Spec Sheet zu N-Log.

https://download.nikonimglib.com/archiv ... (En)01.pdf

So richtig geheim ist da nicht was sie bei der Umwandlung machen.

VG



Antwort von Darth Schneider:

Also Nikon kenne ich gar nicht,
aber im Fall von Panasonics VLog sieht (so wie mein Laien Auge das sieht) diese Lut Option von Gamut doch gar nicht schlecht aus oder ?



Dürfte doch so ähnlich doch mit absolut jedem LOG Material möglich sein, theoretisch.
Oder etwa nicht ?
Gruss Boris



Antwort von Frank Glencairn:

Color Space Transformation ist halt ein viel eleganterer Weg, und trennt sauber Farbraum und Gamma.
Ich mach eigentlich alles nur darüber.

Bei (den wenigen fremden) Look LUTs nutze ich nur den Farbteil und lass den Gamma Teil außen vor.



Antwort von cantsin:

"Frank Glencairn" hat geschrieben:
Color Space Transformation ist halt ein viel eleganterer Weg, und trennt sauber Farbraum und Gamma. ...und macht Tone Mapping, und kann nicht nur nach Rec709 übersetzen...



Antwort von andieymi:

pillepalle hat geschrieben:
Zu Beginn gab's z.B. von Nikon auch mal ein technisches Spec Sheet zu N-Log.
https://download.nikonimglib.com/archiv ... (En)01.pdf
So richtig geheim ist da nicht was sie bei der Umwandlung machen. "Geheim" (falls ich das so geschrieben habe) bezog ich eher auf die Art der Implementierung von der Log-Konvertierung. Da steckt halt oft der Teufel im Detail. Weniger in der mathematischen Funktion der Log-Kurve (da kenn ich mich viel zu wenig aus, um das Beurteilen zu können), sondern oft im der praktischen Implementierung im Rahmen der Hardwaregestaltung einer Kamera.

Beispiel: Sony hat irrsinnig viel an der subjektiven Skintone-Qualität der FX-Serie im Vergleich zur FS-Serie verbessert. Da gab es wahnsinnig viel Trickle-Down von der Venice, allerdings hauptsächlich in S-Cinetone! Dort funktioniert das, mit weniger Reserven in der Post. In Slog3 funktioniert das noch nicht so gut. Warum? Dazu gibt's nichts. Kann ich nur unter der Hand Vertreter-Bingo von Messen referenzieren, die dürften nicht die Rechenleistung dafür haben (vgl. mit Venice) um die Farbgebung konsequent in Slog-Encodieren zu können. Klingt nicht unbedingt plausibel, das weiß ich selbst - aber die Resultate zeigen dass es da hapert, z.B. hier:

https://www.youtube.com/watch?v=HeXwIa9zuk4&t=35s

Und das meine ich letztendlich, ich verwende das jetzt bewusst mit "im Geheimen": Leider haben die wenigsten Lower End Hersteller (Ausnahme da ist Blackmagic vielleicht) wirklich konsistente Infos über Implementierungen und exakte Infos ohne Bullshitting. Da wird auf einmal 16-Bit-Raw Extern Ausgegeben, obwohl die Infos von 12-Bit-Linear stammen (ansonsten wäre die Dynamik größer, heißt im Endeffekt sie könnten aus auch in 10-Bit Log Encodieren - aber 16-Bit-Raw klingt noch besser). Das ist gezielte Desinformation zu Marketing-Zwecken, was die sich bei der High-End-Schiene nicht erlauben können, weil das die Kundschaft dort nicht gutiert. Auf dem DSLM bis FX9 Level freut sich der stolze Reviewer dann schon mehr über sein rauschendes 16-Bit Raw, das noch weniger Dynamik hat als dann intern-aufgenommene 10-Bit-Log-Material, aber sei's drum.

Die einzigen, wo mir auffällt dass das halbwegs konsistent ist sind Blackamgic, Arri und Sony bei der Venice. Red ist ein eigenes Kapitel, da funktioniert das im Hinblick auf praxisrelevante Infos für IPP2 & R3D insofern gut, als es die Dreh & Post-Spezifischen Bereiche betrifft, aber überhaupt nicht bei der Encodierung (Stichwort: JPG2000 im Raw) und allem was das Patent angeht, da wird da "verheimlicht", dass sich die Balken biegen (etwa was Wechsel von Wavelet auf DCT angeht). Sony Foto - FX Serie ist da eine Katastrophe was exaktere Infos über die Log-Implementierung, Farben (Slog3-Workflow vs. S-Cinetone), und externes Raw angeht. Canon bei der R-Serie mit (Fake?)Überhitzungs-Limts, die Clog2/3-Themakik, von Panasonic kann man da im Vergleich eigentlich nur Gutes sagen. Aber irgendwie fragt man sich doch warum Leute sich mit dem Abgeben und nicht einfach eine Blackmagic (egal welche), C70 oder Komodo holen. "Fullframe Look", wirklich? Kauft Euch Speedbooster oder T2-Zooms und dreht offenblendig, statt Fullframe-Look mit Zoom bei f/4 zu praktizieren.

Genau wie die Raw-Implementierungen. Mir ist absolut bewusst, dass das Raw mehr rauscht als jeder interne andere Codec. Aber was hilft es, wenn das tolle interne N-Raw auf einmal 1.5 Blenden weniger Dynamik vor Entrauschen hat bzw. das Raw dermaßen noisy ist, dass man eh alles wieder (stark) entrauschen muss? Der Siegeszug von Arri die letzten 15 Jahre kommt in erster Linie von folgenden Parametern:

- Die Bilder haben hohe Dynamik - ok, das ist schwer zu kopieren. Aber C70 und Ursa Mini machen das sehr gut mit ähnlicher DGA-Architektur. Das ist wichtiger für Dynamik als große Sensoren. Selbst der Unterschied zwischen Alexa S35 und LF ist dynamiktechnisch vernachlässigbar.
- Das Bild schaut aus der Kamera gut aus. Priorisierung von Skintones, die sind dort wo sie sein sollen. Egal ob mit Log-Normalisierungs-Workflow oder nativem Rec709-Drehen. Ein Log-Gamma, das dafür einfach sitzt, mit jeder Arri Kamera über die letzten 10-15 Jahre.
- Ehrliche & umfassende Kommunikation dem Kunden gegenüber, die Features & Limitierungen der Kameras sind für Anfänger begreifbarer als bei jeder Sony/Canon DSLM.

Das sind jetzt alles keine Punkte, wegen denen eine Kamera 70000€ kosten muss. Sie machen es sich einfacher, weil es halt in Wirklichkeit lange nur einen Sensor gab. Blackmagic macht es nach. Die haben es halt nicht notwendig, Marktanteile im Fotobereich mit teilweise an Kunden-Beschiss-Grenzenden-Features zu verteidigen.



Antwort von Frank Glencairn:

andieymi hat geschrieben:
.. da wird da "verheimlicht", dass sich die Balken biegen (etwa was Wechsel von Wavelet auf DCT angeht). Auch nicht so wirklich.
Now we have changed the compression transform from wavelet to discrete cosine transform
(DCT). Although DCT is associated with JPEG, just like wavelet transform it takes spatial image data into the frequency
domain allowing efficient encoding of salient image data. Even with this change, the core philosophy and RAW recording
of the R3D remain the same, giving users all the same benefits they’ve always enjoyed https://docs.red.com/955-0179/REV-B/Ben ... RAW.pdf

Side note: Apropos verheimlichen - was mir eben erst aufgefallen ist (weil ich danach gesucht habe) Red scheint zu verhindern, daß Google das RedUser Forum indiziert.



Antwort von andieymi:

"Frank Glencairn" hat geschrieben:
Now we have changed the compression transform from wavelet to discrete cosine transform
(DCT). Although DCT is associated with JPEG, just like wavelet transform it takes spatial image data into the frequency
domain allowing efficient encoding of salient image data. Even with this change, the core philosophy and RAW recording
of the R3D remain the same, giving users all the same benefits they’ve always enjoyed https://docs.red.com/955-0179/REV-B/Ben ... RAW.pdf

Side note: Apropos verheimlichen - was mir eben erst aufgefallen ist (weil ich danach gesucht habe) Red scheint zu verhindern, daß Google das RedUser Forum indiziert. Mittlerweile nicht mehr. Das war in Anfangszeiten von Komodo so. Jeder wusste: R3D ist Wavelet. Bis das irgendwann überhaupt nicht mehr zu Stromverbrauch der neuen passte. Informierte User mit Naheverhältnis (z.B. Phil Holland) wussten da bald Bescheid, irgendwann ist was durchgesickert und dann war das ohnehin öffentlich. Aber da hast Du körperlich gespürt, wie sehr Land in den ersten Streams zur Vorstellung und den Fragen die in die Richtung gehen herumgedruckst hat :D

Aber ja, ich hätte das Präteritum verwenden sollen. Für die Specs von R3D gilt das allerdings immer noch. Dass das eigentlich JPG2000 in einem Wrapper sein dürfte sagt von Red auch keiner so direkt, ist ja RAAAAAAW. Stört auch keinen, weil da funktioniert es halt trotzdem in der Praxis.



Antwort von Frank Glencairn:

Ja, ich erinnere mich dunkel an einen Post auf RedUser von Land, als er das mit DCT geschrieben hatte.

Ich weiß allerdings nicht mehr in welchem Stadium der Debatte und zu welchem Zeitpunkt das war, deshalb hab ich ja danach gegoogeld und zu meinem Erstaunen festgestellt, daß Google das nicht weiß - WTF?

Nach nem kurzen Mandella-Effekt Moment und etwas weiterem Nachbohren war dann klar, daß Red die Indizierung des Forums unterdrückt, was mir den Laden nicht gerade symphytischer macht.






Antwort von andieymi:

"Frank Glencairn" hat geschrieben:
Nach nem kurzen Mandella-Effekt Moment und etwas weiterem Nachbohren war dann klar, daß Red die Indizierung des Forums unterdrückt, was mir den Laden nicht gerade symphytischer macht. Auch so ein Aspekt :D