Canon Prototype Full Frame DSLR Shooting RAW Video

jo59 · 22 Februar 2010

chmee schrieb:
Warum?

Wir sprechen hier von DSLR-Video - und da entspricht die Sensor- nicht der Videoauflösung, für Video werden Sensorpixel zusammengefasst... (FullHD)

chmee schrieb:
Der Sensor wird ausgelesen und die Daten roh gespeichert. Die Kamera angegebenen MP sind Sensorpixel, die ihre Farbigkeit nach dem Bayer-Prinzip erstellt. Ergo a[MP]*14[Bit]/(8*1024*1024)= b[MB/Bild]

mfg chmee

Also 21MPix-RAW (5DII) bei 14 Bit Farbtiefe und bisher 30 Frames pro sec müssen erstmal weggespeichert werden...

chmee · 22 Februar 2010

Ich gehe davon aus, dass Du die letzten Seiten (wo das Thema Datendurchsatz & Problematik Thema war) schon durch bist, oder? Die Frage lässt sich mM noch nicht eindeutig beantworten, denn ich habe bis Dato keine Ahnung, wie 1920x1080 (oder 1280x720) aus dem Sensor extrahiert werden. Ist es Binning oder Slicing/Lineskipping? Wie wird die Horizontale umgerechnet?

Zur zweiten Anmerkung: Wurde hier mehrmals (auch von mir) errechnet und zur Diskussion gestellt.

WENN es Bayer-RAW-Daten sind, ist es 14Bit pro Pixel.
WENN es zusammengerechnete RGB-Pixeldaten sein sollten, sind es 3x14Bit pro Pixel.

In beiden Fällen kann man jedenfalls nicht wirklich von 14Bit Farbtiefe/Pixel sprechen. Im ersten Fall ist es aufgrund Bayer eigentlich nur ein gefärbter Lumapixel (denn 4 Sensorpixel ergeben erst den eigentlichen Farbwert) und im zweiten Fall wär es 3*14Bit Farbtiefe..

Aber nun muss ich auf die Antwort der obigen Frage warten, wie das FullHD-Bild aus dem Sensor erstellt wird. Aufgrund der AA/Moiré-Fehler tippe ich auf Zeilen- bzw. Pixelauslassen und nicht auf Zusammenfassen.

mfg chmee

p.s.: Wer redet von 21Mpix@RAW@30fps? Ein himmelweiter Unterschied zu FullHD (~2MP).

p.p.s.: Um auf den davorigen Beitrag nochmal anzusprechen: Man kann das Bayerpattern auch erhalten und trotzdem runterrechnen. Was meiner Ansicht blödsinnig wäre, aber die Canon-Ingenieure haben sich da wohl schon n paar mehr Gedanken gemacht...

p.p.p.s.: Thema Binning Lineskipping :

Quelle: Video vom Vortrag Tim Smith (;Canon Inc. Prod.Manager Digital Images) sagt dort klar und deutlich, dass die ganzen Line- oder Pixelskipping Gerüchte nicht stimmen, weil die D5, (;und die D7 wird das nicht anders machen), mit 6x6 Binning arbeitet

Link zum Fund : http://www.slashcam.de/info/Canon-7D-Aliasing-Test---720p50-quasi-unbrauchbar--379321.html

Der Workshop war am 23. Juli 2009, also nicht so lange her, vor der Digital Cinema Society.
Workshop war "Digital still cameras for motion picture production"
http://dcsjulymeeting.eventbrite.com/
http://digitalcinemasociety.org/content.php?page=Lighting Workshop

Vortrag lässt sich nur als Member der DCS anschauen, sorry..

NoComment · 23 Februar 2010

jo59 hat in sofern recht, dass die volle Sensoraufloesung am Port zwischen Sensor und Chip anfaellt

.
Das ist aber irrelevant, denn die DIGIT's der 5D/7D/550D sind ja auch schon in der Lage das auf 1920*1080 herunterzubrechen

.
Was die Prozessoren auch machen ist das ganze in RGB imzuwandeln, ein Schritt der bei RAW Video natuerlich sinnfrei ist, denn dieser Schritt soll ja nachher am Computer mit eigenen Einstellungen selber gemacht werden

.

D.h. nach dem verkleinern der Aufloesung auf 1920*1080 im DIGIT-Chip (was die Modelle 5D/7D/550D ja alle schon machen) wird diese Datenmenge (http://www.wolframalpha.com/input/?i=%28%281920*1080*14bit%29%2F%288bit*1024^2%29*30%29MB+per+second) an die CF-Schnittstelle weitergegeben.

Zum Funktionsprinzip eines CMOS- Sensors:
Laut Wikipedia, wird jeder pixel seperat verstaerkt und an den Sensor angebunden (ich denke hier werden pixel gruppiert da man sicher nicht 18.000.000 (fuer 18MP) Pipes nuetzen will).
D.h. wenn der Sensor ausliest kann er einfach die Gruppen einlesen die erbraucht, sie runterscalieren (2x DIGIT IV sollten genung Power haben) und dann abspeichern (also so wie sRAW und mRAW funktioniert --> also v(ideo)RAW

)

Quelle:
http://de.wikipedia.org/wiki/CMOS-Sensor

Und ich denke diese Datenmenge ist durchaus zu speichern und damit waere VideoRAW machbar.
Sollte sie auch noch leicht komprimiert werden koennte man das Raw- Video wahrscheilich auch noch an einem i7 Computer fluessig bearbeiten/konvertieren.
Ein anderen Vorteil von RAW- Video sehe ich gerade noch: All' diese Filter zur Entrauschung, Farbveraenderung, Schaerfe, etc. arbeiten viel verlustfreier

.

chmee · 23 Februar 2010

jo59 hat in sofern recht, dass die volle Sensoraufloesung am Port zwischen Sensor und Chip anfaellt

Das habe ich aber auch schon geschrieben, ist also nix Neues - Und Du hast die Begründung auch nochmal geliefert, diesen Umrechnungsschritt machen alle VDSLRs schon - ergo ist 1 DIGIC auch potent genug - sogar mit Demosaicing und Encoding nach H.264.

Sollte sie auch noch leicht komprimiert werden koennte man das Raw- Video wahrscheilich auch noch an einem i7 Computer fluessig bearbeiten/konvertieren.

Naja, da bin ich ein bisschen am Hadern.. 1 Spur, ja sollte was werden, aber schicker Schnitt mit 2-3Spuren wird mühselig, meine theoretische Einschätzung. Immerhin ist es immer noch in Echtzeit umgerechnetes RAW. Aber was solls, alles Flickschusterei ohne praktische Beweise im Moment..

(p.s.: Heute neue Equipvorstellung, wenn man einem Twitter-Eintrag Vertrauen schenken darf??)

mfg chmee

p.s.:

..also so wie sRAW und mRAW funktioniert --> also vRAW..

sinnvolle Ableitung, aber auch dazu habe ich bis Dato keine klaren Aussagen gefunden, wie s/mRaw aus dem Sensor extrahiert wird. m/sRaw haben aber den Vorteil halbe/viertel so groß zu sein, die Errechnung/Erstellung ist in so weit einfach - im Gegensatz zu 1080 Bildbreite, welche so gar kein ganzer Teiler der Sensoren ist. Zumindest diesen sRAW-Thread gefunden, der recht schnell an Qualität verliert..

TheSoulhunter · 26 Februar 2010

Bezüglich Speichermöglichkeit und Datenmenge:

Bin heute über das hier gestolpert...

NoComment · 26 Februar 2010

Naja, da bin ich ein bisschen am Hadern.. 1 Spur, ja sollte was werden, aber schicker Schnitt mit 2-3Spuren wird mühselig, meine theoretische Einschätzung. Immerhin ist es immer noch in Echtzeit umgerechnetes RAW. Aber was solls, alles Flickschusterei ohne praktische Beweise im Moment..

Hier muss man in Betracht ziehen, das Intel den ollen FrontSideBus abgeschafft hat und damit einen anderen Falschenhals mehr eliminiert hat. Mit min. 4GB RAM, i7 975EE, einer potenten Grafikkarte und SSD sollte ein angenehmer Schnitt ermoeglicht werden.
Das wichtigste ist aber die Software

. Wenn diese die Grafikkarte voll nutzen kann, dann ist Echtzeitschnitt mit 3 - 5 Spuren kein Problem. Denn man muss bedenken das heutige Grafikkarten um einiges rechenstaerker als ein (im Vergleich) lahmer i3/i5/i7.

Quelle:
Irgendeine c't, die das Thema Nuetzung von GPU's fuer Decodung von Videos abgehandelt hat.
In einem Passwortknack- Benchmark (als Referenz, da mangelder ander Testprogramme) hat eine nVidia GPU verglichen mit der Top CPU von Intel ca. 1,5 mal weniger Zeit gebraucht (ca. 1 Jahr vorbei)

chmee · 28 Februar 2010

@NoComment:
Die Realität sieht aber leider noch anders aus. GPGPU-Anwendungen kann man als (R)evolutionären Schritt ansehen, wenn sie denn endlich im OS ankommen. Win7 wird über die MS-eigene Bibliothek endlich was dafür haben, nun müssen wir warten, dass es auch benutzt wird. Kommen wird es, das steht ausser Frage und dann werden hoffentlich auch LR/Photoshop/Premiere damit ausgestattet. ~1Terraflop Rechenleistung auf einer AMD5850 sind ne klare Aussage im Vergleich zu den 40Gigaflops eines i7-965.

p.s.: c't 07/09 - S.92ff bzw. c't 06/09
Der Unterschied ist höher! Vergleich Dualcore Athlon zu 2x9800GX2 (54x), also knapp 13x bei einem 9800-Chip!
Link zu BarsWF - http://3.14.by/en/md5
Nvidia-Cuda-Link - http://www.nvidia.de/object/cuda_apps_flash_new_de.html# -zwischen 2x und 1000x schneller...

@TheSoulHunter:
Wir hatten ja auch schon Firewire im System (1D, wenn ich mich nicht täusche), das mit 400MBit (~50MB/s) guten Durchsatz erreicht hat. Auch USB wär mit (USB2) 480MBit nicht so falsch gewesen, USB-Sticks sind billig und USB3 bietet theor. 4,8GBit. Mal schauen. Die wohl wichtigen Gründe für CF/SD-Speicherkarten sind das robuste Interface und das ressourcenschonende Übertragungsprotokoll. CFast und CompactFlash5.0 sind jedenfalls schöne Verbesserungen..

mfg chmee

NoComment · 1 März 2010

Die Realität sieht aber leider noch anders aus. GPGPU-Anwendungen kann man als (R)evolutionären Schritt ansehen, wenn sie denn endlich im OS ankommen. Win7 wird über die MS-eigene Bibliothek endlich was dafür haben, nun müssen wir warten, dass es auch benutzt wird. Kommen wird es, das steht ausser Frage und dann werden hoffentlich auch LR/Photoshop/Premiere damit ausgestattet. ~1Terraflop Rechenleistung auf einer AMD5850 sind ne klare Aussage im Vergleich zu den 40Gigaflops eines i7-965.

Aber was ja noch nicht ist, kann (wird) ja noch kommen

. Das der Unterschied zwischen CPU und GPU so gross war wusste ich nicht

.
Diese Techniken stecken doch genau wie RAW-Video in den Kinderschuhen . . . und koennen dann bitte gemeinsam erwachsen werden

.

TheSoulhunter · 1 März 2010

Auch was das angeht ist die Freeware/OpenSource-Gemeinde schon seit Jahren etwas weiter...
Ich nutze nunmehr schon seit 5 Jahren diesen GPU Denoiser für Videos, also eigentlich ein "alter Hut"!

chmee · 14 März 2010

In den Canonrumours wird nicht besonders viel erzählt, aber mit einer kleinen Aussage haben sie nochmal meine Denke geweckt:

A source told me that canon have indeed created a raw video option for HDSLR’s. It will utilize the HDMI port on the cameras to output full uncompressed HD content for recording on an external device.

Geht es einfach nur um Roh anstatt komprimiert? 1920x1080 unkomprimiert am HDMI-Ausgang?! Keine 14Bit-Raw-Philosophie (was wirklich ein Knüller wäre), sondern einfach nur unkomprimiert anstatt 25MBit H.264. Punkt. Das ist für ne kleine Kamera immer noch genug. Canon wird sich sicherlich fragen, warum grad die VDSLRs einen 14Bit-Video-Output bekommen sollten. Damit füttert man eine 10.000Eur Kamera mit EF-Mount, die eine RED und sonstige Revoluzzercams alt aussehen lässt

@Soulhunter:
Seitdem Grafikkarten eine eigene Scriptsprache (HLSL) und vielfach parallele "Prozessoren" haben, wird auch an Anwendungen jenseits von Texturen und 3D-Objekten gefeilt. Der Unterschied ist aber die Zugänglichkeit für "alle" Programmierer und Allgemeingültigkeit für alle Grafikkarten, sonst landen wir wieder im Mittelalter der Nvidia- und AMD/ATI-kompatiblen Anwendungen.

mfg chmee

BDeKid · 19 März 2010

Bitte sehr , http://www.engadget.com/2010/03/17/arri-alexa-joins-red-to-kill-celluloid-in-2010/

Das ist die Antwort von Arri auf RED

......................

Bzgl. der verbreitung von RED Cams am Set muss man bedenken das die grossen Studios alle noch sehr viel Geld in die eigenen Kopierwerke gesteckt haben und ein sofortiger umstieg auf digital kaum möglich ist bzw wirtschaftlich.

.......................

RAW Video wird schlussendlich auch bald (laufe der nächsten 3-5) Jahre einzug in der Consumer Liga halten. Auch im Bezug auf VDSLR.

........................

Die StockFootage Argenturen werden vermehrt auch kleine Clips von Presse Sport Fotografen ankaufen - dies wird den Markt auch umstellen.

........................

Film(Set) Cams werden weiterhin gutes Geld kosten , man nehme einfach mal die Preise einer PL Mount Linse und vergleiche Sie mit hochwertigen KB Optiken.

.........................

Beim lesen dieses Threads habe Ich leider nur wenige Beiträge als relevant einstufen können.

Viele haben leider auf dem Video / Film Sektor kein fundiertes/ praktisches Wissen am Start , dies ist insofern schade, weil Sie dadurch Wissen / Meihnungen formen die so nicht stimmig sind.

Man sollte neue Entwicklungen eher fördern als sie schlecht zu reden.

Ansonsten einige sehr gute Comments dabei von Leuten die wissen worum es geht!

MfG
B.DeKid

PS: Und noch ganz wichtig -- an alle die Angst haben VideoFunktionen würden eure Fotos schlechter machen - keine sorge das wird nicht der Fall sein;-) Aber auch nur wenn eure Fotos jetzt schon gut sind , ansonsten dürft Ihr das gern auf die Videofunktion schieben;-)