Ich habe den Beitrag mit Interesse verfolgt. Wir doktorn schon lange an diesem Problem herum. Ich kann bestätigen, dass es mit Apple QT 7.6 auf dem PC funktioniert. Einfach installieren neu starten und sich freuen - nach all den aufwendigen Versuchen, es irgendwie anders zu lösen.
Ich habe es auch mit EDIUS 5.01 getestet. Der original Clip sieht schon prima aus und gewinnt noch Qualität, wenn man diesen in de Canopus HQ Codec umrechnet.
Tipp für einen schnellen Test: MOV im QT abspielen, dann im Menü auf "kopieren" gehen und in einem Bildbetrachter/Bildbearbeitung auf "Einfügen" gehen. Mit allen anderen QT Versionen wird das Bild hier dunkler.
filmpraxis hat geschrieben:
Ich habe es auch mit EDIUS 5.01 getestet. Der original Clip sieht schon prima aus und gewinnt noch Qualität, wenn man diesen in de Canopus HQ Codec umrechnet.
Ein Codec der die Qualität verbessert? Ah ja. Sehr interessant.
filmpraxis hat geschrieben:
Tipp für einen schnellen Test: MOV im QT abspielen, dann im Menü auf "kopieren" gehen und in einem Bildbetrachter/Bildbearbeitung auf "Einfügen" gehen. Mit allen anderen QT Versionen wird das Bild hier dunkler.
Thomas Wagner
Eben nicht. Oh Leute ... in QT gibt es einen Kompatibilitätsmodus für FCP, der macht das Bild dunkler was an der Gamma Verschiebung liegt. Das hat damit überhaupt garnichts zu tun.
---------
Ich habe nun die neue Version von QT installiert und das Problem bleibt das selbe. Ein PNG, rausgerechnet mit MPEGStreamclip hat mehr Dynamikumfang als der selbe Frame mit QT nach PNG. Bei letzterem sieht man im Histogramm deutlich, dass schlichtweg oben und unten etwas abgeschnitten wurde, und zwar genau bei 16 und 235.
MB
Ich will lieber mit Weisen irren, als mit Unwissenden recht zu behalten. (Cicero)
Habe gerade das Update in der Windows-Version installiert. Damit ist das Problem definitiv behoben. Ich finde es nur heftig, dass Apple dafür satte drei Jahre gebraucht hat.
MarcBallhaus, ich kann es auf dem Mac momentan nicht mit einer Waveformdarstellung prüfen. Aber der Bildvergleich zeigt nach dem Update gegenüber der Quicktime-Vorversion erkennbar mehr Details in Lichtern und Schatten. Also eine Verbesserung kann ich erkennen, aber ich weiß nicht, ob das Clipping damit - so wie es in der Windows-Version der Fall ist - ganz behoben ist.
Marco hat geschrieben:Habe gerade das Update in der Windows-Version installiert. Damit ist das Problem definitiv behoben. Ich finde es nur heftig, dass Apple dafür satte drei Jahre gebraucht hat.
MarcBallhaus, ich kann es auf dem Mac momentan nicht mit einer Waveformdarstellung prüfen. Aber der Bildvergleich zeigt nach dem Update gegenüber der Quicktime-Vorversion erkennbar mehr Details in Lichtern und Schatten. Also eine Verbesserung kann ich erkennen, aber ich weiß nicht, ob das Clipping damit - so wie es in der Windows-Version der Fall ist - ganz behoben ist.
Marco
Die Verbesserung kann ich erkennen, betrifft aber den Gamma, nicht das Clipping.
MB
Ich will lieber mit Weisen irren, als mit Unwissenden recht zu behalten. (Cicero)
Änderungen im Gamma habe ich eigentlich gar nicht berücksichtigt. Es sind erkennbare Verbesserungen in den dunkelsten Schwarz- Weißbereichen. Aber für mich derzeit auf dem Mac leider nicht messbar.
Eine ausschließliche Gammaveränderung kann ich mir eigentlich nicht wirklich vorstellen, das wäre ja ein Witz. Das Bild würde zwar weicher aussehen (Spreizung der 226 auf 256 Stufen mit feineren Abstufungen) aber das würde das Clippingproblem ja in keiner Weise lösen.
Ich bin auf dem Mac mal den Umweg über eine Grafiksoftware gegangen, um es zumindest per Histogramm vergleichen zu können. Leider habe ich aus der alten QT-Version nur noch einen einzigen Screengrab, in dem die Lichter nicht so sonderlich kritisch waren. Aber im Schwarzbereich war dort mit QT 7.5 noch deutlich das Clipping erkennbar und auch per Histogramm messbar. Mit QT 7.6 zeigt der gleiche Clip auch im Histogramm im Schwarz keinerlei Clipping mehr. Was dort vorher durch Clipping im Schwarz weggeschnitten war, ist nun als Bildinformation im Bereich 0-15 erhalten.
Das Problem ist, zumindest für Quicktime, behoben, der Thread obsolet. Alles jetzt noch zu beklagende Clipping rührt von der Belichtung bei der Aufnahme her.
Na und? Im Fernsehen wird ja auch alles wiederholt ...
Axel hat geschrieben:Das Problem ist, zumindest für Quicktime, behoben, der Thread obsolet. Alles jetzt noch zu beklagende Clipping rührt von der Belichtung bei der Aufnahme her.
Aha. Und warum sehe ich dann einen Unterschied von der SELBEN Aufnahme, zwischen MPEGStreamclip und QT? Egal ob angezeigt oder exportiert, QT schneidet bei 16 und 235 ab und stretcht auf 0 und 255.
MB
Ich will lieber mit Weisen irren, als mit Unwissenden recht zu behalten. (Cicero)
Nachdem ich jetzt mal MPEG Streamclip auf dem Mac installiert hab und ein paar Vergleiche zwischen Streamclip und QuicktimePlayer auf Mac-Plattform und Frame-Exporte aus beiden Tools mit den Windows-Ergebnissen verglichen habe, verstehe ich gar nichts mehr.
Hab nochmal hin- und herverglichen, auch zwischen Mac und PC. Zwischen der vorherigen Quicktime-Version 7.5 und der aktuellen Version 7.6 ist auf jeden Fall ein gewaltiger Unterschied. Deutliches Clipping in Schwarz und Weiß bei Version 7.5, im Prinzip kein Clipping mehr in Schwarz und Weiß bei Version 7.6 - weder auf dem Mac, noch auf dem PC.
Die Quicktime-decodierten Signalversionen zwischen Mac und PC sind im Grunde genommen identisch. Geprüft habe ich die Signale auf dem PC mit Waveform, Histogramm und RGB-Parade. Vom Mac habe ich dazu die Canon H.264-Files in FCE importiert und von dort als Quicktime-File mit PNGs exportiert.
Außerdem habe ich vom Mac über MPEG Streamclip PNGs exportiert. Diese Streamclip-Signale sind wiederum grundsätzlich identisch mit den Versionen, die ich auf dem PC per Streamserver an Quicktime vorbeigeschleust hab. Also den Output von Streamclip auf Mac und Streamserver auf PC kann ich eigentlich gleich setzen. Und natürlich auch hier kein Clipping in Lichtern und Schatten.
Trotzdem gibt es einen deutlich erkennbaren und leicht messbaren Unterschied zwischen den "Stream"-Versionen und den Quicktime-Versionen. Die Quicktime-Versionen kommen fast nie unter RGB 16, haben insgesamt ein "helleres" Gamma und stauchen (nicht: clippen) das Weiß dann letztlich etwas mehr. Von Clipping im Weiß kann dort aber dennoch nicht Wirklich die Rede sein, bzw. wenn, dann wäre das in einem Bereich von nur etwa 1 oder maximal 2 Prozent. Ich könnte das, was ich dort sehe, gerade im Vergleich zu der vorherigen Quicktime-Version aber nicht als Clipping bezeichnen. Im Schwarz eh nicht.
Insgesamt scheinen die Quicktime-Versionen dennoch etwas mehr Dynamik zu verschenken als die "Stream"-Versionen. Nur weiß man ohne Testbild als Basis nicht, welches der Signale authentischer ist.
Im Gegensatz zum Output von Quicktime 7.5 könnte ich jetzt mit beiden Versionen leben.
@Marco ... machs doch nicht so kompliziert, exportier je ein ein PNG aus MPEGStreamClip und QT - am Mac -, und lad beides in Photoshop. Dann kannst du im Histo sehen, dass die QT Variante clippt. Schränkt man mittels Tonwertkorrektur die Dynamik in der MPSC-Version auf 16 und 235 ein, sieht das PNG exakt genau so aus wie das aus QT. Also clippt QT.
MB
Ich will lieber mit Weisen irren, als mit Unwissenden recht zu behalten. (Cicero)
Das hatte ich auch gemacht (wenn auch nicht in Photoshop). Da clippt es ebenfalls nicht, bzw. so minimal, dass es eigentlich nicht relevant ist. Und die Unterschiede zur vorherigen QT-Version sind riesig.
Marco hat geschrieben:Das hatte ich auch gemacht (wenn auch nicht in Photoshop). Da clippt es ebenfalls nicht, bzw. so minimal, dass es eigentlich nicht relevant ist. (...)
Marco
Du bist ja witzig. Also clippt es doch!
Dann filme mal Nachts und dann wirst du sehen, dass das was vorher minimal war, plötzlich ein Problem ist, weil die Kontraste Nachts am höchsten sind und du dann vor allem auf Highlights und Zeichnung in den Tiefen angewiesen bist, während die Mitten schnurzegal sind, bei Tagaufnahmen ist es genau anders herum.
MB
Ich will lieber mit Weisen irren, als mit Unwissenden recht zu behalten. (Cicero)
Hab mal eine lineare Kontrastkurve (von RGB 0 bis 255) als Quicktime H.264 gerendert und verschiedene Decodings analysiert. Wenn das H.264-Signal auf einem Mac decodiert wird, wird die Kontrastkurve verändert. Mit einem unkomprimierten AVI passiert das dort nicht. Auf dem PC passiert's auch mit H.264 nicht. Zudem sind die Varianten, die (vom Mac aus) aus MPEG Streamclip als Frameexport mit Gamma 2.2 rausgehen, nahezu identisch mit den Quicktime-Ausgaben (geprüft auf dem PC). Aber Ausgabe mit Gamma 1.8 aus Streamclip ist deutlich näher am Original.
Also bei allem, was ich bisher von den Mac-Outputs der H.264-Files gesehen habe, ist eine Änderung der Kontrastkurve deutlich erkennbar, bei Quicktime mehr, bei Streamclip weniger dramatisch, je nach Exporteinstellung. In keinem der Fälle wird die Kontrastkurve des Originals beim H.264-Decoding auf dem Mac korrekt reproduziert. Clipping ist nur noch geringfügig auszumachen (3 Prozent).
Ich denke, das Clipping-Problem mit Quicktime ist größtenteils behoben, aber die Darstellung der Kontrastkurve bei Mac-Bearbeitung kann noch ein Stück optimiert werden.
"Du bist ja witzig. Also clippt es doch!"
Bei kritischen Signalen wurden mit Quicktime 7.5 noch 13 Prozent des Signals geclippt. Mit Quicktime 7.6 sind es nur noch etwa 3 Prozent. Den genaueren Wert kenne ich erst, seitdem ich es mit dem Grauverlauf testen konnte (bei den Realvideos, die ich letzte Nacht unter die Lupe nahm, war das so genau gar nicht zu analysieren). Das ist ja schon eine enorme Verbesserung.
Die eigentliche Signalveränderung hat zwar viel mit der Veränderung der Kurve, aber weniger mit dem Clipping zu tun. Das war mit QT 7.5 noch ganz anders. Würden die das Gamma noch optimieren, wäre vermutlich bei der Sichtprüfung schon gar kein Unterschied mehr erkennbar. Tatsächlich lässt sich per Gammakorrektur die nach Mac-Export gekrümmte Kurve wieder zum Original hin begradigen. Also größtenteils ist's ein Gamma-Problem. Der Verlust durch Clipping bleibt natürlich auch nach der Gamma-Korrektur.
Das Histogramm erweist sich dabei übrigens nicht als gutes Messinstrument. Die Waveform-Anzeige macht deutlicher, was passiert.
Die Rede ist hier nicht von H.264 am Mac allgemein, sondern von Aufnahmen der 5D die in H.264/MOVs vorliegen. Was du beschreibst ist reine Theorie, was ich schreibe ist Praxis. Sorry, nicht falsch verstehen, aber dein Ergebnis mag theoretisch richtig sein, praktisch ist es aber einfach nicht der Fall.
Das Histogramm ist m. e. das beste Werkzeug um den Tonwertumfang aufzeigen, denn für nichts anderes ist es da.
Ich will lieber mit Weisen irren, als mit Unwissenden recht zu behalten. (Cicero)
Der Unterschied zum Quicktime PNG ist nicht minimal sondern erheblich. Vom Histo mal abgesehen, sind rechts obene im Bild schwarze Löcher, ebenso im Rhein links, während das Bild aus MPEGStreamclip hier noch deutliche Zeichnung hat.
Ich will lieber mit Weisen irren, als mit Unwissenden recht zu behalten. (Cicero)
Du hast Recht, QT hat im Schwarz ziemlich viel geclippt. Nur beim Mpeg SC Bild können über eine Tonwertkorrektur (allerdings nur dann) die winterlich kahlen Zweige links im Himmel wieder sichtbar gemacht werden.
Was bleibt also, wenn man mit FCP schneiden will? Originaldatei aus der Kamera in Color importieren und als 10bit unkomprimiert ausgeben ...
Na und? Im Fernsehen wird ja auch alles wiederholt ...
Natürlich ist der Umgang mit generierten Testbildern fern der Praxis. Aber bisher fehlt solchen Überprüfungen der Canon-Clips ja jegliche objektive Referenz! Solange man nicht weiß, wie ein Bild überhaupt im Originalzustand aussehen könnte, kann man kaum verlässliche Aussagen darüber machen, welches Werkzeug das Bild letztlich optimal darstellt und wo genau welcher Fehler passiert. Da muss ich Wolfgang recht geben, dass ein von der Canon generierter, genormter Farbbalken sehr wertvoll wäre (und besser als ein selbst generiertes und zu H.264 encodiertes Testbild).
Der Unterschied auf deinen Screenshots ist wirklich deutlich. Aber selbst das Signal aus Streamclip clippt noch immer ein wenig. Das Clipping im Schwarz, das auf deiner Quicktime-Version zu sehen ist, scheint zudem in etwa den o.g. 3 Prozent zu entsprechen. In diesem Motiv auch rein visuell erkennbar, in denen, die ich bisher habe, leider nicht.
Ist das Original-File vielleicht irgendwo als allgemein zugänglicher und legaler Download erhältlich?
Was mich dabei am meisten stört ist vor allem der Unterschied zwischen dem Mac- und dem PC-Decoding. Wenn ich ein Canon 5D-File aus FCE als unkomprimiertes AVI exportiere und diesen Output mit dem Original Canon-Signal auf dem PC vergleiche, dann muss ich das Gamma des FCP-Signals um den Wert 0.4 anheben, um eine prinzipiell vergleichbare Darstellung zu haben. Also beim Vergleich der Mac- und der PC-Ausgabe erschlägt der Unterschied im Gamma erstmal jeden anderen Fehler.
Marco hat geschrieben:
Ist das Original-File vielleicht irgendwo als allgemein zugänglicher und legaler Download erhältlich?
Das sind alles Mood Aufnahmen, mit 1-2 Minuten Länge. Ich guck aber mal, was an Ausschuss dabei ist wo ich vielleicht nach 5 Sekunden abgebrochen habe ... hast du eine eMail Adresse für mich?
MB
Ich will lieber mit Weisen irren, als mit Unwissenden recht zu behalten. (Cicero)
Marco hat geschrieben:Ich habe im Web noch ein paar Quellen gefunden. Ich schau erstmal, ob dort vielleicht noch ein paar kritische Motive drunter sind.
Marco
Da würde ich nicht so viel drauf geben, weil ich hab kaum was gesehen, wo die Leute die richtigen Settings gefunden haben.
MB
Ich will lieber mit Weisen irren, als mit Unwissenden recht zu behalten. (Cicero)
Könnt Ihr diesen Clip dort rechts unten bei VIMEO brauchen?
** S8-Hobbyfilmer seit 1970, Video seit 1988, Rechner i9-14900K, NVIDIA RTX 5060, W11 Pro**
** Aktuelle Hauptkameras: DJI Osmo Pocket 3 Gimbal-Kamera, Xiaomi 14T Pro und Sony ZV-1**
Bei dieser Aufnahme war die Kamera schon krass fehleingestellt, aber dennoch konnte ich damit ansatzweise auch das Clipping im Schwarz nachvollziehen. Hatte heute nochmal eine Ladung von rund 10 völlig verschiedenen 5D-Clips durchgeschleust. Das Problem mit dem falschen Gamma beim FCE-Export und dem Korrekturwert von +0.4 dafür auf dem PC ist bei allen gleich.
Anscheinend besteht auf dem PC mit Quicktime-Decoding das Clipping-Problem in den Schatten nicht, auch nicht zu den geringen 3 Prozent. Aber das ist mit den mir zur Verfügung stehenden Clips nicht eindeutig auszumachen. Dieser letzte Clip ist qualitativ einfach grottig schlecht. Trotzdem gibt es dort in den Schatten hie und da ein "Detail", das nach Quicktime-Decoding auf dem Mac nicht mehr reproduzierbar ist, gleich wie an einer Farbkorrektur geschraubt wird.
MarcBallhaus, wenn du ein kurzes Sample eines Motives, ähnlich dem auf dem Screenshot gezeigten, finden würdest, das wäre schon interessant. Denn bei einem hochwertigerem Signal könnte ich verlässlicher testen, ob und wie sich das Clipping zwischen PC- und Mac-Quicktime-Decoding unterscheidet. Mein Mailkontakt:
Ohne Zweifel aber ist mit dem Quicktime-Decoding noch ein bisserl was im Argen, trotz erheblicher Verbesserung gegenüber der Vorgängerversion.
Ich habe dir nen Rohschnipsel geschickt. Der ist zwar buggy, weil ich vergaß die Automatik abzuschalten, aber dafür auch nur 20 MB groß. Aber zum testen ist das ja vielleicht garnicht so schlecht.
Gib doch mal ein Feedback, würde mich freuen.
MB
Ich will lieber mit Weisen irren, als mit Unwissenden recht zu behalten. (Cicero)
Super, danke für den Clip! War genau das richtige Motiv.
Also erstmal zum PC, das ist schnell abgehandelt. Ob ich auf dem PC den Clip mit der Windows-Version von MPEG Streamclip, dem QuicktimePlayer oder der Schnittsoftware (die für das Decoding auf Quicktime zurückgreift) decodiere, macht keinen Unterschied. Das Gamma stimmt scheinbar und selbst die tiefsten Schatten werden nicht geclippt.
Da der zweifelsfrei objektivierbare Bezug z.B. in Form eines genormten Farbalkens aus der Kamera fehlt, ist die Annahme, dass das Gamma der Windows-Versionen korrekt ist, immer noch zu einem Teil spekulativ. Ich berufe mich dabei auf die Testreihe mit dem intern generierten Graukeil, der nach Quicktime H.264-Encoding und anschließendem Decoding korrekt dargestellt wurde. Das birgt aber dennoch ein gewisses Fehlerpotential.
Auf dem Mac:
Da ich die Signale auf meinem MacBook nicht richtig prüfen kann, habe ich jeweils einen Export zu PNG Bildsequenzen gemacht. Einmal mit MPEG Streamclip und einmal mit FCE. Die PNG-Sequenzen habe ich dann auf dem PC überprüft.
Beide Versionen - Export aus FCE und Export aus MPEG Streamclip sahen gleich aus. Um den Wert 0.4 verändertes Gamma und zudem das leichte Clipping in den Schatten.
Wenn ich aus Streamclip einen anderen als den einzelnen Frameexport wähle, habe ich keine Wahl beim Gamma. Ich denke, es wird dann immer 2.2 benutzt. Genau das scheint auf dem Mac bei Streamclip und bei Quicktime zur größten Abweichung zu führen.
Ich habe dann nochmal das erste Frame des Clips aus Streamclip mit Gamma 1.8 exportiert. Das Resultat ist besser, liegt irgendwo zwischen der 2.2-Version und den Windows-Versionen und das Clipping scheint grundsätzlich eliminiert.
Was mich aber wundert ist, dass beim Mac Streamclip-Export zum einen das Gamma bei der 1.8-Exportoption letztlich nicht zu einer Abweichung von 0.4 Werten gegenüber der 2.2-Exportoption liegt und damit noch immer nicht gleich den Windows-Versionen ist.
Zum andern sind auch dort (bei der Gamma 1.8 Exportoption) die dunkelsten Schatten noch stark komprimiert, so dass es bei einem solch kritischen Motiv nur knapp an einem Clipping vorbeischießt.
Also mal unabhängig davon, welches Werkzeug auf welcher Plattform zur optimalen Decodierung führt, gelingt es mir nicht, beim Decoding der 5D-Clips auf Mac und PC ein einheitliches Resultat zu erhalten.
Den Gamma-Shift wird es deshalb geben, da Quicktime den Mac-eigenen Gammawert von 1.8 ausgleichen versucht. Wobei ich beispielsweise einen Monitor-Gamam von 2.2 habe… Schon wieder falsch:) Unmöglich einen Standard für die "richtige" Rezeption aufzustellen. Zuviele Monitore, Betrachtungssituationen, Parameter…
Sowas fürchte ich auch. Ich bin auf dem Mac noch nicht sattelfest. Ich dachte nur immer, dass das Gamma von 1.8 lediglich für Mac-interne Betrachtung und Player relevant wäre, der endgültige Videoexport aber grundsätzlich für eine 2.2-Wiedergabe ausgelegt sein müsste. Ich glaube, bei anderen Videoformaten wird dem in Quicktime (auf Mac) auch Rechnung getragen. Nur H.264 scheint da aus der Reihe zu tanzen.
Womit auch wieder die Frage im Raum steht, welches Gamma-Mapping denn die Canon D5 beim H.264-Encoding verwendet.
Meine Unsicherheit, ob das mit Quicktime 7.6 auf Windows-Plattform denn wirklich so perfekt ist, wie es auf den ersten Blick scheint, ist womöglich auch nicht so ganz ungerechtfertigt. Es gibt Vermutungen (in anderen Foren), wonach das nur eine "Quick'n'Dirty"-Lösung ist, bei der etwas unglücklich zwischen 3 verschiedenen Farbräumen hin und hergewandelt wird, was zwar zu einem Signal ohne Clipping von Schwarz und Weiß führt, das 8-Bit-Signal dabei aber überstrapaziert wird, so dass Informationen an anderer Stelle verloren gehen. Erkennbar wird das an Lückenbildung im Histogramm. Das hatte ich auch mit etwas Verwunderung bemerkt.
Außerdem gibt es hie und da Äußerungen dazu, dass das Gamma beim H.264-Decoding per Quicktime auf Windows-Plattform etwas zu hoch angesetzt wird und das Bild dadurch heller scheint als es sein sollte. Dann würde letzten Endes ja fast gar keine Decodierungsversion mehr stimmen (zumal das Resultat von der Windows-Version von MPEG Streamclip mit dem Quicktime-Resultat identisch ist).
Möglicherweise ist ja das Resultat von MPEG Streamclip auf Mac (und die Streamserver-Variante auf PC) noch das beste, im Sinne von: am nächsten am Original.
Marco
Nachtrag:
Die Lösung, die den authentischsten Eindruck macht und zudem in jedem Meßinstrument die wenigsten Artefakte zeigt, ist die mit dem Streamserving per AviSynth.
Am suspektesten ist dagegen noch immer der Weg über Quicktime. Da wurden mit der Lösung des einen Problemes offenbar neue Probleme geschaffen.
MPEG Streamclip mit Gamma 2.2 Output hat zwar ebenso wenig Artefakte wie die AviSynth-Lösung, aber vermutlich falsches Gamma und clippt. MPEG Streamclip mit Gamma 1.8 clippt zwar wohl nicht mehr, zeigt aber schon mehr Artefakte (aber immer noch weniger als Quicktime auf Windows) und es bleibt fraglich, ob das Gamma hier korrekt ist (die Frage stellt sich allerdings bisher bei jeder der hier beschriebenen Lösungen).
Zuletzt geändert von Marco am So 25 Jan, 2009 02:10, insgesamt 1-mal geändert.
Hab oben noch was ergänzt. Ich würde dir gerne ein paar Resultate inklusive den Anzeigen der Messinstrumente (Waveform, Histogramm und RGB-Parade) zukommen lassen. Die Tatsache, dass ein jedes Werkzeug ein anderes Resultat produziert, bremst allerdings.
Mein momentanes Fazit wäre, dass trotz Quicktime-Update für ein Resultat mit möglichst wenig Qualitätsverlust Quicktime vermieden werden sollte, auf dem PC noch immer besser der Weg über Frameserving gegangen sollte, auf dem Mac MPEG Streamclip mit optimalen Gamma-Mapping (sofern möglich).
Wer allein damit zufrieden ist, dass das Quicktime-Update das Clipping mehr oder minder verbessert hat und andere Faktoren eher in die theoretische Nische abstellt, findet mit dem Quicktime-Update natürlich schon eine einfache Lösung.
Für dich persönlich ist vermutlich eher die Mac-Seite von Bedeutung, oder?
Marco hat geschrieben:
Für dich persönlich ist vermutlich eher die Mac-Seite von Bedeutung, oder?
Marco
Ja, schon eher. Ich hab zwar noch diverse PCs, aber eben auch ein Macbook und ein paar ordentliche Mac Pro. Aber wenns nur auf dem PC bequem geht, dann eben PC.
MB
Ich will lieber mit Weisen irren, als mit Unwissenden recht zu behalten. (Cicero)
Auf Windows habe ich tatsächlich kein Clipping, auch nicht mit Quicktime 7.6. Aber die Resultate sind dennoch fragwürdig, mit Ausnahme der Frameserver-Methode.
Ich komme heute nicht mehr dazu Beispiele zusammenzustellen. Ich werd's morgen oder übermorgen nachholen.
Rechtliche Notiz: Wir übernehmen keine Verantwortung für den Inhalt der Beiträge
und behalten uns das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
