Wie bereits angekündigt, wollte ich zur Black Dots Frage der Panasonic AG-HPX301E auch etwas beitragen (zur Erinnerung: viewtopic.php?t=75673). Dummerweise hatte ich gerade keine solche Kamera griffbereit, was natürlich zu einer unmittelbaren Bestellung der selben geführt hat. Nun hat das UPS-Weihnachtsmännchen doch tatsächlich gestern noch eine vorbeigebracht und ich hab sie gleich mit nach Hause genommen.
Die Kamera wurde im September 2009 hergestellt und mit Firmware 9.30 ausgeliefert (nach Update nun 9.33). Für die Tests verwende ich das KIT Objektiv XT17x4.5BRM-K14 und zwei 32GB P2 Karten der E-Serie.
Die Aufnahmen habe ich im 1080pn25 Modus bei AVC-Intra 100 und den Default-Settings der Kamera gemacht. Anbei ein Originalframe (1920x1080), das ein RGB-Feld bei -3dB, ND-Clear, f/4 und ein anderes bei +6dB, ND4, f/4 zeigt. Erwartungsgemäß ist das Rauschen bei -3dB kaum und bei +6dB erheblich wahrzunehmen. Black Dots speziell im Blau konnte ich nicht nachvollziehen. Vielmehr scheinen sich schwarze und weiße Ausreißer bei allen Farben die Waage zu halten.
Zum Vergleich die gleichen Aufnahmen mit einer Sony PMW-EX3. Habt ihr noch Vorschläge, was ich filmen bzw. testen soll?
Deti
PS: Der rote Punkt im RGB-Feld ist das Tally-Licht des Camcorders.
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Zuletzt geändert von deti am Fr 25 Dez, 2009 11:13, insgesamt 1-mal geändert.
Die EX3-Bilder kann man zwar nicht ganz mit jenen der Pana 301 vergleichen, weil sie offenbar mit einem viel weicheren Gamma aufgenommen wurden, aber interessant ist der Speicheraufwand der hier gezeigten komprimierten Bilder im Vergleich.
Je mehr Details nämlich ein Bild zeigt (und dazu gehört natürlich auch Grain) um so mehr KB benötigt die Jpeg-Kompression. Demnach rauscht die Pana mit 265 bzw 305 KB weniger als die EX3 mit 316 und 390 KB für jeweils -3DB und +6DB Gain.
Ein tolles Ergebnis für Pana, sehe keine ungewöhnlichen Fehler mehr.
@Domain: Die unterschiedliche Gammakurve bei der EX3 hast du gut erkannt - die Kamera ist bei uns ja schon im Einsatz gewesen - hab deshalb den Test mit den Default-Einstellungen wiederholt. Dabei habe ich auch die JPEG-Exportqualität höher eingestellt, wodurch die nun resultierenden Dateien der EX3 wieder größer geworden sind (also nicht wundern). Interessant ist auf jeden Fall der Unterschied bei +6dB - das Rauschen der Panasonic ist schon ziemlich hart - vermutlich ist da auch die Einzelbildkompression bei 100Mbit/s förderlich. Bei der EX3 geht so feines Rauschen, das ja in jedem Frame komplett unterschiedlich ist, vermutlich durch die Quantisierung der MPEG2-Kompression unter.
Demnach rauscht die Pana mit 265 bzw 305 KB weniger als die EX3 mit 316 und 390 KB für jeweils -3DB und +6DB Gain.
So eine "windige" Rechnung habe ich ja noch nie gesehen .... Mottenkabinett.
Wo ist die Herleitung ??? Oder ist das wieder so eine "Grazer-Ahnung" ?
@ Deti
Bei der EX3 geht so feines Rauschen, das ja in jedem Frame komplett unterschiedlich ist, vermutlich durch die Quantisierung der MPEG2-Kompression unter.
Die geht vermutlich schon bei der A/D Wandlung, also nicht erst bei der Codierung, verloren ... und mit ihr natürlich alle Bilddetails dieser Frequenz.
Vergessen darf man auch nicht, die unterschiedlichen Quantisierungsverfahren (Tabellen) der IDCT und der DCT, der sich doch sehr stark unterscheidenden Codecs, weil es z.B auch 1/4Pix Auflösung in MPEG2 gar nicht gibt.
Aber ich gebe zu, so ein Test ist auf die Schnelle nicht zu machen.
Es gäbe für mich zwei Unterschiede zu "beleuchten" einmal die Vorzüge von 10 Bit, die sich natürlich nicht in drei abgegrenzten RGB Tafeln widerspiegeln können, die nimmt auch eine Kamera mit 4 Bit tiefe mehr oder weniger korrekt auf und zum Andern liegen natürlich die Unterschiede im Codec, der sich im überwiegenden Teil in der Bewegungsprädiktion zeigt, also auch nix für eine statische Farbtafel.
Weil das Bildprozessing aber dynamisch ist, zeigen sich auch erst in der Bewegung die Limits.
Das Rauschen ändert sich nämlich mit dem Bildprozessing, also eine Rauschanalyse, wie sie hier gemacht ist hat auch nur Gültigkeit für dieses eine, statische Motiv. Zugegeben nichts, was der Videofilmer nun täglich als Cotent aufnimmt :-))
WoWu hat geschrieben:
So eine "windige" Rechnung habe ich ja noch nie gesehen .... Mottenkabinett.
Wo ist die Herleitung ??? Oder ist das wieder so eine "Grazer-Ahnung" :-))
Die Herleitung ist ganz einfach, aber vielleicht nicht richtig. Fülle ein 1920*1080-er Bild in Photoshop mit einer einheitliche Farbe, z.B. in blau. Speichere dann das Bild in Jpeg und du erhälst z.B. 150 KB.
Dann verändere das Bild durch Einfügen eines Rauschstörfilters. Sieht dann aus wie bei der Pana, wunderbares Grain und speichere es erneut unter denselben Konditionen in Jpeg ab. Danach hat dein Bild plötzlich fast 4 MB. Heute vormittag getestet ;-))
Kannst du sofort selbst nachvollziehen. Wie erklärst du das?
So also machst Du VIDEO-Analysen ?
Sorry, aber da sträuben sich mir leider die Haare.
Da kannst Du die Bilder ja gleich ausdrucken und auf eine Briefwage legen und schaun, welches schwerer ist .... das hat dann mehr Farbe aufgesogen und damit mehr rauschen im Bild.
Dreh mal ein Bild in Photoshop um 1° und anschliessend wieder zurück (ohne UNDO) und dann schau mal, was Photoshop daraus gemacht hat.
@WoWu: Die schwarzen Pünktchen bekommt man mit der HPX301E schon hin, aber tatsächlich nicht auf Farbflächen. Der Effekt hat scheinbar mit dem Bildinhalt zu tun - zumindest kann ich ihn an realen Szenen sichtbar machen. Wenn man sich den Ort eines Dots merkt, dann sieht man dort immer wieder Dots auftauchen - die bleiben dann meist länger als nur ein Frame (ca. 5-10 Frames). Gleichzeitig gibt es Areale, wo nie Pünktchen auftauchen. Anbei ein Bild, wo man verstreut viele Pünktchen sieht - ein besonders schöner Punkt ist links unten im blauen Teil der Flamme der zweiten Kerze.
Irgendwie erscheint es mir sehr schwer eine "immer wenn ... dann ..."-Beziehung herzustellen, denn zumindest bei meinem Exemplar dieser Kamera muss man ziemlich experimentieren bis man diese Dots hinbekommt.
Nach dem Urlaub versuche ich das Ganze mal via HD-SDI, um auszuschließen, dass der Codec diesen Effekt provoziert.
... und der Fairness halber muss ich sagen, dass ich selten so knackscharfe und ausgewogene Standbilder aus einem Video gecaptured habe. Da sieht jedes Frame aus, wie ein Bild einer ziemlich guten Fotokamera.
Deti
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Danke, Deti.
Dann scheinst Du eine der "Guten" zu haben .. oder anders herum, die von Sandor war wahrscheinlich ziemlich verkurbelt.
Vielleicht hat sie ja schon mal jemand zur Probe gehabt, der sich im Maintenace Menue verirrt hatte und munter geschraubt hat.
Was die Bildqualität betrifft, solltest Du man ein ordentliche Objektiv draufschrauben .. da fällst Du vom Glauben ab, denn die Aufnahmen sind auch im Videobereich super scharf.
Wir warten jetzt nur noch auf die 2/3" ... das wär´s dann für eine ganze Weile.
Wenn Du übrigens Dots erzeugen kannst, zieh mal nur die Schärfe, damit veränderst Du sie auch.
Das war die Serie, die ich neulich für Sandor noch gemacht hatte.
Da liessen sich die Punkte nach belieben mit Schärfe ein- und wieder ausblenden.
Sag mal Bescheid, wenn Ihr neue Erkenntnisse bezüglich des OS habt, weil, da geht hier keiner ran.
WoWu hat geschrieben:
Dreh mal ein Bild in Photoshop um 1° und anschliessend wieder zurück (ohne UNDO) und dann schau mal, was Photoshop daraus gemacht hat.
Tut mir leid WoWu du liegst daneben. Habe gerade mal das ursprüngliche blaugefüllte ungestörte Bild um 5 Grad nach rechts und dann ohne Undo wieder nach links gedreht.
Tatsächlich, das Bild hat nun einen Speicherbedarf von 208 KB statt wie vorher von 144 KB. Aber es hat nun 2108 *1415 Pixel, wohl eine Eigenart von Photoshop nach der Drehung und Retourdrehung, d.h. es ist um 43,8% größer geworden und das entspricht genau der Zunahme von 144 auf 208 KB.
Ich wollte damit auch nur sagen, dass Photoshop zur Videoanalyse wie ein Griff in die Wundertüte ist.
Mal ganz von der Latte an Fehlerquellen im Codecwechsel abgesehen.
Also mit solchen Methoden hier zu kommen wird dem Thema beim besten Willen nicht gerecht.
Dabei würde ich es auch jetzt gern belassen und Photoshop nicht weiter zum Gegenstand der Diskussion machen wollen.
Das mit PS kann ich glaub Ich erklären - das liegt am Container JPG - mit dem man auch "Daten" speichern kann.
Mit zB DriveCrypt kann man in Bildern und Sound files normale Daten ein arbeiten ohne dabei die MusikFile oder das eigentliche Bild zu verändern.
Ich denke das PS in den Bilder auch die "Protokol" Daten schreibt.
Merken kann man das auch wenn man ein Bild mit mehreren Ebenen in PS anlegt und dann die Ebenen zusammenführt. Das Bild wird nicht "kleiner" sondern meist grösser.
MfG
B.DeKid
PS. Das KerzenBild ist der HAMMER - wenn das ein "StillFrame " ist - also dann weiss Ich wirklich nicht wo es da was zu meckern gibt - Kubrick hätte sich zu BarryLyndon sowas gewünscht;-)
WoWu hat geschrieben:Domain, Du lernst aber auch nicht aus der Vergangenheit.
Lassen wir´s dabei.
Wir belassen es nicht dabei, im Gegenteil.
Ich habe aus der Vergangenheit gelernt, dass man dir nicht alles unbesehen glauben darf. Und nun erkläre mir doch mal wirklich, wieso ein Still aus welchem Video auch immer und danach in Jpeg komprimiert nicht einen Hinweis auf die Detailfülle korrespondierend mit seinem Speicherbedarfes liefert und wenn es auch nur das Korn betrifft.
Ich bin da aber durchaus lernfähig und würde Fehler sofort einsehen.
Ja, das ist genau deine Methode: wenn dir nichts mehr einfällt wirst du pummelwitzig und gleitest voll ins Unsachliche ab. Was anderes habe ich bei dir noch nie kennengelernt.
Oder du erklärst mir mal, wieso das mit Korn verunzierte Bild plötzlich 3, 96 MB hat statt 144 KB beim ungestörten hat.
zB TOPAZ ist ein Hammer Progi wenn es um Stills geht da kann PP wirklich nicht mithalten auch nicht VLC - obwohl alle Progis JPEG ausgeben.
Hier ist es aber dem Internen Algorythmus zu verdanken das Topaz knackscharfe und Farbdetail reiche Bilder ausspuckt. (Da also mit Filtern drüber wandert) was ja PP nicht macht und somit eher als RAW zu verstehen ist - was für eine Analyse aber auch besser zu nutzen wäre ( welche ICH auch erstmal - wenn Ich denn auch mal Langeweile hätte - machen würde)
............
Eine VideoAnalsye Software - kenn ich leider nicht - würd mich freuen wenn WoWu (mir) da mal was empfehlen könnte.
............
Ansonsten kann ich immer nur schmunzeln über eure "Fehden" und empfehle mal keine "Wundertüte" sondern eine " Friedenspfeife" ;-)
Ihr habt beide soviel Potenzial - da find Ich das immer sehr schade - aber seis drum - Ihr "rockt" .
..............
MfG
B.DeKid
Wie würd DUWA schreiben - heute mal als "Streitschlichter" ;-)
Für mich ist das eher geistige Gymnastik, weil mir als Pensionist fad ist. Ich selbst nehme nichts, aber auch gar nicht persönlich, es ist nur ein geistiges Duellieren und ich würde jederzeit gerne einen Caipirinha mit WoWu trinken so wie in alten Zeiten und ich glaube anderseits auch, dass er es mir nicht übel nimmt.
Macht euch da keine Sorgen.
@WoWu:
Na wie gut, dass wir heute Abend mit der Kamera noch schnell zum Testdreh in der Stadt unterwegs waren. Anbei zwei hochskalierte Screenshots (1920x1200) des p2viewers, gedreht in AVC-Intra 100 bei 720p50 mit DRS an bzw. aus. Im Scene File ist DRS EFFECT Default (=3).
Ich sehe da nur einen Unterschied in den Farbflächen.
Die Kamera ist erstaunlich sparsam - ein 105Wh V-Mount Akku war nach 3h Dauerbetrieb immer noch fast voll.
Deti
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Wenn man P2 AVC-Intra Material mit Sony Vegas Pro verarbeiten möchte, dann ist das eine schmerzhafte Angelegenheit. Zum einen scheint Sony mit seiner Pro-Version nicht wirklich professionelle Kunden zu adressieren, zum anderen scheint Sony(-creative) kein übermäßiges Interesse an Formaten der Konkurrenz zu haben.
Eine Lösung stellt das Plugin "Raylight Ultra" des Herstellers DVFilm (siehe http://www.dvfilmstore.com/raylight-ultra.html) dar. Die aktuelle Betaversion 1.2 (siehe http://dvfilm.com/update/updateBeta.htm) unterstützt AVC-Intra und soll auch 4:2:2 Material verarbeiten können. Ich habe diese Betaversion mal auf Sony Vegas Pro 9.0c getestet und komme zu folgendem Ergebnis:
- Die Installation Raylight Ultra 1.2 ist aktuell nur bei Vegas Pro in der 32bit-Version möglich.
- Nach der Installation kommt ein Konfigurationsdialog, in dem man verschiedene Optionen zur Verarbeitung von P2-Material auswählen kann. Man sollte auf jeden Fall
-- das Default System auf 50i/50p setzen.
-- alle 4 Audio-Tracks importieren, wenn man eine Kamera hat, die 4 Tracks aufzeichnet.
-- Slate auf "None" stellen, da sonst das erste Frame jedes Clips eine Zusammenfassung der P2-Metadaten enthält. Das kann ganz schön störend sein.
Dummerweise muss man immer wieder den "Output Folder" aufs Neue setzen, da diese Einstellung scheinbar verloren geht und sich sonst der Konfigurationsdialog nicht schließen lässt.
Nach dem Start von Vegas Pro kann man per Drag & Drop oder Datei/Importieren/Medien oder im Explorer-Fenster einfach Video MXF-Dateien den Projektmedien oder der Timeline hinzufügen.
Die Metadaten der P2-Clips werden weitestgehend übernommen und lassen sich in der Detailansicht der Projektmedien bzw. in den Eigenschaften der Clips korrekt anzeigen. Seltsamerweise sind 1080pn25 Clips als interlaced gekennzeichnet, jedoch bei 720p50 wird korrekt "progressiv" angezeigt.
Kommen wir nun zum praktischen Einsatz von P2-Material. Dazu haben wir einen Testdreh mit einer HPX301E gemacht und ca. 100 Clips angesammelt.
- Die Anzeige der Clips in den Projektmedien bzw. Auf der Timeline funktioniert schnell und flüssig.
- Allerdings lässt der Import so mancher AVC-Intra-Dateien das Raylight-Ultra-Plugin mit einem H.264-Dekoderfehler reproduzierbar abstürzen (siehe Bild anbei).
- Wenn man die Projektmedien auf die korrekt importierbaren reduziert, dann kann man einige Zeit störungsfrei arbeiten. Allerdings sollte man das Projekt häufig abspeichern, denn es kommt immer wieder zu unvorhersehbaren Abstürzen (siehe Bild anbei).
- Beim Öffnen eines Projekts, das schon P2-Clips enthält, kommt eine Meldung, dass in den Mediendateien nicht der korrekte Stream gefunden werden konnte. Diese Meldung kann man weg klicken und hat sonst auch keine Auswirkung.
- Das Rendern von Projekten in 32Bit (Full Range) mit AVC-100 Material ist selbst auf einem Quadcore-System langwierig. Ein Grund dafür ist der vom Raylight Ultra Plugin verwendete H.264-Dekoder. Hier wird der vom Heinrich Hertz Institut als Open Source veröffentlichte Dekoder "ldecod" in der Version 15.1 eingesetzt (weitere Informationen: http://iphome.hhi.de/suehring/tml/index.htm). Dieser Dekoder ist nicht für bestimmte Hardwarearchitekturen optimiert und daher ziemlich träge (ca. 150ms pro Frame!).
Das im Lieferumfang des Plugins befindliche Transkodierprogramm Raylight P2 Maker, funktioniert aktuell noch nicht mit Dateien im AVC-Intra-Format.
Fazit: Das Raylight Ultra Plugin ist in der Betaversion auf dem richtigen Weg eine wichtige Lücke im Sony Vegas Pro NLE zu schließen. Allerdings steht den Entwicklern noch einige Arbeit bevor, um die nötige Stabilität und Kompatibilität zu erreichen. Gleichzeitig sollte Sonycreative dringend an der nativen Unterstützung von P2-Material arbeiten, um im Profibereich kompromisslos ernst genommen zu werden.
Marco hat geschrieben:Ich kann das mit XDCAM-Material nicht reproduzieren (getestet mit XDCAM HD und XDCAM EX 1920x1080p25). Das wird korrekt als 25p interpretiert.
Ja, du hast absolut Recht! Ich habe mich da geirrt - habe gerade mit XDCAM EX-Material getestet und konnte nachvollziehen, dass bei 1080p25 korrekt "progressiv" angezeigt wird. Auch Panasonic speichert AVC-Intra bei 1080pn25 tatsächlich als progessiv:
1080p25:
Stream Type : Profile ID Profile @ Level 41
Video Type : Component
Video Format : YUV422
Aspect Ratio : 1:1(square)
POC Type : 0
Timing Type : Fixed
MaxFPS : 50
HRD Type : Not Present
Bit Rate : Not Present
CPB Size : Not Present
DPB Size : 4
Max Ref Frames Num : 0
Picture No : 3
Picture Order Count : 0
Decoding No : 3
Picture Type : Frame
Nr. Slices : 10
Data Partition : Off
--------------------------------------------------------
PSNR : No ref yuv file
--------------------------------------------------------
Picture Size : 1920x1088
- Cropping Left : 0
- Cropping Right : 0
- Cropping Top : 0
- Cropping Bottom : 8
Encoding Type : CAVLC
--------------------------------------------------------
Tools available in this picture:
I Slices, Intra Prediction, CAVLC, 8x8 Transform,
Quantization Scaling Matrices, Seperate Cb/Cr QP Control,
Zum Vergleich 720p50:
Stream Type : Profile ID Profile @ Level 41
Video Type : Component
Video Format : YUV422
Aspect Ratio : 1:1(square)
POC Type : 0
Timing Type : Fixed
MaxFPS : 100
HRD Type : Not Present
Bit Rate : Not Present
CPB Size : Not Present
DPB Size : 9
Max Ref Frames Num : 0
Picture No : 9
Picture Order Count : 0
Decoding No : 9
Picture Type : Frame
Nr. Slices : 10
Data Partition : Off
--------------------------------------------------------
PSNR : No ref yuv file
--------------------------------------------------------
Picture Size : 1280x720
Encoding Type : CAVLC
--------------------------------------------------------
Tools available in this picture:
I Slices, Intra Prediction, CAVLC, 8x8 Transform,
Quantization Scaling Matrices, Seperate Cb/Cr QP Control,
Ich habe meinen Text korrigiert. Danke für den Hinweis!
Zunächst vielen Dank für den Test. Sehr aufschlussreich. Ich weiss schon, warum wir uns gleich für ein professionelles Schnittsystem entschieden haben, denn auch Apples FCP ist ja alles andere als professionell.
Hast Du eigentlich in 10 Bit arbeiten können, sind also alle Komponenten durchgängig 10-bit fähig gewesen ? Könnte darauf die Einschränkung in Bezug auf das Thempo zurück zu führen sein oder kann es, Deiner Einschätzung nach, eher die unangepasste Architektur der Software sein.
Zum Thema Black Dots gibt es vermutlich aus Deiner Sicht keine neuen Erkenntnisse ?
Beste Grüße aus der Sonne zum Jahreswechsel.
Quantel iQ.
Damals gab es nicht viel Auswahl und ich hatte damals schon befürchtet, dass sich die NLE (und PC) Welt wohl schwer damit tun werden, sich auf Neuerungen einzustellen.
Dafür haben wir jetzt ein homogenen Archiv, was das Format betrifft und ich denke auch, es wird noch ein ganze Weile reichen.
Formatumstellungen sind immer sehr lästig (wie man auch an den Schnittprogrammen jetzt wieder sieht.)
Beste Grüße zur Jahreswende.
Nein, natürlich nicht, da bin ich mit Dir völlig einig, und die Klientel ist auch klar der kommerzielle Anwender.
Nur sollte man auch bei den 560 EUR Programmen überlegen, ob man die Bezeichnung "professional" nicht einwenig verbiegt, wenn die Teile nicht mal annähernd so arbeiten, wie das richtige Programme (und Hardware) tun ud wie das "Professionelle" erwarten.
Wie gesagt, wir hatten damals gar kein Auswahl und heute bin ich froh, dass wir nicht mit der Entscheidung gewartet haben, bis die semi-professionellen Programme irgendwann einmal nachrücken.
Das wäre ein schlimmes Debakel geworden.
WoWu hat geschrieben:Hast Du eigentlich in 10 Bit arbeiten können, sind also alle Komponenten durchgängig 10-bit fähig gewesen? Könnte darauf die Einschränkung in Bezug auf das Tempo zurück zu führen sein oder kann es, Deiner Einschätzung nach, eher die unangepasste Architektur der Software sein.
Um diese Frage beantworten zu können, musste ich erst mal herausfinden, ob die Vegas Projekteinstellung für 8bit oder 32bit Fließkomma sich nur auf die lokal berechneten Effekte oder auch auf die importierten Daten bezieht. Es hat sich gezeigt, dass tatsächlich 10Bit importiert und verarbeitet werden. So bleibt bei einem Export in eine YUV-AVI-Datei tatsächlich der Wertebereich erhalten. Die Renderingzeiten verhalten sich folgendermaßen:
Rendering von 161 Frames (6:11) nach AVI unkomprimiert auf Q9550, Windows 7, Sony Vegas 9.0c (32bit):
Fazit: Solange man keine Effekte anwendet (diesen Fall habe ich nicht getestet), kann man problemlos mit 32bit Fließkomma arbeiten.
Anmerkung: Das Rendern von P2-Material nach "Sony YUV-Codec" oder "Sony 10-bit YUV-Codec" führt zu buntem Rauschen (es wird angezeigt: "Keine Neukomprimierung erforderlich").
WoWu hat geschrieben:Zum Thema Black Dots gibt es vermutlich aus Deiner Sicht keine neuen Erkenntnisse ?
Die Black Dots sind da, aber in einem sehr erträglichen Maß - zumindest bei unserem Exemplar. Man kann sie zum Teil über einige Einzelbilder des Rohmaterials hinweg gut erkennen und wie mir scheint sind sie nicht wirklich stark vom Gain abhängig. Was auch auffällt, ist eine Abhängigkeit vom Bildinhalt. Bilddetails sind für die Bildung der Dots förderlich, während Farb(verlaufs)flächen ziemlich frei von Dots sind. Meine Vermutung geht da in Richtung Signalverarbeitung, denn der Sensor selbst dürfte weder eine Abhängigkeit vom Kontrast zeigen, noch ein solches Pixel über mehrere Frames hinweg an bzw. ausschalten. Mir scheint da ist irgendein Algorithmus verantwortlich, der eine partielle Aggregation von statischen Bildarealen über mehrere Frames hinweg zur Rauschunterdrückung nutzt. Die Dots kommen auch nicht vom AVC-I Codec, denn man kann sie auch gut via HD-SDI capturen.
Einen kleinen Erfolg habe ich noch zu vermelden: Ich kann Shell-Skripte und selbst kompilierte SH4-Executables von der SD Karte bei laufender Kamera ausführen. Als nächstes versuche ich via Telnet einzuloggen, indem ich die Kamera über einen USB-Ethernet-Adapter mit dem Netzwerk verbinde.
WoWu hat geschrieben:Beste Grüße aus der Sonne zum Jahreswechsel.
Dir auch - aus dem kalten und mittlerweile wieder verschneiten München!
"Das Rendern von P2-Material nach "Sony YUV-Codec" oder "Sony 10-bit YUV-Codec" führt zu buntem Rauschen (es wird angezeigt: "Keine Neukomprimierung erforderlich")."
Welches Material war das? AVC-I mit dem Raylight-Ultra Beta-Plugin? Oder DVCProHD?
Marco hat geschrieben:Welches Material war das? AVC-I mit dem Raylight-Ultra Beta-Plugin? Oder DVCProHD?
Wie im selben Post oben geschrieben AVC-I 100 (also 10bit in 4:2:2). Bei DVCPRO-HD wären es keine 10bit.
ABER: Ich hab's gerade mit einem Clip im Format DV100_720/50p und einem entsprechenden Projekt getestet. Gleiches Ergebnis: Sobald "Keine Neukomprimierung erforderlich" da steht, ist das gerenderte Erbenis beim Sony YUV-Codec Schrott.
Ich kann den P2-Clips, die ich momentan zur Verfügung habe, erst gar kein Smartrendern entlocken. Überhaupt kann ich nur Sony YUV-Material wieder zu Sony YUV smartrendern (das ist dann allerdings fehlerfrei).
Kann's nicht sein, dass das an dem Beta-Plugin liegt?
Was ist, wenn du das Smartrendern in den Präferenzen deaktivierst?
Marco hat geschrieben:Ich kann den P2-Clips, die ich momentan zur Verfügung habe, erst gar kein Smartrendern entlocken. Überhaupt kann ich nur Sony YUV-Material wieder zu Sony YUV smartrendern (das ist dann allerdings fehlerfrei).
Kann's nicht sein, dass das an dem Beta-Plugin liegt?
Ja, das liegt ganz bestimmt daran, denn in der 1.1er Version klappt es zuverlässig nach Sony YUV zu rendern. Dort schaffe ich es auch nicht P2-Material ohne Neukodierung auszugeben. Im Prinzip wäre dafür wohl in den Raylight Settings der Punkt "Supress Recomp" zuständig, aber der scheint bei 1.1 nie und bei 1.2 fast immer aktiviert zu sein.
Marco hat geschrieben:Was ist, wenn du das Smartrendern in den Präferenzen deaktivierst?
Nein, das macht leider keinen Unterschied - der Punkt bezieht sich ja nur auf Long-GOP-Formate.
Dann habe ich gleich noch einen Bug gefunden, der auch schon in der 1.1er Version vorhanden ist: Versuch mal nach P2 MXF zu rendern - das führt sofort zu einem Absturz von Vegas.
Nach meiner Ansicht hat das Raylight Plugin bestenfalls Amateurqualität und genügt auf keinem Fall professionellen Ansprüchen. Für so eine Software $195 zu verlangen ist schon fragwürdig, wenn man bedenkt, dass Sony Vegas Pro auch nur gute $500 kostet. Ich bin fast versucht eine kostenlose Opensource Lösung zu programmieren, um zu zeigen, dass man sowas auch richtig machen kann.
Zurück zur HPX301E. Falls sich jemand für die FBC (Flash Band Compensation)-Funktion interessiert, habe ich unter ein anschauliches Beispiel hochgeladen.
Die FBC-Funktion soll die durch den Rolling Shutter entstehenden hellen Streifen beim Filmen von Blitzlicht beseitigen.
Deti
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Rechtliche Notiz: Wir übernehmen keine Verantwortung für den Inhalt der Beiträge
und behalten uns das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
