@freezer
Mit abschneiden in Premiere meine ich, die kann man nicht sehen. Wenn ich sie nach unten ziehe, sehe ich sie logischerweise wieder ;)
Hast du einen besseren Begriff als *abschneiden*?
Sind halt unsichtbar ;)
Wie sieht es denn mit Sony- oder Canon-8-Bit-Log-Material aus? Da scheint ja immer auch mehr da zu sein an Höhen als man zunächst direkt sieht. Nutzen die auch zusätzlichen diesen Superwhite-Bereich? Oder "nur" den üblichen Range?
dienstag_01 hat geschrieben:Premiere zeigt Werte oberhalb von 1 (und das ist 235) alle als Weiss. Mich würde mal interssieren, ob das Programm *versteht*, dass bei der GH4 jetzt auf einmal diese Werte *sichtbar* seien sollen ;)
Premiere schneidet das Superweiß nur ab, wenn Du die Sequenz nicht auf maximale Bittiefe gestellt hast.
Gehe in die Sequenzeinstellungen und aktiviere unten rechts "maximale Bittiefe". Nun leg einen Videofilter wie Luminanzkurve oder RGB-Kurven auf Deinen Clip und zieh mal den oberen Endpunkt der Kurve runter und schau was die RGB-Parade dann macht - plötzlich ist wieder Zeichnung da.
Stimmt.
Bei After Effects kommen die wenn ich auf 32-Bit stelle auch wieder. Bei 16 interessanter Weise nicht.
-paleface- hat geschrieben:Bei After Effects kommen die wenn ich auf 32-Bit stelle auch wieder. Bei 16 interessanter Weise nicht.
Vielleicht haste einfach nur deinen Monitor zu hell eingestellt ;)
Im Ernst, mir ist schon weiter oben aufgefallen, dass du in AE die Lumawerte angeblich nicht siehst. Da dürftest du der einzige sein. Der verlinkte Clip (Luma_0-255) muss natürlich in AE richtig zu sehen sein. Ist er bei mir auch.
Schon zuviel dran rumgedreht?
Es ist ja kein Wunder, dass dieses Thema schon seit Generationen für hunderte Thread-Seiten gesorgt hat, wenn schon die verschiedenen NL-Editoren, wenn auch u.U. durch spezielle Einstellungen verschieden reagieren können, weiters auch die div. Viewer und erst recht die Wiedergabegeräte. Alles ziemlich undurchsichtig vor allem auch im Zusammenspiel.
Nur eines erscheint mir klar: eine begrenzende 16-235 Aufzeichnung schon in der Kamera kann nicht sinnvoll sein, wer geht bei 8 Bit schon freiwillig auf ein gröberes Quantisierungsmuster?
Null bis 255 erscheint mir anderseits auch nicht optimal, denn was außer Rauschen findet man denn schon unter 16?
16-255 kommt mir daher eher sinnvoll vor.
Abgesehen davon würde es mir nie einfallen, ein nicht standardisiertes Superweiß rauszurendern, denn so selten gebe ich meine Videos auch wieder nicht weiter.
schon die gh2 macht 16-255, 1. korrekturschritt in premiere, das auf 235 runterziehen.
jedoch bin ich auch bei wowu, ein mapping in 8bit, ist auch nicht das wahre.
mich würde ein vergleich interessieren, welche methode bringt mehr bild-qualität/(-realität?) 0-255 zu 16-235 oder direkt 16-235 oder wie verhält sich der gewinn an werten gegenüber der distortion der werte durchs mapping?
Ich frage mich gerade wie man das beantworten soll. Auf die Antworten bin ich gespannt - weil mir fällt da kaum ein Weg sowas schnell und einfach zu vermessen und zu beantworten.
srone hat geschrieben:nun ja, testtafel und eine gh4 mit einer guten festbrennweite, bearbeitung premiere zb, dann final differenzbild.
Ja klar - aber das fällt halt nicht mehr so ganz unter die Kategorie "schnell und einfach". :)
Zumindest nach meinem Empfinden.
Und ob Premiere dafür geeignet ist - hat es nicht geheißen dass das Superweiß wegschneidet?
ja, deswegen korrigiert auf 16-235 für die finale ausgabe, schlussendlich geht es ja, um die qualität der 0-255 auf 16-235 anpassung, bzw um die frage, ergibt das ein besseres bild als 16-235 "unbearbeitet"?
wolfgang hat geschrieben:Und ob Premiere dafür geeignet ist - hat es nicht geheißen dass das Superweiß wegschneidet?
Macht jedes NLE.
Lies dir nochmal den Vergleich durch, den Srone machen will.
Ich denke, du wirst es nie verstehen. Superweiss, wer sowas schon schreibt ;)
Edit:
Ich versteh ja, dass es nicht so ganz einfach ist, nachzuvollziehen, dass 235 im Video auf einem Bildschirm Weiss ist, der aber sagt, dass ist 255. Aber *irgendwann* sollte man es dann doch mal durchdrungen haben. WEISS ist WEISS, und weisser als WEISS geht nicht. Auch bei 10bit ist WEISS WEISS. Was ich gewinnen kann, sind mehr Lumawerte ZWISCHEN Schwarz und Weiss, aber die ändern nichts am Schwarz- oder Weisswert. Deshalb sind Begriffe wie SUPERWEISS reine Marketingbegriffe und eines halbwegs mit Videotechnik Vertrauten eigentlich unwürdig. Und, um das gleich vorwegzunehmen, die Lumawerte, die man gewinnt (bei 10bit oder weil man in 8bit bis 255 aufnehmen kannt), werden für eine Ausgabe in 8bit für Video mit Rec709 natürlich wieder auf dieselben Werte gestaucht (verringert), als hätte man sie bei der Aufnahme gar nicht zur Verfügung gehabt.
Wenn die Cam 0-255 liefert, steht das auch in Premiere Pro zur Verfügung.
Wegen der Begrifflichkeit "wegschneiden":
Es gibt zwei Wege, um auf 16-235 zu trimmen, die nicht verwechselt werden dürfen. Einmal durch "Wegschneiden", also Löschen der Infos außerhalb 16-235 (geht ja tatsächlich), und einmal durch Stauchen der Lumakurve. Wegschneiden macht natürlich keinen Sinn.
-----
Zur Frage nach mehr Bild-Qualität/-realität:
Technisch liefert wohl die direkte 16-235-Aufnahme das bessere Ergebniss, wenn man Auslassungen, Sprünge und Verdichtungen in den Wertebereichen nicht mag. Die Stauchung lässt sich eben in einem Integer-Wertebereich nicht so linearisieren, dass sie einer 16-235- Wave gleichkommt.
Visuell liefert m.E. die 0-255-Aufnahme das bessere Ergebnis bzw. die bessere Ausgangssituation für bessere Ergebnisse. Also durchaus mehr Realität. Was aber akribische Nacharbeit bedeuten kann. Pauschal auf 16-235 stauchen hieße, die Vorteile gerade nicht nutzen und das Ziel verfehlen.
Insgesamt ist das wohl aufnahme-/motiv-/belichtungsabhängig.
Beispiel: In einem Clip existieren weder Tiefen noch Lichter. Kommt häufig vor. Die 0-255-Aufnahme muss gar nicht gestaucht werden. Alles im sichtbaren Bildbereich vorhanden. Sie wird gegenüber der 16-235-Aufnahme wohl das bessere Bild liefern, weil der Luma-Bereich breiter ist, in dem sich das eigentliche Motiv befindet. Folge: technisch perfekt (nicht gestaucht), jedoch mehr Farben, mehr Details, also mehr Realität in diesem Fall.
Nein nicht jede NLE schneidet automatisch Superweiss weg. Denn womit meinst du hat dir der sehr geduldige User viramedia extra für dich (!) die Files mit einmal 0..255 und einmal mit 16..235 erstellt und ins Netz gestellt? Na mit dem Hex editor sicher nicht. Es gibt also NLEs die es wahlweise so oder so können und machen.
Ich habe sehr wohl verstanden was der Kollege will. Es steht dir ja frei die hier gewünschten Tests zu machen wenn dir das auch klar ist.
Mich interessieren die Fragestellung von ihm eher weniger. Einfach weil ich nicht von der altmodischen Denke ausgehe dass man koste was wolle die Endausgabe auf 16..235 den Lumabereich beschränken muss. Ich verstehe dass ich für die meisten meiner Zwecke sehr wohl in 16..255 filmen, schneiden und ausgeben kann - und dann habe ich seine Fragestellung halt eher selten. Und für andere wenigen werden die meist wenigen Hochtöner halt mal beschnitten oder gestaucht - denn so dominant sind die maximal bei Winterlandschaften oder in der Wüste. Und bei 10bit hört sich das eh ziemlich alles auf.
Zu vergessen warum wir das überhaupt diskutieren heisst halt das eigentliche Problem ignorieren. Und das ist lediglich das Vermeiden von Clipping.
Aber jemand der sich schon vom Wort Superweiss fürchtet - der einfach nur dagegen ist - na der wird das halt aufgrund seiner Emotionalität tatsächich nicht verstehen können.
Wenn der Lumabereich eher schmal ist - was oft vorkommt - wird man entweder beim Filmen bereits den Bereich verbreitern; was die bessere Wahl ist. Sonst hat man weder was vom nicht genutzten Luma Bereich noch einen ausreichenden Kontrast. Das geht auch mit flachen Gammakurven in die man eingreifen kann recht gut. Oder man muss sich den Kantrast in der Postpro holen - aber dann hat man halt nur den schmalen Lumabereich. Aufdehnen ohne ins Clipping zu kommen ist daher meist der bessere Weg.
wolfgang hat geschrieben:Denn womit meinst du hat dir der sehr geduldige User viramedia extra für dich (!) die Files mit einmal 0..255 und einmal mit 16..235 erstellt
Das mit 0-255 hab ich wohl verpasst ;)
Zumindest ist das File, was so heisst, einfach 16-235.
Wird dir aber nicht auffallen. Dem Kollegen von dir ist das aber schon bewusst, darüber denk mal nach.
srone hat geschrieben:schon die gh2 macht 16-255, 1. korrekturschritt in premiere, das auf 235 runterziehen.
jedoch bin ich auch bei wowu, ein mapping in 8bit, ist auch nicht das wahre.
mich würde ein vergleich interessieren, welche methode bringt mehr bild-qualität/(-realität?) 0-255 zu 16-235 oder direkt 16-235 oder wie verhält sich der gewinn an werten gegenüber der distortion der werte durchs mapping?
lg
srone
Gegenfrage: welchen Vorteil bring eine "theoretische" Erweiterung des Werftenbereiches, die man hinterher wieder staucht ?
Und "Superweiss" gibt es nur da, wo eine falsche Signalisierung stattfindet, denn in 709 ist FullWell auf 235 gemapped.Und woher soll das zusätzliche Weiss kommen ? Das entsteht nur da, wo Monitoren nicht signalisiert wird, dass sie 709 bekommen und dann auch 255 brauchen, um weiss zu werden.
Und ob die Kameras wirklich mehr Werte erzeugen, denn die können sie ohnehin erst ab 240 erzeugen, denn bis dahin geht Chroma von 709, das steht noch auf einem andern Blatt.
Es kann ebenso gut sein, dass die Kameras nur anders mappen.
Und weil unsern Content Kunden auf TV Geräten zu sehen bekommen, die das Signaling richtig verstehen, machen wir Bilder, die garantiert auch beim Kunden gut ankommen.
Und wenn dann jemand mit einer Computergurke schaut, die die Programmstromheader nicht richtig auslesen, soll uns das recht sein.
Also: es gibt einen Standard, der seit nun rd. 20 Jahren bestens funktioniert und ich habe noch keine schlagenden Gründe gefunden, davon abzuweichen.
Speziell nicht, weil weiss nicht weisser wird und nicht klar ist, ob man überhaupt zusätzliche Farbwerte bekommt.
Und wenn ich das möchte, dann mache ich x.v.YCC, da hat man nämlich wieder die richtige Signalisierung im Datenstrom und erhält auch mehr Chromawerte .. und ist sogar noch kompatibel zu 709.
Es gibt also für Beides eine anständige Lösung.
Alles andere ist, in meinen Augen, ziemliches Gebastelt.
wolfgang hat geschrieben:Aufdehnen ohne ins Clipping zu kommen ist daher meist der bessere Weg.
Die Lösungswege für mein Beispiel in der Post sind klar, Wolfgang.
Bei einer 0-255-Aufnahme muss ich in diesem Fall aber weniger spreizen, habe mehr Details im Bild und werde auch dann das bessere Ergebnis erzielen. Es ging ja nur um den Unterschied, nicht um Problemlösungen.
Ich denke, dass diejenigen, die ihre 0-255-Aufnahmen ohne Rücksicht auf die Waverform und auf das Motiv auf 16-235 stauchen - oder womöglich sogar hart beschneiden! -, die Vorteile, die in ihren Aufnahmen stecken, zerstören, bevor sie nutzbringend verwendet werden können. Wenn sie wissen, was sie da tun und mit dem Ergebnis zufrieden sind, ist alles gut. Der Kunde oder Konsument weiß eh nicht, dass ein anderes Ergebnis hätte erzielt werden können. ;)
Kann mir mal einer erklären, seit wann wir für Web 16-235 brauchen?
Youtube und Vimeo erwarten doch wohl RGB von 0-255, abesten als h.264 oder täusche ich mich?
Auf welchem Level arbeitet Premiere intern, also was sind dort im Waveform "100%"? Was exportiert Premiere, wenn man eine Standard mpeg2 exportiert? RGB oder 601/709?
Ich verstehe sowieso die ganze Aufregung nicht, denn selbst wenn man 255 übertragen würde, hat man noch keinen einzigen zusätzlichen Farbwert, weil man sich noch im selben Farbraum bewegt.
Benutzt man x.v.YCC hingegen, hat man 1,8 mal soviele Farbwerte weil man sich in einem erweiterten Farbraum beweg. Ausserdem hat man standardisierte Signalisierenden, die auch der AVC-Codec unterstützt.
Diese Werteerweiterung von 240 auf 255 ist nicht anderes, als ein Mappen innerhalb der Tabelle, die nirgend korrekt signalisiert wird, keinen einzigen zusätzlichen Farbwert bringt und zu etlichen Problemen führt.
Was diese "Bastelei" eigentlich soll, kann vermutlich auch keiner sinnvoll begründen. ... Das ist einwenig wie "möglichst viele Pixels"...
WoWu hat geschrieben:Diese Werteerweiterung von 240 auf 255 ist nicht anderes, als ein Mappen innerhalb der Tabelle, die nirgend korrekt signalisiert wird, keinen einzigen zusätzlichen Farbwert bringt und zu etlichen Problemen führt.
Naja, eigentlich könnten die GH4 Besitzer mal posten, was Panasonic ihnen dazu ins Manual geschrieben hat.
You can set the luminance range for motion pictures. When you combine multiple materials into a single motion picture, set a range that covers all materials.
MENU > [Motion Picture] > [Luminance Level] Settings: [0s255]/[16s235]/[16s255]
This function works only for motion pictures. Still pictures (including those you take during motion picture recording) will be taken with [0s255].
• When [Rec Format] is set to [AVCHD] or [MP4], [0-255] in [Luminance Level] will switch to [16-255].
Aber das ändert ja nichts daran, dass sie keinen erweiterten Farbraum haben, weil 255 nicht gleich einem grösseren Farbraum entspricht.
Dann doch lieber x.v.YCC, da hat man wenigstens ein weiteres Farbspektrum.
Das hier sorgt nur dafür, dass Weiss an einen andern Wert gemapped wird.
Natürlich hat man einen Vorteil, wenn man in 0-255 filmt.
Beispiel: Filme ich in 16-235 und habe dann bei ungünstigemLicht einige Aufnahmen, die zu wenig Helligkeitsdynamik haben und somit zu flau aussehen, dann möchte ich diese nachträglich verbessern. Ziehe ich diese aber auf, dann verschlechtert sich die Bildqualität und ich bekomme ggf. auch noch Banding ins Bild.
Filme ich aber in 0-255, dann ist die Helligkeitsdynamik in der Aufnahme bei gleichem Motiv bereits höher. So muß ich bei der Endausgabe 16-253 gar keine Dynamik aufziehen, sondern nur die "unbelichten" Teile bei Weiß und Schwarz "abschneiden".
Klar, daß ich bei allen gut belichteteten Clips dafür aber die Helligkeitsdynamik verringern muß, aber die Luminanz-Dynamik zu verringern bringt keine Bildqualitätsverschlechterung und auch kein Banding.
Also: Selbst wenn die GH4 in einem Clip mal tatsächlich den ganzen Bereich von 0-255 ausnutzt bringt eine Änderung auf 16-235 (oder 241) keine Verschlechterung.
Filme ich aber gleich in 16-235, und muß dann die Luminanz aufziehen (sprich die Luminanz-Dynamik erhöhen), weil die GH4 das Motiv zu flau belichtet hat, dann verschlechtert sich die Bildqualität sehr wohl (im schlimmsten Fall handle ich mir dadurch sogar Banding ein).
Also filme ich grundsätzlich mit 0-255 (wenn's die Cam denn möglich macht), und habe somit immer Bearbeitungsreserve (ohne Gefahr von Bildqualitätsverlusten, weil ich die Luminanz-Dynamik immer nur verringern (oder abschneiden oder auch nur im Schwerpunkt verschieben) muß.
Das ist leider ein Trugschluss, weil FullWell des Sensors die Dynamik bestimmt und der Wert ist einmal auf 235 gemapped und das andere Mal auf 255. Die Dynamik ist in beiden Fällen identisch denn die wird nicht durch das Mapping bestimmt.
Aber andere Frage ... wenn Du mehr Werte haben möchtest, warum benutzt Du nicht x.v.YCC, da hast Du auch gleich noch einen erweiterten Farbraum mit fast doppelt so vielen Farbwerten ?
Warum das Gebastelt, was gar nix bringt ?
Letztlich..ja.
Mir ist nur nicht klar, ob sie da YCbCr nehmen oder RGB. letzteres hätte ja auch noch andere Auswirkungen z.B. auf die IntDCT, die in AVC benutzt wird, aber ich denke, dass sie schon den Vorteil der neuen DCT nutzen werden und damit bei YCbCr bleiben.
Man müsste so ein Signal mal untersuchen, was sie da eigentlich machen.
Mich würde auch interessieren, was sie an die Folgegeräte (bzw. Player) im Datenstrom signalisieren (und wer das verstehen soll, denn 16-255 ist kein normiertes Format).
Ich hatte mal bei Panasonic angefragt, was in welchen Bits signalisiert wird ... aber das konnte mir auch keiner sagen.
ich versteh den Hype darum nicht, denn keine neuen Farbwerte, umgemappte Luma- und vermutlich auch Farbwerte- und das alles ... wofür ?
Es gibt zwei standardisierte Verfahren für Video: 709 und x.v.YCC und wer mehr Werte in den Tabellen braucht, (wobei sich bei 8 Bit die Frage stellt, warum), kann 10 Bit nehmen.
Blackeagle123 hat geschrieben:
Auf welchem Level arbeitet Premiere intern, also was sind dort im Waveform "100%"?
Zu den Premiere Pro - Fragen:
YC-Waveform
Es gibt im YC-Waveform-Monitor von Premiere keine 100%.
Angezeigt wird für Videos, die auf PAL basieren, eine Skala mit Volt-Werten. Der sichtbare Bildbereich, also dass was über einen Software-Player auf dem Monitor oder auf einem TV zu sehen ist, befindet sich zwischen 0,3 V und 1V. Das entspricht (verkürzt auf Y ausgedrückt) Y(16-235).
Cams, die irgendwas Y > 235 aufzeichnen (verkürzt ausgedrückt: 0-255, aber eben Y, nicht RGB) produzieren Bildanteile oberhalb 1V. Will man diese Bildanteile sichtbar machen, muss man sie nach unten drücken, unter die 1V-Linie.
Die selbe Skala wird automatisch statt in Volt in »IRE« angezeigt, wenn das Video einer NTSC-basierten Quelle entspringt. Das kann nicht händisch umgestellt werden.
Interne RGB-Speicher
Intern wird in Premiere Pro das dekodierte Videobild von YCbCr in 32bit-Float-RGB-Speicher gemappt. Der sichtbare Bildbereich für den Monitor befindet sich zwischen RGB (0,0/0,0/0,0) und RGB (1,0/1,0/1,0). Dahinein wird der sichtbare Y-Bereich (Y16 - Y235) zusammen mit den Chrominanzwerten nach RGB umgerechnet.
Die Werte Y > 235 führen in Premiere Pro zu RGB-Werten größer 1,0, was erlaubt ist. Dadurch gehen sie nicht verloren und stehen folgenden Manipulationen (Effekte) zur Verfügung. Jedoch: Sie sind zwar vorhanden, aber eben nicht sichtbar. Nicht auf dem Monitor und nicht in einem Video, dass mit diesen Informationen exportiert wird.
Für die Ausgabe auf den Vorschau-Monitor wird der Bereich RGB(0,0) bis RGB(1,0) nach RGB 0-255 umgerechnet. Geht nicht anders.
Beim Export wird der gesamte RGB-Speicher (inkl. Werte > RGB 1,0) nach YCbCr umgerechnet. Aus RGB (1,0/1,0/1,0) wird Y235.
Der RGB-Paraden-Monitor
Der RGB-Paraden-Monitor in Premiere Pro besitzt eine Skala von 0 bis 100.
Auch das ist nicht Prozent. Da sich abhängig von der Bearbeitung (genutzte Effekte) und der Quellen dahinter konkrete 8bit- oder 32bit-Werte befinden können, ist das neutral gekennzeichnet. "100" meint also entweder RGB 255 oder RGB 1,0.
Workflow
Es ist immer zu unterscheiden, in welchem Speicherbereich sich Daten befinden. Ein simpler Video-Clip liegt ja in mehreren Speichern gleichzeitig vor (z. B. nicht dekodiert: Import / dekodiert und bearbeitbar : YCbCr / intern: RGB 32bit und RGB 8bit usw.)
Was man im Workflow wann wie tut (an welchen Stellen wird eingegriffen) und auf welche Monitore man sich dabei verlässt, wirkt sich unmittelbar auf die Bildqualität aus.
Erschwerend kommt hinzu, dass die Importer Quellen beim Import ins Programm typgerecht interpretieren. Für unterschiedliche Quellen gibt es unterschiedliche Importerprogramme (läuft alles automatisch, nicht drüber nachdenken). So werden beispielsweise Bilder anders behandelt als Videos. Und bei Videos hängt es davon ab, ob sie PAL oder NTSC sind. Bei allen ist es zudem ein gravierender Unterschied, oder ob ihnen eine explizite Farbraumbeschränkung mitgegeben ist (beispielsweise 16-235) oder nicht (embedded Profile).
Fotos und Grafiken
Deshalb brauchen Fotos, Grafiken usw. üblicherweise nicht vorweg reduziert zu werden. Sie sollten auch nachträglich im Videoprogramm nicht auf 16-235 getrimmt werden, wenn man sie schließlich möglichst originalgetreu im Video sehen möchte.
Der Importer weiß, dass der gesamte Farbraum des Bildes, also eben das Bild, im sichtbaren Bereich liegen muss und mapped ihn im Videoprogramm zwischen RGB 0,0 und RGB 1,0 (oder RGB 0-255).
Betrachtet man das Foto im YC-Wavemonitor, liegt es genau zwischen 0,3V und 1,0V (was Y16-235 meint), also eben im sichtbaren Video-Bildbereich.
Wer solche Bilder, Grafiken etc. nachträglich im Videoprogramm auf 16-235 trimmt, also nochmal staucht, zerstört Bildinhalte. Falls das aber gewünscht oder nötig ist, wäre der richtige Ort für die Korrektur des Bildes im Workflow ein Bildbearbeitungsprogramm wie Photoshop (weshalb auch Photoshop mit den Videoprogrammen Premiere Pro und After Effects integriert arbeitet).
@Reiner
Unterabgetastete Werte erzeugen in RGB Illegale Farben weil die schwarzen Werte, wie in dem Beispiel „positiv“ Rot, „negativ“ Grün und „negativ“ Blau.
haben.
Du hast zwar geschrieben, sie könnten nicht dargestellt werden, aber Auswirkung kommt in Deiner Beschreibung einwenig kurz.
srone hat geschrieben:gespreizt/gemapped, wie auch immer.
Vor allem: wie auch immer ;)
Der Wert RGB255 besagt, dass Rot, Grün und Blau mit einer Luminanz von 255 vorliegen. Das passt nur gaaaaaaaaanz grob zur Luminanz von 235.
Es ist wie immer, der Farbraum und die Anzeige am Computer, das macht noch unsere Besten konfus ;)
Reiner M hat geschrieben:"100" meint also entweder RGB 255 oder RGB 1,0.
235. Wie sollte denn bei Luma 235 bei RGB 255 rauskommen?
Es gibt eben einen gravierenden Unterschied ziwschen YCbCr und RGB: Sie enthalten keineswegs identische Werte! Wie sollten sie auch?
Identische "Zahlen" durchaus, aber die "Werte" haben völlig unterschiedliche Bedeutung.
RGB kennt keinen Luminanz-Kanal, und nur 3 statt 4 Farben. Die Umrechnung Luminanz + Cb + Cr nach RGB Rot/Grün/Blau wird nach standardisierten Matrizen mit definierten Koeffizienten vorgenommen. Und niemals 1:1. Hier greift die Matrix yuv2rgb-full.
Diese Standard-Verfahren sind das, was "mapping" meint. Es sind komplizierte Umrechnungen, und die werden beispielsweise selbstverständlich auch von Software-Playern für die Video-Wiedergabe am PC genutzt. Geht nicht anders. ;)
Wobei sich darin schon der nächste Fehler verbirgt, weil in den Wandlungen in erster Linie, mit dem Lumawert und nicht mit der Luminanz, also nicht in einem linearen Umfeld gerechnet wird. Daraus resultiert dann, dass Pixel mit einem positiven Wert heller erscheinen, als sie sein dürfen.
Statt also mit den "komplizierten" Umrechnungen zu arbeiten, die eigentlich nur Näherungsformeln sind, sollte man erst mal das Gamma entfernen und erst anschliessend die Berechnungen vornehmen. Das Gamma kann dann durch Investierung der Formel wieder aufgebracht werden.
Also, so toll ist die ganze Umrechnung nicht und weicht an allen Ecken und Kanten vom Original ab.
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.
