Hallo zusammen,
ich hoffe, ihr könnt mir ein wenig weiterhelfen. Ich komme eigentlich eher aus der Fotografie und mache derzeit ein paar Versuche, mal kleinere Filmchen zu schneiden. Mit Colormanagement für Bilder kenne ich mich halbwegs gut aus. Das Quellmaterial sind *.mov h264 Dateien aus einer Canon.
Im laufe der Zeit stellen sich mir ein paar Fragen, auf die ich nicht so einfache eine Antwort finde, da das Thema ja doch recht komplex ist. Ich weiß, dass diese drei Fragen vermutlich zu viel für diesen einen Thread sind. Wobei ich vermutlich noch viel mehr zu fragen wüsste. Evtl. könnt ihr einfach eure Antwort passend zu der Nummer geben.
Vielen lieben Dank
1)
Farbraum: In welchem Farbraum befinden sich Videos direkt aus einer DSLR? Ist das Rec709? Oder sogar srgb?
Die Videos scheinen ja deutlich zu gesättigt, wenn ich sie auf einem Widegamut Bildschirm in einem Player ohne Farbmanagement anschaue. In AE hat man ja z.B. die Möglichkeit ein Eingabe-Farbprofil für das Footage auszuwählen. SRGB oder Rec 709 scheinen am sinnvollsten.
2)
Die meisten Bildschirme sind ja auf Gamma 2.2 kalibriert oder liegen zumindest in der Nähe.
YouTube Videos oder auch die meisten Player verwenden ja nun mal kein Colormanagment für Videos. Das bedeutet für die Luminanz, dass eigentlich alle Videos hinterher beim Konsumenten mit einem Gamma von 2.2 dargestellt werden und nicht mit einer sRGB Gradation.
Nun frage ich mich, ob srgb oder Rec709 überhaupt überhaupt sinnvoll sind als Ausgabeprofil, da die srgb Gradation ja nicht mit Gamma 2.2 übereinstimmt.
Hinzu kommt, dass die meisten TVs und nicht kalibrierten Bildschirme, mal abgesehen von Wide Gamut Screens, mittlerweile einen doch schon deutlich größeren Farbraum als sRGB besitzen und Videos die in srgb oder Rec 709 ausgegeben werden bei vermutlich 80% der Konsumenten in nicht CM- fähigen Playern zu bunt erscheinen würden.
Welches wäre ein guter Farbraum bzw. Ausgabeprofil für eine spätere Ausgabe, die zu 90% auf das Internet abzielt?
3)
Ich habe das Gefühl, dass FullHD Videos auf meinem PC leicht ruckeln - so eine Art Microruckeln. Als wenn frames ausgelassen werden oder etwas ähnliches. Das passiert sowohl im VLC als auch im HCP. Evtl. tritt dieses Ruckeln auch bei kleinen Videos ein, sobald die auf Vollbildschirm ausgegeben werden. Gibt es eine Möglichkeit, das Ganze zu messen? Oder zu beurteilen? Ich habe von Cypheros ein paar Testbilder mit einem Pendel. Irgendwie stottert das ganze schon ganz ordentlich. Ich habe keine Codecpacks installiert, außer mal ffdshow getestet. Treiber sind alle aktuell - Chipsatz, Nvidia etc.
Bei den erweiterten Farbräumen ist in der Regel zwar auch eine erhöhte Farbsättigung festzustellen, aber das ist Nebensache. Im Grunde geht es um die Darstellung von Farben, die sich nicht mehr im „Zentrum" der ursprünglichen Farbmodelle befinden sondern über deren „Ränder" hinausgehen, also meist intensive Farben, die in der Natur selten vorkommen.
Es spielt in der Praxis daher keine große Rolle ob mit ohne ohne extendet-Color rausgerendert wird.
Abgesehen davon muss ein Video auf Youtube ja nur gefallen und wenn du selbst eine durchschnittlich gute Darstellung auf deinem PC erreicht hast, dann trimmst du m.E. die eigenen Videos halt auf diesen, nämlich deinen eigenen Standard hin.
Der Standard für Video ist in der Rec. 709 beschrieben (für HD). Das heisst, egal wo du herkommst (aus welchem Farbraum dein Material kommt), da musst du hin. TV aber auch Youtube erwarten Material nach diesem Standard und zeigen es dann auch "richtig" an. Meistens. Nicht immer. Das Luminanzspektrum von 709 (16-235) wird ja auf Computermonitoren auf das Spektrum 0-255 gemappt. Das funktioniert je nach Material (Codec) und Player nicht immer richtig. Einfluß hat man da eher weniger.
Ruckler: In VLC und anderen Playern kann man sich eine Statistik anzeigen lassen, die beinhaltet auch die ausgelassenen Frames. Sollten dort keine als ausgelassen angezeigt werden, können solche kleinen Ruckler auch durch die beiden unterschiedlichen Frequenzen von Video (50Hz) und Grafik/Monitor (60Hz) entstehen.
Farbraum von DSLR: was man so hört und liest, halten die sich an gar keine Farbraumdefinition. Nur ungefähr.
Es gibt zwei Gesetze, nach denen Video quantisiert werden.
Das ist einmal das "μ-Law", (http://de.wikipedia.org/wiki/Μ-law), das bei NTSC/ATSC Anwendung findet und das "A-Law" (http://de.wikipedia.org/wiki/A-law), das dem für europäische Anwendungen gefolgt wird.
Auf dem A-Law basiert REC 709, dem sich fast alle Kamerahersteller angeschlossen haben.
Canon macht da eine der Ausnahmen und folgt dem "μ-Law".
Das führt in der Konsequenz zu den Beobachteten Abweichungen im Bildeindruck, hervorgerufen durch die veränderte Lage der Gammkurve.
Was Gamma 2.2 betrifft, so schreibt REC 709 eine variable Bandbreite vor, weil ein fester Gammawert immer voraussetzt, dass der Monitor kalibriert ist, was für TV Anwendung aber alles andere als gegeben ist.
ich hab die Spanne jetzt nicht auf's Zehntel im Kopf, aber ich meine, es war von 1.8 bis 2.6 (unverbindlich). Daher sollten solche festen Werte immer nur unter der Prämisse verwendet werden, wenn es sich um professionelle Anwendungen und Equuipment handelt. (Was bei You-Tube bestimmt nicht der Fall ist).
;-)
Was das Ruckeln angeht, so magst Du Recht haben denn den neueren TV Monitoren fehlt natürlich genau das, was früher Standard war: Die Dunkelphase. -Sowohl beim Film, als auch bei der Röhre-.
Weicht man nun von den rechnerischen Grössen in Bezug auf die Bewegungsgeschwindigkeit im Verhältnis zum Pixelpitch und dem Shutter ab, dann entstehen genau diese Micro-Rucker.
Also, eine geschickte Auswahl der Parameter bei der Produktion minimiert solche Effekte.
Die Alternative wären Monitore mit einer Dunkelphase. Diese Monitore aber haben dann nur noch eine geringe Lichtausbeute und würden daher wenig Akzeptanz bei Consumern finden.
Im professionellen Bereich gibt es sie jedoch.
Hallo und danke ihr Lieben!
Ich merke, das ist ein sehr komplexes Thema.
@domain:
Ja, ich finde den Unterschied doch schon recht brutal. Wenn ich in srgb oder rec709 ausgebe und das auf einem Widegamut anschaue, dann gruseln mich die übersättigten Farben doch schon sehr. Aber das ist ja für die meisten User unvermeidbar mit einem zu großem Farbraum und ohne CM für Video.
@dienstag:Vielen Dank für die ganzen Infos.
Ich hatte mal ein Video in 709 (16-235) erstellt und auf sehr vielen Playern und vielen Rechnern wurde das Bild kontrastarm wiedergegeben. Wäre dann nicht die 0-255 für den PC, Youtube und andere Portale die sicherere Lösung?
Die verlorenen Frames werden im VLC mit 0 angezeigt.
Du schreibst von dem Unterschied zwischen 50Hz Video und 60hz Monitor. Da hätte ich aber doch keinen Einfluss drauf?
Kommt sonst evtl. noch etwas in Frage, oder gibt es eine Testmöglichkeit?
Danke schön!
@Wowu:
Ah okay, danke danke. Gäbe es denn ein geeigneteres Inputprofil für "μ-Law" als Rec709 für meine Canon Videos?
Mal angenommen, ich würde das Video nur an Personen mit einem auf Gamma 2,2 kalibrierten Bildschirm verschicken - also nicht für TV. Wenn ich nun mein Video im Rec.709 oder sRGB ausgebe (ich glaube die Gradation ist ja sehr ähnlich der sRGB Gradation), dann wäre das Video aber von vornherein bei allen Personen ohne Farbmanagement im direkten Monitorfarbraum in den Schattentönen dunkler?! So ist es zumindest bei einem einfachen Foto. Wenn ich ein Bild in sRGB ohne Konvertierung in einem Farbraum mit Gamma 2.2 betrachte (z.b. AdobeRGB), dann gehen viele dunkle Bildtöne verloren.
So wäre ich fast dazu geneigt Videos für das Web oder zum versenden in einem Farbraum mit Gamma 2.2 auszugeben. Dazu zählen sRGB und Rec709 dann ja leider nicht ganz, da die Gradation in den Tiefen etwas abweicht.
Vielen Dank!!! Das ganze ist schwer verständlich.
Moin Michael,
eigentlich ist das Thema nicht so schwer verständlich, man muss sich nur einmal damit beschäftigen.
Das Hauptproblem besteht eben darin, dass viele "in der Mitte" einsteigen und dann nur noch an den Ergebnissen "rumdoktern".
REC 709 schreibt -aus den erwähnten Gründen- kein festes Gamma vor, wissend, dass es für TV-Equuipment keine Gültigkeit haben kann.
Wohl aber geht es von einem Wert von 2.2 aus.
Aber das nutzt eben nur, wenn der Monitor sich auch daran hält.
Auf der Erstellungsseite liegst Du mit 2.2 also absolut korrekt.
Wenn man sie Konsequenz des von Canon benutzten "μ-Law" einmal betrachtet, so liegt sie im Wesentlichen in einem Y-Offset der Gammkurve, das durch die korrekte Wahl der Quantisierungslevel fast vollständig beseitigt werden kann. Das betrifft in weitem Maße auch die Farbsättigung, die damit ja unmittelbar zusammenhäng.
Was Du über die dunkleren Schattentöne sagst, ist natürlich richtig, nur dass Du dann eben auch, solange Du im oberen Bereich nicht in der Sättigung bist- dort den Gewinn hast.
Verschiebst Du die Kurve, veränderst Du deine "gewinn/verlust" Rechnung, um es mal so auszudrücken. Aber da sind wir dann im Bereich der geschmacklichen Korrektur.
Effektiv verlierst Du lediglich das, wozu es eigentlich mal gedacht ist, einen geringen Wert im SNR.
Aber im Ausblick auf UHDTV wird sich das alles sowieso erledigt haben, denn UHD arbeitet in einem deutlich grösseren Farbraum und bei 10 bzw. 12 Bit dürften sich auch die verschiedenen Kurven erübrigt haben.
Michael33 hat geschrieben:Farbraum: In welchem Farbraum befinden sich Videos direkt aus einer DSLR? Ist das Rec709? Oder sogar srgb?
Wenn der Hersteller nichts anderes angibt, dann würde ich zunächst sRGB/BT.709 annehmen. Der Farbraum, d.h. die Menge der darstellbaren RGB-Farben, von sRGB und BT.709 ist gleich. (Anmerkung: Unter Verwendung von YCbCr-Farben kann ein größerer Farbumfang untergebracht werden.)
Unterschiede gibt es nur bei der Signalisierung des Minimal- und des Maximalwerts der Farbkanäle (sRGB Min-Max: 0-255; BT.709-RGB Min-Max: 16-235), sowie der Übertragungsfunktion (wird auch als "Gamma-Kurve" bezeichnet).
Michael33 hat geschrieben:
Die Videos scheinen ja deutlich zu gesättigt, wenn ich sie auf einem Widegamut Bildschirm in einem Player ohne Farbmanagement anschaue.
Beim PC kann bisher davon ausgegangen werden, dass Programme sRGB ausgeben, wenn sie selbst kein Farbmanagement betreiben. Daher sind die Farben der normalen Programme ohne Farbmanagement auf Wide-Gamut-Displays übersättigt.
Am einfachsten wäre es daher, beim Display die sRGB Emulation zu aktivieren und im OS bzw. den CM-Systemen ein sRGB-Profil zu hinterlegen. Über sRGB hinausgehende Farben kann man dann natürlich nicht mehr darstellen.
Michael33 hat geschrieben:
YouTube Videos oder auch die meisten Player verwenden ja nun mal kein Colormanagment für Videos. Das bedeutet für die Luminanz, dass eigentlich alle Videos hinterher beim Konsumenten mit einem Gamma von 2.2 dargestellt werden und nicht mit einer sRGB Gradation.
Ein komplettes CM brauchen sie auch nicht. Im Grunde würde es genügen, wenn sie YCbCR korrekt nach RGB umwandeln, Minimal- und Maximalwert anpassen und die Übertragungsfunktion verändern.
Allerdings kümmern sich nicht alle Player darum. Beispielweise könnten sie eine Umrechnung von YCbCr nach RGB, wie sie für SD vorgesehen war, verwenden. Es könnte sein, dass sie nur die Minimal- und Maximalwerte der Farbkanäle anpassen und die Übertragungsfunktion ignorieren.
Michael33 hat geschrieben:
Nun frage ich mich, ob srgb oder Rec709 überhaupt überhaupt sinnvoll sind als Ausgabeprofil, da die srgb Gradation ja nicht mit Gamma 2.2 übereinstimmt.
In der Praxis ist es IMO noch immer eher ein Durcheinander.
Michael33 hat geschrieben:
Hinzu kommt, dass die meisten TVs und nicht kalibrierten Bildschirme, mal abgesehen von Wide Gamut Screens, mittlerweile einen doch schon deutlich größeren Farbraum als sRGB besitzen und Videos die in srgb oder Rec 709 ausgegeben werden bei vermutlich 80% der Konsumenten in nicht CM- fähigen Playern zu bunt erscheinen würden.
Das ist dann aber ganz einfach das Problem der einzelnen Betrachter. Wenn man nichts weiß, dann kann man derzeit nur ein sRGB-Display beim Betrachter annehmen. Man hat ja auch keine Ahnung davon, ob dieser es in den Einstellungen womöglich völlig verstellt hat, ob die Umgebungsbeleuchtung geeignet ist, usw.
Michael33 hat geschrieben:
Welches wäre ein guter Farbraum bzw. Ausgabeprofil für eine spätere Ausgabe, die zu 90% auf das Internet abzielt?
sRGB.
Michael33 hat geschrieben:
Ich habe das Gefühl, dass FullHD Videos auf meinem PC leicht ruckeln - so eine Art Microruckeln. Als wenn frames ausgelassen werden oder etwas ähnliches.
Wie stark ist das Ruckeln? Die Empfindlichsten sehen auch Unterschiede bei 50p auf 60p Displays. Sind es jedoch deutlichere Ruckler, dann könnte ein anderes Problem die Ursache sein.
Danke für die ausführlichen Antworten!
Das Ruckeln kann ich schwer beschreiben. Ich würde sagen es ist subtil, aber es ist eben nicht so flüssig wie im TV, also nicht so flüssig, als wenn ich mir das selbe Video über einen USB Stick am TV anschaue.
Folgende Problematik stört mich aber doch sehr.
Wenn ich ein Video in sRGB ausgebe und damit los-ziehe und mir das auf sagen wir mal 20PCs von Freunden etc. anschaue. Dann kann ich eigentlich sagen, dass bei allen die dunklen Grautöne etwas absaufen bzw. zu dunkel sind. Was ja darauf zurückzuführen ist, dass die meisten Bildschirme bzw. Windows und IOs ja alle grob mit Gamma 2.2 fungieren.
Nun habe ich mir einfach ein neues Farbprofil erstellt mit den Primärfarben von sRGB aber einem reinen Gamma von 2.2.
Wenn ich das Video in diesem Profil ausgebe, dann übersetzen sich die dunklen Bildbereiche deutlich besser auf Bildschirme mit Gamma 2.2.
Das ist mir sehr recht.
Leider kommt zu dem das Problem, dass vermutlich 80-90% der User, bei denen ich mir mein Video anschaue, einen Bildschirm mit einem größeren Farbraum als sRGB haben. Das variiert vermutlich von leicht größer als sRGB bis hin zu leicht größer als Adobe RGB (Eizo etc). So kann ich ebenfalls feststellen, dass auf fast allen Bildschirmen mein sRGB Video leicht zu bunt, bis deutlich zu bunt dargestellt wird.
Dem würde ich ebenfalls gerne etwas entgegenwirken.
Gibt es einen Farbraum/Profil, dass einen Gamma von 2.2 und einen Farbraum Gamut zwischen sRGB und Adobe RGB hat? So würde ich noch eine bessere Übersetzung erzielen. Ich meine, für mich macht es wenig Sinn in sRGB oder Rec.709 auszugeben, nur weil es irgendeine Norm ist, aber eigentlich wird es dann zu 90% in den Tiefen zu dunkel und dazu noch oft deutlich zu bunt dargestellt. Auch, wenn man argumentieren könnte, da sind die User doch selber Schuld....
Danke!!!!
Michael33 hat geschrieben:Wenn ich ein Video in sRGB ausgebe und damit los-ziehe und mir das auf sagen wir mal 20PCs von Freunden etc. anschaue. Dann kann ich eigentlich sagen, dass bei allen die dunklen Grautöne etwas absaufen bzw. zu dunkel sind. Was ja darauf zurückzuführen ist, dass die meisten Bildschirme bzw. Windows und IOs ja alle grob mit Gamma 2.2 fungieren.
Kann sein.
Kann aber auch sein, dass du in 0-255 ausgibst und die Player das fehlinterpretieren. Und das scheint mir deutlich wahrscheinlicher.
Ich habe gerade mal ein Testvideo in rec709 16-235 und rec709 ausgegeben.
Das Video in 16-235 ist auf 3 PCs sowohl im VLC als auch im MPC (in Standardeinstellungen) im Schwarzwert nur noch Grau und das weiß ist ebenfalls kein richtiges weiß.
Das sowohl als h264 mp4 als auch wmv und quicktime.
Auch beim Upload auf youtube bleibt es grau.
Was mache ich falsch, wenns daran liegen sollte?
Als mp4 (h264) auf Youtube sollte es so funktionieren.
Aus den Adobe-Programmen heraus exportiert ist es aber meines Wissens wieder anders richtig. Mit was arbeitest du?
Ist ein weites Feld, der Farbraum Workflow am Computer.
in welchem Programm schneidest du? ich nehm mal an in Premiere...
Zieh dir mal einen Fast Color Corrector auf deinen Clip, lass deine Input Levels auf 0-255 und stell die Output Levels auf 16-235, dann solltest du wieder "richtiges" weiss und schwarz bekommen - soweit ich das verstanden hab wird dabei der gesamte Dynamikumfang des Bildmaterials von Weiss bis Schwarz in 16-235 "reingequetscht", sodass der gesamte Dynamikumfang in "rec709 16-235" richtig dargestellt werden kann.
Also, wenn ich ehrlich bin, für Premiere und After Effects muss ich passen, zumindest was h264 angeht. Damit funktioniert es auf Youtube schonmal nicht (irgendwelche abstrusen Farbkorrekturen in Premiere mal aussen vor gelassen, das kann für einen ordentlichen Workflow überhaupt keine Alternative sein).
Was funktioniert, für den Upload einen Codec verwenden, der Farbrauminformationen übergibt. Ich habe es mit Avid DNxHD getestet - geht.
Ich hatte das mit den Adobe-Produkten noch im Hinterkopf, dachte aber, es zuletzt eigentlich hinbekommen gehabt zu haben. Aber egal.
Ich verwende sonst immer Sorenson Squeeze, da funktioniert auch die Ausgabe mit h264. Spart Datenrate beim Upload.
WoWu hat geschrieben:Farbrauminformationen werden in H.264 auch übergeben.
Mag sein. Oder sogar sicher. Aber eben nicht aus den Adobe-Produkten heraus (bei AE steht es sogar explizit unter den Color Managment Einstellungen).
Mit Sorenson geht es ja auch, ein kleiner Klick auf "Set Black Normalisation Level to 16" und - voila.
MPEG würde gar nicht ohne diese Metadaten im Header funktionieren, weil sie mendatory sind und die Decodierung darauf basiert.
Denn der Decoder ist zunächst einmal "dumm" und führt nur das aus, was ihm anschliessend im TS/PS oder dem Metadatenfolder mitgeteilt wird.
[quote="WoWu"]
Auf dem A-Law basiert REC 709, dem sich fast alle Kamerahersteller angeschlossen haben.
Canon macht da eine der Ausnahmen und folgt dem "μ-Law".[/quote]
Gibt es für diese zwei Behauptungen irgendwelche Quellen?
Du must Dir eigentlich nur die Lage der Gammakurven der einzelnen Kameras anschau'n.
Daran kannst Du schon sehen, wer nach welchem "Law" arbeitet.
Von Canaon gibt es auch ein umfangreiches "whitepaper" dazu (hab den Link nicht griffbereit).
Ansonsten gibt es genügend SMPTE Papier zum Thema 709, weil das ja bereits in den 90er Jahren standardisiert wurde und eigentlich ein "alter Hut" ist.
Da gibt es also eine wahre Papierflut drüber.
Es geht bei beiden Gesetzen um Quantisierung.
Der ist es ziemlich egal, ob da Video oder Audio drin steckt. :-)
Es geht genau darum, wie die Quantisierungskurve den Nulldurchgang schneidet.
In der Konsequenz führt das dazu, dass sich (bei Video) das Verhalten im Schwarzbereich ändert und die Kurve im Verlauf ins Minus geht.
Das hat entsprechende Konsequenzen für den Störabstand, der sich bei einer entsprechenden Korrektur in der Wiedergabe verbessert.
Ich müsste für die Links ebenso wieder recherchieren, wie Du.
Wenn ich sie bei Gelegenheit finde, schick ich sie Dir -sofern Deine Profil irgendwie einen Kontakt zeigt-.
In der Anlage habe ich Dir mal den generellen Unterschied aufgezeigt.
Eigentlich kommt da nicht mal das Wort Law im Dokument vor.
Bei einer Suche nach [Canon "μ-Law"] über Google.com sind bei den ersten zehn Treffern neun mit der μ-Law > G.711 (Audiocodec!) Beziehung. Ein Treffer ist dann unsere kleine Diskussionsrunde hier.
Michael33 hat geschrieben:Ich habe gerade mal ein Testvideo in rec709 16-235 und rec709 ausgegeben.
Das Video in 16-235 ist auf 3 PCs sowohl im VLC als auch im MPC (in Standardeinstellungen) im Schwarzwert nur noch Grau und das weiß ist ebenfalls kein richtiges weiß.
Das sowohl als h264 mp4 als auch wmv und quicktime.
Auch beim Upload auf youtube bleibt es grau.
Was mache ich falsch, wenns daran liegen sollte?
Mach einfach gar nichts.
Die Canon DSLR zeichnet YUV BT.709 auf (16-235), was nach RGB korrekt in 0-255 mündet. Du bekommst also den vollen Farbumfang mit ausgewogenen Verhältnissen auf den RGB-PC-Monitoren zu sehen.
Bei der Wiedergabe auf PCs sind in erster Linie die Player für die Unterschiede verantwortlich. Betrachte mal das selbe Video nebeneinander auf dem selben Monitor in Quicktime, VLC und Windows Media Player - signifikante Unterschiede.
Welche Player Benutzer verwenden oder in Web-Applikationen zum Einsatz kommen, und welche Hardware sie einsetzen, kannst Du nicht steuern. Es macht daher keinen Sinn, das Video auf eine bestimmte Konfiguration (Player/Grafikkarte/Monitor nebst höchst invidueller Settings) abzustimmen.
Wenn Du in AE den Farbraum des Arbeitsbereichs auf RC.709 16-235 zwingst, wird es in der RGB-Darstellung keine Werte 0-15 und keine 236-255 geben, was auf dem PC-Monitor zu hellem Schwarz und zu dunklem Weiß führt. Willst Du wohl eher nicht.
Wenn Dir die Farben für Deine Zwecke zu satt erscheinen, ist der Weg der: Bereits bei der Aufnahme mit den Canon DSLRs Sättigung und Kontrast etwas absenken (User defined Preset / Picture Style erzeugen; es gibt auch fertige Presets dafür, beispielsweise: http://web.canon.jp/imaging/picturestyl ... amera.html) und in der Post motivabhängig nachbearbeiten.
Beste Grüße,
Reiner
Zuletzt geändert von Reiner M am Mi 02 Okt, 2013 13:28, insgesamt 1-mal geändert.
Reiner M hat geschrieben:Die Canon DSLR zeichnet YUV BT.709 auf (16-235), was nach RGB korrekt in 0-255 mündet.
Falsch. 16-235 sind natürlich RGB Werte und bleiben deshalb auch 16-235. Für die Ausgabe auf dem Computerdisplay werden die Werte auf dessen Farbraum umgemapped (Color Profile), dann sind sie 0-255. Das ist halt bissel verwirrend, aber wenn man schon was erklärt...
Reiner M hat geschrieben:Wenn Du in AE den Farbraum des Arbeitsbereichs auf RC.709 16-235 zwingst, wird es in der RGB-Darstellung keine Werte 0-15 und keine 236-255 geben, was auf dem PC-Monitor zu hellem Schwarz und zu dunklem Weiß führt. Willst Du wohl eher nicht.
Auch falsch. Solange man innerhalb eines Farbraums bleibt, passiert gar nichts. Erst bei Farbraumwechsel, bspw. bei Im- oder Export, kann es zu Veränderungen kommen. Also, innerhalb eines Farbraums arbeiten und das File mit diesem Farbraum exportieren schneidet nichts ab. Klebt auch nichts ran ;)
Reiner M hat geschrieben:Die Canon DSLR zeichnet YUV BT.709 auf (16-235), was nach RGB korrekt in 0-255 mündet.
Falsch.
Die Canon DSLR zeichnet YUV BT.709 auf (16-235), was nach RGB korrekt in 0-255 mündet.
Den Unterschied zu RGB solltest Du kennen. Und auch, wie YCbCr nach RGB gemappt wird!?
dienstag_01 hat geschrieben:
Reiner M hat geschrieben:Wenn Du in AE den Farbraum des Arbeitsbereichs auf RC.709 16-235 zwingst, wird es in der RGB-Darstellung keine Werte 0-15 und keine 236-255 geben, was auf dem PC-Monitor zu hellem Schwarz und zu dunklem Weiß führt. Willst Du wohl eher nicht.
Auch falsch. Solange man innerhalb eines Farbraums bleibt, passiert gar nichts.
Die Canon DSLR zeichnet YUV BT.709 auf (16-235), was nach RGB korrekt in 0-255 mündet.
Ich hatte das aber so verstanden, dass kein Farbmanagement stattfindet. (er es nicht benutzt)
Dann ändert sich am Mapping überhaupt nicht.
Und "automatisch" schon gar nicht.
YUV nach RGB ergibt die identischen Mappingwerte, bis auch die Wandlingsfehler.
Es ist einfach hoffnungslos.
Aber egal, ich fang jetzt nicht wieder an, alles von der Ursuppe an zu erklären. Bringt ja eh nichts ;)
Man sollte eben nur den Arbeitsfarbraum nicht mit dem Anzeigefarbraum verwechseln. Oder in einen Topf schmeissen.
WoWu hat geschrieben:Ich hatte das aber so verstanden, dass kein Farbmanagement stattfindet.
Reiner M. will hier sagen, dass 16-235 bei der Conversion von YUV (mal verkürzt) nach RGB in 0-255 umgeschrieben werden. Und zwar als Standard. Totaler Unfug. Aber weil er immer in seine Adobe Produkte starrt...
Es gibt halt immer solche, die nichts von Theorie halten und lieber an den "Knöpfchen" drehen, bis es (so ungefähr) passt.
Das ist halt die "Alternativmethode".
WoWu hat geschrieben:
Ich hatte das aber so verstanden, dass kein Farbmanagement stattfindet. (er es nicht benutzt)
Dann ändert sich am Mapping überhaupt nicht.
Genau.
Und daraus folgt?
Mal so ausgedrückt: Das PAL Signal der Canon DSLRs liegt exakt zwischen 0 und 700mV (Y 16 bis 235; Y nicht RGB). Füllt also ideal den bildgebenden Bereich. Nichts drunter, nichts drüber.
AM PC wird dieser Bereich völlig korrekt nach RGB 0-255 übertragen. Fertig. Alles ist gut. Top Bild.
Und deshalb: Nichts an den Projekteinstellungen oder am Farbmanagement ändern! Das ist Spezielfällen vorbehalten. Die liegen hier nicht vor. Er will ja ganz einfach Videos für PC/Web herstellen ... total easy.
-----
WoWu hat geschrieben:
Es gibt halt immer solche, die nichts von Theorie halten und lieber an den "Knöpfchen" drehen, bis es (so ungefähr) passt.
Das ist halt die "Alternativmethode".
Genau. Die funktioniert aber: Kann auch jeder Zeit nachgestellt werden, macht, was es soll und ist auch übrigens exakt das, was der TO beobachtet hat.
Während die "theoretischen" Beiträge entweder nichts bringen oder sogar komplett in die Irre führen. ;)
BTW:
Hast Du eine Canon DSLR?
Hast Du AE?
Dann probiers aus ...
Beste Grüße,
Reiner
Zuletzt geändert von Reiner M am Mi 02 Okt, 2013 14:41, insgesamt 1-mal geändert.
Eigentlich kommt da nicht mal das Wort Law im Dokument vor.
Bei einer Suche nach [Canon "μ-Law"] über Google.com sind bei den ersten zehn Treffern neun mit der μ-Law > G.711 (Audiocodec!) Beziehung. Ein Treffer ist dann unsere kleine Diskussionsrunde hier.
Da werde ich wohl dumm sterben müssen.
Kai
Moin Kay
Die Suche nach REC 709 sollte keine Schwierigkeit bereiten und Du wirst massig Material darüber finden.
Die Suche nach μ-Law mag sich etwas schwieriger gestalten, weil die eigentliche Gesetzmässigkeit eher von Interesse für Chiphersteller ist.
- Aber noch einmal zum Verständnis. Es geht hier um Quantisierung.
Bei Quantisierung ist es aber völlig egal, ob es sich am Eingang um ein Video- oder um ein Audiosignal handelt.
Denn μ-Law ist gleichfalls auch die Grundlage nach der PCM quantisiert und auch für Telefonübertragung codiert wird.
Es ist also eine Quantisierungsvorgabe, auf die sich die ITU (International Telecommunication Union) aus Gründen eines veränderten Störabstands entschieden hat.
Edit:
Wenn Du Dein Profil um eine WEB Seite erweiterst, über die ich Dich erreichen kann, schicke ich Dir Material aus meinem Archiv.
Kommt nur mir das so vor, oder schwafelt der Forumsteilnehmer WoWu sich hier ziemlich einen ab?
Fakten:
-"μ-Law" & "A-Law" haben was mit Audiosampling, -quantisierung & -komprimierung zu tun.
- die haben (bis zum Beweis des Gegenteils) auch wirklich gar nichts mit der REC 709 zu tun.
- Was Canon da also anders machen soll, ist weiterhin unklar.
Tja, das kommt davon, wenn man nicht mal anständig recherchieren kann/will.
Edit:
Ich hab mal rasch geschaut, ob es wirklich zu schwer ist, Infos zu finden, oder ob man dazu nur nicht in der Lage sein muss.
Einmal den Suchbegriff gegoogelt und
An ITU standard for converting analog data into digital form using pulse code modulation (PCM). A-Law uses a companding technique that provides more quantizing steps at lower amplitude (volume) than at higher amplitude. Europe uses A-Law, while North America and Japan use mu-Law (µ-Law).
Die Puls-Code-Modulation (Abkürzung PCM) ist ein Pulsmodulationverfahren, das ein zeit- und wertkontinuierliches analoges Signal in ein zeit- und wertdiskretes digitales Signal umsetzt. Es wird beispielsweise in der Audiotechnik im Rahmen des G.711-Standards und in der Videotechnik für digitale Videosignale nach dem Standard ITU-R BT 601 verwendet und bildet die Basis für Digitalaudio-Anwendungen, deren bekannteste die Compact Disc ist.
Aber vielleicht kennst Du ja auch den Unterschied zwischen 601 und 709 nicht, aber das schenke ich mir jetzt, weil es in diesem Zusammenhang nicht relevant ist.
Wenn Du also schon nicht den Unterschied zwischen einem "Gesetz" und einer Anwendung kennst, mach bitte nicht Andere für Dein Defizit verantwortlich.
Um es einfach zu sagen ... bei Dir wird z.B. das Ohm'sche Gesetz auch nur für eine Anwendung benutzt, wenn ich Dich richtig verstanden habe.
Also, mein lieber Kai, wenn man schon keine Ahnung hat, sollte man nicht den dicken Max machen sondern sein Wissensdefizit auffüllen.
Reiner M hat geschrieben:Mal so ausgedrückt: Das PAL Signal der Canon DSLRs liegt exakt zwischen 0 und 700mV (Y 16 bis 235; Y nicht RGB). Füllt also ideal den bildgebenden Bereich. Nichts drunter, nichts drüber.
AM PC wird dieser Bereich völlig korrekt nach RGB 0-255 übertragen. Fertig. Alles ist gut. Top Bild.
Wenn du geschrieben hättest, es wird so angezeigt, dann gut. So aber ...
Da ich eine Canon habe, die Adobe-Suite und auch noch Avid, hab ich mir mal folgenden Spass gemacht:
Vier Bilder, jeweils zwei aus Avid und Premiere. Canon Material importiert. Wie sehen die Kurven aus? Schon gleich oder. Es gibt einen kleinen Unterschied: im Avid gibt es eine Binärskala, und die zeigt 16 und 235 für 0 und 100 Prozent an. Alles andere wäre auch Quatsch. Und warum, glaubst du, lässt Premiere diese Skala weg?! Weils einfach falsch wäre, 0 und 255 anzugeben, es sind nunmal nur 16-235.
Im Ergebnis hätte man aber am Computer mit 16-235 nur ein flaues Bild, deshalb muss es an irgendeiner Stelle auf diese Werte gemapped werden. Bechäftige dich doch an dieser Stelle mal mit Farbmanagment in After Effects und Display Profile. Vielleicht klingelts dann bei dir.
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
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.
