slashCAM Forum

:-)) Nee, das ist nur eine andere Bezeichnung als 709. Das ist genau, was es eigentlich ist: Korrekt. Und ziemlich unmissverständlich. Nur in 709 steht natürlich noch ein bisschen mehr drin, als nur die Westgrenzen für das Videosignal.
Aber ist völlig richtig.

Morgen haut der NEEL uns windelweich, dass wir hier zu nachtschlafender Zeit seinen Thread vollmachen.
Ich spring jetzt raus, bevor ich mir morgen Prügel einhandle.

Ok, halten wir mal fest:

ein Video auf einem Comutermonitor darzustellen, beinhaltet die Schwierigkeit, dass dessen Farbraum größer als der in den Specs für Video beschriebene ist.
Mit einigen Codecs ist das kein Problem, mit so gängigen wie h264 aber schon. Ergebnis: das Video hat einen eingeschränkten Kontrastumfang, sieht flau aus.
Bei Verwendung des Videos im Internet unter Zuhilfenahme von Flash (mp4 Container, zum Beispiel YT) tritt das Problem nicht auf.
Mein Workflow: Video in 709 bearbeiten und farbkorrigieren (16-235), mit Sorenson Squeeze encodieren (Input is 16-235), Ergebnis: Luminanzwerte werden über den kompletten Luminanzbereich von 0-255 dargestellt (voller Kontrast).
Der Weg über After Effects und den Adobe Media Encoder hat mir noch nicht die gewünschten Ergebnisse gebracht, möglicherweise gibts den aber.

Edit: Für die Darstellung des Videos im QT-Player gibt es noch den Workarround mit vorrübergehenden Umstellung der Transparenzeigenschaften unter visuelle Eigenschaften (QT Pro), Nachteil: keine globale Einstellmöglichkeit, müsste man für jedes Video neu machen.
Ebenfalls möglich ist, die Videoeigenschaften der Grafikkarte zu verändern, hab ich aber keine Erfahrung, wie sich das auf z.B. Videos auswirkt, die eigentlich "richtig" wiedergegeben werden.

http://www.photoscientia.co.uk/Gamma.htm


bringt etwas Luft rein..

motiongroup hat geschrieben:bringt etwas Luft rein.

Nur zum Teil. Die falsche Darstellung von h264 Videos (wie oben beschrieben) bleibt natürlich auch an einem kalibrierten Monitor falsch.

nein dem ist nur dann so wenn die verwendete Software auf einer nicht modifizierten QT Import Export Schnittstelle aufbaut..

Bei Edius war dies bis zur Version 5.5 so was aber in der Edius 6 behoben wurde. Den obigen Link zu den Playern habe ich nur hinzugefügt um aufzuzeigen das eine Beurteilung am PC überhaupt nicht möglich ist...
Was nützt es die Gammawerte zu kalibrieren wenn die NLE oder die Player schon beim Import alles falsch interpretieren??

Wie gesagt, es ist den Profis über Jahre nicht aufgefallen....Bei Adobe haben sie über 4 Jahre gebraucht um zu erkennen aber nicht zu reagieren den bis zur CS4 wurde es nicht behoben.

Die Auflistung was wann mit welchem Material geschieht ist der einzig praktikable Ablauf.

erstens beim Import falsch interpretiert.
zweitens bei der Ausgabe falsch verarbeitet..

Lösung dafür finden via Splitscreen, Diffkeyer, Vectorscope, Viewer usw.

Für das Material den passenden Weg merken..

http://chrismarquardt.com/blog.php?id=7 ... 7447333704

Ich hatte das oben schon angemerkt.
Der Autor des Artikel hat sein FCPX mit 10.6.x betrieben, das aber noch diverse Teile von QT benutzt.
Sobald er auf 10.7 umstellt, das nun keinerlei Reste von QT mehr aufweist, klappt auch das Gamma in FCPX.
In irgend einem Thread hatte ich auch beschrieben, warum das so ist. Will ich jetzt nicht wiederholen.

Wo hast du das her Wolfgang .... ich bin auf Lion unterwegs und QT ist vorhanden.. QTX und QT7...

Es stimmt zumindest das der GammashiftBug bei mir nicht nachweisbar ist wobei ich aber im Moment selten mit h264 AVC MOV oder Mp4 arbeite..

bei meinem aktuellen Projekt verwende ich umgepacktes AVCHD Material welches via Clipwrap in den MOVContainer umgepackt wurde, da die AVCHD Clips nicht mit der CAM eigenen Verzeichnisstruktur angeliefert wurden und somit mit FCProX nicht nativ verstanden wird..

Schonmal versucht die von dir exportierten Clips auf einem anderen Rechner zu sichten?

Ich hatte mal Probleme mit diversen "nicht kalibrierten" Software-Playern, die durch diverse Settings die Videos bei der Wiedergabe schlicht und ergreifend falsch wiedergegeben haben. Das fängt bei den Output-Settings der Grafikkartentreibern schon an und zieht sich durch etliche Instanzen.

Eventuell wurde das Output-Modul des NLE zb von der VLC-Player-Installation umgeschrieben und dadurch mit falschen Werten belegt?

Ich hab keinen Bock mir den ganzen Thread hier durchzulesen, ich kann aber aus eigener Erfahrung sagen:

- Installation von Software-Playern wie zb VLC kann einem das ganze System madig machen, selber schon mehrmals erlebt.
- falsche Einstellungen zb der GraKa-Treiber kann die komplette Wiedergabe madig machen - ist zwar banal aber muss man erstmal drauf kommen.

Vielleicht hilft es ja, wenn nicht - dann nicht ;-)

Wo hast du das her Wolfgang ....

Eigene Erkenntnis, denn wir haben das Gammshift mit FCPx natürlich gleich mal ausprobiert .... es war aber auch bei FCPx noch da.
Als wir dann auf Lion umgestellt hatten, haben wir unmittelbar neu getestet. Ergebnis: weg.
So wie wir das sehen, hing es mit der QT Verwendung zusammen weil in 10.6 noch diverse Classes aus der QT C-API benutzt wurden.
Das ist in 10.7 nun nicht mehr so und damit dürfte QT, und nun auch der Gamma Bug, Vergangenheit bleiben.

na ja Fehler behoben, aber QT ist immer noch mit von der Partie in Form von QTX 10.1 und QT7..

Ja, ich befürchte, das bekommst Du wirklich nur raus, wenn Du komplett umgestellt hast und selbst die Bezeichnung am besten nur noch hinter vorgehaltener Hand benutzt. :-))
(Aber sind die Server nicht auch umgestellt) ??

Aber Apple scheint wirklich nicht viel Aufwand mit der Behebung von Problemen zu betreiben oder Bugs zu fixen .... das ist eigentlich einwenig schade denn was nutzt mir die nächste Technologie, die alles viel besser macht, wenn ich die Alte noch die nächsten Jahre benutzen muss.

sorry aber ich verstehe dich nicht.. was soll ich umstellen??

ich bin auf OSX Lion und FCutPro X QT ist nach wie vor an Board in beiden Versionen ... der Bug ist zwar weg und das ist auch gut so..
Server?? wie was? ich schneide Privat mit nem neuen 2011 MacBookPro17" fertig alles..

Ich hatte das QTX und 10.1 falsch interpretiert. Disregard ... :-)

okok nur wie sieht es nun mit der Aussage aus das unter Lion kein QT mehr vorhanden ist, resp. verwendet wird??

wenn du in 64bit arbeitest, ist das so. Weil das System auf AV-Foundation aufsetzt. Es hat zwar nicht soviel Classes und Methode, wie Quicktime, aber immerhin mehr als noch QTKit.
Es ist ja weniger eine Frage, wie ein Player heisst, sondern mehr, mit welchen Tools er arbeitet.

na das ist mal eine Brotkrümelsuche aber danke für das Lösen des Gordischen Knotens..

http://www.philiphodgetts.com/2010/08/i ... oundation/

Besser spät als nie!
Das Problem hat mich erst die letzten paar Monate beschäftigt.
Da ich keinen Mac habe konnte ich viele Lösungsansätze nicht ausprobieren.
Ich konnte z.B. nicht den codec x264 statt h264 in Quicktime verwenden.
Laut Beschreibung verwedet mein encoder Avidemux x264 was mir aber
nichts gebracht hat. VLCplayer, winMedia player, Premiere CS3 und
youtube haben das Video korrekt wiedergegeben. Vimeo, Quicktime und
mein auf QT basierender JW player haben es verwaschen.(aus schwarz
wurde dunkelgrau)

Getstet unter winXP und win7 mit Firefox und Opera

vimeo


youtube


Ich habe hunderte posts darüber gelesen, das Problem liegt daran wie QT
mp4 wiedergibt.
In irgendeinem Forum schrieb jemand dass mit HandBrake dieses
Problem nicht auftritt. Und es ist (zumindest bei mir) tatsächlich so.
Ich verwende in HandBrake die gleichen Einstellungen wie in Avidemux
mit dem Unterschied dass bei der Wiedergabe in QT schwarz immernoch
schwarz bleibt und nicht dunkelgrau.

hier das neu codierte Video im JW player
http://www.leerywitter.com/frameprj.html

Gruß, Marko

Mit dem Video kann ich nix anfangen. Alles abgesoffen und ausgefressen.

Das Thema betrifft ja nur die Darstellung der jeweiligen App. Ich verbiete das einfach im Setup der Grafikkarte und habe durchgehend keine Probleme:

axl* hat geschrieben:Ich verbiete das einfach im Setup der Grafikkarte und habe durchgehend keine Probleme:

Vergleiche die beiden Videos auf YT und Vimeo nochmal genau, dann wirst du sehen, dass deine *Lösung* keine Lösung ist.
Diese *Lösung* gibt es in dem Sinne auch gar nicht, da der Farbraum bei mp4/h264 von dem einen Player so, von dem anderen Player eben anders interpretiert wird. Ein einheitliches Ergebniss ist da nicht zu erhalten.

Auf dem PC: H264 Mp4 wird mit dem Windows Mediaplayer korrekt angezeigt und mit VLC milchig und desaturiert.

Auf dem Mac unter Mountain Lion: Alles H264 Material, auch direkt aus AVCHD oder H264.mov wird mit Quicktime Player milchig und desaturiert mit falsche Farben angezeigt und mit dem VLC player, einem Bluray SW Player und Toast Player wird es exakt so angezeigt wie es in der Adobe Premiere Timeline Vorschau auch zu sehen ist.

Das ist momentan mein Stand und denke es ist unter OSX der Quicktime player, der den Farbraum und Gamma falsch interpretiert, während VLC das auf dem PC nicht richtig hinbekommt.

Auf meinem Windows System gibt es dieses Problem nicht. Dass vorher die Windows Farbverwaltung korrekt eingerichtet wurde ist unumgänglich.

Ich habe gerade ein durchgehendes Video mit der Cam direkt vom Monitor abgefilmt um das zu dokumentieren. Das ist natürlich qualitativer Murks, aber für das Erkennen von Gammaveränderungen genügt es. Es wird dort zwischen Mediaplayer, VLC, Divxplayer, sowie Youtube und Vimeo live hin und her geschaltet. Die Abweichungen sind marginal. Mein System ist zusätzlich gespidert und die dortige Monitorausgabe deckt sich ziemlich gut mit der Anzeige eines Studiomonitors.

@axl*
Darum geht es doch gar nicht. Versuche folgendes: exportiere ein mp4/h264 Video aus deinem NLE. Schau dir diese Video in verschiedenen Softwareplayern an. Es wird verschieden wiedergegeben werden.

???

Was meinst du denn, was in meinem Video gezeigt wird? Es wird eben NICHT verschieden wiedergegeben.

Ich hatte das von dir beschriebene Problem früher auch und nun habe ich es nicht mehr.

Alles klar, unter Osx konnte ich feststellen, dass nur der Quicktimeplayer und Fcpx mein mit einem colorimeter calibriertes Displayprofil berücksichtigt, alle anderen Player und Premiere Pro greifen darauf nicht zurück. Wenn ich nun als Displayprofil einfach das sRGB Profil auswähle, sieht es in jedem Player gleich aus.

Habe nun erstmal den Monitor auf Werksseitig sRGB gestellt und das sRGB Displayprofil beibehalten - kalibriere nochmal neu. Vielleicht hatte ich da falsche Einstellungen verwendet.

Vielleicht weiß das jemand von Euch. Ich habe einen Dell 2711 Ultrasharp. Verwende ich beim Kalibrieren die Einstellungen für einen Wide Gammut LCD?

axl* hat geschrieben:???

Was meinst du denn, was in meinem Video gezeigt wird? Es wird eben NICHT verschieden wiedergegeben.

Ich hatte das von dir beschriebene Problem früher auch und nun habe ich es nicht mehr.

Ja, anhand deines Videos kann man gut erkennen, dass du keine Probleme mit unterschiedlicher Anzeige hast.

Auf dem PC hat bei mir nur der VLC ein helleres Bild, sonst passt es.

Beim Umstellen der Farbprofile in der Windows Farbverwaltung, gerade im Zusammenhang mit Spidern, muss das System zur vollständigen Übernahme neu gestartet werden. Das hat mich mal Einiges an Nerven gekostet. Der Königsweg scheint es zu sein zunächst den Spider zu deaktivieren, dann die Farbverwaltung einzurichten, jeweils neu starten und dann erst neu spidern.

Der Witz unter Windows (zumindest Win7), mein Profil deaktiviert sich nach einiger Zeit (tage-wochen) von selbst. Dann hat er plötzlich wieder standard srgb angeschmissen.

Das Spider Profil oder das Win Profil?

Vielleicht weiß das jemand von Euch. Ich habe einen Dell 2711 Ultrasharp. Verwende ich beim Kalibrieren die Einstellungen für einen Wide Gammut LCD?

Normalerweise nicht.
Und im Betrieb auch nur, wenn der Monitor eine color-gamut conversion function hat.

axl* hat geschrieben:Das Spider Profil oder das Win Profil?

Das Spyderprofil wird deaktiviert. Ich weiß nicht, woran das liegt. Schalte ich dann einmal zum Windows Profil und wieder zurück, ist alles wieder gut.

WoWu hat geschrieben:

Vielleicht weiß das jemand von Euch. Ich habe einen Dell 2711 Ultrasharp. Verwende ich beim Kalibrieren die Einstellungen für einen Wide Gammut LCD?

Normalerweise nicht.
Und im Betrieb auch nur, wenn der Monitor eine color-gamut conversion function hat.

Danke Wolfgang, dann war das vielleicht mein Einstellungsfehler. Muss ich testen...

axl* hat geschrieben:???

Was meinst du denn, was in meinem Video gezeigt wird? Es wird eben NICHT verschieden wiedergegeben.

Sorry, hatte ich vorhin noch nicht gesehen.

axl* hat geschrieben:Ich hatte das von dir beschriebene Problem früher auch und nun habe ich es nicht mehr.

Schalte doch mal spaßeshalber deine Nvidia-Einstellung auf Video-Player um, da müsstest du schon einen sehr alten VLC-Player haben, dass der das Video falsch anzeigt.
Ich will damit sagen, dass war alles mal sehr verworren, hat sich aber inzwischen stark verbessert. Ich würde trotzdem nicht davon ausgehen, dass es mit allen klappt.
An den Einstellungen der Grafikkarte zu drehen war aber für jemanden, dem es darum ging, seine Videos möglichst kompatibel für viele Player auf verschiedenen Rechnern zu machen, eigentlich nie der Weg.
Aber egal, scheinbar ist es sogar wieder an der Zeit, die Kompatibilität zwischen Windows und Mac neu zu untersuchen. Da hatte ich nämlich bisher zwei verschiedene Files für :(