Noch was unklar? Dann in unserem Forum nachfragen
Zum Original-Thread / Zum Adobe After Effects-Forum

Infoseite // Adobe + Prores files + 0-255 Bug?



Frage von -paleface-:


Hallo,
ich habe identisches Material welches einmal normal mit der Gh4 Aufgeommen wurde und einmal als Prores 4:2:2.
Aufgezeichnet intern sowie mit dem Shogun.
Luminanzwerte von 0-255

Wenn ich beides in AfterFX CC oder Premiere CC ziehe habe ich ein Problem.

Das Gh4 Material wird korrekt angezeigt.
Bei den ProResfiles wird einfach auf 16-235 gekappt.

Dachte erst das es am Shogun liegt.
Aber ein Bekannter hat es nun bei Davinci reingeladen und ihm wird bei den Prores Files das komplette 0-255 angezeigt.

Arbeitsfarbraum ist Rec 709.

Weiß jemand woran das liegen kann?

Bug oder Einstellungssache?

VG

Space


Antwort von -paleface-:

Hier noch ein Beispiel.
Rechts Prores

Space


Antwort von CameraRick:

Auf was haste Deinen Farbraum gestellt, 8 16 oder 32bit?
Was ist im Color Management Tab eingetragen?

Sonst wirf mal den Color Profile Converter auf das Material und stell den Input auf REC709 (Rest auf Default) bzw den Output auf REC709 (Rest auf Default)

Space


Antwort von CameraRick:

Wenn Du kannst, lad mal einen Schnipsel rohes Material hoch (einfach eine Sec getrimmt mit Quicktime zB, ohne neu zu enkodieren)

Space


Antwort von dienstag_01:

http://wolfcrow.com/blog/what-is-full-s ... -part-one/

;)

Space


Antwort von -paleface-:

Hier gibts die Raw files

https://www.wetransfer.com/downloads/ac ... 618/f90aea

Auf Maximale Bildtiefe umschalten hat nix gebracht.

Space


Antwort von WoWu:

ProRes unterhalb von 4:4:4:4 kann nur 709 und das v_f_r in Deinem Content steht auch auf "0".
AE liest das flag also richtig aus. === VUI ===
aspect_ratio_info_present_flag : 1
aspect_ratio_idc : 1
sar_width : 0
sar_height : 0
overscan_info_present_flag : 0
overscan_appropriate_flag : 0
video_signal_type_present_flag : 0
video_signal_type_present_flag : 0
video_format : 0
video_full_range_flag : 0
colour_description_present_flag : 0
colour_primaries : 0
transfer_characteristics : 0
matrix_coefficients : 0
chroma_loc_info_present_flag : 0


Space


Antwort von -paleface-:

Hmm...
Aber warum zeigt es Davinci angeblich korrekt an?

Space


Antwort von -paleface-:

Hier noch 2 Files

Gh4 jeweils rechts, prores links

Space



Space


Antwort von dienstag_01:

Wenn du in einem 32bit Projekt arbeitest, kannst du dir die Werte oberhalb und unterhalb der Legal Range auf jeden Fall mit der Farbkorrektur wieder *reinholen*. In 8 und 16bit nicht.

Space


Antwort von -paleface-:

Scheint bei Adobe nicht zu gehen.

Ich mache ein 32Bit Projekt in AfterFX.
Dann importiere ich das Prores File.
Ich lege eine Kurve drauf, ziehe den oberen Regler etwas nach unten.
Keine Information, es wird nur alles grauer.

Space


Antwort von dienstag_01:

Nimm mal Levels und schränke den Bereich des Balkens der von Weiss nach Schwarz geht (o. umgekehrt) etwas ein.

Edit: Ok, hab es gerade mit deinem Material getestet, funktioniert nicht.
Edit I: Das wiederum könnte am Codec oder an Quicktime liegen. Mit einem h264 File funktioniert es bei mir.

Space


Antwort von -paleface-:

Ich frag mich ja ein wenig ob der Shogun überhaupt mit 0-255 aufzeichnet.
Hab ein wenig die Befürchtung es sind nur die 16-235.

Das wäre aber meiner Meinung katastrophal.
Mein bekannter sagt das wenn er es in Davinci zieht, beides gleich aussieht von der Luma-Range.
daher schöpfe ich noch Hoffnung das es woanders dran liegt.

WoWu sagt das bei Prores gar kein 0-255 gibt, jedenfalls nicht bei 4:2:2 Material.

Das befürchte ich auch.

Space


Antwort von dienstag_01:

WoWu sagt das bei Prores gar kein 0-255 gibt, jedenfalls nicht bei 4:2:2 Material. Die beiden Bilder von dir sprechen aber eine deutlich andere Sprache.
Ich frag mich ja ein wenig ob der Shogun überhaupt mit 0-255 aufzeichnet.
Hab ein wenig die Befürchtung es sind nur die 16-235.

Das wäre aber meiner Meinung katastrophal.

Solange du vorhast, mit Adobe Produkten zu arbeiten, ist eher 0-255 die Katastrophe ;)

Space


Antwort von -paleface-:

Nimm mal Levels und schränke den Bereich des Balkens der von Weiss nach Schwarz geht (o. umgekehrt) etwas ein.

Edit: Ok, hab es gerade mit deinem Material getestet, funktioniert nicht.
Edit I: Das wiederum könnte am Codec oder an Quicktime liegen. Mit einem h264 File funktioniert es bei mir. Hast du mein File umcodiert oder was eigenes genommen?

Space


Antwort von -paleface-:

Solange du vorhast, mit Adobe Produkten zu arbeiten, ist eher 0-255 die Katastrophe ;) Warum?
Bei dem Gh4 internen Material ist doch alles in Ordnung.

Space


Antwort von dienstag_01:

Was eigenes.

Space


Antwort von CameraRick:

Warum schaust du nicht mal in den DaVinci? Kost doch nüscht.

Ich schau mir das morgen mal auf der arbeit an.

Space



Space


Antwort von -paleface-:

Warum schaust du nicht mal in den DaVinci? Kost doch nüscht.

Ich schau mir das morgen mal auf der arbeit an. Gott klingt das logisch!! :-D

Mach ich jetzt....hast Recht!

Space


Antwort von dienstag_01:

Beim Import in den Avid (Wandlung nach DNxHD in einem HD Projekt) verhalten sich die beiden Streams unterschiedlich.

Space


Antwort von -paleface-:

Beim Import in den Avid (Wandlung nach DNxHD in einem HD Projekt) verhalten sich die beiden Streams unterschiedlich. So siehts auch in Speedgrade aus.

Space


Antwort von dienstag_01:

Der interne Stream hat das Full_Frame_Flag gesetzt, der externe nach Wowu ja wohl nicht.

Vielleicht kann ja der Shogun über die Schnittstelle nicht mit 0-255 umgehen. Zumindest sieht man deutlich das Clippen.

Edit: Auf jeden Fall sollte man Überbelichtung bei 0-255 strikt vermeiden, da ist nun definitiv oben und unten Schluss ;)

Space


Antwort von wolfgang:

Der Shogun zeichnet sehr wohl in 0..255 auf. Je nachdem was etwa in der GH4 eingestellt ist auch 16..235. Wie eine spezifische NLE das dekodiert ist eine Frage des Zusammenspiels aus Dekoder (etwa auch QT) und der NLE. In Edius wird es korrekt als 0..255 angezeigt. In Vegas wirds teilweise gespreizt. In Adobe - na siehe hier. Wer glaubt dass Superweiss nur bei ProRes vorhanden sein kann - na der schaue sich AVCHD oder Profiformate wie XAVC an. Da ist längst alles möglich. Tragisch für einige.

Space


Antwort von WoWu:

Der interne Stream hat das Full_Frame_Flag gesetzt, der externe nach Wowu ja wohl nicht.

Vielleicht kann ja der Shogun über die Schnittstelle nicht mit 0-255 umgehen. Zumindest sieht man deutlich das Clippen.

Edit: Auf jeden Fall sollte man Überbelichtung bei 0-255 strikt vermeiden, da ist nun definitiv oben und unten Schluss ;) Das sieht so aus, als ob der einmal mit der falschen, oder der ignorierten Flag re-muxt worden ist.
Dann hast Du zwei Spreizungen da drin.

Space


Antwort von -paleface-:

Durch Davinci muss ich mich grad noch durchkämpfen.
Guck grad nebenbei die Basic Tutorials.

Lese mich auch etwas in andere Foren ein.

Zur Zeit klingt das für mich alles nach, wer mit dem Shogun aufnimmt sollte Adobe Produkte meiden.

Bisher habe ich jedenfalls keine Lösung für das Problem gefunden.

Space


Antwort von WoWu:

Kann sich mal einer die beiden Histogramme anschauen, ich hab auf dem Rechner nicht die Möglichkeit. --- ob eins die klassischen Lücken zeigt ?-

Space


Antwort von dienstag_01:

WoWu, ich verstehe nur Bahnhof.

Die Schwierigkeit hier besteht ja zusätzlich darin, dass das File total überbelichtet ist.

Space



Space


Antwort von WoWu:

Das sieht nur überbelichtet aus, weil bereits ein Clip "begrenzt" ist.
das Ding ist beim Re-Muxen vermutlich schon mal gegen den "Poller" gefahren.
Wenn Du ein 709 zweimal auseinander ziehst, sieht das so ähnlich aus.
Aufschluss würden die fehlenden Werte im Histogramm geben.

Space


Antwort von wolfgang:

Was ist das für ein Rätselraten? Der Shogun hat einen Waveform Monitor, zeigt je nach Einstellung der GH4 16..235 oder auch 0..255 an. Und damit hat es sich auch schon was diese Hardware angeht. Der Rest ist Decoding und das ist bei QT/ProRes unter Windows und je nach NLE eine Sache für sich.

Space


Antwort von WoWu:

Nur wenn die GH4 709 aufgenommen hat und der Recorder Full range und das Flag von der Kamera ignoriert hat, dann hat man schon die erst Spreizung.
-Aber ist tatsächlich alles nur Mutmassung-
Nur liegen eben nicht identische Ergebnisse eines einzigen Events vor.

Space


Antwort von dienstag_01:

Aber sollte nicht auch beim internen File Luma bei 0 und nicht bei 16 liegen?

Space


Antwort von WoWu:

Ich denke nicht, dass die Kamera zwei separate Signale processed, eins für interne und eins für extern.
Das wird wohl dasselbe Mapping sein. (?)

Space


Antwort von dienstag_01:

Ich meine, wenn ich in 0-255 aufnehme (wie es hier gewesen sein soll), dann sollte doch Black bei Null sein, oder?

Space


Antwort von toxitobi:

Hallo Zusammen,

ich freue mich dass ihr so fleißig meine Couch bestaunt ;-)
Also von meinen Test mit der Gh4 weiß ich dass die Einstellung 0-255 oder 16-235 keinerlei Einfluss auf die interne GH4 Aufzeichnung nimmt, die ist immer 16-235.
Die Einstellungen ändern nur den Output per HDMI. Sehr gut sichtbar im Histogramm vom Shogun.
An der Stelle wäre es interressant zu wissen wie die Daten von der Internen 16-235 auf die externe 0-255 Breite umgerechnet werden, hoffentlich möglichst früh, wie ich das testen soll kA.
Der Shogun nimmt das Ganze auch korrekt auf so wie in der GH4 eingestellt. Dies alles -wie von paleface schon gesagt- überprüft mit Davinci Resolve. Da kann ich ganz einfach festlegen wie das Material interpretiert werden soll. Data oder Video level, bzw. Auto.
In AE zum Beispiel beim Export von .dpx kann ich den Luma Bereich festlegen, gibt es diese Einstellung etwa beim Import von Prores nicht?

Weiß jemand wie andere Kameras das handhaben?
Wie macht Arri das bei seiner Prores Implementierung?
BMD machts ja scheinbar bei allen Kameras 0-255

Grüße vom Tobi

Space


Antwort von dienstag_01:

Also von meinen Test mit der Gh4 weiß ich dass die Einstellung 0-255 oder 16-235 keinerlei Einfluss auf die interne GH4 Aufzeichnung nimmt, die ist immer 16-235. Interessant ist in diesem Zusammenhang aber, dass das Full_Range_Flag auf 1 steht. Allerdings auch bei Files meiner Canon :(
Was heisst das?

Space


Antwort von -paleface-:

So...ich bin nach dem gucken von ein paar Tutorials auch ein "mini davinci crack" ;-)

Also ich kann definitiv bestätigen das in Davinci die prores Files korrekt angezeigt werden.

In After FX und Premiere jedoch nicht.
Ich rufe morgen mal bei dem Supoort an.
Mal sehen was die sagen.

Space



Space


Antwort von CameraRick:

Oh man!
Hast Du überhaupt mal probiert, einen Color Profile Converter drauf zu legen, wie ich geschrieben hatte?

Ich hab das nämlich grad mal gemacht, und "auf ein mal" sehen die beiden Clips extrem ähnlich aus (natürlich nur wenn man in 32bit arbeitet). Der Difference deckt nicht 100%, aber das ist logisch (habe die beiden Clips jetzt nicht Frame-genau gematched, dazu der Unterschied der Codecs)
Output Profile steht auf "HDTV (Rec. 709) 16-235"

Space


Antwort von -paleface-:

Oh man!
Hast Du überhaupt mal probiert, einen Color Profile Converter drauf zu legen, wie ich geschrieben hatte?

Ich hab das nämlich grad mal gemacht, und "auf ein mal" sehen die beiden Clips extrem ähnlich aus (natürlich nur wenn man in 32bit arbeitet). Der Difference deckt nicht 100%, aber das ist logisch (habe die beiden Clips jetzt nicht Frame-genau gematched, dazu der Unterschied der Codecs)
Output Profile steht auf "HDTV (Rec. 709) 16-235" Sag mir doch bitte mal genau wie du vorgegangen bist.
Weil bei mir kommt nichts zum besseren.
Und wir wollen ja von dem 16-235 weg.

Space


Antwort von dienstag_01:

Genau, das ist komplett der falsche Weg, am Arbeitsfarbraum rumzudrehen. Damit bekommt man die Werte oberhalb 235 und unterhalb 16 auch nicht wieder hergestellt.

Space


Antwort von CameraRick:

Genau, das ist komplett der falsche Weg, am Arbeitsfarbraum rumzudrehen. Damit bekommt man die Werte oberhalb 235 und unterhalb 16 auch nicht wieder hergestellt. Der Arbeitsfarbraum wird ja nicht umgedreht, das Color Management in AE ist unverändert. Wir helfen in diesem Fall ledigilich der Datei ein wenig auf die Sprünge.
Ist echt blöd dass die Werte nicht zurück kommen, müssen se aber auch nicht weil die ja schon da sind. Das sind eben Werte über 1, wenn Du in 8 oder 16bit arbeitest wirst die nicht zurück bekommen. Siehe Screenshot, einmal mit und einem ohne Color Profile Converter (und einer satten Anpassung damit es auch jeder sieht)

Komm wir spielen ein Spiel, es heißt "finde das AVCHD"
Innerhalb dieses Screenshots ist ein Quader des originalen AVCHDs, der Rest ist konvertiertes Prores. Komm, weils ja nicht funktioniert und die Werte nicht zurück kommen, sag mir wo Du es sehen kannst.


@paleface
-Das Projekt auf 32bit stellen
-Color Profile Converter Effekt auf den Shogun Clip legen
-das Output Profile auf "HDTV (Rec. 709) 16-235" stellen

Einfacher kann ichs nicht mehr schreiben :(

Space


Antwort von -paleface-:


@paleface
-Das Projekt auf 32bit stellen
-Color Profile Converter Effekt auf den Shogun Clip legen
-das Output Profile auf "HDTV (Rec. 709) 16-235" stellen

Einfacher kann ichs nicht mehr schreiben :(
Bei mir kommt es so aber raus...ich sehe keine Struktur....
Projekt ist 32Bit

Space


Antwort von dienstag_01:

Ich glaube nicht, dass das so geht.
(Weiss es aber nicht genau)
Wenn man den Shogun Clip teilt und auf eine Hälfte den Effekt anwendet und auf den anderen nicht, dann sieht man, dass (besonders) Weiss nicht mehr richtig Weiss ist. Sollte aber, wenn es Clipped.
(rechts liegt der Effekt)

Space


Antwort von CameraRick:

CC2014, ist das nicht eine veraltete Version? Oder heißt die bei Dir nur so und ist die aktuelle 13er?

Wenn Du mit dem Cursor über die weißen Stellen gehst, welche Farbwerte werden Dir unter "Info" angezeigt?

Sonst häng mir mal Dein Projekt an.

Space


Antwort von CameraRick:

Ich glaube nicht, dass das so geht.
(Weiss es aber nicht genau)
Wenn man den Shogun Clip teilt und auf eine Hälfte den Effekt anwendet und auf den anderen nicht, dann sieht man, dass (besonders) Weiss nicht mehr richtig Weiss ist. Sollte aber, wenn es Clipped.
(rechts liegt der Effekt) Wo nimmst Du denn die Scopes her? Im Color Finesse sieht das auf den ersten Blick richtig aus, habe leider keine anderen Scopes in AE. Da der Smoke hier gerade herum rührt will ich ungern einen Clip im AE rendern und wo anders inspizieren.

Space


Antwort von dienstag_01:

Der ist aus Color Finesse.

Space



Space


Antwort von -paleface-:

Warum das noch CC2014 heisst weiß ich nicht.
Aber ist definitiv die aktuelle Version.

Wenn ich das Shogun File in AfterFX ziehe hat der weiße Streifen eine Info von
RGB jeweils 1
Wenn ich den Konverter drauf packe 0,9216

Space


Antwort von CameraRick:

Kann ich nicht reproduzieren. Richtige Tests mit ColorFinesse gehen mir auch auf den Keks, so lahm wie das ist :p

Seid ihr sicher, dass ihr in 32bit arbeitet? Bzw keine anderen Umgänge drin habt, die das Signal clippen?

Space


Antwort von CameraRick:

Wenn ich das Shogun File in AfterFX ziehe hat der weiße Streifen eine Info von
RGB jeweils 1
Wenn ich den Konverter drauf packe 0,9216 Irgendwas clipped da bei Dir, ich kriege Werte über 1 raus; nicht groß, aber drüber (1,06 zB). Sowohl links bei dem, der noch Zeichnung hat, als auch rechts bei den anderen.

Dann kommen wir mal von der anderen Seite: welche Quicktime Version hast Du drauf? Nutzt Du Miraizon Codecs?

Space


Antwort von -paleface-:

Quicktime ist 7.6.5

Von Miraizon höre ich gerade zum ersten mal.

Space


Antwort von CameraRick:

Ich hänge Dir mal mein Projekt an, wo es normal funktioniert. Clippt es dort auch?


Hast Du die Prores Decoder-Komponente drauf? https://support.apple.com/kb/DL2?locale=de_DE

Langsam gehen mir hier die Ideen aus, für mich ist das ziemlich klar ein Software-Problem, aber keins vom Material.
Daheim hab ich auch einen Windows, da kann ich heut Abend nochmal schauen.

Space


Antwort von -paleface-:

So sieht es aus wenn ich dein File öffne und das Gh4 Material (links) daneben halte.

Also wie vorher auch.

Space


Antwort von -paleface-:

Hab gerade mit dem Support telefoniert.

Als ich aber von Luminanzwerten und 0-255 angefangen habe, hat er mich unterbrochen und gesagt das für sowas der Support nicht zuständig ist.

Ich soll mich ans Forum wenden und schauen ob da jemand Rat weiß.
Wäre wahrscheinlich nur eine Einstellungssache.

Space


Antwort von CameraRick:

Ok Wow, das ist natürlich krass, denn so ists bei mir ja offensichtlich nicht. Dann wird da wirklich irgendein Fehler sein, da dienstag den auch zu haben scheint ists ggf eine Windows-Sache (nutzt dienstag auch Windows?), die mit dem Prores beim Decoding Probleme hat. DaVinci nutzt sofern ich weiß gerne eigene Parameter etc, möglicherweise ist es deswegen dort kein Problem.
Hast Du denn die Decoding Komponente nun drauf, oder nicht? Wenn nicht, mal installieren und neustarten.

Schaue mir das heut Abend an.

Space


Antwort von dienstag_01:

Windows

Space



Space


Antwort von -paleface-:

Hmm...das wäre ja verrückt wenn es daran liegt.
Den decoder konnte ich gar nicht installieren.
Da stand ich hätte schon einen aktuellen drauf.

Space


Antwort von CameraRick:

Habs mir mal hier drauf gezogen, und was soll ich sagen: ist genau wie bei euch. Huh.
Ich bin mir recht sicher dass das was mit Quicktime zu tun haben wird (habe 7.7.6 drauf). Auf Mac ists eben leider kein Thema.

Tja sorry, da kann ich nicht helfen. Hat das Forum irgendwas abgeworfen?

Space


Antwort von -paleface-:

Krass....danke fürs checken.

Wenn muss man denn dann ans Bein pinkeln?

Apple, Microsoft oder Adobe?

In dem Forum von Adobe passiert nicht viel:

https://forums.adobe.com/thread/1854874 ... TiPxfFOKRg

Space


Antwort von CameraRick:

Microsoft hat damit wohl eher herrlich wenig zu tun, außer eben dass sie nicht Apple sind.

Ich glaub in dem Fall ists Apple, die die Quicktime Komponente nicht optimal durch ziehen (denn DaVinci scheint es ja richtig zu machen (hab ich nicht getestet))

"Also bei Davinci wird ja alles korrket angezeigt.
Ist nur bei Adobe so.

Daher liegt es nicht direkt am File."

Ist eher eine schwierige Aussage, der Flag den Mylenium da anspricht kann gut und gerne das sein, was Dir da den Strich durch die Rechnung macht. Das File, bzw seine Flags, würde ich da nicht unbedingt ausschließen.

Generell würde ich es auch eher im englischen Teil als im Deutschen versuchen, auch wenn Du mit Mylenium einen der Kompetentesten AEler am Zipfel hast

Space


Antwort von TheBubble:

Als ich aber von Luminanzwerten und 0-255 angefangen habe, hat er mich unterbrochen und gesagt das für sowas der Support nicht zuständig ist.

Ich soll mich ans Forum wenden und schauen ob da jemand Rat weiß. Hast Du angesprochen, ob Deine Frage nicht vielleicht in die Support-Hierarchie nach oben weitergeleitet werden kann?

Space


Antwort von -paleface-:

Nein.
Wusste nicht das es sowas gibt :-D

Aber da es ja offensichtlich ein Windows / Mac Problem ist,
werd ich da morgen nochmal anrufen und das konkret beschreiben können.

Vielleicht hab ich ja wen anders dran.

Space


Antwort von CameraRick:

Was mich viel mehr interessieren würde ist, wieso die Flag offenbar falsch gesetzt ist.
Hast Du mal Atomos zu dem Fall befragt? Immmerhin erstellt der Shogun die Datei, da sollte man annehmen der Hersteller weiß, was er da macht?

Im Zweifel mal über DNxHR nachgedacht?

Space


Antwort von dienstag_01:

Vielleicht ist das gar nicht *falsch*, soll vielmehr so sein (um mehr Werte zu erhalten). Würde mich mal interessieren.

Space


Antwort von CameraRick:

Vielleicht ists nicht falsch, aber das ist dann auch eher ein Streit um Worte.

Fakt ist, am Mac kann ich es ohne Probleme zurück holen, und am Windows schaffen wir das nicht. Vielleicht sind wir alle totale Nasen und können die Software nicht recht bedienen, aber wenn der selbe Weg auf zwei Systemen zu unterschiedlichen Ergebnissen führt stimmt irgendwas halt nicht.
Und da würde ich auch mal den Hersteller befragen, nur so als Idee halt.

Space



Space


Antwort von -paleface-:

Bin heute den ganzen Tag unterwegs.
Werde aber sobald Zeit ist nochmal Adobe anrufen.

Wenn die nix wissen, mich mal bei Atomos melden.

Jemand aus der Slashcam Redaktion hat doch bestimmt auch Insider Kontakte zu irgendwelchen Leuten die irgendwen kennen?
;-)

Space


Antwort von CameraRick:

Atomos würde ich unabhängig von Adobe so oder so kontaktieren. Wäre doch angenehm wenn es out of the box funktioniert, haben die ggf auch ein Interesse dran das zu überprüfen.

Space


Antwort von wolfgang:

Hast Du mal Atomos zu dem Fall befragt? Immmerhin erstellt der Shogun die Datei, da sollte man annehmen der Hersteller weiß, was er da macht? Als jeman der den Shogun durchaus hat und kennt sage ich es nochmals: der Shogun nimmt die Datein völlig korrekt in 16..235, oder 0..255, oder 16..255 auf.

Das belegen auch zahllose Tests die bereits vor einiger Zeit gemacht worden sind.

http://www.videotreffpunkt.com/index.ph ... post283043


Was eine Schnittanwendung dann damit macht ist das eigentliche Problem, hängt in vielen Fällen mit der miesen Implementierung von QT in Windows ab; aber nicht in allen Fällen. Edius etwa geht mit den Shogun Files korrekt um, aber nicht mit den 0..255 clips der GH4 internen Aufzeichnung. Vegas spreizt den Lumabereich auf weil sie den QT-Decoder von Apple nutzen. Was Adobe damit macht weiß ich zu wenig. Übrigens is das hier genutzte Bild zum Testen auch nicht optimal. Viel besser geeignet sind die von der GH4 erstellten Farbbalken (etwa ARIB).

Space


Antwort von CameraRick:

Der zur Verfügung gestellte Clip ist schon total brauchbar, weil er Bereiche hat an enen man es direkt sieht ohne nach messen zu müssen. Find ich super.

Ich hab die ganze Diskussion am Anfang eher halbherzig verfolgt, aber es so verstanden dass da Flags 'falsch' gesetzt wurden?
Das Problem hier ist mir noch nie unter gekommen, dass Dinge am Windows nicht gehen die ich am Mac ohne Probleme hin kriege (innerhalb der gleichen Software). Und Prores ist jetzt nicht wirklich neu :)

Ob Atomos da ein Händchen drin hat ist eine Sache, nachfragen schadet aber dennoch nicht. Atomos sollte ein Interesse daran haben dass es auf jedem System gut funktioniert, zumal die Adobe Suite in seiner Nutzerschaft die von Edius vermutlich um ein vielfaches übersteigt. Ich wäre als Hersteller zumindest daran interessiert, aber gut.
Was ich nun nicht verstehe ist Dein Problem mit dem Edius und den nativen GH4 Daten - der Edius kriegt das nicht zurück geholt? Die sind ja zB bei Adobe kein Problem, bzw selbst wenn muss man eben nen Color Profile COnverter drauf werfen und gut

Space


Antwort von dienstag_01:

Ein anderer User hat ja geschrieben, dass es intern in h264 kein 0-255 gäbe.
Man sollte sich vielleicht nochmal die Scopes aus dem Avid hier auf Seite 1 anschauen. Das sieht irgendwie Out of alle Normen (oder eben extrem überbelichtet) aus ;)

Space


Antwort von wolfgang:

Nein, das Motiv ist unbrauchbar als es kein normiertes Signal ist, mit dem man weser eine Lumaspreizung noch eine Farbverschiebung erkennen würden. Für sowas nutzt man Testcharts, hier durchaus problemlos von der GH4 selbst generierbar.

Man kann ja im Atomos Forum fragen wenn man will. Ob Atomos zu einer NLE was sagt ist fraglich, aber dort finden sich zumindest User die eine GH4, den Shogun und Adobe nutzen.

Space


Antwort von CameraRick:

Nein, das Motiv ist unbrauchbar als es kein normiertes Signal ist, mit dem man weser eine Lumaspreizung noch eine Farbverschiebung erkennen würden. Ja wenn wir das zu 100% festnageln wollten was da abgeht wäre das schon hilfreicher, aber wenn Du ehrlich meinst dass mit dem Material nicht feststellbar ist ob und wie Werte zurück geholt werden können fällt mir auch nichts mehr ein :/

Space


Antwort von WoWu:

Ein anderer User hat ja geschrieben, dass es intern in h264 kein 0-255 gäbe.
Man sollte sich vielleicht nochmal die Scopes aus dem Avid hier auf Seite 1 anschauen. Das sieht irgendwie Out of alle Normen (oder eben extrem überbelichtet) aus ;) H.264 kann beide. Es kommt darauf an, wie die Flag gesetzt wird.
ProRes kann nur YCbCr (709), weil die "colormatrix" nur auf 1 oder 6 zu stellen ist und das ist entweder 709 oder 601

Und wenn Du die beiden Waveforms mal so legst, dass du hin und her schalten kannst, dann siehst Du auch, dass das zweite Signal von der Mitte (128) nach den Seiten gestreckt wird.

Space


Antwort von dienstag_01:

Naja, bei mir (also der h264 Stream) steht das Flag auf 1 und trotzdem sind unten (kleiner 16) keine Werte. Oben (größer 235) schon;)

Space



Space


Antwort von WoWu:

Dann ist das Flag falsch gesetzt oder wird falsch ausgelesen.
1 wird nur im Zusammenhang mit dem xvYCC Farbraum geschaltet. Ansonsten steht das auch auf 0.
Nun weiss ich nicht, was die drei Schaltstufen der GH4 da genau mit den Headern machen, denn so irgendwas müssen die ja auch dem Header mitteilen. Vielleicht liegt da die Ursache ?
Und die 16-255 ist ja ein Monitorneteich, der mit der Aufnahme eigentlich gar nichts zu tun hat.

Space


Antwort von dienstag_01:

Die Ursache sicher nicht, denn ich hab beide Materialien als 709 importiert. Das heisst im Avid, mach nichts mit dem Material, denn es stimmt schon. Daher kann man sofort sehen, ob es in der Range ist, oder nicht.

Space


Antwort von WoWu:

Dann ist das zweite File irgendwo im workflow schonmal gespreizt, denn Du siehst die Spreizung unmissverständlich, wenn du die Ergebnisse umschaltest.

Ich würde mir mal schritt für Schritt im Workflow anschauen und, wie Wolfgang schon sagt, mal mit dem eingebauten FB.
Stellt sich sowieso die Frage, warum man extern ein zweites 709 aufzeichnet, wenn es intern schon vorliegt, denn ProRes macht nur 709 und ich tippe mal drauf, dass da in Erwartung eines 255 irgend eine Fehlbedienung (sprich Setting) vorliegt und irgend ein Header zwangsweise auf die falsche Position gedrückt worden ist.
Aber das kriegt man nur raus, wenn man den workflow nochmal systematisch durchgeht.

Space


Antwort von dienstag_01:

Nee, ne Spreizung sehe ich nicht.
Ich sehe Werte von 0 bis 255, oben hart abgeschnitten.

Space


Antwort von WoWu:

Leg die beiden Bilder mal übereinander und schalt mal hin und her. Dann siehst Du die Spreizung aber ganz deutlich und auch, dass sie von 128 ausgeht (hin zu Null und 255 und nicht wie bei RGB von Null.
Das ist ein ganz klares YCbCr.

Space


Antwort von dienstag_01:

Möglicherweise ist das andere aber auch gestaucht ;)

Space


Antwort von WoWu:

Die haben beide 'ne Macke, denn das erste ist ja schon 255 und nicht 235. Das ist also auch schon out of range.
Da ist irgendwo munter nach RGB gespielt und fleissig gespreizt worden. Deshalb sagte ich schon, man sollte sich mal das Histogremm anschauen, da sticht einem die Spreizung dann auch ins Auge, weil man die ganzen fehlenden Werte sieht.

Space


Antwort von dienstag_01:

Man sollte, glaube ich, nicht wirklich drüber nachdenken ;)

Space


Antwort von WoWu:

Nee, ist schon richtig.
Ich würde mir nur einen vernünftigen Workflow zurechtlegen, von dem ich weiss, dass er funktioniert und in dem ich weiss, wo ich mit welchem Signal umgehe und nicht so ein Teil, in dem ich zweimal 709 in unterschiedlichen Settings aufnehme.

Space



Space


Antwort von wolfgang:

Ja wenn wir das zu 100% festnageln wollten was da abgeht wäre das schon hilfreicher, aber wenn Du ehrlich meinst dass mit dem Material nicht feststellbar ist ob und wie Werte zurück geholt werden können fällt mir auch nichts mehr ein :/ Wenn du einen Filter darüber legen willt, der eine entsprechende Korrektur duchführt, und das exakt, wirst nicht darum kommen die Sache zu vermessen.

Dann ist das zweite File irgendwo im workflow schonmal gespreizt, denn Du siehst die Spreizung unmissverständlich, wenn du die Ergebnisse umschaltest. Das Problem mit den Spreizungen oder Stauchungen ist, dass man erst Anhand von Testbildern - wie etwa ARIB - klar erkennt, wie hier gespreizt oder gestaucht wird. Das ist eben der Vorteil der Vermessung.

Ich ergänze nochmals dass dies von dem jeweiligen Werkzeug abhängt, und welcher Decoder zum Einsatz kommt. In Vegas etwa wird QT genutzt, und da findet eine lineare Speizung von ProRes des Shoguns immer statt, wenn man also auf der GH4 16..235 einstellt geht das nach Spreizung sehr wohl in den Superweiß Bereich hinein. In Edius hingegen wird dieses ProRes Material in allen 3 GH4 Einstellungen 0..255, 16..235, 16..255 korrekt dargestellt. Bei Premiere weiß ich es nicht.

Bei mir ist der Workflow derzeit so, dass ich mit der GH4 in 16...235 arbeite; mit dem Shogun als ProRes (also nicht DNxHR) in UHD aufnehme; mit TMPGenc zu Cineform wandele und das in Vegas schneide. Grund dafür ist, dass ich damit kein Clipping bekomme, und andererseits in Vegas einen 10bit worklflow durchführen kann. Sowas muss man sich halt für das benutzte Werkzeug überlegen und austesten.

Space


Antwort von CameraRick:

Wenn du einen Filter darüber legen willt, der eine entsprechende Korrektur duchführt, und das exakt, wirst nicht darum kommen die Sache zu vermessen. Vielleicht ist das ein Streit um Worte, aber "unbrauchbar" um das Problem zu erkennen ists (für meine Begriffe) sicherlich nicht.

Das Problem ist ja nicht die Range als solche, denn die Werte sind ja definitiv da.
Ich kann sie hier am Mac ja einfach holen, ohne Effekt oder sonst was - die Info ist halt einfach da, ohne wildes Gefummel. Aber in der identischen Software auf einem anderen OS lässt sich das eben nicht herbei zaubern; da wird also irgendwo ein Fehler sein.

WoWu sagt ja schon, dass die Flag soweit richtig ist, weils anders gar nicht ginge (wenn ich das richtig verstanden habe). Ich vermute daher eben, dass Quicktime einem da ein wenig in die Seite fährt - wobei es kein generelles Windows Ding ist, DaVinci schafft es ja. In den Nuke hab ichs noch nicht geladen.
Bei Atomos nachfragen kann sicher nicht schaden

Space


Antwort von dienstag_01:

Der Avid *schafft* es auch.
Wenn du vom ProRes ausgehst.
Das H264 intern ist irgendwie an sich seltsam ;)

Space


Antwort von WoWu:

Ich glaube da nicht an Quicktime, das Quicktime Problem ist anders gelagert.
Meiner Meinung nach hat hier jemand "händisch" wenn auch nicht bewusst, ein Signal, das einer festen Begrenzung unterliegt, in einen andern Wertebereich gemapped.
Und was "Werte sind doch da", angeht, so ist das auch noch nicht wirklich klar. Das würde sich erst zeigen, wenn man sich mal die Mühe macht, das Histogramm mal anzuschauen, denn wenn ich von der Richtigkeit der Waveform Darstellung vom AVID ausgehe, die dienstag gepostet hat -und da gehe ich von aus-, dann haben beide Signale bereits einen Fehler denn das eine Signal sieht nach 16-255 aus, hat also den ATI Offset und das andere Signal die Spreizung.

Space


Antwort von -paleface-:

So...bin auch wieder da.

Also der Workflow sah so aus:

Gh4 auf 0-255 gestellt. Was raus geht kann man nicht speziell einstellen.
Intern mit der Gh4 aufgenommen und gleichzeitig per HDMi out in Prores 4:2:2 8bit.

Das wars.

Wir wollen ja nun in beiden Files den Lumarange 0-255 angezeigt bekommen.
Die Files sind auf den ersten Blick auch, wie wir inzwischen wissen, korrekt.

Denn Davinci zeigt es korrekt an. Avid anscheinend auch.
Adobe auch...ABER nur auf dem MAC.

Sobald das selbe File auf einem Windows Rechner importiert wird.
Fehlt bei dem Prores Files Lumarange.
Wenn ich z.B. dort bei dem Gh4 Material per Tonwertkorrektur 16-235 eingebe sieht es genauso aus wie das Prores Material.

Mich würde mal interessieren ob wer anders eine Cam hat die Prores aufnehmen kann und wir so checken können ob es bei allen Prores Files so ist ODER nur bei dehnen die aus dem Shogun kommen?

Oder fällt euch noch ein anderer Test ein?

Mein erneuter Anruf bei Adobe hat nix gebracht.
"Solche spezifischen Fragen stellen sie bitte im Forum!" -_-

Space


Antwort von WoWu:

Mach doch das Ganze einfach nochmal mit dem internen Farbbalken und stell von jedem Signal 3 Frames ein.
Dann hat man doch wenigstens einen Bezug.
Arbeitsaufwand dürfte sich ja im 5 min Bereich bewegen.

Space


Antwort von dienstag_01:

Die Files sind auf den ersten Blick auch, wie wir inzwischen wissen, korrekt. Nein. Zwei im selben Modus aufgenommene, aber im Ergebnis unterschiedliche Files können nicht beide korrekt sein.
Sobald das selbe File auf einem Windows Rechner importiert wird.
Fehlt bei dem Prores Files Lumarange.
Kann ich auch nicht bestätigen. Siehe Scopes auf Seite 1.
Da wird Luma abgeschnitten (aber erst oberhalb von 255).

Space


Antwort von -paleface-:

Sobald das selbe File auf einem Windows Rechner importiert wird.
Fehlt bei dem Prores Files Lumarange.
Kann ich auch nicht bestätigen. Siehe Scopes auf Seite 1.
Da wird Luma abgeschnitten (aber erst oberhalb von 255). Also wenn du beide Files in Premiere/AfterFx auf einem Windows Rechner über einander legst und hin und her switchst sehen die EXAKT gleich aus?

Damit mein ich keine Scopes sonder reine Augenkontrolle :-D

Space


Antwort von wolfgang:

Teste die Sache mit dem internen GH4 Testgenerator, nimm das als ProRes mit dem Shogun auf und analysiere das im Waveformmonitor deines Schnittprogramms! Das liefert eindeutige Aussagen was in der NLE passiert.

Und das kann man für alle 3 Luma-Einstellungen an der GH4 machen. Klar notieren welches ProRes File welche Einstellung hat.

Und man kann das für jede Einstellung auch am Waveform Monitor des Shoguns mit vergleichen. TIPP: die Shogun Anzeigen stimmen nach zahlreichen Tests übrigens immer. Die Rückfrage bei Atomos kann man sich sparen. Eine Abweichung davon in der NLE ist auf die NLE selbst und/oder - im Fall von Windows - auf den über QT installierten miesen ProRes Decoder unter Windows zurück zu führen, je nachdem ob die NLE einen eigenen Decoder für ProRes hat oder auf QT aufsetzt.

Ach ja, man kann das immer mit GH4 intern aufgezeichneten Files vergleichen wenn man will. Ebenfalls mit dem Testbalkengenerator der GH4 erstellt versteht sich.

Space


Antwort von dienstag_01:

Also wenn du beide Files in Premiere/AfterFx auf einem Windows Rechner über einander legst und hin und her switchst sehen die EXAKT gleich aus? Diesen Test hab ich nicht gemach, wüsste auch nicht was der bringen soll. Ich hab ja auf der ersten Seite auch einen Artikel verlinkt, der sich mit den Ranges in den Adobe Produkten befasst. Fazit: darauf würde ich mich also NIE verlassen.

Space


Antwort von WoWu:

Und dann stell doch mal die Originalfiles ins Netz, ohne vorher irgendwas umzukopieren.

Space


Antwort von -paleface-:

Also wenn du beide Files in Premiere/AfterFx auf einem Windows Rechner über einander legst und hin und her switchst sehen die EXAKT gleich aus? Diesen Test hab ich nicht gemach, wüsste auch nicht was der bringen soll. Ich hab ja auf der ersten Seite auch einen Artikel verlinkt, der sich mit den Ranges in den Adobe Produkten befasst. Fazit: darauf würde ich mich also NIE verlassen. Dann kannst du aber auch nicht sagen das es nicht an dem Mac und Windows unterschied liegt.

Weil es ist ja ein unterschied. Und dieser macht sich beim Grading bemerkbar.

Hier sind die Sofa original Files:
https://www.wetransfer.com/downloads/ac ... 618/f90aea

Die Testbars schaffe ich heut nicht mehr. Kommen aber noch.

Space


Antwort von dienstag_01:

Dann kannst du aber auch nicht sagen das es nicht an dem Mac und Windows unterschied liegt. Hab ich auch nie behauptet. Es könnte genauso gut an einem Mac-und-Windows-Unterschied nur für die Adobe-Produkte handeln. Könnte. Weiss ich nicht. Müsste man z.B. mit einem Mac-Avid gegenchecken.
Aber man kann nicht sagen, unter Windows läuft prinzipiell was schief, wenn man nur mit einem Produkt testet.

Edit: Das swind doch (hoffentlich) die selben Files, die du schon mal hochgeladen hattest.

Space


Antwort von -paleface-:

Dann hab ich das vorhin von dir falsch verstanden, sorry.

Ja sind die selben Files.

Space


Antwort von wolfgang:

Also GH4 intern aufgezeichnte Testbalken mit den 3 Lumaranges finden sich hier:

https://www.mediafire.com/folder/qsyk2j ... Testbalken

Mit dem Shogun aufgezeichnete Testbalken (über den HDMI-Eingang) folgen.

Space


Antwort von dienstag_01:

OK, bei diesem Format steigt der Avid aus. 4K kann meiner sowieso nicht, die h264 (mov) hat er aber genommen.

Space


Antwort von wolfgang:

Hier die UHD-Testbalken, aufgezeichnet mit dem Shogun:

https://www.mediafire.com/folder/07jpvc ... Testbalken

Ja, leider sind die beiden Formate in UHD aufgezeichnet - HD habe ich gar nicht mehr vorrätig gehabt. Heißt - die jeweilige NLE muss für diese Formate leider 4K/UHD tauglich sein. Aber ist das der Fall ist die Anwendung recht einfach. Man werfe die 6 files in die timeline und schaue sich das Ergebenis im waveform Monitor an.

Space


Antwort von PeterC:

Ich habe einmal die 6 Test-Clips von Wolfgang in Premiere importiert.

Premiere CC V8.1 / Windows:

Der Import lief einfach jeweils bei den einzelnen Clips über "Neue Sequenz aus Clip".

Alle 3 Shogun-Videos sehen in der Waveform-Anzeige identisch aus.
Die Farbbalken erstrecken sich von 0-100 IRE. Unter 0 IRE ist nichts vorhanden, scheint also abgeschnitten.

Die GH4 internen 16-235 und 16-255 sind insgesamt vom Gesamtsignal her ähnlich zu den 3 Shogun-Clips, aber es gibt hier und da kleinere Sprünge, die eventuell an der Kompression liegen könnten. Entscheidend ist hier aber, dass es einen Sprung unter 0 IRE gibt.
Es gibt insgesamt aber keine Spreizung oder Stauchung des Gesamtsignals.

Der einzige Clip, der richtig aus der Reihe fällt, ist der "GH4 intern 0_255 ARIB.MP4", dort ist das Signal gestaucht.


Premiere CS6 Version 6.0.5:

Hier sieht es grob bei allen Fällen genauso aus, wie in CC, außer dass hier bei den 3 Shogun-Clips auch der eine Balken unterhalb von 0 IRE auf dem Waveform sichtbar ist, der in Premiere CC abgeschnitten wurde.
Und es gibt oben einen kleinen Ausreißer über 100 IRE.

Space


Antwort von WoWu:

Intern 16-255 zeigt bei mir 0-255.
Intern 16-235 zeigt 0-255
Intern 0-255 zeigt bei mir 16-235
Keines der Files zeigt also, was es zeigen soll.
Kann das sein, dass die Files falsch gelabelt sind ?

Alle Files weisen aber 709 als Header aus.
Das würde aber nur für den Inhalt von Probe drei, nicht aber für das Label stimmen.
Keines der Files ist 16-255. Stellt sich zunächst mal die Frage, wie das Setting der Kamera auf den internen Recorder überhaupt auswirkt.
Wobei es sinn macht, denn für 16-255 gibt es gar kein Flagg.

Bei den 0-255 wäre ein Verlauf noch interessant, um zu sehen, ob in einem Histogramm alle Werte vorhanden sind. Das geht mit einem FB nur schwer, weil man den Verlaufspart entsprechend spreizen muss und dann der Messfehler zu gross wir.

Space


Antwort von wolfgang:

Das Verhalten von den 3 ProRes Testfiles belegt, dass alle 3 Luma-Bereiche sauber und korrekt in deiner Premiereversion dekodiert werden. Da wird bei ProRes nicht gestaucht oder gestreckt, wie deine Charts zeigen. Das stimmt mit der Info überein, dass Premiere einen eigenen ProRes Dekoder verbaut haben dürfte.

Den Umstand der falschen Dekodierung der 0..255 GH4 intern aufgezeichneten Datei tritt leider auch in Edius auf wie ich kürzlich aufgezeigt habe. Das ist besonders schade, da hier die nächste namhafte NLE bei diesem Material patzt.

Wie es bei anderen NLEs ist, das ist nur teilweise dokumentiert. ProRes wird etwa unter Vegas gespreizt, das GH4 Material ist dort ok was den Lumak-Range angeht. Überall also ein unterschiedliches Verhalten.

Nein, die labels sind korrekt.

Space


Antwort von domain:

Schon bemerkenswert, dass uns unser Superweiß etc. schon seit 10 Jahren hinsichtlicht Dehnung, Stauchung oder Beschneidung mindestens 1000 Postings beschert hat.
Niemals gab es ergiebigeres Thema ;-)

Space


Antwort von WoWu:

Die drei ProRes Files zeigen alle 0-255 , unabhängig vom Label aber im Header 709. Damit stimmt das Aufnahmeformat mit dem signalisierten Inhalt nicht überein. Stauchung oder Spreizung richtet sich aber ausschliesslich nach dem korrekten Auslesen des Headers. Trifft das NLE auf das falsch gesetzte Flag, ist der Verursacher schuld.
Der Fehler wird also im Shotgun gemacht, der für 255 den 235 Header setzt. Weil ProRes nur 1 oder 6 akzeptiert, also gar kein 255 zulässt.
Bliebe nur noch zu analysieren, ob das 255er Signal überhaupt lückenlos aus der Kamera bedient wird, oder ob es ein gepimptes 235 ist.

Space


Antwort von wolfgang:

Die drei ProRes Files zeigen alle 0-255 , unabhängig vom Label aber im Header 709. Damit stimmt das Aufnahmeformat mit dem signalisierten Inhalt nicht überein. Stauung oder Spreizung richtet sich aber ausschliesslich nach dem korrekten Auslesen des Headers. Da patzt vermutlich nicht der Shogun sondern der Codec selbst, ich vermute diese Headerauslesung ist der Grund warum ProRes in vielen Applikationen gespeizt erscheint (bei denjenigen, die hierfür QT in der Windows-Welt nutzen).

Denn am waveform-Monitor des Shoguns sieht man bei den Testbildern durchaus den korrekten Lumabereich. Und das ist auch in Edius und Premiere der Fall.

Übrigens sind das nicht irgendwelche Superweiß-Diskussionen. Sondern hier zeigt sich eher, dass (zumindest in der Windows-Welt) mit diesem Standard-Codec aus der Apple Welt auch ziemliche Probleme bei den Usern geben kann. Je nach Werkzeug halt.

Die GH4 files prüfe ich zumindest sicherheitshalber nochmals.

Space


Antwort von WoWu:

Nein, da patzt Shogun, denn eigentlich müsste das YCbCr erst korrekt in ein RGB Signal überführt werden und dann in 0-255 gespeichert und signalisiert werden.
Das würde nur den ProRes ausschliessen, weil der nunmal kein RGB macht.
Shogun hätte entweder den Codec so benutzen müssen, wie er nunmal ist, oder einen andern Codec nehmen müssen.
Der Codec kann da nix zu denn die Implementierungsvorschriften sind da eindeutig.

Aber es wäre wirklich mal interessant, sich das Signal auf seine Konsistenz anzuschauen, mit was man es da eigentlich zu tun hat denn wenn es ein gespreiztes Signal sein sollte und hinterher (über den Header) wieder gestaucht wird, kommt ja ein (fast) einwandfreies Signal dabei wieder heraus.
Nur die vermeintlichen Vorteile des Shogun schmelzen dahin.

Fest scheint nur zu stehen, dass die ganze GH4 Steuerung irgendwie "Bananen" macht, wenn, wie Du sagst, die Labels stimmen.
Mir scheint es so, dass sie damit lediglich Monitore ansteuern wollen.
Ich hatte vor einem Jahr mal angefragt, wie sie denn 16-255 signalisieren. Wüssten sie auch nicht, sagte der technische Support ... nun wissen wir's .. gar nicht.

Space


Antwort von wolfgang:

Also zu den GH4 intern aufgezeichneten files - die sind schon korrekt. Habe sie nochmals vom Server runter geladen und getestet. Zeigen bei mir genau das bekannte Verhalten, und stimmen auch mit dem überein was ich dazu aus etlichen Tests im Kopf habe.

Diese GH4 intern aufgezeichneten Files werden in Vegas korrekt interpretiert. Dabei ist zu sagen, dass die ARIB Balken genau das zeigen was sie sollen -nämlich dass das Testmaterial im Waveform-Monitor sich zwischen 0%(=16) und 100% (=235) bewegt. Diese Files belegen lediglich, dass es zu keiner Stauchung oder Spreizung kommt.

Hier mald ie Testbilder wie ich sie hier sehe.

Space


Antwort von wolfgang:

Will man sich ansehen ob es Superweiß oder Superschwarz Anteile in entsprechenden Files befinden, sind andere Testbilder nütztlich - nämlich reale Motive. Wo man einmal die GH4 einstellt und dann bei sonst gleichen Einstellungen nur den Lumabereich verändert. Das habe ich vor einiger Zeit auch gemacht - und ich hänge hier mal Snapshoots an (diese Files habe ich nicht hochgeladen).

Und da sieht man dass die GH4 den Lumarange tatsächlich auf 0..255, 16..255 oder 16..235 korrekt beschränkt - je nach gewählter Einstellung.

Hier mal Echtbilder, wo man klar diese Bereiche erkennen kann.

Space


Antwort von WoWu:

Versteh' ich nicht.
Du stehst in der TL auf 16-255 und dein WF zeigt dir 0-255 (???)
In den andern genau so. Egal, wo Du stehst, die Anzeige ist immer 0-100%

Space


Antwort von wolfgang:

Nein, da patzt Shogun, denn eigentlich müsste das YCbCr erst korrekt in ein RGB Signal überführt werden und dann in 0-255 gespeichert und signalisiert werden.
Das würde nur den ProRes ausschliessen, weil der nunmal kein RGB macht.
Shogun hätte entweder den Codec so benutzen müssen, wie er nunmal ist, oder einen andern Codec nehmen müssen.
Der Codec kann da nix zu denn die Implementierungsvorschriften sind da eindeutig. Also an den Anzeigen des Shogun selbst - Waveform Monitor - sind die Lumaranges korrekt. Ebenso in der Dekodierung in Edius wie - hier gezeigt - auch in Premiere.

Bei der GH4 internen Aufzeichnung ist der Shogun unbeteiligt. Der ist ja nur für ProRes in Verwendung. Die GH4 internen Materialtests zeigen dort recht schön dass das Material stimmig ist mit der Vegas-Anzeige. Auch wenn Vegas nicht Maßstab aller Dinge ist.

Space


Antwort von wolfgang:

Versteh' ich nicht.
Du stehst in der TL auf 16-255 und dein WF zeigt dir 0-255 (???) 0% = 16
100% = 235 in der Vegas-Anzeige.

Bild 1 steht auf 16..255 - waveform zeit 0% bis ca. 105% an. Korrekt

Bild 2 steht auf 16..235 - waveform zeigt 0% bis 100% an. Korrekt

Bild 3 steht auf 0..255 - waveform zeigt ca. - 5% bis ca. 105% an. Korrekt.


Bitte sich nicht von der gelben Linie iritieren lassen. Es zählen die %-Achsen.

Space


Antwort von WoWu:

Ich kann mich nur daran orientieren, was der R&S Analyser mir zu den eingefütterten Files sagt und kann wenig dazu beitragen, was andere Systeme daraus machen.
Eins steht nur fest ... 255 und ProRes mit einer Signalisierung von 709 ist falsch.
Egal, was andere Systeme daraus machen und ob sie das Signal nun auf 709 stauchen oder den Header nicht lesen.
Im File sind 254 Wertepositionen und nicht 219.
Man kann das jetzt drehen und wenden ... das ist fehlerhaft.

Space


Antwort von PeterC:

Ist es in Premiere CC nicht bedenklich, dass die 3 Shogun-Clips bei 0 abgeschnitten werden?
(Bei CS6 scheint es ja noch zu funktionieren.)

Und was wäre die Worst Case-Variante, wenn man den gestauchten GH4 internen 0-255 ARIB -Clip in Premiere verarbeiten müsste?
Das Signal über Effekte/Schnelle Farbkorrektur, mit Hilfe der Level auf 16-235 zu stellen oder ähnliches, um den Farbbalken wieder im Waveform von 0-100 zu bringen? Das bereitet mir schon etwas Magenschmerzen.

Space


Antwort von WoWu:

Prinzipiell kann man sowas natürlich "fixen" man muss nur wissen, was sie genau gemacht haben und was sie übertragen.
Wenn sie beispielsweise YCbCr nur in 255 übertragen, dann kann man symmetrisch stauchen denn das Format baut sich symmetrisch auf.
Haben sie aber RGB daraus gemacht, das sich von Null nach 255 aufbaut, wird man die Farbwert wieder dorthin bringen müssen, wo sie hingehören. Das ist einwenig schwieriger.
Abet prinzipiell auch möglich und solange damit nicht weitere Wandlungen vorgenommen worden sind und erst einmal ein Signal geklippt ist, geht alles.
Man muss eben nur genau wissen, wie das Signal entstanden ist.
Deswegen bringt dieses ganze "geht hier, aber da nicht" nichts und ist nur ein "rumgedocktere" an den Symptomen.
Dazu müsste man aber auch mal endlich eindeutig herausbekommen, welches Signal die GH4 eigentlich an den Ausgang legt, ob es dasselbe ist, das sie Aufzeichnet oder es anders gewonnen wird und ob es sich um 254 individuelle Werte handelt und ob es in RGB oder YCbCr anliegt.
Wenn man der Flag glaubt, sind es nämlich nur 219 Werte.

Space


Antwort von -paleface-:

Dazu müsste man aber auch mal endlich eindeutig herausbekommen, welches Signal die GH4 eigentlich an den Ausgang legt, ob es dasselbe ist, das sie Aufzeichnet oder es anders gewonnen wird und ob es sich um 254 individuelle Werte handelt und ob es in RGB oder YCbCr anliegt.
Wenn man der Flag glaubt, sind es nämlich nur 219 Werte. Und wie bekommt man das raus?

Space


Antwort von WoWu:

Das naheliegendste wäre ja eine vernünftige Auskunft von Panasonic aber damit ist ja wohl nicht zu rechnen, wenn schon die Angaben im Manual so schwammig sind, dass jede Möglichkeit offen steht.

Das nächste wäre mal wirklich zu sehen, ob alle Benutzten Werte in der Shogun Aufzeichnung auch individuelle Inhalte haben, ob also nicht aus 219 Werten nur 254 gemacht worden sind.
Das macht man am schnellsten mal mit einem Helligkeitsverlauf und schaut sich dann das Histogramm mal an.
Der Recorder müsste eigentlich auch Auskunft darüber geben, ob sie RGB oder YCbCr aufzeichnen ... ich tippe mal auf letzteres denn YCbCr in fullrange ist ja nichts ungewöhnliches.
Die offene Frage bleibt, warum sie dann einen Codec, der 709 geflaggt ist, mit 255 füllen.
Dass die interne Einstellung irgendwas mit der externen Aufzeichnung zu tun hat, ist auch noch nicht klar.

Ich kann auch Wolfgangs Beispiel nicht wirklich nachvollziehen.
Er sagt ja, das NLE setzt entsprechend der Einstellung einen Bewertungsfilter, sodass der Content immer korrekt von 0-100% angezeigt wird.
Ich habe auch weder die 105 noch die -5 aus dem Signal ablesen können. Daher meine Vermutung mit dem Bewertungsfilter.
Ich kann ansonsten nicht erkennen, wie er auf die Werte kommt.
Die drei externen Aufnahmen zeigen bei mir auch auch alle 1-254 an (wie bei ihm), ohne jede Bewertung.
Insofern gehe ich mal davon aus, dass die Einstellung in der Kamera nach aussen gar nicht wirkt .. oder vom Shogun nicht umgesetzt wird.
Intern zeigt sich ja ein ähnliches Problem in der Diskrepanz zwischen Setting und dem, was aufgezeichnet wird.

Ansonsten bin ich kein Freund davon, alles einfach nur auf die nachfolgenden Player, Systeme oder NLAs zu schieben, solange an der Signalaufbereitung noch derart viele Ungereimtheiten existieren.
Wenn die geklärt sind und es immer noch Fehler gibt, dann kann man weiter hinten in der Kette suchen, aber solange die Kamera und der Recorder noch so viele Fragen offen lassen, sollte man die erst mal klären.

Und dass sich Folgesysteme unterschiedlich verhalten kann durchaus sein, wenn einige sich an den Flags und andere sich an den Systemeinstellungen orientieren, dann ist das normal.
Dann muss man eben, aufgrund der vorgelegten Videosignals seinen Workflow einrichten.
Das ist das Normalste Ding auf der Welt. Nur dazu muss man eben wissen, womit man eigentlich umgeht und das ist hier alles andere als klar.

Space


Antwort von srone:

...solange an der Signalaufbereitung noch derart viele Ungereimtheiten existieren... wie immer, der punkt, wo es hakt. ;-)

lg

srone

Space


Antwort von dienstag_01:

Die offene Frage bleibt, warum sie dann einen Codec, der 709 geflaggt ist, mit 255 füllen. Ich vermute mal, dass die (Panasonic) etwas anderes vorhaben, als du erwartest. Die wollen einfach diesen Wertebereich (unterhalb 16 und oberhalb 235) mit nutzen. Damit können sie mehr Werte übergeben.
Und das da ein FullFrameFlag gesetzt wird oder nicht, möglicherweise hilft das beim Monitoring oder dem einen oder anderen NLE, ist aber irrelevant.

Anders kann ICH mir das nicht vorstellen, denn ein Flag für 16-255 gibt es ja sowieso nicht, oder. Wie sollte man dann dieses Format verstehen - die bewegen sich ausserhalb der Spezifikationen.

Space


Antwort von WoWu:

Ich vermute mal, dass die (Panasonic) etwas anderes vorhaben, als du erwartest. Jam das glaube ich auch, denn ich erwarte, dass sie da Signale, icl.Flags zur Verfügung stellen, die angeschlossene Geräte auch verstehen. Dafür gibt es solche Flags nämlich.
Die wollen einfach diesen Wertebereich (unterhalb 16 und oberhalb 235) mit nutzen. Damit können sie mehr Werte übergeben. Die Wertebereiche unterhalb von 16 und oberhalb von 235 sind für xvYCC inclusive des entsprechenden Flags vorgesehen.
Wenn die Kamera xvYCC macht, dann ist das ok.
Macht sie aber nicht.
Vielleicht sollte Panasonic mal sagen, was sie da eigentlich machen ...
Kann ja sein, dass sie YCbCr mit 255 machen, dann sollen sie aber auch sagen, wie sie das flaggen und wer das verstehen soll.

Kann auch sein, dass sie da RGB machen ... HTML kann aber RGB nur in 4:4:4
Also, was machen sie da, wenn sie 709 verlassen und wie wird es signalisiert ?

Im Manual steht zu dem Thema nur lasches Larifari. Kein Wunder, dass nachfolgende Workflows nicht funktionieren. Wie sollten sie auch ?Und das da ein FullFrameFlag gesetzt wird oder nicht, möglicherweise hilft das beim Monitoring oder dem einen oder anderen NLE, ist aber irrelevant. Wieso ist das irrelevant, wenn das nicht funktioniert ?
denn ein Flag für 16-255 gibt es ja sowieso nicht Stimmt, weil 16-255 eine ATI Spezifikation ist, die sich ausschliesslich auf ihre Grafikkarten bezieht und mit Formatübertragung soviel zu tun hat, wie meine Grossmutter mit der NASA.

Deswegen konnte mir auch keiner im Tech-Support die Signalisierung nennen.
Auch die Frage, ob sich die Einstellungen auf das Aufnahmeformat beziehen oder nur auf den HDMI Ausgang, also auf die Wiedergabe wusste keiner. Da die Einstellung im Aufnahmemenü des Videobereichs ausgewählt werden kann, gehen wir davon aus, dass es sich um eine Aufnahmefeature handelt:

Mail-Anhang.gif

Für weitere Fragen stehen wir gern zur Verfügung.
... war die Antwort.

Aber meinst Du nicht, sowas sollte man im Manual vielleicht mal klären ?

Space


Antwort von wolfgang:

Ich kann mich nur daran orientieren, was der R&S Analyser mir zu den eingefütterten Files sagt und kann wenig dazu beitragen, was andere Systeme daraus machen.
Eins steht nur fest ... 255 und ProRes mit einer Signalisierung von 709 ist falsch. Es mag sein dass dies falsch ist. Aber auch wenn es falsch ist - dann nützt dies dem Anwender unmittelbar leider wenig, weil er kann einen etwaigen Fehler nicht beheben.

Mein Augenmerk liegt daher darauf einen stimmigen workflow zu entwickeln. Und den habe ich für mich über die Konversion zu Cineform gefunden, ein Codec der heute gratis verfügbar ist - und der sowohl in Premiere wie auch in Vegas gut nutzbar ist.

Space


Antwort von dienstag_01:

Ich denke, wenn man nicht wirklich weiss, was Panasonic da für Daten speichert, wäre der stimmigste Workflow, Finger weg von solchen Formaten ;)

Space


Antwort von WoWu:

Zumal auch der vermeintliche Qualitätsgewinn schnell ins Ggenteil umschlagen kann.
Nicht umsonst entstehen ja solche Fehler, wie der TS sie hier moniert.
Die Frage ist eben nur nach der Ursache und die Spekulationen, es könne sich hier um Ungereimtheiten im Zusammenspiel mit andern OS handeln, scheinen immer unwahrscheinlicher zu werden, je genauer man sich die Sache anschaut.

Klar kann man an jedem Content solange rumbiegen und um-mappen, bis es irgendwie passt nur was bei Re-mappings und keiner richtigen Wandlung herauskommt, ist hier schon oft besprochen worden.

@Wolfgang
Wenn ich die Wahl hätte zwischen R&S oder Panasonic für die Richtigkeit der Angaben, dann besteht da kein Zweifel,dass ich Rohde & Schwarz eher vertraue zumal der Content auf jedem x-beliebigen Waveform genauso aussieht.

Aber auch der Shogun ist noch nicht aus dem Schneider, denn 0-255 und 709 Flag passen nunmal nicht zusammen und ProRes mach nun mal nur 709.
Da ist also auch nicht klar, was sie sich da vorgestellt haben.

Space


Antwort von -paleface-:

mit was konvertierst du denn in Cineform?

Witziger weise, wenn ich mit dem Media Encoder umwandel...hab ich das selbe Problem.

Zieht sich also durch die komplette Adobe Kette...

Werde bei Zeiten mal beim Shogun mit den Avid Codec aufnehmen und schauen ob sich das lohnt.
Beim letzten Dreh blieb der Shogun aber zu Hause.

Space


Antwort von Goldwingfahrer:

Witziger weise, wenn ich mit dem Media Encoder umwandel...hab ich das selbe Problem. das wäre aber mehr als nur peinlich......

Hat mir jemand ein kurzes Testfile,dann würde ichs mal mit dem Cinec
umwandeln.

Selber habe ich mit diesem,inzwischen schon etwas älterem Tool eigentlich keine Probleme.

Space


Antwort von -paleface-:

Auf der ersten Seite ist noch der We transfer link.
Kann aber sein das er inzwischen off ist.
Daher hier noch einmal zu meiner Dropbox:
https://www.dropbox.com/s/klo4ni1w45wht ... t.rar?dl=0

Space


Antwort von Goldwingfahrer:

Hier 2 Screens


Link nun gelöscht

Oberste Spur ist das Original
Bei der 2.+3. obersten Spuren sehe ich keinen farblichen Unterschied.
Aber wohl bei der untersten Spur,da ists einen Hauch heller.

Gesamtdateigrösse in Prores,alle Spuren ergeben knapp 4 GB.


Space


Antwort von wolfgang:

mit was konvertierst du denn in Cineform? Ich habe dafür TMPGenc 5 und jetzt auch TMPGenc 6 genutzt.

Den Cineform codec bekommt man gratis ins System, wenn man die gratis Version von GoPro Studio installiert.

Funktioniert auch in 10bit 422 - wo ja der Shogun grundsätzlich seine Stärke im Zusammenspiel mit der GH4 ausspielt. Allerdings nutzte ich nur 16..235 - nein, nicht weil die anderen Lumaranges für mich illegarl wären, sondern weil auch TMPGenc nach meinen Tests den Luma-Range des ProRes Material spreizt und es damit zu Clipping kommen würde.

Cineform ist für mich auch deswegen interessant, weil es nativ in Vegas implementiert ist, man also damit die 10bit problemlos verarbeiten kann, und weil der codec auch auf meinem älteren Schnittrechner sehr performat ist.

Und der workflow ist hier mit diversen Testmaterial durcherprobt und vermessen, da kommt es zu keinen Lumaveränderungen oder Farbveränderungen. Details hier, ab posting 52:
http://www.videotreffpunkt.com/index.ph ... /?pageNo=3

Und damit geht die Sache in der Praxis durchaus. Und um das geht es zumndest mir.

Space


Antwort von Goldwingfahrer:

da kommt es zu keinen Lumaveränderungen oder Farbveränderungen. eine leichte Helligkeitsveränderung sehe ich allerdings,ist aber nicht weiter tragisch.
Tragisch ist schon eher die Anzeige im Wellenformonitor.

Space


Antwort von freezer:

Ich muss jetzt diesen Thread wieder ausgraben, weil ich bei der Suche im Web nach einem anderen Problem nun auf eine Lösung für -paleface-'s Problem gestoßen bin.

In der Tat ist es so, dass das Quicktime aus dem Shogun sehr wohl die Details in den Superwhites beinhaltet, aber zB. After Effects CC2014 interpretiert das ProRes falsch und schneidet die Superwhites ab. Das lässt sich weder durch Einstellen des Arbeitsfarbraumes noch durch Konvertieren der Farbprofile beheben und scheint ein Bug von Adobe zu sein.

Jedenfalls gibt es einen Workaround:
Man kann die ProRes MOVs mit dem Mediaencoder in Cineform MOVs konvertieren, dabei bleiben die ursprünglich vorhandenen Superwhites erhalten und können zB in AFX wieder zurückgeholt werden.

Die korrekten Einstellungen für AME habe ich als Screenshots angehängt.

Space


Antwort von dienstag_01:

Schön, dann ist das mal geklärt.

Allerdings ahnen wir, was passiert, wenn man ein standardkonformes Videofile (16-235) von ProRes in Cineform umwandelt ;)

Naja, nichts ist vollkommen ;)

Space


Antwort von -paleface-:

Ah, ok. Muss ich mal testen.

Inzwischen nehme ich aber nur noch mit dem Avic Codec auf.
Da habe ich bisher keine Prbleme gehabt.

Aber dennoch werde ich mir das mal ansehen.

Space


Antwort von wolfgang:

Allerdings ahnen wir, was passiert, wenn man ein standardkonformes Videofile (16-235) von ProRes in Cineform umwandelt ;) Ich weiß nicht was die Ahnung sein soll.

Aber ich wandle seit geraumer Zeit die 16..235 Shogun ProRes Files mit TMPGenc in Cineform. Und die sind dann wieder 16..235 - in Vegas. Warum sollte das in Premiere anders sein? Cineform wird dort ja auch korrekt interpretiert.

Ich würde übrigens eher Cineform avi nehmen - aber das könnte unter Premiere anders aussehen.

Und ja. Natürlich hat der Shogun bei einer Einstellung einer GH4 mit 0..255 auch 0..255 im ProRes File. Übrigens auch in DNxHR.

Space


Antwort von dienstag_01:

Danke, Wolfgang, ich habe natürlich VERGESSEN, dass meine AHNUNG sich auf die Wandlung in Adobe bezieht. Sind ja in einem Thread, wo das nicht jedem klar sein könnte ;)

Space


Antwort von wolfgang:

Nur weiß keiner was deine Ahnungen sind, und mit Ahnungen kannst auch falsch liegen.

Und Cineform ist ein Produkt welches auch mit CS zusammen vertrieben worden ist oder sogar noch wird. Warum also sollte bei Nutzung des Cineform codecs so eine Lumaspreizung auftreten, wie sie bei ProRes immer wieder beobachtbar ist??

Space


Antwort von WoWu:

Weil proRess nur 220 Werte adressiert und CF vermutlich 255 und den Grund, warum gespreizt wird, haben wir neulich ausführlich diskutiert und wenn sowas wie "Super Weiß" Auftritt, dann wird eben irgendwo Das Systemweiss nicht korrekt signalisiert.
Denn wer glaubt, FW würde in (egal welchem) Codec nicht richtig adressiert, sollte sich seinen Workflow besser genauer ansehen.

Space


Antwort von wolfgang:

Also ich kann nur sagen:

1) Filmen mit dem Shogun zu ProRes in einer GH4 mit 16..235
2) Konversion mit TMPGenc zu Cineform
3) Cineform Material zeigt ordnungsgemäß den Bereich 16..235.

Das habe ich mehrfach nachgemessen und dieser Workflow liefert korrekte Ergebnisse. Der dritte Schritt erfolgt bei mir zwar in Vegas, aber warum sollte Cineform von CS nicht ordnungsgemäß dekodiert werden?

Freilich, gerade mit ProRes in der Windows Welt sollte man sich schon die Mühe machen und den eigenen Workflow kontrollieren. Gehr etwa mit den internen Testbalken der GH4 recht einfach. Würde man oben etwa 16..255 oder 0..255 in der GH4 einstellen, kommt es nach dem Schritt 2 zu clipping.

Space


Antwort von WoWu:

Das wäre ja auch so i.O.
Ich hatte das von Frezzers Post nur so verstanden, dass dann aus 235 plötzlich 255 wird und "dienstag" scheint das ja auch so verstanden zu haben.
Aber das ist eben immer das gleiche Spiel mit Systemweiss und dem Weisspunkt.

Space


Noch was unklar? Dann in unserem Forum nachfragen
Zum Original-Thread / Zum Adobe After Effects-Forum

Antworten zu ähnlichen Fragen //


Dolby Digital Encoder zur Erzeugung von AC3-Files aus wav-Files
Q: Panasonic *.mov-Files in DV *.avi-Files Konvertieren
Sigma Firmware Update für die fp verbessert ISO-Bug, externes SSD-Recording uvm.
Update 10.4.9, Export Bug nur in 1080 obwohl andere Auflösung
Sony FX9 Firmware 2.01 fixt Noise-Bug in 2.0 Firmware.
Premiere Proxy-Bug
Resolve 17.2 - Kein BT-Audio? Bug?
Immernoch der Colortab Bug!
GH6 Bug
Fusion Bug beim Timeline Resolution ändern in Davinci Resolve
Bug bei S5ii real-time LUTs?
DVD-lab "704->352"-Bug?
Unterschied zwischen ProRes 422 und ProRes 422HQ in der Praxis
DJI Mavic 3: Neue Firmware bringt u.a. Aufnahme mit ProRes 422 und ProRes 422 LT
Panasonic GH6 Firmware 2.0: 120 fps ProRes RAW mit Ninja V+, mehr internes ProRes und mehr...
Adobe bestätigt: ProRes RAW in Premiere Pro kommt
Wo speichert Adobe die Video Codecs in OSX_MpegStreamclip zeigt keine ProRes Codecs
Adobe Premiere Pro und After Effects bekommen ProRes RAW und mehr Neues...




slashCAM nutzt Cookies zur Optimierung des Angebots, auch Cookies Dritter. Die Speicherung von Cookies kann in den Browsereinstellungen unterbunden werden. Mehr Informationen erhalten Sie in unserer Datenschutzerklärung. Mehr Infos Verstanden!
RSS Suche YouTube Facebook Twitter slashCAM-Slash