Testbericht So erzeugt die D800 ihr Videobild ...

[falconeye]

Ich habe erste Resultate meiner Labortests zum Videoteil der D800.

Ich werde es später auf DPReview oder meinem Blog posten, aber für die Freunde des NF-F schon mal vorab (es wurde ja viel gerätselt) ...

1. Das FX 1920x1080 Videobild wird generiert aus dem folgenden Crop aus der vollen Sensorfläche (von 7360 x 4912):
6720 x 3780 (Cropfaktor 1.095).

2. Aus diesem Bereich wird nun jede 3. Zeile gelesen, in den gelesenen Zeilen werden alle Pixel, oder fast alle Pixel gelesen und per Binning oder Downsampling werden 3 Pixel einer Zeile zu einem zusammengefasst. Das Ergebnis ist ein natives 2240 x 1260 RGB Bild. Ich habe keinen Hinweis darauf gefunden, dass jeweils 4 Pixel einer Zeile zu einem zusammengefasst werden und die Lumolabs-Tools messen die Samplingrate ziemlich genau.

Ich schliesse nicht aus, dass "eine Zeile" auch Pixel der Nachbarzeile ausliest und dafür in der eigenen Zeile überspringt, um für alle 3 Farben Werte zu erhalten. Ich habe leichte Hinweise für so etwas in der Frequenzanalyse gefunden.

3. Das 2240 x 1260 Bild wird im Verhältnis 7:6 auf 1920 x 1080 downgesamplelt.

4. Gegenüber einer vollen FX-Lösung ohne Lineskipping (Binning aller Pixel) werden 1/3.6 der Pixel gelesen, d.h., das ISO-Rauschen bei ISO 6400 entspricht ISO 23000. Vergleiche mit der 5DmkIII sollten dahingehend überprüft werden, als Plausibilitätscheck meiner Analysetechnik.

5. Im Liveview-Modus ist das Lineskipping feiner, das Bild löst feiner auf als das Videobild. Zusätzlich sind senkrechte Strukturen dabei erheblich besser aufgelöst als waagerechte, daher sollte man manuell im LV an vertikalen Kanten fokussieren (Bäume, Häuserecken, Laternen etc.).

6. Full Disclosure: http://falklumo.blogspot.de/2012/04/lumolabs-nikon-d800-video-function.html

Fazit: Die Befunde bzgl. Liveview und Video sind weniger schlecht, als ich zunächst befürchtet hatte. Allerdings wird die Sensorarchitektur zu Kantenflimmern waagerechter Strukturen in Videoaufnahmen führen (Geländer, Dachkanten etc.).

Klicken zum Weiterlesen...

 

[Norden]

Spannend und ich will lieber gar nicht fragen, wie du das herausgefunden hast.

Noch eine Verständnisfrage: werden die Zeilen aus den "Rohdaten" (also bevor das Demosaicking des Bayer-Musters stattfindet) herausgeschnitten? Wenn ja: wie werden denn dann die Farbinformationen errechnet? In einer Zeile fehlt ja immer eine Grundfarbe. Oder ist es das, was du meintest, als du schriebst, dass evt. Pixel aus einer Nachbarzeile ausgelesen werden, um die volle Farbinformation zu bekommen?

Ich denke mal, dass dieses Überspringen von Zeilen genutzt wird, weil Sensoren zeilenweise ausgelesen werden und man so die Zeit spart, die man benötigt, um bis zu 30 Bilder pro Sekunde zu erzeugen. Richtig?

 

[falconeye]

Spannend und ich will lieber gar nicht fragen, wie du das herausgefunden hast.

Über die Frequenzanalyse von False Circles in Zone Plane Charts (vgl. mein Blog). Später dazu Bilder, sobald ich etwas für den Blog hab.

Noch eine Verständnisfrage: werden die Zeilen aus den "Rohdaten" (also bevor das Demosaicking des Bayer-Musters stattfindet) herausgeschnitten? Wenn ja: wie werden denn dann die Farbinformationen errechnet?

Yepp, es werden die Sensel vor Demosaicing übersprungen bzw. gelesen, das machen fast alle HDSLRs so (das Nokia 808 Handy nicht, was eine weitere, weniger beachtete Sensation ist, von den 41MP überschattet).

Richtig, der Sensor ist zu langsam, um 30 mal/s alle Pixel auszulesen. Er müsste nach meinem Schema 254 MP/s auslesen. Das wären aber 7fps bei voller Auflösung, weshalb ich glaube, dass in einer Zeile vielleicht nicht alle Pixel ausgelesen werden.

Der Unterschied zwischen 7 und 4fps pro Bild sind 100 ms. Der Shutter braucht 2-mal 6 ms, der Spiegel ca. 20 und (30-6) ms, bleiben gut 40 ms, die dann die D800 schneller sein könnte. Fokus? Kann die D800 4fps mit aktivem AF.C? Falls ja, würden die Zahlen zusammenpassen.

Die Frequenzanalyse liefert numerisch, dass jede 2.99-te Zeile gelesen wird und wahrscheinlich jede Spalte. Natürlich ist 2.99 Meßungenauigkeit, aber genau genug, um sagen zu können, dass jede 3-te und nicht jede 3.5-te Zeile gelesen wird, was ja dem Auflösungsunterschied entspräche.

Was ich nicht sehe, ist, welche Sensel genau gelesen werden. Da es einen leichten False Circles Effekt auch waagerecht gibt, schliesse ich nicht aus, dass andersfarbige Pixel "neben einer Zeile" mitgenommen werden.


Anbei die "geradlinige" Lösung:



Hier ergibt sich NACH dem Auslesen "zufällig" wieder ein RGGB Bayer-Muster (einfach mal nur die farbigen Sensel allein betrachten: hoppla!), d.h., man kann alle schon vorhandenen Demosaicing-Routinenes weiterverwenden. Dies ist die wahrscheinlichste Lösung, die wohl auch die 5DmkII hatte, allerdings ohne anschl. 7:6 Downsampling.

Hier eine Variation:



Ein solches Schema kann ich nicht vollständig ausschliessen. Wohl aber, nur 2x2 Blöcke zu lesen (das linke grüne Sensel der "L"s jeweils auch noch "runterzuziehen", oder gar wegzulassen). Denn dann ergäben sich i.w. symmetrische "False Circle" Frequenzen, die ich definitiv nicht sehe.

 

[falconeye]

Full disclosure

Blogartikel nun online:

-> http://falklumo.blogspot.de/2012/04/lumolabs-nikon-d800-video-function.html

(Engl. language!)

 

[Norden]

Was ich nicht sehe, ist, welche Sensel genau gelesen werden. Da es einen leichten False Circles Effekt auch waagerecht gibt, schliesse ich nicht aus, dass andersfarbige Pixel "neben einer Zeile" mitgenommen werden.

Ist das nicht recht unwahrscheinlich? Da doch der Sensor zeilenweise ausgelesen wird, müsste dann ja doch die gesamte Zeile ausgelesen werden, um dann einzelne Pixel zu nutzen. In dem Fall könnte man dann ja auch je zwei übereinander liegende Zeilen nutzen, um die vier zusammengehörigen Pixels des Bayermusters auszuwerten.

 

[falconeye]

Ist das nicht recht unwahrscheinlich?

Nach den Meßergebnissen schon.

Allerdings lesen diese Exmor Sensoren mit column-parallel ADC ja alle Pixel einer Zeile parallel aus, was rasend schnell geht (es dauert in etwa so lange, wie nur ein Sensel zu lesen). Der Flaschenhals ist der anschliessende digitale Transfer aller Werte einer Zeile auf die paar Auslesekanäle des Chips.

Nun kenne ich den Chip nicht genug im Detail, aber dieses Auslesen einer Zeile lässt sich programmieren, z.B., Anfangsposition, Endposition (Windowing genannt), aber oft auch ein Überspringen (jedes 2., 3., etc.). Je nach Details liese sich das also umsetzen oder nicht.

Ich verstehe übrigens sowieso nicht, warum Sony diesen letzten Flaschenhals nicht wie ein paralleles Speicherinterface mit DMA-Mode ausgeführt hat: Freie Programmierbarkeit per Anlegen von Adressen und Bandbreite ohne Ende. 4k Video ohne Rolling Shutter wäre dann kein Problem mehr. Ich rechne bei jeder neuen Generation damit, bei der D800 war's offensichtlich noch nicht so weit.


Hier übrigens mal ein Analysebild aus dem Blogartikel (zum Vergrößern bitte anklicken):

 

[WideAngle²]

Ich verstehe übrigens sowieso nicht, warum Sony diesen letzten Flaschenhals nicht wie ein paralleles Speicherinterface mit DMA-Mode ausgeführt hat: Freie Programmierbarkeit per Anlegen von Adressen und Bandbreite ohne Ende. 4k Video ohne Rolling Shutter wäre dann kein Problem mehr. Ich rechne bei jeder neuen Generation damit, bei der D800 war's offensichtlich noch nicht so weit.

Man darf nicht vergesen, daß die A/D-Wandlung auch Zeit benötigt. Wenn es so abläuft wie es in Deinem Link http://www.nikon-fotografie.de/vbul...ducts/SC-HP/cx_news/vol47/pdf/featuring47.pdf beschrieben, dann läuft die A/D-Wandlung für alle Pixel einer Zeile synchron ab, weil sie sich einen gemeinsamen D/A-Wandler teilen. Lediglich das Datenregister, das den Endwert enthält und die Komparatoren sind für alle Spalten separat ausgelegt. Weil das Zählverfahren zur A/D-Wandlung relativ langsam ist (im Vergleich z.B. zur sukzessiven Approximation) muß man die A/D-Wandlung für eine große Anzahl von Pixeln, z.B. alle Pixel einer Zeile parallelisieren. Wäre ein wahlfreier Zugriff auf einzelne Pixel möglich, müßte man die A/D Wandlung ebenfalls aus Zeitgründen parallelisieren. Dazu wäre es dann nötig, zunächst durch Beschreiben einiger tausend Adreßregister festzulegen, welche Pixel als nächstes A/D gewandelt werden sollen. Dann würde die Wandlung für alle diese Pixel gleichzeitig stattfinden und schließlich könnte das Ergebnis ausgelesen werden. So einfach wie beim Speicher-schreiben und -Lesen geht es jedenfalls nicht. Damit könnte man evtl. hinsichtlich Rolling Shutter eine Verbesserung erzielen, aber das normale Auslesen eines Bilds wäre wohl langsamer.

Grüße
WideAngel²

 

[falconeye]

Anmerkungen über das Potential von Column-parallel ADCs

1. Man darf nicht vergesen, daß die A/D-Wandlung auch Zeit benötigt. Wenn ... dann läuft die A/D-Wandlung für alle Pixel einer Zeile synchron ab, weil sie sich einen gemeinsamen D/A-Wandler teilen.

2. Lediglich das Datenregister, das den Endwert enthält und die Komparatoren sind für alle Spalten separat ausgelegt. Weil das Zählverfahren zur A/D-Wandlung relativ langsam ist (im Vergleich z.B. zur sukzessiven Approximation) muß man die A/D-Wandlung für eine große Anzahl von Pixeln, z.B. alle Pixel einer Zeile parallelisieren. Wäre ein wahlfreier Zugriff auf einzelne Pixel möglich, müßte man die A/D Wandlung ebenfalls aus Zeitgründen parallelisieren.

3. Dazu wäre es dann nötig, zunächst durch Beschreiben einiger tausend Adreßregister festzulegen, welche Pixel als nächstes A/D gewandelt werden sollen.

Hi, ich glaube, der Gedanke ist nicht zuende gedacht. Über diese Punkte hatte ich durchaus nachgedacht und mein Posting war das Ergebnis.

Ad 1.) Die Pixel einer Zeile teilen sich keinen ADC. Das steht doch fett im Paper! Es gibt tausende ADCs in den neuen Sony Chips, das ist ja Geniale.

Ad 2.) Genau. Nur dass das im D800 Sensor schon passiert. Also ohne Konjunktiv

Ad 3.) Dazu hatte ich geschrieben, "DMA Mode". Auch DRAMs haben Latenz, dagegen gibt es seit Ewigkeiten den DMA Mode, in dem man ganze Blöcke (hier: Teile einer Zeile) überträgt. Man muss nur statt des wohl nur 14 Bit breiten LVDS-Interfaces ein echtes Prozessor-Businterface einbauen und die Post ginge ab ... (Zeilenadresse anlegen, und der Reihe nach die gewünschten Spaltenadressen/Blöcke abklappern). Nach meiner Berechnung (s.o.) ist des LVDS-Interface Sensel-seriell und >254 MHz getaktet. Da am Chip eine Clock anliegt (75 MHz oder mehr), wahrscheinlich ein Vielfaches der Clock, die ich aber nicht kenne.

Ein übliches 4-Channel DDR3-1600 Interface z.B. liefert in Benchmarks gut 30GB/s, selbst 1-Channel noch 10GB/s. Damit (10GB/s) könnte eine komplette D800-Zeile (7360 x 14Bit = 12.6 kB) in 0.4 µs ausgelesen werden, selbst 0.1 µs wären technologisch machbar, aber begnügen wir uns mit 1 µs, die dann auch genug Zeit für Latenzen und die eigentliche A/D Wandlung beinhalten (die A/D Wandlung der 12 Channel 12.1 MP 9fps Nikon 3DS ist ungefähr 0.1 µs je Pixel, > ~1 µs für die Wandlung sind also viel Zeit und mit ein Grund für die hohe Qualität der Sony-Sensordaten).

Also "kann" Sony eine Zeile in 1 µs liefern, die Technik gibt das locker her.

Aber damit liesse sich der Sensor in 5 ms komplett auslesen, d.h., Video in 200 fps ohne Subsampling des Sensors wäre technich kein Problem. Etwas in der Art scheint die neue Sony FS400 zu machen. Nikon hätte nur auf einem echten Speicherinterface bestehen müssen, als die Sensorproduktion beauftragt wurde. Natürlich verbraucht das Strom (Kühlung), aber nur, wenn man die Bandbreite auch ausreizt.

Hinzu kommt, würde man die Technologie auf 1/1000s je Frame hochzüchten, dass auch für die Still-Fotographie völlig neue Anwendungen möglich werden: Ultra-Langzeit aus der Hand, keine Verwacklungsunschärfe mehr bei <=200mm Brennweite, mehr als 20 Blenden Dynamikumfang, ... klar, brauchts da auch den potenten Signalprozessor dahinter, aber wofür gibt es Ingenieure? Sony vs. Nikon wird noch spannend, kein Grund für Nikon, Atem zu holen.

 

[WideAngle²]

AW: Anmerkungen über das Potential von Column-parallel ADCs

Ad 1.) Die Pixel einer Zeile teilen sich keinen ADC. Das steht doch fett im Paper! Es gibt tausende ADCs in den neuen Sony Chips, das ist ja Geniale.

Ich glaube, Du täuscht Dich hier. Es sind tausende von ADCs, das ist schon in gewisser Weise richtig, aber sie arbeiten nicht unabhängig voneinander. Ich gehe mal davon aus, daß das Sony-Papier noch aktuell ist. Dort sieht man folgendes:

1) In Figure 3 ist auf der linken Seite ein einziger D/A-Converter, der die Vergleichspannung für alle Pixel einer Zeile erzeugt. Es also nicht ganz richtig, daß jede Spalte einen eigenen ADC hätte, es ist mehr eine "Mischkonstruktion". Ein Teil des ADCs ist gemeinsam für alle Spalten nur einmal vorhanden (der D/A-Wandler der die Rampenspannung erzeugt) und andere Teile sind für jede Spalte separat vorhanden (die Komparatoren und Zähler).

2) Figure 4 zeigt, daß der A/D-Wandler mit dem Zählverfahren arbeitet, d.h. es wird über den D/A-Wandler eine Rampenspannung erzeugt, gleichzeitig beginnen die Zähler bei den Spalten zu zählen bis der Spannungswert des Pixelwerts gleich der Rampenspannung ist. Der letzte Zählerstand entspricht dem Digitalwert des analogen Pixelwerts.

Das Zählverfahren ist ein sehr langsames Verfahren, weil der Zähler bei 14bit Auflösung alle 16384 Stufen durchlaufen muß. Wenn wir davon ausgehen, daß der Zähler mit 300Mhz getaktet ist (siehe Sony-Papier) dann braucht eine A/D Wandlung mindestens 54µs. Dabei werden allerdings alle Pixel einer Zeile gewandelt, also ca. 7000 bei der D800. Um 4000 Zeilen zu wandeln braucht es etwas mehr als 200ms für die Wandlung eines Bildes, was ungefähr mit den 4fps korreliert.

Nur das Zählverfahren erlaubt es, einen gemeinsamen D/A-Wandler zu verwenden, was auch einen Vorteil darstellt, weil dessen Linearität für die Wandlung aller Pixel maßgebend ist. Das ist IMHO das Geniale.

Bei der D3S ist es etwas anders, hier sind vermutlich wirklich separate ADCs vorhanden, allerdings nur 12, die voraussichtlich nach dem Prinzip der sukzessiven Approximation arbeiten und wesentlich schneller sind, weil eine 14-bit A/D-Wandlung je nach Zählweise mit etwa 14-16 Taktschritten auskommt. Dafür braucht es aber einen eigenen DAC für jeden ADC, weil der DAC individuell für jede A/D-Wandlung angesteuert werden muß und nicht einfach nach oben gezählt wird.

Du hättest recht, wenn jede Spalte einen eigenen D/A-Wandler hätte und dieser nach dem Prinzip der sukzessiven Approximation arbeiten würde. Aber das steht in dem Sony-Papier nicht drin und auch die Werbeaussagen zur D800 bezüglich Genauigkeit der Wandlung wären dann hinfällig. Hätte jede Spalte ihren eigenen D/A-Wandler so würden sich Abweichungen in der Wandler-Linearität im Bild sichtbar niederschlagen. Dies zu verhindern wäre eine große Herausforderung an den Chip-Hersteller.

Grüße
WideAngel²

 

[falconeye]

AW: Anmerkungen über das Potential von Column-parallel ADCs

Ich glaube, Du täuscht Dich hier.

Ich glaube, grundsätzlich sind wir uns einig. Ich habe allerdings i.d.T. übersehen, dass der jetzige ADC im Sony-Chip dermassen langsam arbeitet, also 16384/300MHz oder 55µs für eine Zeile braucht. Ich hatte einfach mit 1µs als Überschlagswert gearbeitet, was nicht zulässig ist, weil ein anderer Typ ADC zum Einsatz kommt.

Danke für den Hinweis und die Richtigstellung. Ich hatte Unrecht.

Interessanterweise ändert das wenig an meiner Kernthese:

Nikon hätte Sony in die Spec schreiben können, dass es einen 10Bit Wandlermodus geben soll, der dann trotzdem wieder nur 3.3 µs je Zeile benötigt und ein Frame mit für Video völlig ausreichender sRGB Qualität vollständig ohne Subsampling in 13.7 ms liefert, genug für 1080p@60fps HD Qualität in grandioser Downsamplingqualität ohne Binning oder Line-Skipping.

Wir sind uns also wahrscheinlich einig, dass Nikon/Sony hier eine Chance vertan hat, Canon eins auszuwischen. Panasonic hat dieses Detail offenbar besser im Griff.