slashCAM hat geschrieben:Wohlgemerkt haben wir für diesen Test versucht mit einem stark verrauschten, unterbelichteten Motiv die Artefakte bewusst zu provozieren, jedoch zeigt das Ergebnis ebenso deutlich, dass der H.264-Encoder der GH5 signifikant mehr Reserven bereithält als die HEVC-Encodierung. Bei weniger Rauschen könnte dies eventuell noch einmal anders aussehen, jedoch haben wir dies bislang nicht näher untersucht.
Eigentlich ist es ja genau umgekehrt, Luma wird aus aus den interpolierten Farbwerten gewonnen (also auch aus Grün, wenns denn da ist).Zitat Slashcam hat geschrieben:Da jedoch ein großer Teil des Grüns aus dem Luma-Signal gewonnen wird, das ja sowieso für alle 4 Pixel gespeichert wird, hält sich selbst für Grüntöne der zusätzliche “Farb-Differenzierungsgewinn” in Grenzen.
Gedankenspiel: Nimm 2 x 2 Bayer Sensel:dienstag_01 hat geschrieben: ↑Mi 18 Okt, 2017 11:42
Eigentlich ist es ja genau umgekehrt, Luma wird aus aus den interpolierten Farbwerten gewonnen (also auch aus Grün, wenns denn da ist).
Sensor/Debayering (RGB) -> Übertragung (YUV).
das ist doch quatsch!
Das hat zwar mit meinem Einwand gar nicht zu tun, weil du hier wieder das Pferd von hinten aufzäumst, denn Grün wird vom Sensor aufgenommen und dann erst gewandelt. Du beziehst dich immer auf die *Rückwandlung*. Bzw. manchmal sprecht ihr von *Aufzeichnung* und dann im nächsten Satz von *gewonnenem* Grün. Heilloses Durcheinander. Darüber hinaus zeigt ein Blick auf die Formeln der Color Conversion klar und deutlich die Anteile von Cb und Cr im Grün. Man sollte also nie von *ortsgenau* sprechen, wenn von Bayernsensor und YUV (eigentlich YCbCr) mit Color Subsampling gesprochen wird. Ist alles interpoliert.Rudi hat geschrieben:Grün wird praktisch nur in den Y Werten gespeichert und kaum bis gar nicht in der Farbdifferenz UV .
Sorry, ich will keine Verwirrung stiften und bin auch immer gerne bereit noch was dazu zu lernen. Die Verwirrung kommt wohl daher, dass es tatsächlich zwei Wandlungen sind (RGGB nach YUV und von da wieder zur Anzeige nach RGB).dienstag_01 hat geschrieben: ↑Mi 18 Okt, 2017 13:03Das hat zwar mit meinem Einwand gar nicht zu tun, weil du hier wieder das Pferd von hinten aufzäumst, denn Grün wird vom Sensor aufgenommen und dann erst gewandelt. Du beziehst dich immer auf die *Rückwandlung*. Bzw. manchmal sprecht ihr von *Aufzeichnung* und dann im nächsten Satz von *gewonnenem* Grün. Heilloses Durcheinander. Darüber hinaus zeigt ein Blick auf die Formeln der Color Conversion klar und deutlich die Anteile von Cb und Cr im Grün. Man sollte also nie von *ortsgenau* sprechen, wenn von Bayernsensor und YUV (eigentlich YCbCr) mit Color Subsampling gesprochen wird. Ist alles interpoliert.Rudi hat geschrieben:Grün wird praktisch nur in den Y Werten gespeichert und kaum bis gar nicht in der Farbdifferenz UV .
Ich denke schon.rudi hat geschrieben: ↑Mi 18 Okt, 2017 13:22Sorry, ich will keine Verwirrung stiften und bin auch immer gerne bereit noch was dazu zu lernen. Die Verwirrung kommt wohl daher, dass es tatsächlich zwei Wandlungen sind (RGGB nach YUV und von da wieder zur Anzeige nach RGB).dienstag_01 hat geschrieben: ↑Mi 18 Okt, 2017 13:03
Das hat zwar mit meinem Einwand gar nicht zu tun, weil du hier wieder das Pferd von hinten aufzäumst, denn Grün wird vom Sensor aufgenommen und dann erst gewandelt. Du beziehst dich immer auf die *Rückwandlung*. Bzw. manchmal sprecht ihr von *Aufzeichnung* und dann im nächsten Satz von *gewonnenem* Grün. Heilloses Durcheinander. Darüber hinaus zeigt ein Blick auf die Formeln der Color Conversion klar und deutlich die Anteile von Cb und Cr im Grün. Man sollte also nie von *ortsgenau* sprechen, wenn von Bayernsensor und YUV (eigentlich YCbCr) mit Color Subsampling gesprochen wird. Ist alles interpoliert.
Meine These ist, dass von RGGB nach YUV das meiste Grün in Y landet und kaum in UV, drum ist eine reduzierte UV Speicherung für Grün nicht sonderlich relevant.
Und ob man die Differenz von rot und blau zweimal speichert oder einmal sollte keinen großen Unterschied machen, da diese beiden Farben bei einem 1:1 Sensor Readout nur einmal gesamplet wurden.
Habe ich da einen Denkfehler?
Ich denke genau das ist der Punkt, an dem wir uns nicht einig sind. Hier steht jetzt Gedankenspiel gegen Annahme ;)dienstag_01 hat geschrieben: ↑Mi 18 Okt, 2017 13:31
Edit: der letzte Satz geht auch von einem Gedankenexperiment aus: Wenn ich nur einen Farbanteil aufnehme, den dann mit anderen Farbanteilen zur Gesamtfarbe interpoliere, muss danach dieser Farbanteil nicht mehr genau dem aufgenommenen Farbanteil entsprechen. Ist eine Annahme, ok.
so ganz einfach und trivial wird die interpolation heute beim debayern praktisch nie mehr gehandhabt.rudi hat geschrieben: ↑Mi 18 Okt, 2017 14:06 Ich habe mal vor langer etwas in dieser Richtung gearbeitet (programmmiert) und damals galt noch ein Grund-Credo: Es macht keinen Sinn schon eine Interpolation zu speichern, die man auch nachträglich beim Entpacken machen kann. Sprich: Wann immer du ein genaues Sample speichern kannst zieh das einer Interpolation vor, denn die Interpolation kannst du immer später, und meistens sogar cleverer machen.
Ich glaube, die 14bit betreffen nicht das Bild nach dem Processing, sondern die Ausgabe des A/D Konverters. Das ist ein Unterschied.Paralkar hat geschrieben: ↑Mi 18 Okt, 2017 14:26 Sorry aber Dienstag hat doch vollkommen recht, du hast ein Bayersensor der dir erstmal n 14 bit RGB aus dem Debayering rausschmeißt und das ganze dann brutal runterzwängt in ein 420 oder 422 oder sonst was. Die Farbwerte die dank des Debayerings zusammen interpoliert werden sind schon soviel differenzierter als RGGB des Bayernpatterns, dass dieses Beispiel mit dem 422 is bei 1:1 Readout kaum noch sinnvoll, garkein Sinn macht.
auch das ist in der praxis wieder ein bisserl komplizierter als man es auf den ersten blick vermuten würde, weil hier auch noch rundungsfehler bzw. die konsequenzen verschiedener wertedarstellungen bei der umsetztung der entsprechenden algorithmen sehr sauber berücksichtigt werden müssen.dienstag_01 hat geschrieben: ↑Mi 18 Okt, 2017 14:37 Ich glaube, die 14bit betreffen nicht das Bild nach dem Processing, sondern die Ausgabe des A/D Konverters. Das ist ein Unterschied.
Sehr spannend! Schade, dass das RAW-File überall offline ist, hätte mir das gerne mal angeschaut :)mash_gh4 hat geschrieben: ↑Mi 18 Okt, 2017 14:34 interessant ist speziell diese seite:
http://www.ruevski.com/rawhistogram/40D ... facts.html
ja -- leider! -- ich hab dieses file leider auch niergends mehr finden können...CameraRick hat geschrieben: ↑Do 19 Okt, 2017 09:09 Sehr spannend! Schade, dass das RAW-File überall offline ist, hätte mir das gerne mal angeschaut :)
Moin Wolfgang,WoWu hat geschrieben: ↑Fr 20 Okt, 2017 00:05 „jedoch zeigt das Ergebnis ebenso deutlich, dass der H.264-Encoder der GH5 signifikant mehr Reserven bereithält als die HEVC-Encodierung. Bei weniger Rauschen könnte dies eventuell noch einmal anders aussehen, jedoch haben wir dies bislang nicht näher untersucht.“
Warum ziehen sich eigentlich immer wieder so platte Behauptungen durch die Artikel.
HEVC gibt es bis „verlustfrei“ und damit bitgenau zu den Quellbildern.
Wenn also irgendwelche Artefakte sichtbar werden, liegt das nicht am Codec, sondern daran, dass der Anwender für den Content das falsche Profile/Level gewählt hat.
Auch in der Auswahl des Codecs bestehen Contentspezifische Schwerpunkte, die es zu kennen und zu beachten gibt.
Es geht ja auch niemand in ein Geschäft und verlangt irgend ein paar Schuhe und beschwert sich hinterher, dass sie drücken.
Wer mit Codecs umgeht, sollte sie einigermaßen kennen und nicht einfach seine Fehler auf den Codec schieben.
Kann sein, dass sie dich nerven, aber die Wirklichkeit ist, (wie ich weiter oben im Zusammenhang mit HEVC als Akquisitionscodec schrieb), dass man ihn auf der Pro-Seite gar nicht findet (RED & Konsorten) und auf der Consumer-Seite eben mit dem einzigen Ziel, Datenraten weiter zu drosseln, anstatt Qualität zu erhöhen, wozu der Codec selbst wohl in der Lage wäre.
Theoretisch erhöht HEVC die Qualität - nur leisten die Consumerprodukte aktuell "Entwicklungshilfe". Morgen wird HEVC oder was ganz anderes da stehen wo heute noch vereinzelt MPEG-2 bzw. H.264 ist.Axel hat geschrieben: ↑Fr 20 Okt, 2017 14:25 Kann sein, dass sie dich nerven, aber die Wirklichkeit ist, (wie ich weiter oben im Zusammenhang mit HEVC als Akquisitionscodec schrieb), dass man ihn auf der Pro-Seite gar nicht findet (RED & Konsorten) und auf der Consumer-Seite eben mit dem einzigen Ziel, Datenraten weiter zu drosseln, anstatt Qualität zu erhöhen, wozu der Codec selbst wohl in der Lage wäre.
Ich ertappe mich selbst dabei, Auflösung für ein Kriterium zu halten, was ich früher eher spöttisch sah. Der Trend zu größeren Sichtgeräten ist unverkennbar, zumal bei mir. Mein nächster TV wird darüber hinaus ein HDR-Gerät sein. Der Kontrast von Dunkelgrau zu Hellgrau fällt mir langsam unangenehm in's Auge. Kluge Hersteller lassen in den Demofilmen für die Mediamärkte die üblichen kreischend bunten Papageien mit nächtlichen Timelapses abwechseln, neben denen das "Programm" auf den übrigen Bildschirmen flach und tot wirkt.Roland Schulz hat geschrieben: ↑Fr 20 Okt, 2017 14:27Ich stelle hier z.B. auch immer wieder fest, bei Dir ja auch, dass 4K/UHD von vielen gar nicht so unbedingt im Fokus steht. Klar, man kann auch in 2K riesen Geschichten erzählen und tolle Arbeit produzieren. Ich erkenne "für mich" aber dass 4K schon einen rasanten Vorteil liefert, ich mag sehr hochauflösende Bilder! Der Schritt von SD auf HD war sicherlich bedeutender als der von FHD zu UHD, trotzdem ist es das Stück mehr was mich wirklich begeistert - und ich hab ne Menge solcher gleichgesinnten Vögel um mich rum ;-)!
Hoffentlich mal in für mich bezahlbaren Kameras.
Red hatte sich zunächst gegen ProRes gesperrt, dann aber den Kundenwünschen nachgegeben. Hätte Red stattdessen eine HEVC basierte Lösung angeboten, wäre das Geschrei groß gewesen - selbst wenn sie besser gewesen wäre.
So schaut's - der Codec ist nicht für die schlechte Qualität verantwortlich, die Implementierung des Encoders zeigt Defizite.WoWu hat geschrieben: ↑Fr 20 Okt, 2017 14:33 Also nochmal in der Zusammenfassung.
Die GH5 macht in HEVC keine zufriedenstellend Bilder.
Nun ist es ziemlich egal, ob Panasonic „zu früh“ für die verfügbare Rechenleistung oder Bandbreite oder Speicherkapazität, solche Bilder macht, oder ob andere das gar nicht erst anbieten .. oder ob der Codec falsch eingesetzt wird ....es ist ziemlich egal, es liegt nicht am Codec.
Es liegt an der Kamera, dass sie das nicht kann.
Der Artikel schiebt das aber auf den Codec und verschleiert die realen Umstände.
Und auch solche Feststellungen wie „kein Aquisitionscodec“ sind ziemliche Quatsch.
Der Codec kann alles, bis hin zu lossless und wenn ihn Panasonic aus Bandbreitengründen so nicht einsetzen kann, liegt das auch nicht am Codec.
Von einer solchen Besprechung würde ich aber erwarten, dass Ross und Reiter nicht verwechselt werden.
Wie oben schon gesagt, nutzen die NX HEVC recht gut.Roland Schulz hat geschrieben: ↑Fr 20 Okt, 2017 15:58 Das sagt ÜBERHAUPT NICHTS aus - ein 200Mbps nVidia Stream sieht schlechter aus als ein 60Mbps Stream aus ner X70 oder x264!
Aber das ist genau das, was ich meine.iasi hat geschrieben: ↑Fr 20 Okt, 2017 15:30Red hatte sich zunächst gegen ProRes gesperrt, dann aber den Kundenwünschen nachgegeben. Hätte Red stattdessen eine HEVC basierte Lösung angeboten, wäre das Geschrei groß gewesen - selbst wenn sie besser gewesen wäre.
Samsung hatte HEVC sehr gut in ihren NX-Modellen implementiert und zumindest die Richtung vorgegeben. Schade, dass Samsung die Serie eingestellt hat - ein 10bit-Nachfolgemodell wäre sehr interessant gewesen.