GH-5K - Echte, interne 5K-Aufzeichnung mit der GH5

[slashCAM]

Die GH5 macht ihrem Namen alle Ehre und kann seit kurzem sogar intern 5K mit 10 Bit aufzeichnen. Kein Aprilscherz, aber offensichtlich wird die Funktion bisher von den meisten Anwendern schlichtweg übersehen. Und sie hat auch ihre Tücken...



Hier geht es zu Artikel auf den slashCAM Magazin-Seiten:
Praxistest: GH-5K - Echte, interne 5K-Aufzeichnung mit der GH5

[Axel]

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.

Wer auf HDR zumindest tendenziell hinarbeitet - und Log-Profile und dergleichen beinhalten das ja - wird immer auch Bildanteile mit schlechteren Signalen einfangen, andernfalls hätte das Bild ja keine nennenswerte Dynamik von Haus aus. Effizientere temporale Kompression macht dann aus einem schlechteren Signal - Rauschen - einen ins Auge springenden Artefakt: Blockartefakte in den Tiefen. HEVC ist schön, damit mehr Selfie-Videos aufs Smartphone passen, für die Anmutung von Qualitätsbildern ist es als Akquisitionscodec aber ein Siebenmeilenschritt in die falsche Richtung.

[dienstag_01]

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.

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

[rudi]

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

Gedankenspiel: Nimm 2 x 2 Bayer Sensel:

RG
GB

Und nun soll das in YUV gespeichert werden. Dann hast du 2 Y-Werte zu einem großen Teil aus den 2 Grünen Senseln gewonnen wurden und jeweils einen Luma Y-Wert aus dem roten Sensel und aus dem blauen Sensel.
Und dann speicherst du noch zusätzlich die zwei Farbdifferenzen B-Y und R-Y, das sind UV.

Grün wird praktisch nur in den Y Werten gespeichert und kaum bis gar nicht in der Farbdifferenz UV .

Ob man nun für die vier RGGB-Sensel zweimal UV oder nur einmal UV speichert, betrifft die Genauigkeit der Grüntöne gegenüber Rot oder Blau daher relativ wenig.

[mash_gh4]

HEVC ist schön, damit mehr Selfie-Videos aufs Smartphone passen, für die Anmutung von Qualitätsbildern ist es als Akquisitionscodec aber ein Siebenmeilenschritt in die falsche Richtung.

das ist doch quatsch!

schau dir einfach an, wie gut HEIF und BPG auch jenseits der temporalen kompression funktionieren.

unter den verlustbehafteten bildformaten bzw. eben auch all-intra-codecs erreicht man damit momentan mit abstand die beste bildqualität bei vorgegebener gleicher bandbreite/filegröße.

[dienstag_01]

Grün wird praktisch nur in den Y Werten gespeichert und kaum bis gar nicht in der Farbdifferenz UV .

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]

Grün wird praktisch nur in den Y Werten gespeichert und kaum bis gar nicht in der Farbdifferenz UV .

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.

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

[dienstag_01]

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.

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).
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 schon.
Zumindest verstehe ich dich so, dass mit RGGB die Sensordaten vor dem Debayering gemeint sind (auf diese Art verstehe ich jetzt auch dein ortsgenau). In YCbCr wird aber das RGB Bild erst nach dem internen Processing (inklusive Debayering) gewandelt, was heisst, der Grünwert (mal als Beispiel) des RGB Bildes (Pixels) ist ein anderer als der Grünwert des ausgelesenen (grünen) Sensorpixels.
So sehe ich das ;)

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.

Edit I: Thema Ortsgenau: Ich vergesse mal meine Annahme aus Edit, die vom Sensor aufgenommenen Daten finden sich entgegen meiner Annahme doch 1:1 im debayerten Pixel. Man bekommt also ein Bild (hier 4 Pixel) RGB RGB RGB RGB. Die fetten Werte wären dann die ausgelesenen (ortsgenauen). Also immer nur ein Farbwert pro Pixel. Als Gesamtwert aus allen drei Farben ist der Pixel aber interpoliert. Und erst dieser interpolierte Pixel wird nach YCbCr umgerechnet.

[rudi]

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.

Ich denke genau das ist der Punkt, an dem wir uns nicht einig sind. Hier steht jetzt Gedankenspiel gegen Annahme ;)
Ich muss leider bald weg, nicht wundern wenn ich dan nicht mehr antworte. Ein Anmerkung möchte ich dennoch in Rennen schicken:

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.

[dienstag_01]

Ich hatte nochmal was angefügt. Sorry, bissel konfus ;)

[mash_gh4]

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.

so ganz einfach und trivial wird die interpolation heute beim debayern praktisch nie mehr gehandhabt.

siehe:
https://en.wikipedia.org/wiki/Demosaicing#Algorithms
https://de.wikipedia.org/wiki/Demosaici ... _Artefakte
https://rawpedia.rawtherapee.com/Demosaicing#Method
https://pixinsight.com/doc/tools/Debaye ... #usage_002
https://photo.stackexchange.com/a/30952
https://www.informatik.hu-berlin.de/de/ ... o10_03.pdf

[Paralkar]

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.

[mash_gh4]

interessant ist speziell diese seite:

http://www.ruevski.com/rawhistogram/40D ... facts.html

wo man nur mit der maus über die paar aufgezählten demosaicing techniken fahren muss, um ziemlich deutlich vor augen geführt zu bekommen, welchen gravierenden unterschied es bereits macht, die beiden grün-werte innerhalb einer vierer-gruppe nicht einfach zusammenzuzufassen...

[dienstag_01]

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.

Ich glaube, die 14bit betreffen nicht das Bild nach dem Processing, sondern die Ausgabe des A/D Konverters. Das ist ein Unterschied.
Datendeduktion in der Kamera ist *lebensnotwendig* für Echtzeit ;)

[mash_gh4]

Ich glaube, die 14bit betreffen nicht das Bild nach dem Processing, sondern die Ausgabe des A/D Konverters. Das ist ein Unterschied.

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.

eine schöne darstellung zur richtigen/praktischen vorgehensweise gibt's hier:

https://ninedegreesbelow.com/photograph ... dcraw.html

[CameraRick]

interessant ist speziell diese seite:

http://www.ruevski.com/rawhistogram/40D ... facts.html

Sehr spannend! Schade, dass das RAW-File überall offline ist, hätte mir das gerne mal angeschaut :)

[mash_gh4]

Sehr spannend! Schade, dass das RAW-File überall offline ist, hätte mir das gerne mal angeschaut :)

ja -- leider! -- ich hab dieses file leider auch niergends mehr finden können...

das grundsätzliche problem kann man aber ohnehin sehr einfach reproduzieren, auch wenn es natürlich in der praxis meistens nicht ganz so schlimm in erscheinung tritt und spätestens nach den farbsubsamplen meist gar nicht mehr zu entdecken ist.

hier ein artifizielles testmuster im DNG format (unten auf der seite auch downloadbar), mit dem man sogar indirekt nachvollziehen kann, welche debayer techniken in verschiedenen programmen genutzt werden, die ansonsten nicht viel darüber verraten:

https://www.libraw.org/articles/bayer-moire.html

leider ist es halt ziemlich schwer, derartige testmuster einer kamera unterzujubeln, um herauszufinden, wie sie intern arbeitet. tatsache ist aber, dass die meisten geräte in diesem zusammenhang eher unbefriedigende bzw. schnell/einfach zu berechnende lösungen nutzen.

derartiges in den nachbearbeitungsprozess auf leistungsfähigen computern auszulagern, ist daher prinzipiell schon sehr vorteilhaft, trotzdem wird video-RAW leider auch dort nicht immer sehr vorbildlich aufbereitet.

[CameraRick]

Das ist ja schon mal was, vielen Dank :) Habe dem guten Mann mal eine Mail geschickt, vielleicht hat er das File ja noch auf seinem Computer.
Ich arbeite nun selbst aus div. Gründen nicht sooo viel mit RAW (und wenn dann meist die Formate, die man eh nicht in viele Programme hinein bekommt), dennoch ist es ja sehr spannend sich damit auseinander zu setzen :)

[WoWu]

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

[Roland Schulz]

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

Moin Wolfgang,
einleitend (Zitat) ist das erstmal so richtig weil niemand den Codec sondern den Encoder in Frage gestellt hat, das ist ein wichtiger Unterschied! Wenn ich mal so drüber nachdenke haben wir häufigst dieses Ergebnis wo z.B. auch der x264 Encoder dem x265 Encoder selbst bei gleicher Bitrate (zumindest bei höheren Bitraten) in der Bildqualität überlegen sein soll.

HEVC an sich leistet wie Du schreibst eine Qualität bis zur verlustfreien Reproduktion, dann aber mit entsprechender Bitrate die hier nicht in der Überschrift steht. In der Praxis "scheint" das bisher eher noch so auszusehen, dass die Implementierung der Theorie noch Potential hat, die Umsetzung von Software- wie Hardwareencodern noch hinterherhinkt, H.264 da schon qualitativ hochvertigere Derivate am Markt hat.

Dem Anwender würde ich am Ende am wenigsten die Schuld geben denn er kann bei gegebenen Komponenten nur das wählen was vorgesehen bzw. angeboten ist. Es liegt wie oben beschrieben auch nicht an "falschen" Profilen oder Leveln, weil wenn dem Anwender erzählt wird dass HEVC zwischen 30-50% effizienter als H.264 sein soll dann sollte man als Anwender davon ausgehen können, dass 70Mbps HEVC mindestens eine ähnliche Qualität liefert wie 100Mbps H.264. In der Praxis scheint das aktuell noch nicht immer erreicht zu werden.

Ich denke dass HEVC mit den derzeitigen Implementierungen maximal einen Vorteil bei geringeren Bitraten hat. H.264 war aber auch nicht von Tag 1 an perfekt.
Man entwickelt halt noch und das primär beim Consumer. In der Pro Class spielt H.265 derzeit eher noch keine wirkliche Rolle, auch eine EVA1 kommt weiterhin mit H.264 daher. Ich würde H.264 derzeit auch noch vorziehen weil NLEs und Prozessoren noch besser/performanter mit H.264 klar kommen, die Akzeptanz noch im Aufbau ist. Grass Valley z.B. springt erst mit EDIUS 9 voll auf den HEVC Zug, Intel baut seine HEVC Unterstützung in den Prozessoren weiter aus.

[WoWu]

Mag ja sein, aber dann müsste es heißen, dass Panasonic in der Kamera einen schlechten Encoder programmiert hat.
Schuld liegt also bei Panasonic und nicht beim Codec.
Als Tester sollte man dann andere Encodierwerte nehmen, um gute Bilder zu generieren und nicht die Werte auf ungeeignetem Werten stehen lassen.
Wenn keine andern Werte angeboten werden, ist das wieder Herstellersache und nicht die, des Codecs.

[Roland Schulz]

100%!! Das wollte ich ausdrücken. Der Codec selbst ist sicherlich "hochwertiger" als H.264, bietet mehr Funktionen und Definitionen um bei geringerer Datenrate die gleiche Qualität wie H.264 zu liefern. Nur ist es in der Praxis so, dass gerade HEVC bei der Encodierung sehr viel Rechenleistung erfordert, aufwändiger ist als H.264. Die Rechenleistung ist aber endlich, von daher müssen Kompromisse gefunden werden um in Echtzeit zu encodieren. Diese werden aber die Qualität wieder verschlechtern.

Es gab und gibt eigentlich schon immer große Differenzen in der Ausgabequalität von Encodern, x264 ist bekannt sehr gute Ergebnisse zu liefern, mit nVidia Grafikkarten hard-/softwareencodierte Dateien sind da nicht so sehr berühmt. Wenn man sich H.264/265 Material aus billigen CCTV Kameras ansieht ist das auch oftmals Schrott.
Ich würde aber selbst mit hohen Ansprüchen sagen, dass Intel ab dem Haswell, gesteigert mit dem Skylake eine recht gute Qualität bei sagen wir 4K/25p@100Mbps liefert, das auch in hervoragender Encodinggeschwindigkeit. Als das mal bei SandyBridge CPU´s mit QuickSync angefangen hat war´s alles noch Mist. Bei geringeren Bitraten gewinnt x264 gegen QuickSync aber noch immer.
An HEVC werden sich auch noch zahlreiche Entwickler messen denke ich.
Der Anwender kann i.d.R. zumindest in Camcordern heute maximal die Bitrate beeinflussen. Andere Settings sind fest eingestellt, da geht nix.

[WoWu]

Dann hätte der korrekte Schuss eigentlich sein müssen, dass die GH5 noch zu schwach an Rechenleistung ist, es mit einen zeitgemäßen Codec aufzunehmen.

Mich nerven solche Amateurtest ziemlich, weil sie nur selten die Wirklichkeit abbilden und den Vergleich zu Herstellern, die sich mit ihrer Hard-und Software viel Mühe geben, nur verzerren und den Verbraucher damit ziemlich hinter die Fichte führen, um nicht zu sagen „zu ver..schen“.

Im Übrigen wird auch immer weniger Rechenleistung abgefordert, je qualitativ besser das Encodinglevel wird.
Es ist oft nur eine Frage der Datendurchsatz Breite, die solchen Fotoapparaten fehlt.
An dieser Stelle unterscheiden sich nämlich Firmen, wie RED z.B., die technologie zeitgemäß, aber auch zum andern Preis anbieten, von solchen Billigprodukten, die versuchen, mit 5/6k (Marketing) zu punkten.
Solche Tests sollten gerade solche Unterschiede transparent machen und nicht mit falschen Aussagen verschleiern.

[Axel]

Dann hätte der korrekte Schuss eigentlich sein müssen, dass die GH5 noch zu schwach an Rechenleistung ist, es mit einen zeitgemäßen Codec aufzunehmen.

Mich nerven solche Amateurtest ziemlich, weil sie nur selten die Wirklichkeit abbilden ...

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.

[Roland Schulz]

Wir werden nie perfekte Produkte erhalten (auch nicht bei Porsche ;-) ), schon gar nicht als Consumer. Die GH5 kann ohne ne Frage ne Menge und legt die Meßlatte nicht nur bei der Specs auf dem Papier sehr hoch. Was die Specs dann wert sind sehen wir bei solchen Tests wie im Beispiel. Das Eingangsmaterial muss auch nicht zwingend wie im Test "versaut" werden, in diesem Fall stellen sich aber doch höhere Anforderungen an den hier abzuleuchtenden Encoder um Schwächen aufzuzeigen, welche in der Praxis nicht unbedingt jedem Steine in die Quere legen würde.

Ich 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 ;-)!

Zurück zur GH5: auch wenn ich eigentlich "mehr Sony bin" macht Panasonic hier nichts falsch. Panasonic bringt nach Samsung (das war vielleicht ZU früh und überzeugt und eingleisig) HEVC in den Kameramarkt, anfangs noch mit ein paar Krücken und etwas Husten, man verdient aber so Geld was man wieder in die Entwicklung zurückführen wird und HEVC am Ende H.264 ablösen wird. Ich bin froh dass Sony aktuell noch H.264 fährt und ich damit derzeit noch die einfachere, ausgereiftere Technik nutzen kann, aber ich bin davon überzeugt dass irgendwann nur noch HEVC da sein wird genau so wie MPEG-2 eigentlich nahezu verschwunden ist. "Brauchen" tut MPEG-2 heute eigentlich keiner mehr, wenn man ehrlich ist auch kein Sender!

[Roland Schulz]

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.

[WoWu]

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.

[Axel]

Ich 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 ;-)!

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.

Der Codec kann alles, bis hin zu lossless.

Hoffentlich mal in für mich bezahlbaren Kameras.

[WoWu]

Nachdem Apple ja nun zukünftig HEVC unterstützt dürfe sich der Prozess auch in Consumerkameras beschleunigen.
Vielleicht lösen sie dann ja auch endlich mal ihr antiquiertes ProRes gegen einen HEVC ab.

[iasi]

Nachdem Apple ja nun zukünftig HEVC unterstützt dürfe sich der Prozess auch in Consumerkameras beschleunigen.
Vielleicht lösen sie dann ja auch endlich mal ihr antiquiertes ProRes gegen einen HEVC ab.

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.

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.

[Roland Schulz]

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.

So schaut's - der Codec ist nicht für die schlechte Qualität verantwortlich, die Implementierung des Encoders zeigt Defizite.

Trotzdem kann man sich überlegen ob ein Codec von der Definition bzw. den zur "optimalen Aus-/Nutzung" notwendigen Funktionen so aufwändig sein kann, dass es unverhältnismäßig viel Aufwand bei der Entwicklung wie Rechenleistung erfordert, diesen "optimal" umzusetzen.
Gerade in kompakten Geräten, welche Echtzeitverarbeitung erfordern und durch Batteriebetrieb endliche Ressourcen zur Verfügung stellen kann sowas ungeeignet sein.
Die "schlechte Qualität" liegt trotzdem nicht am Codec.

[iasi]

An der Rechenleistung liegt's sicher nicht mehr. Schon die NX500 schaffte UHD mit 150MBit ... 8bit

[Roland Schulz]

Das sagt ÜBERHAUPT NICHTS aus - ein 200Mbps nVidia Stream sieht schlechter aus als ein 60Mbps Stream aus ner X70 oder x264!

[iasi]

Das sagt ÜBERHAUPT NICHTS aus - ein 200Mbps nVidia Stream sieht schlechter aus als ein 60Mbps Stream aus ner X70 oder x264!

Wie oben schon gesagt, nutzen die NX HEVC recht gut.
Die 150 statt 80 bekommt man durch einen "hack" mit durchaus sichtbaren Verbesserungen ... Dass die kleine NX500 diese Datenrate wegschreiben kann, ist nicht ohne. Dabei ist sie auch schon älter.

[WoWu]

Nachdem Apple ja nun zukünftig HEVC unterstützt dürfe sich der Prozess auch in Consumerkameras beschleunigen.
Vielleicht lösen sie dann ja auch endlich mal ihr antiquiertes ProRes gegen einen HEVC ab.

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.

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.

Aber das ist genau das, was ich meine.
Irgendwelche User, gelenkt von solchen dämlichen Blockbeiträgen schreien laut genug, um Hersteller dazu zu bewegen.
Nun hat RED ja vernünftige Alternativlösungen, weil deren Entwicklung nicht aus einem Fotokompromiss bestehen muss.
Nur sollte eben bei solchen „Tests“ die Verdummung mittlerweile ein Ende gefunden und sich bis in die letzte Amateurecke herumgesprochen haben, was der Codec mittlerweile eigentlich kann.
Ebenso wie dieser Quatsch mit Distributions- oder Akquisitionscodec.
Solche Leute wissen einfach nicht, was der Codec beinhaltet, sonst würden sie so einen Mist nicht nachplappern.