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

[DKPost]

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. [Alle Log-Profile haben erweiterte Farbräume, entweder eigene wie Panasonic V-Gamut und Sony S-Gamut, oder offen standardisierte wie Rec2100.]
- Umrechnung der Sensorwerte von linear zu logarithmisch, mit einer passenden Formel, die sowohl an die Dynamik, als auch das Rauschverhalten des Sensors angepasst ist. [Wird schon zum Problem bei ASICs, wenn hier eine Umrechnungsformel für zig verschiedene Sensoren funktionieren muss.]
- 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.

[DKPost]

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

[CineFilm]

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

[DKPost]

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

Es geht doch garnicht nur um Nikon.

[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.



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.



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.

[Frank Glencairn]

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

[cantsin]

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...

[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

[Frank Glencairn]

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.

[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

[andieymi]

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:

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.

[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

[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

[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.

[cantsin]

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...

[andieymi]

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:



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.

[Frank Glencairn]

.. 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 ... %20RAW.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.

[andieymi]

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 ... %20RAW.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.

[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.

[andieymi]

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