Infoseite // 10Bit Master nach 8Bit exportieren = Banding

Frage von pixler:


Tach allerseits,

Ich habe ein AfterEffects Projekt (reine Grafik, kein Video) in 16 Bit erstellt und das Master in 10Bit (ProResHQ) exportiert. Sieht auf dem 10 Bit Broadcast Monitor auch alles tiptop aus. Wenn ich von diesem 10Bit Master nun 8Bit Kopien erstelle (H264, Mp4 usw.) so haben zeigen diese Banding. Banding ist aber auch schon zu sehen wenn mann die 10 Bit Masters auf einem normalen Cinema Display anschaut.

Was macht Ihr dagegen? Ein bisschen rauschen reinrechnen?



Antwort von wontuwontu:

Was macht Ihr dagegen? Ein bisschen rauschen reinrechnen? Ja genau.



Antwort von WoWu:

was soll das bringen ?

Leg die Grafik gleich in 709 an und bring die 16 Bit gleich nach 8 Bit, ohne erst über 10 Bit zu gehen -das könnte vielleicht schon ausreichen-.
Ansonsten leg sie gleich in 8/709 an. Dann passiert sowas nicht.

Grain bringt nur was, wenn das Encoding "Flächen" bildet, weil du ihm dann ein paar Bewegungsvektoren spendierst und er aus seiner faulen Haut aufwacht.
Das ist aber was völlig Anderes als Banding.



Antwort von pixler:

Es sind viele "Formebenen" mit sehr weichen Verläufen. Wenn ich das Projekt in 709 / 8 anlege habe ich genauso Stufen drin.

Habe jetzt kaum sichtbares Grain dazugerechnet und die Stufen sind weg.



Antwort von WoWu:

Lass Dir das patentieren :-)



Antwort von pixler:

Patent pending ;-)



Antwort von fuckyouthatswhy:

Es sind viele "Formebenen" mit sehr weichen Verläufen. Wenn ich das Projekt in 709 / 8 anlege habe ich genauso Stufen drin.

Habe jetzt kaum sichtbares Grain dazugerechnet und die Stufen sind weg.
Ja, das ist die einzige Möglichkeit das wegzubekommen. Das mit In-8Bit-Anlegen ist Quatsch.



Antwort von WoWu:

Dann hast Du aber Blockig und kein Banding denn Banding entsteht aus zu weit auseinander liegenden Werten in der Tabelle. Blockig entsteht im Codec, wenn keine Bewegungsvektoren zur Verfügung stehen. Banding und Blockig sind völlig verschiedene Dinge.
Mit einem geposteten Bild hätte man das vielleicht differenzieren können.
Liess das nochmal in Ruhe nach, bevor Du von Quatsch redest.



Antwort von wontuwontu:

Dann hast Du aber Blockig und kein Banding denn Banding entsteht aus zu weit auseinander liegenden Werten in der Tabelle. Blockig entsteht im Codec, wenn keine Bewegungsvektoren zur Verfügung stehen. Banding und Blockig sind völlig verschiedene Dinge.
Mit einem geposteten Bild hätte man das vielleicht differenzieren können.
Liess das nochmal in Ruhe nach, bevor Du von Quatsch redest. Wen interessiert, wie das Problem heißt? Es ging darum, wie man das Problem löst und das schafft man nur, in dem man ein "Muster" in die Verläufe rechnet. Bums aus.






Antwort von WoWu:

Ihn sollte es interessieren, wie das Problem heisst (und Dich übrigens auch) denn die beiden Probleme verlangen nach unterschiedlichen Lösungen.
Aber wen interessiert es schon, ob er auf der richtigen oder falschen Seite auf der Autobahn fährt, Hauptsache er kommt an.
Schon klar.
"Praktikerdenken".
Solange man den roten Knopf findet, ist alles ok.



Antwort von wontuwontu:

Ihn sollte es interessieren, wie das Problem heisst (und Dich übrigens auch) denn die beiden Probleme verlangen nach unterschiedlichen Lösungen.
Aber wen interessiert es schon, ob er auf der richtigen oder falschen Seite auf der Autobahn fährt, Hauptsache er kommt an.
Schon klar.
"Praktikerdenken".
Solange man den roten Knopf findet, ist alles ok. Der Vergleich mit der Autobahn ist etwas geschmacklos...

Ok gut, ich lasse mich gerne eines Besseren belehren. Kannst du mir den Unterschied im Detail erklären oder mir Quellen nennen, wo ich das nachlesen kann? Wenn ich bzgl. Farbverläufen + Banding suche finde ich zigtausend Vorschläge, bei Blocking aber nichts.

http://www.google.de/search?q=gradients ... g&tbm=isch

Ich arbeite seit über 10 Jahren professionell mit After Effects und kenne das Problem nur als "Banding", also das sichtbare Abreißen von Farbverläufen. Blocking sagt mir hingegen nichts, höchstens die Blockbildung beim Komprimieren...



Antwort von WoWu:

Ich such das für die Kompressorfunktion mal raus.
Aber schau Dir einfach mal an, warum Farbverläufe abreissen, dann wirst Du sehen, dass sich an der Ursache nichts ändert, wenn Du Grain hinzufügst, es sei denn, die Verläufe sind erst in der Kompression betroffen, in der beispielsweise Texturflächen nur noch einfarbig als Fläche dargestellt werden und zu den Rändern hin dann in Makroblockgrösse relativ hart sichtbare Übergänge bilden. Das Phänomen bekommt man mit Bewegungsvektoren abgestellt.
An der Stelle werden aber eben oft dieselben Begriffe (Banding) benutzt, weil es so ähnlich aussieht die Ursachen sind aber nichts miteinander zu tun.
Banding tritt an den Stellen des Bildes auf, an denen Werte indexiert werden, also feine Übergänge (Wertemengen) in die entsprechend gröberen Werte einer Zieltabelle indexiert werden.
Mit Bewegung aus Rauschen ändert man daran nichts, weil kein einziger neuer Wert in der Tabelle geschaffen wird.
Kommt man von 8Bit und geht über 10 Bit wird von den meisten Systemen schon Dither eingesetzt, also eine Pixelstruktur aus den Nachbarwerten, um die fehlenden Originalwerte aufzufüllen.
Damit fallen die Lücken in 10 Bit nicht mehr so stark auf.
Beim Rücksprung zu 8 Bit fallen die Ditherwerte aber wieder dem Index zum Opfer und wenn man Farbwerte in 10Bit so verändert hat, das sie soweit von den original 8 Bit werten abweichen, landen sie im falschen Indexwert und der Abstand zum nächsten Wert wird so gross, dass er als Banding sichtbar wird.
Kommt noch hinzu, dass in 8/709 keine 256 Werte mehr zur Verfügung stehen, sondern nur noch 220. Vergrössert zusätzlich die Bandingneigung.

Aber wie auch immer. Er hat es ja beseitigt. Mein Tipp bei "Grain" ist aber nach wie vor, dass es dann eine Ursache im Codec hatte und kein Banding war.
Aber sei's drum.



Antwort von EnricoPerei:

@WoWu

edit: ah so zitiert man hier (; Mit Bewegung aus Rauschen ändert man daran nichts, weil kein einziger neuer Wert in der Tabelle geschaffen wird. Banding:
00000000000
00000000000
11111111111
11111111111

Grain/Dither/Noise:
01000001000
00110010001
11010101010
11101101111


Wenn dies nun lossy komprimiert wird, sind in den meisten Fällen keine harten Übergänge, sondern eher noch mehr "Verunreinigungen" der Farbfläche zu beobachten.



Antwort von WoWu:

Eigentlich hatte ich auch nichts anderes geschrieben: .... Mit Bewegung aus Rauschen ändert man daran nichts, weil kein einziger neuer Wert in der Tabelle geschaffen wird. [...} ...warum Farbverläufe abreissen, dann wirst Du sehen, dass sich an der Ursache nichts ändert, wenn Du Grain hinzufügst, sondern darauf hingewiesen, dass Grain Implikationen im Coding haben können, weil u.U. aus Verläufen durch die erhöhte Anforderung in der Bewegungsprädiktion fähige Texturen entstehen können, was die Verläufe vergrössert und optisch zu einem ähnlichen Effekt führt.
Das setzt aber ein Ungleichgewicht aus Bitrate und der Anforderung an die höhere Bewegung voraus, wovon ich mal ausgehe, wenn von der Kamera bereits eine Bitrate angelegt wird,

Die Bezeichnung "Verunreinigung" müsstest Du einmal mehr präzisieren.

Ich betrachte Blockbildung auch als "Verunreinigung", die dann bei Einfarbigkeit zu Flächen führt weil die Blockkanten nicht mehr differenzierbar sind.

So ist jedenfalls unsere Erfahrung, die wir seit 20 Jahren mit MPEG Codecs machen.

Edit: Sorry, ich seh' gerade, das sollte oben ein Zitat sein.
Wenn dies nun lossy komprimiert wird, sind in den meisten Fällen keine harten Übergänge, sondern eher noch mehr "Verunreinigungen" der Farbfläche zu beobachten. Wenn die Datenrate grösser gewählt wird, als die Ausgangsrate, kann das sein.



Antwort von EnricoPerei:

Du meinst dies mit Blocking,ricthig?
http://en.wikipedia.org/wiki/File:Sego_lily_cm-150.jpg

Mit "Verunreinigung" deutete ich hierauf:
http://en.wikipedia.org/wiki/File:Jpeg- ... ifacts.gif

Blocking ist glücklicherweise nur bei niedrigen Auflösungen oder extrem gleichen Farbwerten, verbunden mit vergleichsweise sehr hohen Kompressionsraten ein Problem.
Durch Grain zerstreut man aber die ebene Farbfläche.
Bei den üblichen Kompressionsraten für Broadcast oder BluRay reicht dies in der Regel, um Blocking weitgehend zu verhindern.

Banding entsteht auch am Display selbst, wenn die bit Präzision zu niedrig ist, hier hilft Grain dann auch.

... und überhaupt, ein wenig Grain sollte man ohnehin auf alles legen (das keins hat), um das künstliche aus dem Bild zu treiben.



Antwort von WoWu:

Das ist grundsätzlich ja alles richtig, was Du sagst, widerspricht aber nicht dem, was ich gesagt habe, denn erstens ging es hier um eine fast schwarze Fläche, ohne grosse Tonwertdifferenz Blocking ist nur bei niedrigen Auflösungen oder extrem gleichen Farbwerten, n ein Problem.
Durch Grain zerstreut man aber die ebene Farbfläche. Grain setzt aber die menge der Bewegungsvektoren drastisch in die höhe und daher tendieren solche Codecs zum Abbruch der Codierung und dazu einzelne Macroblöcke darzustellen.
Bei H.264 sogar extrem stark, weil Bewegunsvectoren gleichförmiger Bewegungen zu wenigen Bewegunsvectoren zusammengefasst werden und so unverhältnismässig stark zur Effizienz beitrage.
Grain ist aber genau das Gegenteil, weil es nur aus Einzelvectoren besteht und daher überproportional mit Datenrate dagegen gehalten werden muss.
Im Umkehrschluss heisst das, erhöht man bei Graineinsatz nicht die Datenrate, wird die Codierung abgebrochen und die Makroblöcke "as it" dargestellt.
Was in der Fläche (hier fast Schwarz) dann so aussehen kann wie Banding.
Es ist natürlich kein Banding, sondern ein Codiereffekt, (nur dass das nicht miteinander vermengt wird.)



Antwort von TheBubble:

Was macht Ihr dagegen? Ein bisschen rauschen reinrechnen? Was Du willst ist Dithering, kein Rauschen. Rauschen kann die Abstufungen zwar verdecken, tut dies aber auch mit erwünschten Details. Dithering kann hingegen die zusätzliche Abstufungen dort simulieren, wo sie benötigt werden.

Allerdings treibt beides bei einer Kompression die Datenrate nach oben bzw. alternativ an anderen Stellen die Qualität nach unten.



Antwort von WoWu:

...und genau an der Stelle setzt mein Denkansatz fort denn wenn die Datenrate nicht signifikant erhöht wird, wird genau das Gegenteil von dem erreicht, was man eigentlich erreichen wollte.






Antwort von TheBubble:

So ist es. Ich habe es nur noch einmal kurz zusammengefasst. :-)



Antwort von WoWu:

Ich glaube auch, wir meinen alle so ziemlich dasselbe, speziell weil man an dem hier besprochenen Beispiel gar nicht wirklich erkennen konnte, um was es sich eigentlich genau gehandelt hat und wir nur mögliche Ursachen in Erwägung gezogen haben.
Dazu kam noch, dass in dem Fall, wenn ich mich da richtig erinnere, auch das Chroma mächtig erhöht war, was dann noch hätte zu weiteren Spekulationen führen können.
ich weiss bis heute noch nicht, woran es denn nun eigentlich gelegen hat.
Das ist auf die Distanz auch immer schwer zu sagen, wenn man nicht selbst am Rechner sitzt und ein paar Dinge einfach mal ausprobieren kann.
Noch dazu von einem Still. :-(



Antwort von EnricoPerei:

@WoWu

Ich glaube in der Tat, wir reden etwas aneinander vorbei und sagen grob das gleiche.

Ich ging allerdings direkt darauf ein, daß OP's Banding Problem durch Grain nicht gelöst würde.

Bei den üblichen Datenraten heutzutage mit variablen Bitraten ist Blocking kaum vorhanden (ich spreche nicht von Youtube videos).
Es treten viel mehr Artefakte auf durch zu hohe Geschwindigkeiten und weit auseinanderliegende Keyframes.

Da OP von Computergraphik und 10 bit sprach, gehe ich davon aus, daß sein Problem Banding bei den sanften Farbverläufen ist und nicht Blocking.

Aber beide sind durch Grain gut zu bekämpfen.
Wie Du richtig sagst, verlangt Grain eine niedrigere Kompression, um getreu Details darzustellen und zwingt somit den VBR Codec dort weniger in Frame oder gar in time averaging der motion Vektoren zu betreiben.

edit: ich habe hier keine Bilder von OP gesehen, daher bin ich scheinbar noch mehr im Blindflug als do WoWu (;



Antwort von WoWu:

Kann sein, dass ich das jetzt mit einem andern Fall verwechselt habe, in dem so ein Effekt aufgetreten ist.
Nur prinzipiell halte ich die ganze Grain-Geschichte ohnehin für ein Krücke denn wenn die Notwendigkeit dafür auftritt, hat man bereits den Fehler irgendwo im Workflow gemacht.
Sei es, dass man Datenraten zu niedrig gewählt, zu schlecht ausgeleuchtet oder die falschen Tonwerte (Menge und Verlauf) gewählt hat.
Aber sei's drum.

Edit:
Wir haben übrigens mit Abstand bessere Erfahrungen mit H.264 in Bezug auf die GoP gemacht, als z.B. noch mit MPEG2, weil im Verhältnis deutlich mehr I-Frame Referenzen in der GoP sind, und selbst B-Frames noch referenzieren, als früher in der 1-Bild MPEG2 Geschichte.
Insofern hat sich da einiges zum Positiven entwickelt.



Antwort von Stephan82:

Ich hänge mich mal an das Thema dran, weil ich mit Banding oder Blocking selbst immer wieder Probleme habe. Was genau was ist kann ich als Anfänger auch nicht unterscheiden.

Hier mal 2 Screenshots aus After Effects. Footage stammt von einer 700D@1080p@H264.

Screenshot 1: importiertes Footage (unverändert)
Screenshot 2: gleicher Frame + Schwarz-Weiß-Effekt + Tonwertkorrektur Tiefen (20), Mitteltöne unverändert und Höhen (245).

Ich habe also die Tonwerte wirklich nur minimal verändert. Unten rechts ist ein beige-farbenes Waschbecken zu sehen, dass absichtlich in der Unschärfe liegt. Dort habe ich etliche Bildfehler. Ist das nun Blocking oder Banding und wie kann ich dem entgegenwirken?



Antwort von EnricoPerei:

Das ist Banding.
Es entsteht durch die niedrige Farbauflösung(chroma subsampling) und starke Kompression in consumer Kamera Codecs.
Beim Grading kann dann das Bild leider sehr schnell an seine Grenzen stoßen und auseinanderfallen.

Du kannst hier gut mit einem Blur arbeiten und ggf. ein wenig Grain in den nun grainfreieren Bereich rückführen.
Achte darauf, daß Dein Grain mit dem des restlichen Bildes weitmöglichst übereinstimmt, sonst machst Du's nur schlimmer und solltest lieber das Grain weglassen.



Antwort von Stephan82:

Das ist Banding.
Es entsteht durch die niedrige Farbauflösung(chroma subsampling) und starke Kompression in consumer Kamera Codecs.
Beim Grading kann dann das Bild leider sehr schnell an seine Grenzen stoßen und auseinanderfallen.

Du kannst hier gut mit einem Blur arbeiten und ggf. ein wenig Grain in den nun grainfreieren Bereich rückführen.
Achte darauf, daß Dein Grain mit dem des restlichen Bildes weitmöglichst übereinstimmt, sonst machst Du's nur schlimmer und solltest lieber das Grain weglassen. Das ist ja hier ein Standbild! Wenn die Szene läuft bewegen sich etliche Klötze wie beim Tetris hin und her! Sehe ich vor allem, wenn ich in das Bild z.B. auf 200% reinzoome. Dachte daher immer, dass das Blocking wäre. Wegen diesen Klötzchen eben.

Grain hinzufügen? Ok, welchen Effekt nehme ich da? Es gibt in After Effecs verschiedene. Glaube Rauschen oder Korn? Macht das einen Unterschied, ob ich den Effekt direkt auf das Video ziehe oder auf eine Einstellungsebene ziehe und die über dem Footage in der Timeline habe?

Kann man diese Bildfehler schon bei der Aufnahme irgendwie verhindern? Besser in der Cam schon den Schwarz-Weiß-Effekt aktivieren?

Weichzeichner habe ich per Einstellungsebene schon drübergehauen. Hat aber gar nix gebracht. Wie kann das sein?



Antwort von WoWu:

Was kommt aus der Kamera für ein Signal ?
Macht die 709 ?
Kommt da Y'Cb'Cr' raus ?
Wie hast Du dann nach RGB gewandelt ?
Auf welchen Kanal beziehen sich die 240 ?
Wurde vor der Wandlung das Gramma korrigiert oder ist das mit dem verbogenen Gamma gewandelt worden ?
Hat das Signal irgendwann. irgendwo mal 10 Bit gesehen ?
Wie breit waren die Effekte darauf (16/32 Bit) und wieviel Bearbeitungen insgesamt sind darauf ? (Ggf. wegen des Abschneidens der Wortlängen)

Ich hatte oben ja schon geschrieben, dass ich von solchen Verdeckungen nicht viel halte sondern lieber den Fehler im Workflow feststelle und ihn das nächste Mal möglichst nicht wiederhole.
Dazu muss man aber bei einem so "schmalen" Signal, wie es 8Bit nunmal ist, sehr präzise arbeiten.
Stell doch mal ein paar bewegte Frames ein, dass man den Effekt mal sieht. Ansonsten ist das wieder "fischen im Trüben".
Überhaupt ist so eine Ferndiagnose eigentlich eine Wundertüte.
Das Einzige, was bei 8Bit wirklich hlift ist ein absolut sauberer Workflow.



Antwort von EnricoPerei:

Bedenke, daß Du darauf achten solltest, wie sehr Du in den Bereich von Pixelfucking eintauchen möchtest, und was Deine delivery Plattform ist - sprich, ob man das überhaupt je sehen würde.

Wie WoWu sagte, sind einige Faktoren ausschlaggebend.
Zudem kann man in der Tat beim Shooting bereits Maßnahmen treffen einiges zu vermeiden.
Beispielsweise kann man automatische Korrekturen und default Werte abschalten bzw. verändern.
All diese Dinge sind für sich genommen schon weit mehr Worte wert, als man hier schreiben sollte, um TL;DR zu vermeiden.
Gerade für die jeweiligen Kameramodelle gibt es im web eine vielzahl von Settings und Tutorials, wie man den Farbraum verändern kann, um mehr Information in das Bild zu quetschen.
Meist wird das Bild dann Flach und Kontrastarm und kann nicht ohne weiteres Processing/Grading verwendet werden.

Du solltest Dich aber eingehend mit der Materie beschäftigen und relativ sicher sein, was die Einstellungen bewirken und wie Du Sie Richtig anwendest und verarbeitest, bevor Du Dir mehr Arbeit und Kopfzerbrechen machst, als Du mit den Defaultwerten hättest.
Zudem wirst Du diese Probleme nicht komplett eliminieren können, selbst Kameras wie Alexa, Red, F65 etc. haben ihre Probleme.
Wenn Du falsche Farbräume, Settings oder post Processings benutzt, kannst Du unter Umständen unbrauchbares Material bekommen und solltest daher eingehende Tests durchführen.

Nochmal kurz zu dem Blur:
Die Klötzchen (ist hier nicht leicht erkennbar wie weit Du reingezoomt hast und wie groß der Bildausschnitt im Verhältnis zum Gesamtbild ist) bewegen sich, weil die Kamera ein eigenes Grain (eigentlich digitales Rauschen) hat.
Wenn Du also Blur drüber ziehst (nur den fraglichen Bereich ausmaskiert) verwischst Du das Grain und solltest es wieder herstellen(mit gleicher Maske) um ein harmonisches Bild zu erhalten.


Korn/Grain ist dem echten Filmgrain nachempfunden und bietet meist mehr Einstellungsmöglichkeiten.
Genau genommen müsstest Du die drei Farbkanäle und unter Umständen sogar Schatten und Helligkeitsbereiche separat mit anderem Grain versehen...wie gesagt, wenns' korrekt sein soll, rutscht man schnell ins pixelfucking ab und Du solltest abwägen, ob es den Aufwand lohnt.

Du kannst auch versuchen Dein Blur nur auf bestimmte Lumawerte zu beschränken und verschiedene stärken an Blur für verschiedene Bildbereiche, als auch Helligkeiten einsetzen.






Antwort von Stephan82:

Was kommt aus der Kamera für ein Signal ?
Macht die 709 ?
Kommt da Y'Cb'Cr' raus ?
Wie hast Du dann nach RGB gewandelt ?
Auf welchen Kanal beziehen sich die 240 ?
Wurde vor der Wandlung das Gramma korrigiert oder ist das mit dem verbogenen Gamma gewandelt worden ?
Hat das Signal irgendwann. irgendwo mal 10 Bit gesehen ?
Wie breit waren die Effekte darauf (16/32 Bit) und wieviel Bearbeitungen insgesamt sind darauf ? (Ggf. wegen des Abschneidens der Wortlängen) Ich bin ambitionierter Neuling aber kein Codec- bzw. Farbraum-Fachmann. Daher verstehe ich viele Fragen nicht.

Ich habe folgendes gemacht:
1.Clip mit der Cam gefilmt
2.Clip in After Effects importiert (8 Bit Komposition) und in die Timeline gezogen.
3.Einstellungsebene über dem Footage erstellt
4.Schwarz-Weiß-Effekt auf die Einstellungsebene draufgezogen
5.Tonwertkorrektur-Effekt auf die Einstellungsebene draufgezogen. Im Kanal RGB habe ich dann folgende Werte verändert:
a) Eingabe: Tiefen 0 auf 10
b) Eingabe: Lichter 255 auf 240
c) Gamma: 1 auf 0,9
d) Ausgabe: Tiefen unverändert 0
e) Ausgabe: Lichter unverändert 255

Das war alles!!! Das Banding sehe ich sofort in der Live-Vorschau wenn ich den Schwarz-Weiß-Effekt und den Tonwertkorrektur-Effekt anschalte.

Hier mal was mir MediaInfo zu dem Video-File direkt aus der Cam ausspuckt:



Antwort von EnricoPerei:

Das Problem liegt leider an dem 4:2:0 YUV codec, der starken consumer Kompression und den 8 bit.

Versuche ein 16/32bit float Projekt zu eröffnen.
Selbst wenn das Ausgangsmaterial in 8 bit ist, können die feineren Abstufungen gerade bei Blurs und Farbkorrekturen große Auswirkungen haben.

Leider sind einige Probleme aber nicht ganz vermeidbar und können dann nur in der Post teilweise korrigiert oder verschleiert werden.

Wenn es Dich sehr stört und Blur/Grain nicht wirklich helfen, kannst Du notfalls Masken am Rand der Problemzone ziehen und Farbabstufungen einfügen/drüberlegen oder separate Farbkorrekturen für bestimmte Bereiche machen.

Unter Umständen kann es helfen, wenn Du im nativen YUV Farbraum, statt im RGB, deine Korrekturen durchführst.
Hierzu mußt Du aber auch wieder ein wenig Kenntnisse mitbringen, um zu verstehen, was die einzelnen Effekte mit den Farben und der Helligkeit machen.

Mehr Bittiefe schadet auf jeden Fall selten.
Es dauert halt etwas länger zu rendern und es wird mehr Speicher benötigt, aber damit können die neuen PCs und riesigen Festplatten leicht umgehen.



Antwort von WoWu:

@ Stephan82

Danke für die Werte.
Die Info deuten auf einen Fehler hin.
Das Material kommt in REC709, also 16/235,Chroma 240
Deine Filter drückt aber weiss von 255 auf 240. Das deutet darauf hin, dass von REC709 nach RGB falsch gewandelt wurde.
Auch "Tiefen unverändert 0" Tiefen sollten bei 16 liegen wenn Du das Material so verarbeitest, wie es aus der Kamera kommt.
Das Material wurde also gestretched und in der Bearbeitung wurden weitere Tonwerte nachgezogen und bei der Ausgabe dann das Material wieder gestaucht, denn ich denke, das Zielmaterial war wieder Rec709.

Das könnte die Ursache für die zu weit auseinander liegenden Tonwerte sein.
Es ist bei 8 Bit empfehlenswert, wenn Du, wie Enrico schon empfohlen hat, in Y'C'bC'r bleibst.
Die Bearbeitung 16/32 wird nichts bringen, weil die Wortbreite von 8Bit hier bereits festliegt.
Das bringt nur was, wenn Du es im Material ohnehin mit grösseren Wortbreiten zu tun hast, also bei einer Hinzufügung von Computergrafiken z.B.

Also, mein Tipp: Das Material ist mehrmals gestreckt und wieder teilweise gestaucht worden. dadurch haben sich Tonwerte verschoben und sind bei der Stauchung zu falschen Werten kombiniert worden.
Bei 8 bit ist das kritisch, weil die Tonwerte schon im Normalzustand gerade mal an der Grenze des (für den menschen) wahrnehmbaren liegen. Kleine Fehler haben bei 8Bit dann grosse Wirkung und sind sofort wahrnehmbar.

So auf die Entfernung ist das immer "Fischen im Trüben" aber Tonwertabrisse haben eigentlich meistens dieselbe Ursache.



Antwort von EnricoPerei:

Stimme Dir zu, aber: @ Stephan82

Die Bearbeitung 16/32 wird nichts bringen, weil die Wortbreite von 8Bit hier bereits festliegt. Wenn man Blur oder Farbkorrekturen, Curves o.ä. drüberzieht, werden die Berechnungen doch wesentlich feiner abgestuft sein, als bei 8bit.

Bei der Wandlung von 8 auf 16 bit oder ins float entstehen "Lücken" im Farbraster.

8-> 16 bit int
0 = 0
1 = 256
2 = 512
...

Es wird, je nach Wandlung unter Umständen hier bereits Dithering verwendet.
Durch Blur werden diese Lücken nun aufgeschlossen und man bekommt nun beispielsweise einen flüssigeren Verlauf, der vor allem bei Banding zwischen zwei nicht unmittelbar benachbarten Farben enorm hilft.
Grain hebt oder senkt die Farbwerte entsprechend ebenfalls in den "detaillierteren",feineren Bereich zusätzlich zu der Tatsache, daß es den Linienverlauf zerbröselt.
Dither macht dies ebenso, halt nur auf den engeren Verlauf der Linie begrenzt.

Ich arbeite beispielsweise fast ausschließlich in 32bit float und hatte zu Zeiten von 8 bit Grenzen nur in log gearbeitet.
...unabhängig vom Farbraum oder der Bittiefe des Ausgangs- und Zielmaterials.
(log ist zwar ein Farbraum und nicht mit Bittiefe vergleichbar, hat aber durch seine Kurvennatur andere,natürlichere Berechnungsergebnisse)

Selbst bei 32bit float taucht übrigens Banding auf und ist dann recht hartnäckig und fast nur mit Grain zu beschwichtigen, denn Blur ist ja nichts anderes als die Ermittlung von Durchschnittswerten, die das Problem sogar verschlimmern können.

Also OP, leider immer von Fall zu Fall unterschiedlich und experimentieren, bis das Ergebnis ausreichend zufriedenstellend ist...perfekt werden wir es nie schaffen );

P.S.:
Das gleiche machen übrigens SubPixel Berechnungen, also Notfalls auch damit mal ein wenig herumspielen.
Denkbar wäre, das Bild ein paar Pixel in X und Y zu verschieben und wieder zurückzuschieben.
Je nach Filter und subPixel genauigkeit kann das schon genügen, um Farbverläufe smoother zu gestalten.
Man wird ggf. ein wenig Bildschärfe einbüßen.



Antwort von Stephan82:

@ Stephan82
Danke für die Werte.
Die Info deuten auf einen Fehler hin.
Das Material kommt in REC709, also 16/235,Chroma 240 Woran siehst du das? Anhand welcher Daten kann man das ableiten? Ich lese in den Infos nirgends was von Rec709 oder bin ich blind? Was ist Chroma 240?
Deine Filter drückt aber weiss von 255 auf 240. Das deutet darauf hin, dass von REC709 nach RGB falsch gewandelt wurde.
Auch "Tiefen unverändert 0" Tiefen sollten bei 16 liegen wenn Du das Material so verarbeitest, wie es aus der Kamera kommt. Ich weiß nicht ob ich dich richtig verstanden habe. Ausgabe Tiefen und Ausgabe Lichter müssen auf 16 und 235 eingestellt werden, oder? Und bei Eingabe Tiefen/Eingabe Lichter darf ich mich dann nur in dem Bereich zwischen 16 und 235 bewegen?



Antwort von WoWu:

@enrico

Nur kurz, was Adobe dazu sagt: Note: Merely increasing the color depth within a project won’t eliminate gradients if the output format has a low bit depth.
To mitigate banding, After Effects introduces dithering of colors when the colors are converted to 8-bpc colors, including when rendering and exporting to an 8-bpc format. This dithering is not introduced for previews.
 
To force dithering for previews, apply an 8-bpc effect that does nothing—such as the Arithmetic effect with the default values—to an adjustment layer.

... Important: Because some operations—including glows, blurs, and some blending modes—behave differently in 32-bpc mode as compared with 8-bpc or 16-bpc mode, your composition may look significantly different when you switch between high dynamic range and low dynamic range project settings. @Stephan
Deine Infos sagen, dass das material in 709 liegt. Das entspricht dem Videostandard.
In-und out sollten also nicht ausserhalb der Empfehlung liegen, weil dann der Arbeitsbereich gespreizt wird.



Antwort von EnricoPerei:

@WoWu

Beachte: "merely"
Wenn man lediglich das Material wandelt 8 bit -> 16 Bit -> 8 bit passiert herzlich wenig, ausser dem Dithering.

0 = 0 = 0
1 = 256 = 1
2 = 512 = 2

Man muß natürlich seine eigenen Korrekturen durchführen (Blur, Grading, Grain etc.).
Wie auch dort zu lesen ist, werden die Ergebnisse unterschiedlich sein (auch, wenn die das etwas anders meinten).
Dies reicht dann meist, um Banding zu minimieren/eliminieren.

Denn nun passiert es, daß bei Rückwandlungen 1= 2 wird oder 1=0.

1 wird zu 256 und durch Korrekturen zu 50 und wird dann bei Rückwandlung zu 0
oder
1 wird 256, korrigiert auf 480 und entspricht dann einer 2

Beweis: 2+2 = 5 (;



Antwort von WoWu:

Wir reden hier aber von einer Wandlung und einer Bearbeitung.
Und so beschreibt das Adobe in der Warnung auch.
Es bringt ja nix, ein Signal mal eben hin und her zu wandeln.
Wozu soll das gut sein?



Antwort von EnricoPerei:

@WoWU

Deinen letzten Comment verstehe ich nicht ganz.

Der Abschnitt betont, daß lediglich das erhöhen der Bittiefe keine Banding Probleme löst (logisch).

Das andere über die verschiedenen Ergebnisse in den Bittiefen bezieht sich eigentlich auf die Algorithmen und wie sie sich verhalten.

Dinge die Pixel umherschubsen und verschmieren werden in jeder Bittiefe dein Banding zerstören oder minimieren.
Durch höhere Bittiefen hast du aber einfach mehr Raum dafür, der dann bei der Rückwandlung wiederum andere Ergebnisse liefert.

Aber unabhängig davon, Blur und Grain/Dither sind nunmal die bewährtesten Mittel, um Banding etwas zu bendigen.

Und das wollte OP eigentlich nur wissen.


(oh, hehe und ich wandle oft RGB in YUV, um mir das Signal anzusehen, auch wenn ich oft keine Korrekturen in dem Raum durchführe)
Manchmal kann man auch gute Masken und Keys in exotischen Farbräumen erstellen...

(;






Antwort von WoWu:

Aber unabhängig davon, Blur und Grain/Dither sind nunmal die bewährtesten Mittel, um Banding etwas zu bendigen. Das mag wohl sein, aber es ist eben eine Fehlerverdeckung.
Mein Ansatz geht ja hin zur Fehlervermeidung.
Und der beginnt mit einem sauberen Workflow und damit, Tools zu benutzen, von denen man sich auch über die negativen Auswirkungen auf die Bildqualität im klaren ist und darüber, dass es immense Unterschiede zwischen einem Computersignal in einer Grafikumgebung und einem Videosignal gibt.

Und deswegen weiss ich nicht, womit dem Ts mehr gedient ist, ihm zu sagen wie man es verdeckt oder wie man es vermeidet.
Ich denke, auf lange Sicht ist das Vermeiden der bessere Ansatz.
Aber das ist, wie immer, eine Frage des Anspruchs an die Bildqualität, die man generieren möchte.



Antwort von EnricoPerei:

aber es ist eben eine Fehlerverdeckung.
Mein Ansatz geht ja hin zur Fehlervermeidung.
Das ist mir klar und ich bin absolut deiner Meinung.

Ich denke, man muß beides sagen und jeder entscheidet dann für sich selbst, wie weit er womit geht.

Fix it in Post ist eh eine Mentalität, die uns zwar unglaublich viel Arbeit (die eigentlich unnötig und vermeidbar ist) einbringt dennoch oft auf Unverständnis und Kopfschütteln stößt.

Wir sind Künstler Jim, keine Mechaniker.



Antwort von dienstag_01:

Deine Filter drückt aber weiss von 255 auf 240. Das deutet darauf hin, dass von REC709 nach RGB falsch gewandelt wurde. Das ist ein Missverständnis. b) Eingabe: Lichter 255 auf 240 Die Erhöhung der Werte in der Eingabe erhöhen den Kontrast (Also Weiss wird weisser). Und die Range 0-255 besagt, dass AE FullRange (für den Computermonitor) arbeitet.

Dort einen Fehler zu suchen ist jedenfalls sinnlos.



Antwort von WoWu:

Danke, hatte ich anders verstanden.
Alles klar.



Antwort von Reiner M:

Ich weiß nicht ob ich dich richtig verstanden habe. Ausgabe Tiefen und Ausgabe Lichter müssen auf 16 und 235 eingestellt werden, oder? Und bei Eingabe Tiefen/Eingabe Lichter darf ich mich dann nur in dem Bereich zwischen 16 und 235 bewegen? Nein, tue das bitte nicht! Du würdest die Schwarz- und Weißwerte auf Dauer beschneiden. Im exportierten Video würden die tiefen Schwarzwerte und die hellen Lichter definitiv nicht mehr vorkommen! Das Video würde flach erscheinen. Willst Du das? ;)
Ich habe folgendes gemacht:
1.Clip mit der Cam gefilmt
2.Clip in After Effects importiert (8 Bit Komposition) und in die Timeline gezogen.
3.Einstellungsebene über dem Footage erstellt
4.Schwarz-Weiß-Effekt auf die Einstellungsebene draufgezogen
5.Tonwertkorrektur-Effekt auf die Einstellungsebene draufgezogen. Im Kanal RGB habe ich dann folgende Werte verändert:
a) Eingabe: Tiefen 0 auf 10
b) Eingabe: Lichter 255 auf 240
c) Gamma: 1 auf 0,9
d) Ausgabe: Tiefen unverändert 0
e) Ausgabe: Lichter unverändert 255

Das war alles!!!

Mit der Tonwerkorrektur hast Du bei der EINGABE die Werte verändert. Das hast Du wohl getan, weil Dein Schwarz nicht schwarz genug war und entsprechend Weiß nicht am Anschlag war - laut Histogramm.
Wichtig: Das ist RGB! Nicht YCbCR.

Mit dieser Aktion hast Du dafür gesorgt, dass nun RGB 10 auf RGB 0 abgebildet wird und RGB 240 auf RGB 255. Der Wertebereich ist gespreizt. Die Folgen sind klar. Wie man ihnen sinnvoll begegnen kann, wurde schon erzählt. Da ist nichts falsch, nichts kaputt, und es liegt kein Fehler vor ... ;)

Das exportierte Video wird nach dieser Tonwertkorrektur ein Schwarz bis Y=16 und ein Weiß bis Y=235 enthalten. Da meinen die Werte dann YCbCR, nicht RGB.
Alles gut. - Solange Du nicht in diesem Effekt an den AUSGABE-Werten rumdrehst . ;)

Beste Grüße,
Reiner



Antwort von WoWu:

Lass Dich nicht irre machen.
Deine Ausgabewerte sind 16/235 entsprechend REC 709 Einstellung.
Das hast Du schon richtig verstanden.
Schon der Umstand dass Du korrigieren musstest zeigt, das was falsch war.
Und ob man das mit Wortspielereien ..." Schwarz nicht schwarz genug und Weiss am Anschlag"... schön redet oder das Kind beim Namen nennt.
Fehler ist Fehler und Banding entsteht nicht von allein.



Antwort von Reiner M:

Genau, lass Dich nicht irre machen. Der Effekt meint RGB-Werte. Punkt.

Und in After Effects wird der Wertebereich Y 16-235 des Quellvideos breits beim Import IMMER völlig korrekt nach RGB 0-255 übertragen. Alle Arbeiten (Effekte) erfolgen dann in diesem Wertebereich, und zwar vollumfänglich, es sei denn, man arbeitet direkt in YCbCr, das macht der Effekt Tonwertkorrektur aber nicht.

Beim Export wird der Vorgang umgekehrt: Aus RGB 0-255 wird Y 16-235.
Alles gut. Die Verabeitungskette ist vollkommen integer. Du hast zum Schluss ein völlig normales, standardkonformes Video nach REC.709 vorliegen.

Folge: Wenn Du die RGB Werte beschneidest (z. B. mit den AUSGABE-Parametern des Effekts Tonwertkorrektur), wird das Video nicht mehr Y16-235 enthalten, sondern irgendwas um Y22-220 oder so, weil ja jetzt die oberen und unteren RGB-Werte fehlen und die korrespondierenden Y-Werte nicht erzeugt werden können! Tue es nicht ...

Was man übrigens sehr leicht AUSPROBIEREN kann, wenn man After Effects hat ... ;) - ein mehr als hinreichender Beweis.

Das Banding kommt allein aus der Tonwertspreizung, verursacht durch die Verengung der Eingabe-Parameter des Effekts.
Und dafür wurden hier adäquate Lösungsansätze bereits von Praktikern vorgestellt, die After Effects auch sehr gut kennen. Deren Tipps würde ich mir näher ansehen. ;)

Beste Grüße,
Reiner



Antwort von dienstag_01:

Und in After Effects wird der Wertebereich Y 16-235 des Quellvideos breits beim Import IMMER völlig korrekt nach RGB 0-255 übertragen. Immer?
Ich sag mal so: Grau ist alle Theorie - die von Reiner M ist bissel grauer ;)



Antwort von Reiner M:

Immer?
Ich sag mal so: Grau ist alle Theorie - die von Reiner M ist bissel grauer ;) Ist das ein File, dass Du in Avid auf RGB 16-235 getrimmt hast? ;)

Dann zeigt mal den korrespondierenden Y-Wert, gerne anhand einer Luma-Wave... - Aber bitte nicht außerhalb AE / Pr ... - Darüber reden wir hier.

Ja, das passiert immer, Dienstag.
Wenn Du den Farbraum umstellst, oder eine LUT drauflegst die ihn simuliert, oder ein File ein embedded Profile mitbringt, oder ganz schlicht ein Video einbringst, in dem die unteren/oberen RGB-Werte nicht vorkommen ..., ja dann kommen die RGB-Werte auch nicht vor. Super easy.

Ich kann Dir eine Graukarte aufzeichnen. Sie wird in After Effects garantiert keine schwarzen und weißen Werte jenseits 50% nach unten oder oben zeigen. Und? Was beweist das?

Machs doch richtig, entlang der gestellten Frage.
Nimm einfach ein ganz normales REC.709-Video wie es beispielsweise aus einer Cam kommt. Importiere es nach AE ohne Farbraumanpassungen, wie üblich.
Teste es dann aus. Z. B. mit dem Effekt Tonwertkorrektur und dort mit Beschneidung der Ausgabe-Werte (das ist die Frage von Stephan), exportiere das Video und lade es z. B. in Pr. Vergleiche Original und Kopie in der Luma-Wave. Mach das selbe mit Farbraumanpassungen usw. - Dann weißt Du, wie das System funktioniert.

Beste Grüße,
Reiner






Antwort von dienstag_01:

Machs doch richtig, entlang der gestellten Frage. Nee, ich weiss ja, was geht und was nicht. Aber ich schau mir gerne mal deine Behauptungen an: Und in After Effects wird der Wertebereich Y 16-235 des Quellvideos breits beim Import IMMER völlig korrekt nach RGB 0-255 übertragen. ;)
Immer?
Naja, korrekt sieht es so aus:



Antwort von Reiner M:

Nee, ich weiss ja, was geht und was nicht. Das, Dienstag, glaube ich definitiv nicht! ;)

Machs einfach mal. Und schau Dir die Luma-Wave vorher/nacher genau an!

Beste Grüße,
Reiner



Antwort von dienstag_01:

Das, Dienstag, glaube ich definitiv nicht! ;) Dafür, dass du mir nicht glaubst, bin ich dir eher dankbar. Stellt mich das doch in eine Reihe mit den Sachbuchautoren, denen du ja auch nicht glaubst ;)



Antwort von Reiner M:

@Dienstag,

welche Sachbuchautoren meinst Du? Behandeln die Systeme, in denen der bildgebende Bereich in der digitalen Verarbeitung eines Videos nach RGB 0-255 gemappt wird?
Meine Lektüre-Empfehlung für Dich: Die Adobe-Handbücher. ;)

Sorry, Dienstag, neben vielen falschen Dingen, die Du hier erzählst, beweisen die Screenshots, die Du hier eingestellt hast, doch eindeutig, dass Du gar nicht verstehst, was Du eigentlich machst. ;)
Sie passen weder zur Fragestellung noch sind sie geeignet, zu beweisen, dass AE nicht in RGB 0-255 arbeiten würde.

Meine Tipps, das mal sachgerecht und strukturiert auszuprobieren, ohne krampfhaft nach Sonderfällen zu suchen, nimmst Du nicht an und weichst ständig aus.

Mir musst Du nicht beweisen, Dienstag. Es genügt, wenn Du es richtig machst. Denn Du und andere, denen Du hier mit Ratschlägen und Tipps beistehst, werden davon profitieren.

Da Du es nicht ausprobieren willst, und auch offensichtlich nicht beantworten kannst, welche Y-Werte aus Deinen RGB-Werten in Deinen Screenshots resultieren, zeige ich hier eben jedem, den es interessiert, noch einmal, was die Auswirkungen sind, wenn man Videos unsachgemäß, basierend auf falschen Behauptungen, bearbeitet.

Ich würde Dir empfehlen, die folgenden Ausführungen sorgfältig zu lesen! Ich fürchte aber, das wirst Du nicht ... ;)

----------

Beigefügt habe ich ein zip mit drei sehr kurzen Videos. Aufgenommen ist ein Testchart, das für Tests in RGB und YCbCr ausgelegt ist. Die gesamte Grauskala ist drin, sowie alle Farben mit ihren Sättigigungen von 0-100%, die Achsen im Vektorskop darstellen, also die reinen RGB- und YCbCr-Farben.

Video 1 zeigt das Testchart pur.
Video 2 ist das Ergebnis nach einer Tonwertkorrektur der Ausgabe-Parameter auf RGB 16-235 - Das ist der Fall, den Stephan wissen möchte.
Video 3 ist das Ergebnis des Videos pur, jedoch geladen in Ae in einen Farbraum HDTV (Rec.709)16-235.
Mit diesen Videos kannst Du nun selbst spielen.

Screenshot 1 zeigt die Wirkung in AE. Von oben nach unten: A) Nativ, B) mit Tonwerktkorrektur, C) nach Farbraumumstellung. Beachte bitte die RGB-Werte, die das hellste Pixel ausmachen, sowie das Histogramm, das eindeutig von 0-255 läuft. Die Ergebnisse habe ich jeweils exportiert. Das sind die Beispiel-Videos 1,2,3.

Screenshot 2 zeigt die Resultate in Premiere Pro.
Beachte bitte,
- dass das native Video in der Luma-Wave genau im bildgebenden Bereich zwischen 300mV und 1V liegt, also Y16-235 ist!
- dass die Farben im Vektorskop bis auf die 100%-Markierung laufen.
- dass die Farben in der RGB-Parade von 0 bis 100 (RGB 0.0 - 1.0 bzw. 0-255) laufen!

Nun das Resultat des Effekts Tonwertkorrektur mit Ausgabe-Beschneidung:
- die Luma-Wave läuft nicht mehr von 300mv bis 1V. Der schwärzeste Punkt ist nun nicht mehr Y16, der weißeste nicht mehr Y235! Böse Falle!
- Folgerichtig zeigt die RGB-Parade oben und unten leere Bereiche! Logisch: Die RGB-Werte 0-15 und 236-255 fehlen! Die Wertezellen 0-15 und 236-255 sind aber noch da, nur eben leer. Genauer: Es gibt einfach keine Farbpixel mit diesen Werten!
- Schlimmer noch: Das Vektorskop zeigt eindeutig eine Veränderung der Farbsättigung! Die Farbigkeit des Bildes hat sich reduziert. Alle Farben haben gelitten! Das Bild wird optisch flau, wie man sehen kann. Ein häufiges Problem vieler Anwender, die falsch vorgehen. ;)

Ich kann mir beim besten Willen nicht vorstellen, das das gewünscht ist, weder am PC, noch an einem TV als Ausgabemedium, denn die Ergebnisse, die die Meßgeräte zeigen, werden an einem TV identische Wirkungen erzielen. Probiers einfach aus ... ;)

Die Verarbeitungskette in Premiere Pro und After Effects ist völlig integer. Das meint: REC.709-Video rein -> bearbeiten -> exportieren -> Resultat: REC.709.Video.

Was passiert, wenn man da eingreift, z. B. zusätzlich eine REC.709-16-235-LUT drauflegt, oder den Farbraum auf REC.709(16-235) umstellt (was faktisch dasselbe ist), zeigt das dritte Video:
Schaue Dir einfach Wave, Vektorskop und RGB-Parade an. Dem ist wohl nichts hinzuzufügen.

Derartige Farbraumumstellungen sind Sonderfällen vorbehalten. Die diskutieren wir hier besser nicht ... ;)

Jetzt kannst Du jeden Effekt, auch die Tonwertkorrektur und Farbraumvorgaben, beliebig selbst abmischen, ausprobieren und staunen, was da alles bei raus kommen kann!

Fazit: Wir haben gelernt:
AE und PR arbeiten im RGB-Wertebereich bei 8bit 0-255. Das entspricht in YCbCr dem Wertebereich Y 16-235.
Wenn bestimmte RGB-Wertebereiche nicht vorkommen, heißt das nur, dass es keine Pixel im Bild gibt mit diesen Werten. RGB 0-255 gilt trotzdem. IMMER. ;)
Die Verabeitung ist integer und Bedarf keiner händischen Korrekturen, abgesehen von seltenen Spezialfällen.

Wenn man da eingreifen möchte (weil z. B. ein Spezialfall vorliegt), muss man entweder sehr genau wissen, was man da tut, und welche Konsequenzen es hat, oder man testet es aus. Recht simpel.

Ich empfehle Dir dringend, es auszutesten. ;)

Beste Grüße,
Reiner

PS: Meine Einladung an Dich steht nach wie vor.



Antwort von dienstag_01:

@Reiner M
Wenn du sagst, dass man für den Export aus Premiere und AE den Wertebereich auf 0-255 belassen soll, dann ist das selbstverständlich richtig.
(Das dürfte auch die meisten Praktiker interessieren)
Dabei gibt es wie immer eine Einschränkung: wenn das exportierte File in einer anderen Applikation (ausserhalb von Adobe) verwendet werden soll, muss man beim Import das File u.U. remappen. Diese Notwendigkeit ist aber beim Austausch von Files häufig gegeben, also kein Fehler.

Wenn du aber sagst, dass der Wertebereich Y 16-235 grundsätzlich RGB-Werten von 0-255 entspricht, ist das genauso grundsätzlich falsch.
Vielleicht findet sich ja mal jemand bei Adobe und erklärt es so, dass auch du es verstehst. (Einen entsprechenden Artikel hatt ich schon in einem anderen Thread verlinkt, kam übrigens auch von Adobe ;) )

(Meine Einwände oben haben sich übrigens auf das von dir gebrauchte Wort IMMER bezogen. Zwar wissentlich von dir ignoriert, sprichst du jetzt IMMERhin von andersgearteten Spezialfällen. Es gibt also noch ein Quentchen Hoffnung ;) )



Antwort von Reiner M:

Dabei gibt es wie immer eine Einschränkung: wenn das exportierte File in einer anderen Applikation (ausserhalb von Adobe) verwendet werden soll, muss man beim Import das File u.U. remappen. Diese Notwendigkeit ist aber beim Austausch von Files häufig gegeben, also kein Fehler. 1. Ich habe Dir extra Videos beigefügt. Importiere sie wohin Du willst.
2. Das, was schließlich in einem exportierten Video vorliegt, ist NIE das, womit wir in Ae arbeiten. Das sollte Dir eigentlich klar sein. Was erwartest Du also? Erklär mal bitte.

Innerhalb von AE arbeiten wir mit RGB 0-255. Was daraus beim Export entsteht, bestimmt allein der verwendete Codec.
Wenn Du also H.264 für den Export wählst, wird YUV gemäß REC.709 dabei rauskommen, der RGB-Wertebereich 0-255 aus dem Arbeitsbereich von AE wird im Videofile als YCbCr mit Y16-235 gespeichert, ganz automatisch. Ohne weiteres Zutun. Jeder zusätzliche, unsachgemäße oder voreilige Eingriff zerstört das Video!
Habe ich wohl deutlich genug gezeigt.

Ach ja: Um Spezialcodecs für Datenaustausch geht es hier übrigens auch nicht. Weder beim Fragesteller stephan, noch bei den meisten anderen, die einfach nur ein Video erstellen wollen. Was also soll dieser "Sonderfall" hier schon wieder? ;)

Bevor Du Dich um Sonderfälle kümmerst, solltest Du erstmal verstehen, wie es grundsätzlich läuft. Sonst leitest Du doch zwangsläufig falsche Schlüsse daraus ab. ;) Das zeigen ja Deine Screenshot oben hinreichend ... falsche Schlussfolgerungen. ;)
Wenn du aber sagst, dass der Wertebereich Y 16-235 grundsätzlich RGB-Werten von 0-255 entspricht, ist das genauso grundsätzlich falsch. Stimmt. Sorry. ich habe mit "IMMER" etwas überzogen ...
Wenn Du nämlich mit 10bit-, 16bit- oder gar 32bit-Wertebereichen arbeitstest, stimmt 0 bis 255 natürlich nicht. ;)
Es bleibt aber IMMER der volle Wertebereich. ;)
So ist liegt das Video in meinen Premiere Pro - Beispielen nämlich gar nicht in RGB 0-255, sondern in RGB 32bit 0.0-1.0 . Weil das dort der Standard-Wertebereich ist, solange bis ... - ach lassen wir das. ;)
.. sprichst du jetzt IMMERhin von andersgearteten Spezialfällen. Es gibt also noch ein Quentchen Hoffnung ;) ) Mach' Dir da mal keine falschen Hoffnungen, Dienstag! ;)

Die "Spezialfälle", die ich meine, ändern an dem AE-Wertebereich RGB 0 bis 255 nichts. Nur an der Verteilung der Werte.

Dafür habe ich Dir doch extra den "Spezialfall" Umstellung des Farbraums nach HDTV (Rec.709) 16-235 im Beispiel plastisch vor Augen geführt. :-(
Es bleibt bei RGB 0-255, oder nicht? Nicht zu sehen?
Nur treten jetzt Pixel mit bestimmten RGB-Werten einfach nicht auf. Aber das hat unschöne Konsequenzen für den Export unbd damit für das Video.
Probiers aus ...

So, nun kannst Du ja erklären, wofür man diesen "Spezialfall" braucht. ;)


Beste Grüße,
Reiner



Antwort von dienstag_01:

@Reiner M
Du hast es sicher gerne, mal bissel nachzudenken. Und ich weiss hier wirklich nicht weiter ;)
Schau dir den Clip mal in verschiedenen Browsern an, unbedingt auch im Firefox mit HTML5. Was issn da los?

https://www.youtube.com/watch?v=WRPa9BDmYXE

Kommt aus Premiere.

EDIT: ich meine natürlich, HTML5 und Flash ;)



Antwort von Reiner M:

@Dienstag,

was möchtest Du denn erreichen? Was soll schließlich zu sehen sein? Nur die schwarze Fläche mit dem einem weißen Quadrat, oder die verschachtelten Quadrate?

-------------
Aber ein paar Infos dazu, soweit sie in unsere Diskussion passen:

Das Video ist so hergestellt, dass im bildgebenden Bereich (Y16-235) nur die eine schwarze Fläche und das eine weiße Quadrat liegen. Alle Player, die das so wiedergeben arbeiten korrekt nach REC.709.

In Premiere Pro:
Dieser Bereich liegt in RGB 0.0 bis 1.0 (0-255).
Die übrigen Quadrate liegen im Foot- und Headroom.
Der Bereich Y kleiner 16 wird in Premiere Pro zu negativen RGB-Werten führen, der Bereich Y größer 235 zu RGB-Werten größer 1.0 .
Beim erneuten Export werden diese Bereiche berücksichtigt und sind im exportierten Video wieder erhalten, doch nur, solange Du in 32bit bleibst,
Alles gut.

In Ae:
Das Video wird in Ae in jedem Fall nur den bildgebenden Bereich anzeigen, also nur die schwarze Fläche und das eine Quadrat. Logisch.
ABER:
Wenn Du im 8bit-Modus bist, bekommst Du nur die Werte 0 und 255 angezeigt. Sonst nichts. Der Export wird auch nur das exportieren.

Schaltest Du das Projekt auf 32bit um, bekommst Du plötzlich Werte außerhalb 0-255 angezeigt, sobald Du mit der Maus über das Bild fährst. Die Anzeige des Bildes verändert sich nicht.
Der Export wird die Werte speichern und wieder zu Y-Werten kleiner 16 und größer 235 führen.

Alles ganz alles normal, wie zu erwarten.

Und zur Praxis:

Wenn nun Player bei der Wiedergabe von der REC.709-Empfehlung abweichen (das können die Programmierer frei entscheiden), und auch den Head- und den Footroom anzeigen, und Du das nicht möchtest, solltest Du auf ein solches Video in Premiere Pro bewußt den Video-Limiter anwenden und den gespeicherten Datenbereich in YCbCr hart auf 300mV bis 1V begrenzen. Oder im 8bit-Modus arbeiten.

Wenn Du dagegen alle Quadrate immer sehen willst, in jedem Player, wende eine Luminanzkorrrektur an bis die Bereiche außerhalb in den Bildgebenden Bereich fallen.

Wenn es Dir egal ist, lasse es so.

Auf keinen Fall solltest Du mit hier mit unpassenden Werkzeugen arbeiten und z. B. am Farbraum rumspielen.

Beste Grüße,
Reiner



Antwort von dienstag_01:

Beim erneuten Export werden diese Bereiche berücksichtigt und sind im exportierten Video wieder erhalten, doch nur, solange Du in 32bit bleibst, Das ist jetzt nicht direkt der ultimative h264 Codec in 32bit.
Wir bleiben mal schön bei 8 ;)






Antwort von Reiner M:

Beim erneuten Export werden diese Bereiche berücksichtigt und sind im exportierten Video wieder erhalten, doch nur, solange Du in 32bit bleibst, Das ist jetzt nicht direkt der ultimative h264 Codec in 32bit.
Wir bleiben mal schön bei 8 ;) Was bitte schön verstehst Du da nicht?
Natürlich ist YcbCr bei einem 8bit-Video 8bit.

Premiere Pro arbeitet in 32bit und lädt beim Import Y-Werte außerhalb Y16-235 in RGB-Werten kleiner 0.0 und größer 1.0. Daraus werden beim Export vom Codec wieder Y-Werte kleiner 16 und größer 235 generiert. Rein-rum-raus - und alles ist gut. Tipp am Rande, den ich nun gar nicht mehr geben mag: Probiere es aus! ;)

Doch Vorsicht: Sobald Du Premiere Pro in den 8bit-Modus zwingst, sind die Head- und Footroomdaten weg und können vom Codec folglich auch nicht mehr in das Video gepackt werden.

Anm: Genau damit zerstören sich manche Anwender bei der Produktion von Zwischenergebnissen ganz beiläufig Videodaten, die noch sinnvoll sein könnten. Alles eine Frage des Workflows.

Ich denke, Du kennst Premiere Pro? ;)

Beste Grüße,
Reiner



Antwort von dienstag_01:

Daraus werden beim Export vom Codec wieder Y-Werte kleiner 16 und größer 235 generiert. Genau. Und in RGB werden beim Export natürlich Werte kleiner 0 und größer 255 erzeugt. Nach der Theorie von Reiner M.
Absurd.



Antwort von Reiner M:

Daraus werden beim Export vom Codec wieder Y-Werte kleiner 16 und größer 235 generiert. Genau. Und in RGB werden beim Export natürlich Werte kleiner 0 und größer 255 erzeugt. Nach der Theorie von Reiner M.
Absurd. Dienstag .... :-)))
Jetzt wirds echt lustig, um nicht zu sagen lächerlich ...
Willst Du mich veralbern?

Ja,ja, wenn die Erkenntnis aufschlägt, dass die eigenen Grenzen erreicht wurden, wirds in aller Regel hahnebüchend ... ;)


Wir haben doch eben durchgehend über H.264 geredet (Dein Youtube-Video) und über YCbCr, oder nicht? Anderer Meinung?
Was hat RGB-Speicherung damit zu tun? Gar nichts. Falls doch: Sei so gut und erkläre es.

Aber auch das habe ich schon längst beantwortet. Es wäre Dir nicht entgangen, wenn Du aufgepasst hättest:
Innerhalb von AE arbeiten wir mit RGB 0-255. Was daraus beim Export entsteht, bestimmt allein der verwendete Codec. Nochmal passender für Premiere Pro (falls das mißverständlich war):

Innerhalb von Premiere Pro arbeiten wir standardmäßig mit RGB 32bit-Float. Was daraus beim Export entsteht, bestimmt allein der verwendete Codec.

Speicherst Du H.264 als RGB? Ja, dann ...

Wenn Du nun wissen möchtest, wie das im Zusammenhang mit Codecs funktioniert, die Videodaten in RGB speichern, ob das geht oder nicht, hättest Du fragen können. Oder wenn Du einen sinnvollen Beitrag hättest liefern können, der es erklärt, auch sehr gerne das.
Unsinnige Unterstellungen sind m. E. jedoch völlig Fehl am Platz! Du bekommst hier gerade kostenlose Nachhilfestunden geboten. ;)

Daher: Probiers es einfach aus.

Hier gibts jetzt jede Menge Erklärungen dazu. Du kannst es ja noch mal in Ruhe lesen - oder auch lassen. Lernen ist ja hier kein Pflichtprogramm. ;)

Beste Grüße,
Reiner



Antwort von dienstag_01:

Wir haben doch eben durchgehend über H.264 geredet (Dein Youtube-Video) und über YCbCr, oder nicht? Anderer Meinung?
Was hat RGB-Speicherung damit zu tun? Gar nichts. Falls doch: Sei so gut und erkläre es. Du bist wohl neuerdings der Meinung, die RGB-Werte stehen in einem willkürlichen Verhältnis zu den YUV Werten?! Heute so und morgen so ;)
Natürlich nicht. Y16-235 heiss RGB 16-235. Und Adobe mapped diese Werte auf 0-255.
Glaubst du mir nicht. Weiss ich.
Glaubst du auch den von Adobe verlinkten Erklärungen nicht. Weiss ich auch.
Glaubst du auch der Mathematik nicht. Kann man hier deinen Ausführungen entnehmen.

Bei dir wundert mich gar nichts mehr.



Antwort von Reiner M:

Und Adobe mapped diese Werte auf 0-255. Na, bravo! Wir sind einStück weiter ... Genau so ist es, und zwar in den Verabeitungsspeichern der Programme. Doch lernfähig ... ;)
Y16-235 heiss RGB 16-235. Hier ist noch Bedarf zur Fortbildung ...

Dienstag, Du musst unterscheiden, worüber Du redest.
Im Arbeitsspeicher der Programme wird Y16-235 als RGB 0-255 abgebildet. Das hast Du ja inzwischen erkannt.

Mit welchen Werten eine Datei importiert wird oder dann via Export/Codec ausgegeben wird, ist von den internen Arbeitsspeichern unabhängig. Es finden "mappings", Transformationen, Umrechnungen statt.

Das gilt auch bei Datein, die mit RGB-Inhalten angeliefert oder produziert werden.

Gib einfach mal ein Video (z. B. Dein Youtube-.mp4) als PNG-Sequenz aus. Da ist dann RGB 0-255 drin. Und nun? Wo ist denn Dein RGB 16-235 geblieben? ;)

Maßgeblich ist der bildgebende Bereich für den Import und den Export!
Die Import- und Exportfunktionen kennen die Formate. Deshalb liest man in den Produktdatenblättern, welche Formate die Programme lesen und welche sie ausgeben können. Oder man kauft sich benötigte Codecs als Plug-Ins. Uns schon geht, was die können. Das ist also Sache der Codecs.

Dann passiert z. B. das:
Bei YUV / Y16-235 -> Ae/Pr intern: RGB 0-255 -> Export: Codec-Spezifikationen
Bei PNG /TIFF usw.: RGB 0-255 -> Ae/Pr intern: RGB 0-255 -> Export Codec-Spezifikationen.
Usw.
Das NLE (genauer: Importer und Exporter) weiß also, wo das Bild zu finden ist (bildgebender Bereich) und welche Umrechnungsregeln herangezogen werden müssen, um vom Import in den Arbeitsspeicher und von dort in den Export zu kommen. Total easy. ;)

----------

Davon getrennt nochmal (wie schon so oft, aber Du bringst es wieder aufs Tablett):
YCbCr hat mit RGB nichts zu tun! Das ist ein anderes Farbmodell. Die Informationen sind völlig unterschiedlich aufgebaut. Will man zwischen diesen Modellen Daten austauschen, müssen sie aufwendig umgerechnet werden.

Deine Annahme, da gibts ein Beziehungsverhältnis 1: 1 ist falsch!

Das schlimme daran ist: Alle Folgerungen, die Du darauf aufbaust, sämtliche Aussagen, Thesen und Behauptungen in diesem Zusammehang sind daher von vornherein auch falsch. Weils Fundament schon nicht passt. Leider ... ;)

Ich würde mich an Deiner Stelle tatsächlich noch mal näher mit diesen Themen beschäftigen. Mehr kann ich Dir da nicht ans Herz legen.

Beste Grüße,
Reiner



Antwort von dienstag_01:

Aha, man darf Fortschritte konstatieren.
In einem anderen Thread hast du noch behauptet, Y 16-235 sei IMMER (scheinbar dein Lieblingswort) RGB 0-255. Jetzt wird schonmal gepapped.
Wenn du jetzt noch verstehst, dass das eine Besonderheit von Adobe und nicht generell so ist, chapeau, dann gehts in riesen Schritten in die richtige Richtung. Und wenn du dann auch noch verstehst, dass YCbCr sehr wohl was mit RGB zu tun hat, wo glaubst du eigentlich kommen die Werte - um das Verständnis zu erleichtern, sagen wir mal bei einem 3-Chip-Camcorder - her ;), dann, ja dann Reiner...
Ich wage gar nicht, mir das auszumalen ;)



Antwort von EnricoPerei:

OK, um es hier mal ganz klar zu sagen:

Wer beim Import 16 auf 0 und 235 auf 255, sowie alle Werte dazwischen entsprechend mapped, vermurkst sein ganzes Bild, weil er bei der Bearbeitung mit gespreizten Farben gearbeitet hat!!
Egal, ob man das dann wieder beim Export rückmapped oder nicht, es ist NICHT das Original!

WTF ?!



Antwort von Jörg:

deine philanthropische Konsequenz lässt mich schaudern, Reiner...



Antwort von dienstag_01:

Wer beim Import 16 auf 0 und 235 auf 255, sowie alle Werte dazwischen entsprechend mapped, vermurkst sein ganzes Bild, weil er bei der Bearbeitung mit gespreizten Farben gearbeitet hat!! An irgendeiner Stelle passiert das bei jedem Video (wir sprechen von Rec709 16-235, also Standard), was auf einem Videomonitor mit den richtigen Kontrasten ausgegeben wird. Ob das nun nur die Vorschau ist und intern wird mit den *richtigen* Werten weitergearbeitet oder ob die Werte intern umgerechnet werden, sei mal dahingestellt.






Antwort von Reiner M:

In einem anderen Thread hast du noch behauptet, Y 16-235 sei IMMER (scheinbar dein Lieblingswort) RGB 0-255. Da sieht man mal, wie verdreht manches dargestellt werden kann... ;)
Kann aber auch sein, dass ich extraterristisch spreche ...

Nein: YCbCr und RGB sind völlig verschiedene Farbmodelle.
Ja: in Ae und Pr wird Y16-235 aus einen REC.709-Video nach RGB 0-255 übertragen.
War das jetzt Deutsch? Ist es angekommen? ;)

Schau bitte mal gleichzeitig in die YCbCr-Parade und in die RGB-Parade von Premiere Pro. Du siehst zeitgleich die Inhalte zweier verschiedener, völlig getrennter Speicherbereiche in Pr. Die haben miteinander nichts zu tun. Sie produzieren aber beide das selbe Bild.

Sehen sie unterschiedlich aus? Deutet irgendetwas darauf hin, dass sie in einer 1: 1 - Beziehung stehen? Hmmm ?
Dann frag Dich mal, warum das so ist.

Wenn in anderen Programmen der RGB-Arbeitsspeicher 16-235 umfasst, (was ja möglich ist, wie schon so oft erklärt, aber eben nicht in Premiere Pro und After Effects), dann sind die Werte trotzdem in völlig unterschiedlicher Ausprägung gespreichert.

Zum Thema "Mathematik": Ja, der glaube ich! Ich kenne aber auch die Formeln, die für die Umrechnung zwischen YC und RGB nötig sind. Sowohl um YC nach RGB 16-235 zu kommen wie auch von YC nach RGB 0-255, (was völlig ungespreizt funktioniert, weil die Koeefizienten andere sind).

Und zum Thema "Adobe-Doku": Auch der glaube ich. Ich kenne sie aber auch. ;)

Ich gehe mal davon aus, dass von Dir heute nur noch weitere Verdrehungen und aus dem Kontext gerissene, neueingefärbte Aussagen aus alten Texten von mir folgen werden, die alle weder konstruktiv noch zielführend sind, (wobei mir ihr Sinn selbstverfreilich absolut klar und auch ein Stück weit verständlich erscheint),

Gute Nacht & Beste Grüße,

Reiner

Melde Dich einfach, wenn Du doch mal Spaß an einem Treffen hast. Oder wenn Du Antworten zu meinen vielen Fragen liefern möchtest, die fast alle offen geblieben sind.



Antwort von Reiner M:

Wer beim Import 16 auf 0 und 235 auf 255, sowie alle Werte dazwischen entsprechend mapped, vermurkst sein ganzes Bild, weil er bei der Bearbeitung mit gespreizten Farben gearbeitet hat!! An irgendeiner Stelle passiert das bei jedem Video (wir sprechen von Rec709 16-235, also Standard), was auf einem Videomonitor mit den richtigen Kontrasten ausgegeben wird. Ob das nun nur die Vorschau ist und intern wird mit den *richtigen* Werten weitergearbeitet oder ob die Werte intern umgerechnet werden, sei mal dahingestellt. Boah ...

@EnricoPerei
Nein, da wird nichts vermurkst!
Für die Übertragung von YC nach RGB 0-255 werden andere Formeln verwendet, als bei YC nach RG 16-235. das Ergebnis sind völlig glatte Übergänge (vorausgesetzt, sie sind in YCbCr bereits glatt gewesen).

Beste Grüße,
Reiner



Antwort von EnricoPerei:

Wer beim Import 16 auf 0 und 235 auf 255, sowie alle Werte dazwischen entsprechend mapped, vermurkst sein ganzes Bild, weil er bei der Bearbeitung mit gespreizten Farben gearbeitet hat!! An irgendeiner Stelle passiert das bei jedem Video (wir sprechen von Rec709 16-235, also Standard), was auf einem Videomonitor mit den richtigen Kontrasten ausgegeben wird. Ob das nun nur die Vorschau ist und intern wird mit den *richtigen* Werten weitergearbeitet oder ob die Werte intern umgerechnet werden, sei mal dahingestellt.
REC.709 ist ein Standard(wie Du es ja auch sagtest, kein Farbraum), der weit mehr als nur einen Farbraum mit legalen Farben sichert.
Schau Dir mal hier Punkt 5, digital representation an:
http://www.itu.int/dms_pubrec/itu-r/rec ... !PDF-E.pdf

Die Werte 1-254 sind für Videodaten reserviert, wobei 16-235 den legal Colours entsprechen und beim Senden Werte größer und kleiner ceclamped werden.
16 ist nicht Schwarz, es ist ein klein wenig darüber und 235 ist eben nicht Weiß

Wenn ein Mapping nun im Display geschieht, ist das kein Problem.

Aber gerade für die Bearbeitung ist es sehr wichtig, daß man die Farben nicht spreizt!!

Egal, ob Blur, Glow, verschiedenen Merge Operationen oder was auch immer, deine Algorithmen werden völlig andere Zahlen ergeben, ergo anders aussehen.


Auch aus diesem Grunde bin ich einer der Puristen.
Wir bearbeiten unser Material unprocessed (ich will nicht raw sagen, da das nicht dem bekannten RAW entspricht).
Wenn wir uns das, was wir gerade machen, im Zielformat anschauen wollen, dann legen wir ein LUT drauf (aber nur die Anzeige, NICHT das Material!).
Erst am Ende, oder wenn irgendeine Operation dies mal erforderlich macht, wird gewandelt.

AUF DIESE WEISE BLEIBT DAS ORIGINAL MATERIAL INTEGER!



Antwort von Reiner M:

deine philanthropische Konsequenz lässt mich schaudern, Reiner... Ich glaube an das Gute im Menschen. ;)

Beste Grüße,
Reiner



Antwort von dienstag_01:

AUF DIESE WEISE BLEIBT DAS ORIGINAL MATERIAL INTEGER! Aus diesem Grund arbeite ich mit Avid ;)

Danke übrigens für den Link, sowas habe ich schon länger gesucht (und Reiner M fällt beim Lesen von Aussagen wie *R, G, B, Y ist 16* sicher in Ohnmacht)

Was genau Adobe da macht, ich weiss es nicht 100%ig, aber ich bin doch ziemlich sicher, dass sie nur die Vorschau auf 0-255 mappen - also eine Art LUT - aber wie soll ich das genau rausbekommen/beweisen. After Effects jedenfalls kann man Arbeitsfarbräume zuweisen, da werden bspw. bei vollem Weiss auch nur 235 angezeigt, ich denke nicht, dass sie die Werte erst von 235 nach 255 wandeln und dann mit dem Colorpicker wieder 235 anzeigen, sondern genau umgekehrt: sie zeigen den Originalwert 235 an und mappen die Vorschau auf 255, sonst wäre es auf dem Monitor nur Hellgrau. Aber egal.
Wie gesagt, Avid ist da konsequent und man weiss, wo man ist.



Antwort von Reiner M:

Die Werte 1-254 sind für Videodaten reserviert, wobei 16-235 den legal Colours entsprechen und beim Senden Werte größer und kleiner ceclamped werden.
16 ist nicht Schwarz, es ist ein klein wenig darüber und 235 ist eben nicht Weiß Alles bekannt. ;)

Du redest da über Y-Werte in YCbCr-Speicherung. Okay?

Wieviele Bytes stehen Dir denn in YCbCr zur Verfügung, um in RGB den Blau-Kanal zu füllen? In RGB sind es 256 oder 220 Bytes im Blaukanal, je nachdem, ob Du RGB 0-255 oder RGB 16-235 wählst.
Oder 32.768 Bytes bei einem RGB 16bit Arbeitsfarbraum. Oder ganz viele Bytes bei RGB 32bit Float.

Ist es also schlecht in 16bit und 32bit zu arbeiten, weil da ja lauter Lücken vorkommen müssen? Riesige Spreizungen vorhanden sind? Hmmm..

Wieviele Bytes hast Du in YCbCr, um in RGB "braun" zu erzeugen in allen Nuancen (Helligkeiten, Sättigungen)? Leider gibts keinen "Braun-Kanal", weder hier noch dort, was die Sache womöglich schwieriger macht, oder auch nicht. ...

Und vor allem: Wie wird umgerechnet?


Beste Grüße,
Reiner



Antwort von dienstag_01:

@Reiner
Lies dir mal das Papier durch.
Und dann schweige.
Keen Bock mehr auf den Quatsch.



Antwort von EnricoPerei:

AUF DIESE WEISE BLEIBT DAS ORIGINAL MATERIAL INTEGER! Aus diesem Grund arbeite ich mit Avid ;)

Danke übrigens für den Link, sowas habe ich schon länger gesucht (und Reiner M fällt beim Lesen von Aussagen wie *R, G, B, Y ist 16* sicher in Ohnmacht)

Was genau Adobe da macht, ich weiss es nicht 100%ig Ja, den MC mag ich auch.
Der ist ja auch nicht umsonst das Tool der Wahl.

Was mich auch dazu bringt, warum ich AE überhaupt nicht zum arbeiten benutze (;

DS habe ich nicht wirklich ausprobiert, nun ist's dann wohl auch zu spät...

hehe, keine Ursache für den Link, ich dachte mir, wenn wir uns schon darüber unterhalten, sollten wir auch einen Blick auf das nicht ganz in Stein gemeißelte Wunderwerk werfen...



Antwort von Reiner M:

Was genau Adobe da macht, ich weiss es nicht Das wissen doch längst, Dienstag.
Aber heute hattes Du Gelegenheit, viel zu verstehen, wenn Du gewollt hättest. ;)
aber ich bin doch ziemlich sicher, dass sie nur die Vorschau auf 0-255 mappen - also eine Art LUT - aber wie soll ich das genau rausbekommen/beweisen. After Effects jedenfalls kann man Arbeitsfarbräume zuweisen, da werden bspw. bei vollem Weiss auch nur 235 angezeigt, ich denke nicht, dass sie die Werte erst von 235 nach 255 wandeln und dann mit dem Colorpicker wieder 235 anzeigen, sondern genau umgekehrt: sie zeigen den Originalwert 235 an und mappen die Vorschau auf 255, sonst wäre es auf dem Monitor nur Hellgrau. Aber egal. Vom Augenschein abgeleitete Vermutungen, die über Sagen und Legenden direkt ins Reich der Märchen führen.

Das ist es, was Dich komplett unglaubwürdig macht, Dienstag.
Nichts wissen, aber behaupten. Und dann noch falsch. ;)
Sehr, sehr schade. :-(

Beste Grüße,
Reiner






Antwort von Reiner M:

@Reiner
Lies dir mal das Papier durch.
Und dann schweige.
Keen Bock mehr auf den Quatsch. Dienstag, ich kenne die Empfehlung recht gut. Danke. ;)

Dass Du die Antworten zu meinen Fragen bezüglich der RGB-Umrechnungen nicht geben kannst, ist mir doch klar.
Als Quatsch würde ich das an Deiner Stelle nicht abtun.

Da Du ja gerne liest, dann mal hier:http://de.wikipedia.org/wiki/YCbCr

Da bekommst Du einen Eindruck davon, wie zwischen YCbCr und RGB umgerechnet wird, sowohl in RGB 16-235 wie auch in RGB 0-255.

Wer davon ausgeht, die Umrechnung ist in beiden Fällen gleich und quasi nur eine Spreizung, die zu Fehlern führen muss, irrt sich ganz gewaltig. ;)

Und wer davon ausgeht, RGB 0-255 ist nur was für die Anzeige, hat einfach die Systeme ganz und gar nicht verstanden. Sorry. ;)

Beste Grüße,
Reiner



Antwort von WoWu:

Tja, ADOBE sagt dazu: SteveHoeg on Mar 22, 2011 9:56 AM
1) Generally the same color processing occurs during playback as export. Where possible we process and preserve YUV data all the way until display where we will convert on the fly. 2) Only the track items containing non-YUV effects will be converted to RGB, and only for the non-RGB effects.

3) Information can be lost in two ways. First some YUV values will map to negative RGB values or RGB values greater than 255 and we will clamp to those limits. Second a given YUV pixel value may map to a fractional RGB pixel value at which point we have to round to the nearest. 32-bit floating point RGB does not have either of these problems.

4) Many effects work directly in YUV. If you are looking for an example of chroma showing up in an effect's UI, video limiter would be one example. How we present controls to an effect is not always directly correlated to how it is rendered. Using the scopes to monitor YUV values has several purposes. Most output formats are still YUV so you will be monitoring what your output will be. Also depending on your target, ensuring broadcast legal values may be important. Further if you are trying to adjust something like the brightness of a scene the luma channel may be the most important value to measure. Worüber reden wir hier eigentlich ?
Adobe sagt selbst, dass möglichst im selben Farbmodell gearbeitet werden soll, ansonsten kann es zu Beeinträchtigungen kommen.

Und so ganz klar ist auch nicht, ob sie das Gamma eigentlich abstreifen.
Da ist also noch Raum für weitere mögliche Bildbeeinträchtigungen in dem Umfeld.

Vielleicht ist damit ja dem TS geholfen, dass ADOBE das selbst sagt.
https://forums.adobe.com/thread/825920

Und jetzt würden mich mal die ADOBE Papiere interessieren, die Reiner was anderes sagen. Gibt's 'n Link ?

Ansonsten tritt der Threat ziemlich "auf der Stelle".

Edit: Ich hatte bisher eigentlich von Deinen Ausführungen nicht so verstanden, dass Du 16/235/240 in R'G'B' emulierst sondern dass Du FR benutzt. wie sonst willst Du das im nachfolgenden Encoding dem Range-Bit mitteilen ?



Antwort von Reiner M:

Worüber reden wir hier eigentlich ?
Adobe sagt selbst, dass möglichst im selben Farbmodell gearbeitet werden soll, ansonsten kann es zu Beeinträchtigungen kommen. Richtig, Wolfgang.
Deshalb haben sie Effekte entwickelt, die direkt auf dem YCbCr-Speicher arbeiten können. Sie sind in der Effekte-Liste entsprechend markiert und sollten bevorzugt verwendet werden, falls Alternativen bestehen.

Als zweites empfehlen sie in Deinem Zitat die Nutzung von 32bit. Effekte, die das können, sind entsprechend markiert.
Verwendet man Effekte, die das nicht können, fällt das System in den 8-Bit Modus. Daher ihre dringlichen Warnungen an vielen Stellen der Doku.

Der Grund, den sie für die 32bit-Verabeitung neben der höheren Präzision angeben ist: Bei 8bit können RGB-Werte aus der Umrechnung von YUV nach RGB verloren gehen. Man könnte auch sagen, es entstehen "ungültige" Farben, bezogen auf den Zielfarbraum in 8bit. Und zwar können negative Werte entstehen, also kleiner 0, und solche über RGB 255, wie sie im Zitat schreiben. In 32bit sind sie speicherbar.

Das Beispiel dafür haben wir weiter oben gesehen: Dienstags Youtube-Video mit den Quadraten in Head und Footroom. Gehen in 8bit verloren, in 32bit nicht.

Im Umkehrschluss meint das für 8bit: Alle Werte größer-gleich 0 und kleiner-gleich 255 werden gespeichert. Der Arbeitsraum ist RGB 0-255.

Aus einer anderen Stelle der Ae-Doku:
8-Bit-Pixel können für jeden Farbkanal einen Wert zwischen 0 (Schwarz) und 255 (reine, gesättigte Farbe) annehmen. 16-Bit-Pixel können für jeden Farbkanal einen Wert zwischen 0 (Schwarz) und 32.768 (reine, gesättigte Farbe) annehmen. Wenn alle drei Farbkanäle auf den Maximalwert (reine Farbe) eingestellt sind, ergibt sich die Farbe Weiß. 32-Bit-Pixel können Werte unter 0,0 und über 1,0 (reine, gesättigte Farbe) annehmen. Dadurch entspricht die 32-Bit-Farbtiefe in After Effects zugleich High Dynamic Range (HDR)-Farben. HDR-Werte können wesentlich heller als Weiß sein. Das ist es, womit Ae und Pr intern arbeiten.
Ansonsten tritt der Threat ziemlich "auf der Stelle". Da muss ich Dir leider Recht geben.

Beste Grüße,
Reiner



Antwort von EnricoPerei:

Die Werte 1-254 sind für Videodaten reserviert, wobei 16-235 den legal Colours entsprechen und beim Senden Werte größer und kleiner ceclamped werden.
16 ist nicht Schwarz, es ist ein klein wenig darüber und 235 ist eben nicht Weiß
Oder 32.768 Bytes bei einem RGB 16bit Arbeitsfarbraum. Oder ganz viele Bytes bei RGB 32bit Float.

Ist es also schlecht in 16bit und 32bit zu arbeiten, weil da ja lauter Lücken vorkommen müssen? Riesige Spreizungen vorhanden sind? Hmmm..
Reiner, ich habe schon gemerkt, daß Du viel technisches Wissen hast, garantiert in vielen Bereichen weit mehr als ich.

Allerdings mußt Du bei den Bittiefen und Farbraumwandlungen sehr aufpassen, nicht Äpfel mit Birnen zu verwechseln:

Bittiefe drückt die Feinheit oder das Sampling (der analogen Signale) aus.
8 bit und 16 bit sind keine verschiedenen Farbräume,es sind ja nichtmal Farbräume.
Float stellt wiederum statt Ganzzahlen eben Kommazahlen dar.
16 und 32 bit float stellt eben Zahlen mit unterschiedlicher Feinheit/Sampling/Abstufung im Nachkommabereich dar. Mein Wertebereich, sagen wir 0-1 bleibt dabei gleich.


Wenn ich von 8 auf 16 oder mehr Bit(int) wechsle, ist das im Grunde, als würde ich mein Haus erst mit Ziegelsteinen und dann mit Kieselsteinen bauen.
Ein Ziegelstein wird durch 255 Kieselsteine ersetzt, deren Gesamtvolumen/Ausmaße entsprechen dem des Ziegelsteins.
Das Haus bleibt gleich groß, Türen und Fenster passen und sitzen an den gleichen Stellen, aber ich kann unter Anderem wesentlich schönere Bögen gestalten
- weniger(genau genommen feineres) Banding, um mal auf OP zurückzukommen (;.

->Keine Farbwerte werden gespreitzt!!


Wenn ich allerdings erst mit Ziegelsteinen und dann mit Findlingen baue, wobei ich einen Ziegelstein jeweils mit einem weit größeren Findling ersetze, vergrößert sich mein Haus, Fenster und Türen sitzen an anderen Stellen und passen nicht, da sie nun größer sein müssen.

->Farbwerte werden gespreizt.

Dies ist("leicht" übertrieben), was Farblich (nicht nominell) einer Wandlung von 16-235 auf 0-255 gleichkommt.


...na, wenn ich damit mal nicht noch mehr verwirrt habe...mich zumindest habe ich schon...



Antwort von WoWu:

Als zweites empfehlen sie in Deinem Zitat die Nutzung von 32bit. Effekte, die das können, sind entsprechend markiert. Empfehlung ist wohl die falsche Bezeichnung .... Kompromiss wäre zutreffender.

Aber die ganze Einlassung von ADOBE klingt mir da nicht nach:

"Alles prima, wandeln Sie nach RGB und erkennen Sie die Vorzüge unserer fortschrittlichen Programme"...

Das Ganze klingt mir eher nach .... "wenn es sich vermeiden lässt, lassen Sie die Finger davon und wenn es unbedingt sein muss, dann ist 32 Bit zwar nicht der Bringer, aber das geringste Übel".

Ich denke nach wie vor, dass die Einganstipps, es möglichst bleiben zu lassen, die Empfehlungen sind, die dem Bildmaterial noch am besten tun.



Antwort von dienstag_01:

Das Beispiel dafür haben wir weiter oben gesehen: Dienstags Youtube-Video mit den Quadraten in Head und Footroom. Gehen in 8bit verloren, in 32bit nicht. Das ist natürlich voll der Quatsch. Das sind 8bit und das geht auch mit einem Effekt in 8bit.

Edit: Sonst gäbe es auch die ganzen Kameras nicht, die 0-255 oder 16-255 in 8bit aufzeichnen (egal, ob man das nun sinnvoll findet oder nicht)



Antwort von Reiner M:

Allerdings mußt Du bei den Bittiefen und Farbraumwandlungen sehr aufpassen, nicht Äpfel mit Birnen zu verwechseln: Enrico, das ist mir alles bekannt.

Ich möchte Dich eben nur bitten, nochmal näher hinzugucken, wie die Umrechnungen vorgenommen werden. Im Wikipedia-Artikel ist es im Wesentlichen beschrieben. http://de.wikipedia.org/wiki/YCbCr

Es kommen verschiedene Formeln zum Einsatz. Ich muss die richtige wählen, wenn ich von YC nach RGB 0-255 umrechnen will und umgekehrt. Da gibt es dann keine "Spreizungen", weil andere Gewichtungen vorgenommen werden (Faktoren in den Gleichungen). Die Farben sind durchgängig übergangslos in einem Kanal.

Die Vorstellung, dass hier nur fertige Steinchen von einem Farbraum in den anderen geworfen werden, und Doppelungen, Lücken oder Dither entsteht, wo es im größeren Wertebereich 0-255 nicht passen würde, ist falsch. Auch die Vorstellung , dass das nur für Vorschau-Anzeige aufbereitet würde, ist falsch.

So genügt.

Beste Grüße,
Reiner



Antwort von dienstag_01:

Die Tatsache, dass 220 Werte (16-235) umgerechnet (gemapped) auf 256 Werte (0-255) nur mit Interpolation geht und die bei nachfolgenden Berechnungen zu Fehlern führen muss (auch wenn die Werte hundert Stellen nach dem Komma haben) ist eigentlich Schulstoff der, na, ich schätze, 6. Klasse. Reiner aber nicht zu vermitteln.



Antwort von Reiner M:

Das Beispiel dafür haben wir weiter oben gesehen: Dienstags Youtube-Video mit den Quadraten in Head und Footroom. Gehen in 8bit verloren, in 32bit nicht. Das ist natürlich voll der Quatsch. Das sind 8bit und das geht auch mit einem Effekt in 8bit.

Edit: Sonst gäbe es auch die ganzen Kameras nicht, die 0-255 oder 16-255 in 8bit aufzeichnen (egal, ob man das nun sinnvoll findet oder nicht) Dienstag,
Du redest wieder wirres Zeug. ;)

Natürlich ist das in 8bit-YCbCr enthalten. Wo solls denn sonst herkommen?

ABER: Wenn Du das in Premiere Pro oder AE im 8bit-Arbeitsspeicher verarbeitest, ist es dort weg! In 32bit nicht!

Und warum? Weil der Bereich Y16-32 nach RGB 0-255 geladen wird und dort, in diesem Wertebreich 0-255, dann kein Platz mehr ist, um den Head- und den Footroom zu speichern! Wo soll der denn hin???

Und wenn Du davon ein Video exportierst, hatr die Kopie diese Daten nicht mehr! Woher sollen die denn kommen? Wohl aber alles zwischen Y16 und 235. Das ist Unterschied zwischen 8bit und 32bit.

Hast Du den Adobe-Artikel-Ausschnitt, den Wowu gepostet hat, nicht gelesen, oder nicht verstanden? Ist es jetzt klar geworden?

Probiere es doch aus:
Entweder: Lade diese Video nach AE, mach sonst nix. Exportiere es, und schau Dir danach vom Resultat die Luma-Wave an.
Oder: Lade es in Premiere Pro, lege einen 8bit-Effekt drauf, der nix tut (dann arbeitet Pr in 8bit.) Erportiere das Video.
Vergleiche die Luma-Waves von Origianal und Kopie. Und staune.

Immer wieder das selbe ...
Unglaublich! ;)

Beste Grüße,
Reiner






Antwort von dienstag_01:

Reiner, das Video ist von mir. Nicht von dir. Nur mal zur Klarstellung. Erzähle mir also nichts vom Pferd.
Dieses Video ist aus PREMIERE.



Antwort von Reiner M:

Die Tatsache, dass 220 Werte (16-235) umgerechnet (gemapped) auf 256 Werte (0-255) nur mit Interpolation geht und die bei nachfolgenden Berechnungen zu Fehlern führen muss (auch wenn die Werte hundert Stellen nach dem Komma haben) ist eigentlich Schulstoff der, na, ich schätze, 6. Klasse. Reiner aber nicht zu vermitteln. Dienstag,

Hast Du die Formeln in dem Wikipedia-Artikel gesehen?
Das ist für Dich Schulstoff der 6. Klasse? ;)

Da wird nichts interpoliert, sondern mit harten Faktoren völlig anders berechnet.
Du weißt halt nichts darüber, willst es aber auch nicht wissen, schätze ich ... und deshalb is es Dir auch nicht zu vermitteln. Nur solltest Du dann nicht so viel drüber reden. ;)

Dabei hast Du jetzt die Chance. Mach Dich schlau, lies nach, ich beantworte Dir gerne Fragen, wenn was unklar ist.


Beste Grüße,
Reiner



Antwort von Reiner M:

Reiner, das Video ist von mir. Nicht von dir. Nur mal zur Klarstellung. Erzähle mir also nichts vom Pferd.
Dieses Video ist aus PREMIERE. Ja und?
Ändert das was an den technischen Gegebenheiten? Es ist tatsächlich ein gutes Beispiel für viele Themen der Videobarbeitung. Herzlichen Glückwunsch.

Beste Grüße,
Reiner



Antwort von WoWu:

Aber das interessiert mich jetzt doch mal.

Ich hab nochmal in der Literatur geschaut, aber da finde ich kein Format das Y'CbCr nach RGB in 16/235/240 transformieret. Ich hab da fünf Verfahren drin, mit und ohne Gamme, hin und her, aber keins, das 1:1 mapped.

Aber wir lernen ja nie aus ... gib doch mal die Formel oder den Link dazu rüber.
Das würde mich jetzt wirklich interessieren, nach welchem Format das möglich ist und wie das unterstützt wird.

Offenbar hat der ADOBE Supportmensch ja auch nichts darüber gewusst.
Vor allem interessiert mich, wie ein 16/235/240 Modell in RGB signalisiert wird. das müsste sich dann ja in dem Standard finden.



Antwort von dienstag_01:

Ändert das was an den technischen Gegebenheiten? Nein, es zeigt nur, dass diese Aussage: Das Beispiel dafür haben wir weiter oben gesehen: Dienstags Youtube-Video mit den Quadraten in Head und Footroom. Gehen in 8bit verloren, in 32bit nicht. schlicht falsch ist.
Da wird nichts interpoliert, sondern mit harten Faktoren völlig anders berechnet. Du meinst also, die Werte denkt sich das Programm einfach aus. Weil, die gibts ja als Ausgangswerte nicht.
Was erzählst du denn eigentlich...



Antwort von Reiner M:

Als zweites empfehlen sie in Deinem Zitat die Nutzung von 32bit. Effekte, die das können, sind entsprechend markiert. Empfehlung ist wohl die falsche Bezeichnung .... Kompromiss wäre zutreffender.

Aber die ganze Einlassung von ADOBE klingt mir da nicht nach:

"Alles prima, wandeln Sie nach RGB und erkennen Sie die Vorzüge unserer fortschrittlichen Programme"...

Das Ganze klingt mir eher nach .... "wenn es sich vermeiden lässt, lassen Sie die Finger davon und wenn es unbedingt sein muss, dann ist 32 Bit zwar nicht der Bringer, aber das geringste Übel".

Ich denke nach wie vor, dass die Einganstipps, es möglichst bleiben zu lassen, die Empfehlungen sind, die dem Bildmaterial noch am besten tun. Mag ja alles richtig sein, Wolfgang. Das Ganze Videobarbeitungsgesumse ist eine Welt voller Kompromisse. Angefangen bei der Wahl der Objektive vor der Cam ...

Und immerhin ist es m. E. deutlich mehr, als andere NLEs mibringen, können oder bieten. Das ist aber auch egal. Zum Schluss kommt es nur darauf an, ob man sein Werkzeug kennt und beherrscht und wie man einen gescheiten Workflow aufbaut um möglichst gute Ergebnisse zu erzielen. Denn Wege gibt es viele, falsch machen kann man schnell alles mögliche. Wie man auch in diesem Thread haufenweise sieht. Leider.

Schönen Abend,

Reiner



Antwort von Reiner M:

Nein, es zeigt nur, dass diese Aussage: Das Beispiel dafür haben wir weiter oben gesehen: Dienstags Youtube-Video mit den Quadraten in Head und Footroom. Gehen in 8bit verloren, in 32bit nicht. schlicht falsch ist. Du hast es immer noch nicht ausprobiert ...
Schlimmer noch: Du kennst Premiere Pro nicht und glaubst nicht mal der Adobe-Doku. ;)
Da wird nichts interpoliert, sondern mit harten Faktoren völlig anders berechnet. Du meinst also, die Werte denkt sich das Programm einfach aus. Weil, die gibts ja als Ausgangswerte nicht.
Was erzählst du denn eigentlich... Ne, es berechnet sie.
Programme können nicht "denken" ... ;)

Du hast Dir die Formel immer noch nicht angesehen ...

Witzlos.

Beste Grüße,
Reiner



Antwort von dienstag_01:

Du hast es immer noch nicht ausprobiert ...
Schlimmer noch: Du kennst Premiere Pro nicht und glaubst nicht mal der Adobe-Doku. ;) Was heisst, ich habe es nicht ausprobiert?! Ich habe es gemacht. In Premiere. Pro. Verstehst du das?



Antwort von WoWu:

@ Reiner Das Ganze Videobarbeitungsgesumse ist eine Welt voller Kompromisse. Da bin ich nicht so ganz Deiner Meinung.
Letztlich funktioniert alles nach denselben Gesetzmäßigkeiten in der Physik, -und das schliesst die Optik ein- auch wenn einige -ich mein jetzt nicht Dich- das am liebsten nicht wahr haben würden.

Aber weil Physik eben eine harte Wissenschaft ist, ist sie auch nachvollziehbar und funktioniert immer.
Nur muss man auch die Schwächen seines Workflows manchmal im Interesse eines guten Endproduktes kennen und in der Lage sein, von "eingetretenen Pfaden" -nur weil sie's alle so machen oder weil ein NLE es nicht anders kann, abzurücken, wenn es bessere Möglichkeiten gibt.




Aber zu guterletzt ist ja nun doch noch ein Ergebnis dabei herausbekommen.
Und ich hoffe, dass wir dem TS hier einen guten Tipp gegeben haben.

Bin jetzt wieder raus .. gute Nacht.



Antwort von TheBubble:

Ich finde, wie man an den vielen Missverständnissen in dem Thread hier gut erkennen kann, wäre es besser, wenn Programme mit (linearen) RGB Werten arbeiten, auch wenn die nötigen Umrechnungen Performance kosten. So könnte man besser nachvolziehen, was tatsächlich intern passiert.



Antwort von WoWu:

Aber bei den paar Umrechnungen ist das ja noch beherrschbar. :-)



Antwort von dienstag_01:

Ich denke, eigentlich geht es hier gar nicht um YCbCr und den Umrechnungen nach RGB. Reiner braucht nur irgendwas Kompliziertes, damit er seine ganzen Aussagen, die er hier schon aufgeben musste (Y 16-235 ist standardmäßig RGB 0-255, Werte unter 16 und über 235 sind an 16 bzw 32bit Berechnung gebunden etc.) hinter scheinbar noch Gewichtigerem und Unverständlichem verstecken kann. Arm.



Antwort von DWUA:

Ich denke, eigentlich geht es hier gar nicht um YCbCr und den Umrechnungen nach RGB. Reiner braucht nur irgendwas Kompliziertes, damit er seine ganzen Aussagen, die er hier schon aufgeben musste (Y 16-235 ist standardmäßig RGB 0-255, Werte unter 16 und über 235 sind an 16 bzw 32bit Berechnung gebunden etc.) hinter scheinbar noch Gewichtigerem und Unverständlichem verstecken kann. Arm. Auch noch hinterfotzig? Zu zweit? Na prima!



Antwort von dienstag_01:

Naja, sollte eigentlich nicht so sein. Manchmal regen mich nur die ganzen Ausflüchte und Wichtigtuereien auf.
Asche auf mein Haupt.



Antwort von Jörg:

Du benötigst keine Asche aufm Kopp, Du solltest bloss Dein ständiges , völlig von Kenntnissen befreites lamentieren über Zusammenhänge, deren Sinn Du offenbar nicht verstehst ( ansonsten würde ich Dir schon Boshaftigkeit unterstellen wollen) sein lassen.
Über Jahre hinweg betrachtet nervt das ungemein.



Antwort von dienstag_01:

Vielleicht schafft man es ja in diesem Forum, Grundlagen und Standards als Basis zu nehmen und zu schauen, wie Programme diese umsetzen. Momentan ist es eher umgekehrt, man schließt aus der Kenntnis eines Programms auf die Standards.
Es gibt leider immer viel Verwirrung um Sachen wie bspw. Luma-Level und dem richtigen Umgang damit. Das liegt einerseits an der unterschiedlichen Umsetzung in den einzelnen Programmen und anderseits auch noch an Fehlern von Programmen, die nicht als solche erkannt werden.
Man kann eine Frage hier mit dem Hinweis auf den entsprechend zu drückenden Knopf beantworten. Reicht vielen. Manche interessieren aber auch ein paar Hintergründe. Wenn man die beschreibt, sollten man sich an die Fakten halten. Sonst kann man das auch gänzlich lassen.



Antwort von domain:

Manche Fremde entfremden sich hier von scheinbar Fremden.
Schön langsam wird mir das Forum hier fremd, weil zu spezielle Themen mit entfremdendem Nachdruck verfolgt werden, gerade zu so, als wenn man die Benzindirekteinspritzung mit dem Rußen bei bestimmten Lastzuständen und das Doppelkupplungsgetriebe von Autoherstellern mit all seinen Sensoren und Kennlinien bis ins letzte begreifen müsste. Fehler für die Nutzer tauchen aber trotzdem auf, ohne dass sie div. Funktionen auch nur annähernd begreifen und erklären könnten.
Die Frage ist nur was fremd bedeutet?

Max: Fremd ist der Fremde nur in der Fremde.
Lehrer: Das ist nicht unrichtig - und warum fühlt sich ein Fremder nur in der Fremde fremd?
Christina: Weil jeder Fremde, der sich fremd fühlt, ein Fremder ist, und zwar so lange, wie er sich nicht mehr fremd fühlt, dann ist er kein Fremder mehr.
Lehrer: Sehr richtig! Wenn aber ein Fremder schon lange in der Fremde ist, bleibt er dann ein Fremder?
Sarah: Das ist nur so lange ein Fremder, bis er alles kennt und gesehen hat, denn dann ist ihm nichts mehr fremd.
Lehrer: Es kann aber auch einem Einheimischen etwas fremd sein!
Fehrni: Gewiss, manchem Münchner zum Beispiel ist das Hofbräuhaus nicht fremd, während ihm in der gleichen Stadt das deutsche Museum, die Glyptothek, die Pinakothek und so weiter fremd sind.
Lehrer: Damit wollen Sie also sagen, dass der Einheimische in mancher Hinsicht in seiner eigenen Vaterstadt zugleich noch ein Fremder sein kann. Was sind aber Fremde unter Fremden?
Judith: Fremde unter Fremden sind: Wenn Fremde über eine Brücke fahren, und unter der Eisenbahnbrücke fährt ein Eisenbahnzug mit Fremden durch, so sind diese durchfahrenden Fremden Fremde unter Fremden, was Sie, Herr Lehrer, so schnell gar nicht begreifen werden. Lehrer: Oho! - Und was sind Einheimische?
Mariam: Dem Einheimischen sind eigentlich die fremdesten Fremden nicht fremd. Der Einheimische kennt zwar den Fremden nicht, er erkennt aber am ersten Blick, dass es sich um einen Fremden handelt.
Lehrer: Wenn aber ein Fremder von einem Fremden eine Auskunft will?
Sarah: Sehr einfach: Fragt ein Fremder in einer fremden Stadt einen Fremden um irgendetwas, was ihm fremd ist, so sagt der Fremde zum Fremden, das ist mir leider fremd, ich bin nämlich selbst fremd.
Lehrer: Das Gegenteil von "fremd" wäre also "unfremd"?
Sanna: Wenn ein Fremder einen Bekannten hat, so kann ihm dieser Bekannte zuerst fremd gewesen sein, aber durch das gegenseitige Bekanntwerden sind sich die beiden nicht mehr fremd. Wenn aber die zwei zusammen in eine fremde Stadt reisen, so sind diese zwei Bekannten jetzt in der fremden Stadt wieder Fremde geworden. Die beiden sind also – das ist paradox - fremde Bekannte geworden.



Antwort von WoWu:

Dann solltest Du vielleicht in ein literarisches Forum wechseln. Das würde auch all denen entgegen kommen, die hier einwenig Zugang zur Videotechnik erwarten und nicht tiefenpsychologische Betreuung und Ergüsse.



Antwort von domain:

Naja Karl Valentin zählt nicht gerade zur Weltliteratur. Aber ein genialer Linksdenker war er schon. Aber du bist ja im Grunde auch ein Künstler ...
Hast du bei diesem Text nicht schmunzeln müssen?
Wenn nein, dann bist du oberhalb der Weißwurstgrenze aufgewachsen ;-)



Antwort von Reiner M:

Ich denke, eigentlich geht es hier gar nicht um YCbCr und den Umrechnungen nach RGB. Reiner braucht nur irgendwas Kompliziertes, damit er seine ganzen Aussagen, die er hier schon aufgeben musste (Y 16-235 ist standardmäßig RGB 0-255, Werte unter 16 und über 235 sind an 16 bzw 32bit Berechnung gebunden etc.) hinter scheinbar noch Gewichtigerem und Unverständlichem verstecken kann. Arm. Bitte? "aufgeben musste" ? - Da ist wohl der Wunsch der Vater des Gedankens. Was hätte mich denn dazu veranlassen sollen?
Dieser Gedanke sollte sich besser nicht in Deinem Kopf festsetzen. ;)

Wenn Du in deinem Schreibsel mit "standardmäßig" in Premiere Pro und After Effects meinst, und dann die 16-Bit-Geschichte rauswirfst, stimmts. Werde ich doch nicht aufgeben.

Was ist eigentlich an den Aussagen in meinen Beiträgen weiter oben nicht zu verstehen? Hmmm?

----------

Da Du die Sache mit den Headroom-Daten im 8bit-Modus in Pr/Ae nicht ausprobierst, ein Screenshot anbei.
Und nun?
Wo sind die Headroom-Daten hin? Und: Werden sie in einem daraus exportierten File enthalten sein? Ja oder nein?

Diese Geschite ist wichtig und besitzt hohe Praxisrelevanz. Die Unterschiede zwischen Integer-Verarbeitung (8, 10, 16bit) und Float-Verarbeitung (32bit) können das Ergebnis im exportierten Video deutlich beeinflussen, wie man sieht. Adobe weist nicht umsonst mehrfach in der Dokumentation darauf hin.

Soviel an dieser Stelle zu "Hintergründe" und "Fakten".

----------

Und zu "Reiner braucht nur irgendwas Kompliziertes...":
Komplex sind die Formeln RGB-YC-Umrechnung durchaus. Mal reingesehen? Zu kompliziert?
Natürlich ist das deutlich komplexer als Deine völliig falsche Annahme, das ginge einfach so irgendwie 1:1. Erklärt hast Du ja nie, wie das klappen soll. Das wird wohl ewig Dein Geheimnis bleiben. Völlig fern von Fakten.

Kompliziert ist es deswegen allerdings nicht. Das beherrschen NLEs und Software-Player locker. Auch die Entwickler, die all das bauen. Sie tun es einfach. SIE wissen eben, wie es geht.
Zum Glück!

Beste Grüße,
Reiner



Antwort von domain:

Oberster Gralshüter WoWu, wo ist deine Stimme?
Du bist anerkannter Richter, also dann urteile auch, ob Dienstag oder Reiner mehr Recht haben. ...
Das einfache Fußvolk braucht jetzt dringend eine Orientierung :-)



Antwort von Reiner M:

@ Reiner Das Ganze Videobarbeitungsgesumse ist eine Welt voller Kompromisse. Da bin ich nicht so ganz Deiner Meinung.
Letztlich funktioniert alles nach denselben Gesetzmäßigkeiten in der Physik, -und das schliesst die Optik ein- auch wenn einige -ich mein jetzt nicht Dich- das am liebsten nicht wahr haben würden.

Aber weil Physik eben eine harte Wissenschaft ist, ist sie auch nachvollziehbar und funktioniert immer.
@WoWu

Du hast ja Recht: Physik ist Physik. Aber es ging ja um Kompromisse in der digitalen Verabeitung.

Die Praxis beschränkt uns in der reinen Lehre andauernd und zwingt uns Kompromisse auf. Bei der Optik meint das: Es gibt kein ideal geformtes Glas, das ohne Beugungen, Randunschärfen usw. hergestellt wurde. Zumindest nicht im bezahlbaren Bereich für Video/Foto. Und zum guten Schluss ist die Kaufentscheidung oft ein Kompromiss, der sich am Budget orientiert. Die Astronomen freuen sich, wenn sie ein neues Teleskop finanziert bekommen, mit einem superteueren Spiegel, der über Monate hinweg geschliffen wird, um die produktionsbedingten Abweichungen weitgehend loszuwerden, die ihnen sonst Kompromisse aufzwingen würden.

In der digitalen Bildbearbeitung ist der Versuch, die hübsche, bunte, analoge Welt in 24b Bit zu pressen, vollgestopft mit zahllosen Kompromissen. Trotz Physik. Oder nicht? Daraus resultieren die unterschiedlichen Farbmodelle und Farbräume, die versuchen, sich an den Wiedergabe- oder Produktionsmedien auszurichten, wie RGB oder CMYK, oder die versuchen, sich davon zu befreien, wie L*a*b. Immer unter dem Anspruch einer »natürlichen« Farbwiedergabe, die unserem Sehempfinden entspricht.

In RGB versucht man mit verschiedenen RGB-Farbräumen, die sich ja in der Verteilung der Werte unterscheiden, jedoch nicht im Wertebereich, dichter an das heranzukommen, was »ideal« ist, bezogen auf die Beschränkungen, die es nun mal gibt. Damit das nicht alles komplett auseinander läuft, einigt man sich zum Schluss auf Standards, wie z. B. sRGB für Ausgaben auf Computer-Devices, die aber auch nur einen Kompromiss darstellen. Es gibt Vor- und Nachteile.

32-Bit-Float RGB ist inzwischen weit verbreitet, weil das eben eine Möglichkeit bietet, innerhalb desselben Farbraums »produktionsbedingte Abweichungen«, die bei 8bit vorliegen, zu überwinden. Der Spiegel wird geschliffen.

Ich traus mich hier kaum zu sagen: Aus diesem Grund arbeitet Adobe mit den YUV-Effekten intern auch im YCbCr-Speicher mit 32-Bit-Float. Klar: Im exportierten Video hat man dann wieder nur 8 oder 10 bit. Aber der Workflow während der Verarbeitung konnte in jeden Rechenschritt mit einer höheren Genauigkeit rechnen, Interpolations- und Rundungsfehler minimieren, Wertüberläufe auffangen, wodurch sie folgenden Rechenschritten zur Verfügung stehen, usw. . Dieser Workflow wird gute Ergebnisse liefern. Das macht sich insbesondere dann bemerkbar, wenn komplexe, mehrstufige Berechnungen auf einem Videoframe ausgeführt werden müssen.

Zwar gelten auch hier physikalische Gesetzmäßigkeiten entlang der Signalverarbeitung, unbestritten, aber es gelten zusätzlich die Gesetzmäßigkeiten der Informatik, die beschreiben, wie digitale Informationen zu erzeugen, zu speichern und zu verarbeiten sind. Das geht nach festen Regeln, die nicht diskutierbar sind. Und das wird allzu gern ausgeblendet. Leider.

Beste Grüße,
Reiner



Antwort von domain:

Aber weil Physik eben eine harte Wissenschaft ist, ist sie auch nachvollziehbar und funktioniert immer. So ein Unsinn. Physik ist die weichste aller Wissenschaften, im Gegensatz zum Katholizismus.
Denke mal an die schlaflosen Nächte von Einstein, als die ersten Quantentheorien auftauchten und heute geht gar nix mehr ohne, nicht mal der einfachste Laser.
Und so ging das bis heute weiter, speziell was die Entstehung des Universums betrifft, alles nur Glaube und Theorie, aber immer besser fundiert ...



Antwort von WoWu:

Hallo Reiner.
So ganz kann ich die Brücke zu den Kompromissen nicht schlagen weil jedes Verfahren schon seine "Regeln" hat und innerhalb derer die verfahren auch gut, nachvollziehbar und wiederholbar funktionieren.
Und Mängel aus Verfahrensüberschreitungen betrachte ich nicht als Kompromiss sondern als vermeidbaren Fehler des Anwenders.
Blöderweise fördern die Marketingabteilungen solche Anwenderfehler immer noch, weil sie dies teilweise Unkenntnis der Anwender in der "Bits&Bytes-Region" ausnutzen, um sich einen vermeintlichen Marktvorteil zu sichern.
Daher teile ich Dienstags Ansicht, dass einwenig Grundkenntnisse in der Materie noch keinem Anwender geschadet hat.
Die einfachen Zeiten sind mit dem Analogfilm zu Grabe getragen und wer das noch nicht bemerkt hat, sollte sich ein einfacheres Hobby suchen.



Antwort von Stephan82:

Schon der Umstand dass Du korrigieren musstest zeigt, das was falsch war. Naja, ich habe wie fast überall empfohlen (z.B. Philipp Bloom, Fenchel & Janisch etc.) mit einem "flachen Picture-Profil" gefilmt. Hier war es das Canon Neutral-Profil mit völlig heruntergeschraubtem Kontrast, null Schärfe und leichter Entsättigung. Es ist doch so "zwangsläufig" notwendig, dass man in der Post Kontrast und Schärfe verändert!



Antwort von Reiner M:

@domain,

a) die Aussage, die Du zitierst, ist von WoWu, nicht von mir. ;)

b) Wissenschaft ist immer nur ein Spiegel der Zeit. Natürlich wird sie sich weiterentwickeln. Es ist ein immer währender Prozess. Wir werden schon nicht so einfältig sein, dass wir glauben, wir hätten die Weisheit mit Löffeln gefressen, und dass unsere Modelle für alle Zeiten gültig sind. Das würde bedeuten, wir sprechen den kommenden Generationen genau die Fähigkeiten ab, die wir für uns selbst so gern in Beschlag nehmen und die uns bis hier hin geführt haben. Die, die nach uns kommen, sind dann selber groß und werden selber denken - und womöglich anders, als wir heute.

Beste Grüße,
Reiner



Antwort von Reiner M:

Hallo Reiner.
So ganz kann ich die Brücke zu den Kompromissen nicht schlagen weil jedes Verfahren schon seine "Regeln" hat und innerhalb derer die verfahren auch gut, nachvollziehbar und wiederholbar funktionieren. Hallo Wolgang,

Klar hat es "Regeln".

Nehmen wir kurz die Grauskala. Du hast 220 hart von einander getrennte Werte, um sie vollständig abzubilden. Für mich ist das - bezogen auf die Realität! - ein heftiger "Kompromiss". Nicht? - Das ist sicher kein "Anwenderfehler".

Wenn jetzt bei Berechnungen Zwischenwerte auftreten, werden sie wegen des Integer-Formats der Speicherwerte gerundet - also verfälscht. Ein weiterer Kompromiss. Auch da kann der Anwender gar nichts für. Liegt an der Art, wie diese Daten verarbeitet werden können. Nach Regeln der Informatik.

Die Hersteller versuchen nun, Wege zu finden, die den Regeln der Videobearbeitung folgen, aber derartige Kompromisse minimieren unter Nutzung der Möglichkeiten, die die Informatik bietet.

Beste Grüße,
Reiner



Antwort von WoWu:

@Reiner

Tja, das weiss ich nicht.

Ich würde das nicht Kompromiss nennen, es gibt ja bessere Verfahren.
Wenn Du ein Fahrrad kaufst, hast Du ja (normalerweise) auch nicht im Hinterkopf ,damit - statt eines Autos- mit der Familie damit in urlaub zu fahren.

Ich denke, wer sich für 8 Bit entscheidet, sollte 10 oder 12 Bit nicht hinterher heulen und auch nicht versuchen, es mit Verdeckung nachzuahmen.
Insofern ist es für mich kein Kompromiss, sondern ein in sich schlüssiges System. -Eben wie ein Fahrrad-

@@ Stephan

Solche Empfehlungen auszusprechen heisst nicht gleichzeitig zu wissen, was die Konsequenzen sind.
Die wenigsten Anwender haben das Videothema wirklich durchdrungen.
Aber es gibt auch in 8 Bit genügend Beispiele, wo feine Verläufe unbeschädigt über den Bildschirm gehen. Nur sind 8Bit eben an der Grenze dessen, was vom Mensch noch (so eben) als "nicht stufig" wahrgenommen wird.
Und einige Sachen funktionieren eben schon nicht.
Darauf sollten die Empfehlungen, wenn sie substantiell sind, auch hinweisen, bevor man unbesehen solche Profile anpreist.
Denn der Umgang mit den "flachen" Übertragungskurven, sollte schon beherrscht werden, bevor man da einsteigt.
Aber das ist oft leider oft nicht das Ziel solcher Werbeveranstaltungen.

Die Tage von 8 Bit sind ja ohnehin auch bald gezählt und ein paar Probleme damit dann auch schon fast Vergangenheit.



Antwort von domain:

Mir scheint, wir befinden und noch in der Steinzeit der Videotechnologie. So wie damals, als man als Schüler noch verstehen und lernen musste (Allgemeinbildung), wie der Rund-Funk (so mit funkendem Lichtbogensender) im Innersten funktioniert.
Ja hallo wo sind wir denn heute?
Interessiert uns z.B. wie die Datenübertragung beim Smartfon funktioniert?
Beim Auto wird der Diagnosestecker und der Werkstätten-PC aktiviert.
Die Zeiten sind vorbei, als man die Unterbrecherkontakte noch mit Feinschleifpapier abhobelte und mit Zigarrettenpapier die Vorzündung einstellte.
Auf diesem Stand aber wollen uns einige „Spezialisten“ einreden, dass man nach Faust erkennen müsste, was die Video-Welt im Innersten zusammenhält, einfach grotesk ...



Antwort von WoWu:

Ja, das merkt mann, dass die meisten nur noch den Startknopf drücken wollen, ihr Film aber hinterher wie der neuste Blockbuster aussehen soll.

Das hat schon beim 8mm Schmalfilm nicht geklappt.
Die sehen heute noch aus wie Omas Geburtstag.

Damals brauchte man genauso Ahnung und gutes Equipment, wie heute.
Da hat sich nichts geändert.
Muss ja auch nicht. Wer mit 8 Bit eine Nachtdämmerung aufnimmt und davon ausgeht, dass es wie in 12 Bit aussieht, hat sich eben das Fahrrad zur Urlaubsreise gekauft.
Dann muss er damit leben.
Dumm gelaufen, kann man da nur sagen.
Er hätte sich ja mal informieren können, ob das so reibungslos geht. Ja hallo wo sind wir denn heute? Also ich bin in der Gegenwart angekommen.
Wo Du noch bist, kann Du vermutlich nur selbst sagen.
Insofern trifft das "wir" nicht zu. Du musst fragen, wo "Du" bist.



Antwort von EnricoPerei:

Was ist eigentlich das Problem?
(mal vom pissing contest abgesehen (; ...)

-OP hat Banding im Clip.
(ob man dies nun durch optimierte Kameraeinstellungen vermeiden kann, ist zunächst egal, wenn auch zu empfehlen)

-Lösung:
Grain,Dither, Blur und Farbkorrekturen

-professionelle Arbeitsweise:
Das 8Bit Material in 32bit float wechseln
(dies ist keine Farbraumkonvertierung, nur eine Bittiefenveränderung!).
Hierdurch werden die vorher extrem groben 8 bit Abstufungen wesentlich feiner.

-Dann die Lösung anwenden.

-Ausgabe im Zielformat und Farbraum, nach Angabe des Empfängers (z.B. Youtube)

-Fertig.


So, nun zum Farbraum, der getrennt von Bittiefe zu verstehen ist.

YCbCr->RGB (oder umgekehrt):
Es wird hier von einem Verfahren gesprochen das in 8Bit integer die YCbCr Werte (16-235 pro Kanal) auf RGB (0-255 pro Kanal) wandelt.
Hierbei werden ganz offensichtlich, wie Reiner sagte, die Werte 0-15 und 236-255 abgeschnitten und gehen bei einer Rückwandlung verloren.
Dies schneidet alle illegalen Farben raus und zerstört Zusatzinformation, die in den Werten sind.
DUMMES VERFAHREN! Finger weg.
Zudem werden 220 Einzelwerte auf 256 umgerechnet.
Das ist Interpolation, auch / gerade wenn es die Formel nutzt, es füllt Bereiche auf, die nicht gespeichert sind.

Zurück zur Bittiefe:
Die illegalen Werte werden übrigens auch bei 16/32bit integer abgeschnitten.
Bei signed integer rettet man immerhin die (8bit) 0-15 Werte, da die ins negative rutschen.
Die (8bit) Bereiche 236-255 sind dennoch futsch da ja bereits 235 auf 65536 landet (das 16Bit Maximum) oder 235 auf 4294967296 landet(das 32bit Maximum).
Erst wenn man signed float (egal ob 16 oder 32 bit) benutzt, können alle "Überlaufswerte" erhalten bleiben.

Unverständnis:
Wenns' denn schon sein muß, warum wandelt man nicht einfach YCbCr 0-255 auf RGB 0-255.
Dann bleibt alle Information erhalten und man verwirrt sich nicht selbst und zerstört nicht sein Signal dabei.
Nun erhöhe die Bittiefe auf 32bit float und wende Lösung an.
FERTIG.

edit:
ach ja, wenn man dann ein legales Signal ausgeben möchte, dann clamped man einfach die illegalen Werte bei der Ausgabe.

Ein Szenario, bei dem ich mir das 16-235 auf 0-255 Verfahren Sinnvoll vorstellen kann ist, wenn die Kamera das Signal 100% Weiß auf 235 legt und 100% Schwarz auf 16
Wenn nun aber über- bzw. unterbelichtete Bereiche in den Rest gefüllt werden, ist wieder ein 0-255 auf 0-255 zu empfehlen.



Antwort von Stephan82:

Ihr seid echt BRUTAL!!! Ganz ehrlich, ihr braucht ein eigenes Forum!

Ich habe mir echt alles durchgelesen, einiges verstanden, dann aber wieder nicht! Am Ende ist man total verwirrt, weil ständig widersprochen oder von anderen Ausgangsituationen, Umständen geredet wird usw. Ihr seid echt zu KRASS!!!

Ich kleiner Wicht traue mich dennoch mal dazwischenzugrätschen! Das Material aus meiner 700D ist ja laut Aussagen einiger User hier REC709 (16/235). Ich habe den Clip nun einfach mal nur in AE importiert, nichts verändert und in H264 exportiert. Ergebnis: der aus AE exportierte Clip ist kontrastloser als das Original. Auch in der Vorschau in AE sieht man bereits, dass es blasser aussieht.

1. Ich meine hier gelesen zu haben, dass mein gewählter Export-Codec H264 auch wieder "nur" Rec709 mit 16-235 bietet. Warum ist der Clip aber dann heller und kontrastärmer als der Original-Clip? Liegt das daran, dass er von Rec709 (16-235) zu RGB (0-255) und beim Export wieder zu Rec709 (16-235) umgewandelt wird? Oder habe ich das jetzt total falsch verstanden?

2. Kann man die Vorschau oder den Farbraum in AE ändern, sodass der importierte Clip genauso kontrastreich aussieht wie wenn das Original mit einem Software-Player abgespielt wird? Oder ist dieser Helligkeits- bzw. Kontrastunterschied nach dem Import völlig normal?

3. Wird nun durch den bloßen Import schon an den Farben und Kontrasten gedreht bzw. das Material negativ "belastet" oder sozusagen nur "anders" dargestellt?

4. Wenn ich nun Rec709-Material habe, wie sollte ich dann meine AE-Komposition einstellen? Wie sollte der Workflow aussehen, damit das Material so wenig wie möglich hin- und hergewandelt wird?



Antwort von WoWu:

@Enrico Wenns' denn schon sein muß, warum wandelt man nicht einfach YCbCr 0-255 auf RGB 0-255. Dann braucht man aber eine Kamera, die R'dG'dB'd kann.
Das ist aber kein Videostandard und ich kenn auch keine Kamera, die das macht.
Nur wer unbedingt die FullRange haben will, soll doch vxYCC machen.
Ist doch alles da.

@Stephan
Weil AE gern in RGB arbeiten möchte damit es mit den üblichen Grafikmedien zusammenarbeiten kann und in der Umrechnung liegt der Hase begraben.



Antwort von prime:

-OP hat Banding im Clip.
(ob man dies nun durch optimierte Kameraeinstellungen vermeiden kann, ist zunächst egal, wenn auch zu empfehlen) Der OP hat komplett synthetisch generiertes Material :-)
Tach allerseits,

Ich habe ein AfterEffects Projekt (reine Grafik, kein Video) in 16 Bit erstellt und das Master in 10Bit (ProResHQ) exportiert. Irgendwann hat mal jemand dann noch was zu Kameras gefragt und das war dann Ansporn genug ;-)
Ich hänge mich mal an das Thema dran, weil ich mit Banding oder Blocking selbst immer wieder Probleme habe. Was genau was ist kann ich als Anfänger auch nicht unterscheiden.

Hier mal 2 Screenshots aus After Effects. Footage stammt von einer 700D@1080p@H264. @Stephan82 immer mit der Ruhe ;-)
1) Du musst mal schauen wie AE das Material interpretiert (decoding) und verarbeitet (Ausgabe). --> AE-Handbuch/Hilfe
2) Und du musst schauen wie interpretiert der Decoder mit dem du das Material abspielst (also der Codec/media-player den du verwendest). --> Media-Player verwenden wo das genau eingestellt werden kann (MPC z.B.)

Versuch das alles ausfindig zu machen - sonst drehst du an mehreren Stellen ohne Ziel..



Antwort von EnricoPerei:

@Stephan82

keine Angst wir wollen doch nur spielen und beißen nicht (;

zu deiner Frage, ehm. bin mal ein ganz Böser :

benutze Fusion oder Nuke höhö.

(ist eh unpraktisch, da Du ja AE schon hast und kennst aber das mußte mal raus)

Ist da evtl. ein gamma shift in Deiner Umwandlung?



Antwort von Reiner M:

Zudem werden 220 Einzelwerte auf 256 umgerechnet.
Das ist Interpolation, auch / gerade wenn es die Formel nutzt, es füllt Bereiche auf, die nicht gespeichert sind. Enrico, das ist falsch. Da wird nichts interpoliert. Hast Du die Formel verstanden?

Denke vielleicht auch noch mal darüber nach:
Wie viele Bytes hast Du in YCbCr in den Chrominanzkanälen, die "Blau" bedeuten (Sättigung)? Und wie viele Bytes stehen Dir ingesamt zur Verfügung, um einen "Blau"-Ton zu erzeugen (Sättigung * Helligkeit)?
Vergiss bitte die Idee, dass die Wertebereiche "16-235" in YCbCr und RGB identische Inhalte hätten, oder wenigstens solche, die quasi 1:1 zugeordnet werden könnten.
Zurück zur Bittiefe:

Bei signed integer rettet man immerhin die (8bit) 0-15 Werte, da die ins negative rutschen.

Erst wenn man signed float (egal ob 16 oder 32 bit) benutzt, können alle "Überlaufswerte" erhalten bleiben. Das stimmt, aber Signed Integer kommt in Premiere Pro und After Effects nicht vor. 16bit-Float gibt es dort auch nicht.
Also 32bit, und alles ist gut.
Unverständnis:
Wenns' denn schon sein muß, warum wandelt man nicht einfach YCbCr 0-255 auf RGB 0-255. Das wird ja auch gemacht. Z. B. bei JPEG. Da liegt das Bild dann aber auch in Y0-255.

Aber eben nicht bei Videos die in YCbCr nach REC.709 gespeichert sind.
Da liegt das Bild im dafür definierten Bereich Y16-235. Alles außerhalb, gehört nicht zum Bild, das ein Wiedergabegerät ausgeben soll, wenn es auch nach REC.709 arbeitet.

Beste Grüße,
Reiner



Antwort von Stephan82:

@Stephan82
Ist da evtl. ein gamma shift in Deiner Umwandlung? Was ist das und wie kann ich das nachschauen?



Antwort von Reiner M:

Naja, ich habe wie fast überall empfohlen (z.B. Philipp Bloom, Fenchel & Janisch etc.) mit einem "flachen Picture-Profil" gefilmt. Es gibt in AE unter Effekte-> Farbkorrektur -> Belichtung.
Hast Du den schon mal probiert?

Beste Grüße,
Reiner



Antwort von dienstag_01:

@Stephan82
Wenn du Probleme mit dem Kontrast hast, die auf Fehlinterpretation von 16-235 hindeuten, schau dir den Clip in verschiedenen Playern an. Überall gleich?
Darüber hinaus gibt es ein Tool, 5DtoRGB, kann man sich runterladen, da kann man die bewusst von Canon falsch implementierte Farbraummatrix fixen. Kann man mal ausprobieren (ich selbst hab es nur einmal flüchtig getan und keine wirklich signifikanten Unterschiede festgestellt).

Und, Quicktime auf einem halbwegs aktuellen Stand?



Für alle anderen, die Interesse an der Diskussion, wie Adobe arbeitet haben, hier gehts weiter ;)

Was habe ich gemacht:
Ein 8bit File importiert (h264). Man sieht deutlich die Werte (WFM) im Head- und Footroom, in der Videovorschau nicht.

Dieses 8bit File mit dem FastColorEffect bearbeitet. der Effect arbeitet in 8, 16 und 32 bit.

Adobe beschreibt in seinen Blogs, wie man Premiere Effekte in 8bit rechnen lässt, am Beispiel eines DV Files: Steve Hoeg, one of the Premiere Pro engineers, provided some examples of how Premiere Pro will handle color precision in different scenarios:
1. A DV file with a blur and a color corrector exported to DV without the max bit depth flag. We will import the 8-bit DV file, apply the blur to get an 8-bit frame, apply the color corrector to the 8-bit frame to get another 8-bit frame, then write DV at 8-bit. Ich habe also Das Flag für Maximale Bittiefe ausgeschaltet, Premiere rechnet in 8 bit.

Das Ergebnis ist, das File hat die Korrekturen, die es nach Meinung einiger gar nicht haben dürfte, berechnet.

In einem weiteren Test habe ich das File ohne Korrekturen exportiert (h264). Auch hier ist der Head- and Footroom beibehalten.

Was heisst das nun.
Sollte Premiere die Videouelle beim Import von 16-235 nach 0-255 mappen, gäbe es in 8 bit diese Werte gar nicht.
Das wiederum kann nur heissen, dass Premiere die Werte so lässt wie sie sind und nur die Vorschau nach 0-255 mapped. Es werden also keine Werte verändert (es wird eine Art LUT für die Vorschau angewendet), was ein signifikanter Unterschied ist. Aber eben für die Berechnung auch besser.

Desweiteren liegt jeder falsch, der annimmt, für die Verwendung (*Nutzbarmachung*) der Headroom-Daten wären 32 oder 16bit zwingend notwendig. Man solte es in Premiere natürlich trotzdem tun, aber es funktioniert auch in 8bit ;)

Alles klar?!



Antwort von TheBubble:

Interessiert uns z.B. wie die Datenübertragung beim Smartfon funktioniert? Natürlich. Dich etwa nicht?
Auf diesem Stand aber wollen uns einige „Spezialisten“ einreden, dass man nach Faust erkennen müsste, was die Video-Welt im Innersten zusammenhält, einfach grotesk ... Muss man nicht. Man kann die Programme natürlich einfach so benutzen, wie sie sind. Aber dann versteht man auch nie, warum die Programme etwas tun und wie sie es tun und warum man als Benutzer für ein optimales Ergebnis bestimmte Dinge lassen sollte.

Mit etwas Grundlagenwissen kann man auch leichter entscheiden, welches Programm man sich kaufen sollte und was man erwarten kann.



Antwort von WoWu:

Es stellt sich sowieso die Frage, ob ein Forum dazu da ist, dass einige Leute lediglich sagen: "lies erstmal das Manual" oder "probiere doch aus" oder irgendwelche Marketingsprüche dummschwätzig wiederholen, ohne selbst zu wissen was sie eigentlich genau bedeuten oder ob nicht so eine Diskussion,-auch wenn sie manchmal etwas in die Tiefe geht-, unter dem Strich nicht doch die bessere Variante auch für "Einsteiger" ist und dem Zweck einer solchen Plattform sehr viel näher kommt.

Was ich aber gar nicht verstehe sind die Typen, die 10 Seiten lesen und dann so einen Schmarn von sich geben.
Wenn Sie's nicht verstehen, zwingt sie doch keiner weiter zu lesen.

Sollen sie doch ihre Zeit besser nutzen und ein Bier trinken, dann haben sie wenigstens anschliessend noch den Flaschenpfand.



Antwort von TheBubble:

-professionelle Arbeitsweise:
Das 8Bit Material in 32bit float wechseln
(dies ist keine Farbraumkonvertierung, nur eine Bittiefenveränderung!). Genaugenommen bedeutet dies sogar mehr als nur mit zusätzlichen Bits zu arbeiten, da sowohl negative als auch große Werte erhalten werden können. Floats verhalten sich allerdings anders als Integers, die darstellbaren Zahlenwerte sind nicht gleichmäßig verteilt.
Hierdurch werden die vorher extrem groben 8 bit Abstufungen wesentlich feiner. Das ist leider falsch.
Es wird hier von einem Verfahren gesprochen das in 8Bit integer die YCbCr Werte (16-235 pro Kanal) auf RGB (0-255 pro Kanal) wandelt.
Hierbei werden ganz offensichtlich, wie Reiner sagte, die Werte 0-15 und 236-255 abgeschnitten und gehen bei einer Rückwandlung verloren.
Dies schneidet alle illegalen Farben raus und zerstört Zusatzinformation, die in den Werten sind.
DUMMES VERFAHREN! Finger weg. Dies ist bei einer 8-Bit-Verarbeitung der einzig machbare Weg. Lediglich durch einen konsequent genutzten erweiterten Wertebereich lassen sich diese Informationen erhalten.

Nebenbei: Nicht nur durch das "Abschneiden" gehen Informationen verloren, 8-Bit-BT.709-YCbCr kann im Prinzip Farben beschreiben, die nicht im 8-Bit-BT.709-RGB-Würfel liegen.
Zudem werden 220 Einzelwerte auf 256 umgerechnet.
Das ist Interpolation, auch / gerade wenn es die Formel nutzt, es füllt Bereiche auf, die nicht gespeichert sind. Das hat nichts mit Interpolation zu tun. Es ist lediglich eine Spreizung des Wertebereichs durch Multiplikation mit einer konstanten Zahl.
Erst wenn man signed float (egal ob 16 oder 32 bit) benutzt, können alle "Überlaufswerte" erhalten bleiben. Im Grunde richtig, aber man kann sich natürlich auch ein Integer-Format definieren, dass nach oben hin genügend Spielraum lässt.
Wenns' denn schon sein muß, warum wandelt man nicht einfach YCbCr 0-255 auf RGB 0-255. Macht man ja - für die Ausgabe.

Es ist nur eben so, dass im Digital-Video-Bereich aus historischen Gründen ein kleinerer Wertebereich festgelegt ist. Wenn man mit derartigen Geräten kompatibel sein will, dann muss man dies halt so machen.

Für Neuentwicklungen, losgelöst von aller alter Technik, wäre ein Festhalten an diesen alten Vorgaben nicht unbedingt sinnvoll. Ich würde entweder Fließkommazahlen oder, wenn Integer-Werte (mit mehr als 8 Bit pro Sample), einen erweiterten Wertebereich mit Spielraum nach oben und unten hin für sinnvoll halten.

Allerdings: Die meiste Software beginnt nicht als völlig neue eigenständige Entwicklung.



Antwort von TheBubble:

oder ob nicht so eine Diskussion,-auch wenn sie manchmal etwas in die Tiefe geht-, unter dem Strich nicht doch die bessere Variante auch für "Einsteiger" ist und dem Zweck einer solchen Plattform sehr viel näher kommt. Die richtige Darstellung der Zusammenhänge ist eindeutig die bessere Wahl.



Antwort von dienstag_01:

Es wird hier von einem Verfahren gesprochen das in 8Bit integer die YCbCr Werte (16-235 pro Kanal) auf RGB (0-255 pro Kanal) wandelt.
Hierbei werden ganz offensichtlich, wie Reiner sagte, die Werte 0-15 und 236-255 abgeschnitten und gehen bei einer Rückwandlung verloren.
Dies schneidet alle illegalen Farben raus und zerstört Zusatzinformation, die in den Werten sind.
DUMMES VERFAHREN! Finger weg. Dies ist bei einer 8-Bit-Verarbeitung der einzig machbare Weg. Lediglich durch einen konsequent genutzten erweiterten Wertebereich lassen sich diese Informationen erhalten. Man kann in meinem weiter oben geposteten Beispiel sehen, dass keine Werte abgeschnitten werden. Die Grundannahme, dass YCbCr 16-235 auf RGB 0-255 gewandelt werden, ist für Premiere demnach nicht zutreffend. (was ja auch viel besser ist)



Antwort von wp:

der Flaschenpfand war gut. :-)

ich kapier zwar momentan auch nicht viel, warte noch auf entrauschtes footage, dann entscheide ich ob's sich überhaupt lohnt und wem man auch künftig zuhören sollte.

@ TO (offtopic)
darf man mal nachhaken, wie du entsättigt hast?
Über Kanalberechnungen oder nur so irgendwo ein sanftes, schnelles >>clicks'chen<< ...?

Oft ist bei solchen Geschichten (man lese: kann sein, muss nicht sein) aus der Praxis (man verstehe: also wenn das Kind schon in den Brunnen gefallen ist) ein dummer Klick zuviel dran.

mach mal n Standbild und zeig uns die drei Kanäle, und zwar als Bild, nicht als Diagramm. Ich hoffe, es zickt nur der Blaue (wie so oft).

/(offtopic)



Antwort von Reiner M:

Was habe ich gemacht:
Ein 8bit File importiert (h264). Man sieht deutlich die Werte (WFM) im Head- und Footroom, in der Videovorschau nicht.

Dieses 8bit File mit dem FastColorEffect bearbeitet. der Effect arbeitet in 8, 16 und 32 bit.

Adobe beschreibt in seinen Blogs, wie man Premiere Effekte in 8bit rechnen lässt, am Beispiel eines DV Files: Steve Hoeg, one of the Premiere Pro engineers, provided some examples of how Premiere Pro will handle color precision in different scenarios:
1. A DV file with a blur and a color corrector exported to DV without the max bit depth flag. We will import the 8-bit DV file, apply the blur to get an 8-bit frame, apply the color corrector to the 8-bit frame to get another 8-bit frame, then write DV at 8-bit. Ich habe also Das Flag für Maximale Bittiefe ausgeschaltet, Premiere rechnet in 8 bit.

Das Ergebnis ist, das File hat die Korrekturen, die es nach Meinung einiger gar nicht haben dürfte, berechnet.

In einem weiteren Test habe ich das File ohne Korrekturen exportiert (h264). Auch hier ist der Head- and Footroom beibehalten.

Was heisst das nun.
Sollte Premiere die Videouelle beim Import von 16-235 nach 0-255 mappen, gäbe es in 8 bit diese Werte gar nicht.
Das wiederum kann nur heissen, dass Premiere die Werte so lässt wie sie sind und nur die Vorschau nach 0-255 mapped. Es werden also keine Werte verändert (es wird eine Art LUT für die Vorschau angewendet), was ein signifikanter Unterschied ist. Aber eben für die Berechnung auch besser.

Desweiteren liegt jeder falsch, der annimmt, für die Verwendung (*Nutzbarmachung*) der Headroom-Daten wären 32 oder 16bit zwingend notwendig. Man solte es in Premiere natürlich trotzdem tun, aber es funktioniert auch in 8bit ;)

Alles klar?! Nee, eben nicht klar! - Das heißt: MIR schon ... ;)

Dienstag, ....
Sorry, das ist leider komplett und durchgehend falsch!

Es beweißt einmal mehr: Die Grundlage ist falsch und und Du ziehst folglich die falschen Schlüsse daraus. Es erstaunt, mich wirklich, auf welche abstrusen Schlusssfolgerungen man kommen kann. :-(

Aber schauen wir mal kurz drauf, warum ich dieser Meinung bin.
Dass ich hier in dieser Diskussion mit DIR allerdings soweit in die GRUNDLAGEN von Premiere Pro einsteigen muss, hätte ich wirklich nicht gedacht! :-(

Aber gut. Immerhin: Der folgende Text ist für alle Premiere Pro Anwender interessant, die noch nicht wissen, wann Effekte für 8bit- und wann für 32bit-Verarbeitung sorgen werden. Und das sollte man unbedingt wissen.

----------

Aus der Premiere Pro Doku:
Hinweis:

32-bpc-Effekte werden nur mit 32 Bit pro Kanal gerendert, wenn alle anderen Effekte in der Render-Pipeline ebenfalls 32-bpc-Effekte sind. Wenn Sie einen 8-bpc-Effekt in einer Sequenz platzieren, die einen 32-bpc-Effekt enthält, werden alle Effekte in der betreffenden Sequenz von Premiere Pro mit 8 Bit gerendert. Alles klar? (Wenn nicht: Die Adobe-Doku bietet weitere Erläuterungen dazu).

Jetzt muss man nur noch verstehen: Was ist was und wann passiert was?

Premiere Pro hat dafür in seiner Oberfläche leider keine direkte Anzeige, gibt aber in der Effekte-Liste SEHR WICHTIGE Hinweise dazu, die für den RICHTIGEN Workflow von großer Bedeutung sind. Sollte man sich unbedingt ansehen!

Schauen wir einfach in die Effekte-Liste. Als Hilfestellung liegt hier ein Screenshot bei, auf den ich mich nun beziehe.

Hinter jedem Effekt sind bis zu drei Symbole in drei Spalten zu sehen:
1. Symbol meint: Effekt ist GPU-(CUDA)-fähig. Wenn GPU-Rendern aktiv ist, rechnet dieser Effekt automatisch mit der Bittiefe 32bit. (genauer: mit der Bittiefe der Grafikkarte) Übrigens auch unabhängig von "Maximaler Bittiefe".
2. Symbol meint: Der Effekt rechnet in 32bit.
3. Symbol: Der Effekt arbeitet direkt in YCbCr-Speicher.

Wenn man einen Effekt einsetzen will, sollte man also hinsehen, was da markiert ist und wie es kombiniert ist. Das hat Folgen für den Workflow.

"Schnelle Farbkorrektur"
Der Effekt "Schnelle Farbkorrektur" arbeitet also a) direkt in YCbCR, und das in 32bit (!), und das in der Grafikkarte, sofern eingeschaltet.
Da kommt nun mal 32bit-Verarbeitung bei rum!
Und warum? Weil Adobe es so vorgibt und jeden Anwender mit den Symbolen darauf hinweist!

Dienstag, "FastColorEffect" ist "Schnelle Farbkorrektur", oder?
Dann ist Dein Beispiel oben ja gerade dafür der Beleg! Für eine 32bit-Verarbeitung. Und für nichts anders.
Du hast also den falschen Effekt für Deinen *Beweis* gewählt. Und dann daraus völlig falsche Schlüsse konstruiert. :-(
Korrigiere mich, wenns anders ist.

2. Beispiel
Schau in meinem Screenshot auf den Effekt "Färbung". Der ist nur mit dem Symbol "GPU-Verarbeitung" markiert, jedoch nicht mit 32bit.
Wie arbeitet dieser Effekt? In 8bit oder in 32bit? Erklärung dazu:
- Sobald GPU-Unterstützung in Pr aktiv ist, rechnet dieser Effekt in der Bittiefe der Grafikkarte, i. d. R. 32bit-Float, wenn Du eine Nvidia Quadro hast, so gar in 64bit-Float. Premiere Pro bleibt in 32bit, weil es die Daten aus der Graka dafür passend angeliefert bekommt und eben nicht in 8bit.
- Ist GPU-Unterstützung abgeschaltet, arbeitet dieser Effekt auf der CPU, und dort in 8bit. Erst jetzt fällt Premiere Pro in den 8bit-Modus. Weil es die Rechenergebnisse in 8bit angeliefert bekommt.

8bit-Effekte
Nur die Effekte, die keine Symbole besitzen, sind echte 8bit-Effekte!
Beim Einsatz dieser Effekte fällt Premiere Pro in den 8bit-Modus (siehe meine Zitat aus der Doku oben).
Und zwar deshalb, weil es die Rechenergebnisse in 8bit bekommt. Es gibt bei diesen Effekten keine Möglichkeit, auf einer Hardware-Komponente (CPU, GPU) Float-Ergebnisse zu erzeugen.

--------

Das muss genügen, Dienstag. Kann man alles wunderbar in der Adobe-Doku nachlesen.
Dein Zitat über DV 8bit passt übrigens überhaupt nicht zum Thema und behandelt NICHT die Unterschiede zwischen 8bit- und 32bit-Modus in Pr.

Anders als Dein Beispiel, stützt sich meins oben auf genau die richtige Vorgehensweise. Schau noch mal hin, jetzt weißt Du ja, worauf es ankommt.

Nimm also für eigene Experimente bitte ganz einfach einen solchen echten 8-bit-Effekt und machs nochmal, ja? Alles andere ist Unsinn.

Und dann beantworte mir meine Fragen:
Wo sind die Headroom-Daten hin? Und: Werden sie in einem daraus exportierten File enthalten sein? Ja oder nein?

Dann haben wir die RICHTIGEN Grundlagen geschaffen, und dann kannst Du noch mal über die RICHTIGEN Schlussfolgerungen daraus nachdenken ...

Aber ich schätze, Du wirst stattdessen das nächste Sonderkonstrukt anliefern ... bin sehr gespannt darauf. ;)

Beste Grüße,
Reiner



Antwort von dienstag_01:

Vorweg sollte man nochmal auf die Aussage des Adobe-Entwicklers verweisen, die beschreibt, dass man durch Ausschalten der Maximalen Bittiefe sehr wohl im 8bit Modus ist.
Nichtdestotrotz wird das hier angezweifelt. Na gut ;)

Ich habe jetzt mal einen reinen 8bit Effekt in die Bearbeitungs-Pipeline gesetzt und Cuda selbstverständlich ausgeschaltet. Jetzt ist alles *richtiges* 8bit.
Das Ergebnis ist, dass man die Werte aus Head- und Footroom sehr wohl *ins Bild* holen kann. Was ausschließt, dass beim Import die Werte auf 0-255 gemapped werden, sonst kämen die Werte in 8bit nicht vor.

Aber vielleicht gibt es ja nicht nur richtige 8bit-Bearbeitung, sondern *ganz, ganz richtige* 8bit-Bearbeitung ;)

Edit: Das Ausgangsfile für folgende Bearbeitung ist das erste Bild in meinem Post oben, die Lumawerte liegen im Head- und Footroom.



Antwort von Reiner M:

Vorweg sollte man nochmal auf die Aussage des Adobe-Entwicklers verweisen, die beschreibt, dass man durch Ausschalten der Maximalen Bittiefe sehr wohl im 8bit Modus ist.
Nichtdestotrotz wird das hier angezweifelt. Na gut ;) Dienstag, lass' es. Es führt zu nichts. Diese Themen sind erklärungsbedürftig (leider) und spielen hier keine Rolle.
Nur so viel: Es geht dabei um Fälle, in denen Assets, Videos oder Bilder, eine hohe Bittiefe mitbringen, und sicherzustellen ist, dass sie adäquat verarbeitet werden.
Lies bitte die Doku.
Ich habe jetzt mal einen reinen 8bit Effekt in die Bearbeitungs-Pipeline gesetzt und Cuda selbstverständlich ausgeschaltet. Jetzt ist alles *richtiges* 8bit.
Das Ergebnis ist, dass man die Werte aus Head- und Footroom sehr wohl *ins Bild* holen kann. Was ausschließt, dass beim Import die Werte auf 0-255 gemapped werden, sonst kämen die Werte in 8bit nicht vor.

Aber vielleicht gibt es ja nicht nur richtige 8bit-Bearbeitung, sondern *ganz, ganz richtige* 8bit-Bearbeitung ;)
Wie vorhergesehen: Ich habe nichts anderes erwartet!

Der nächste Sonderfall --- Hauptsache ausweichen, abschweifen und vom Hölzchen aufs Stöckchen kommen.
Und wieder die falschen Schlüsse ... Unglaublich!

Du hättest CUDA nicht abschalten müssen ... Schau einfach in die Effekte-Liste und auf die Symbole! Dein Effekt ColorBalance arbeitet eh nicht auf Cuda.

M. E. verstehst Du offensichtlich wieder NICHT, was Du eigentlich machst. Oder willst Du mich hier mutwillig veralbern?

Es geht um Effekte. Daran klebst. Du kannst in Premiere Pro nicht den Arbeitsbereich von 32bit auf 8bit umstellen! Deine Aussage dazu, dass sein nun echtes 8bit, ist einfach falsch! Oder kennnst Du irgendeinen Parameter der das erzwingt? Sag' jetzt bitte nicht "Maximale Bittiefe" ...
Es klebt an den 8bit-Effekten.

Nur zu Erklärung für Leute, die wirklich verstehen wollen, was in Deinem Beispiel abgeht, und das hat was mit der Abarbeitungsfolge von Effekten zu tun. Auch wichtig für den Workflow:

---------

Du hast in der Effektliste mit der 32bit-Farbkorrektur (Symbol in der Effektliste!) im Effektstapel VOR dem 8bit-Color-Balance den Tonwertumfang so verändert, dass die Head-/Footroom-Daten in den bildgebenden Bereich fallen.

Warum sollte das nicht gehen? Ist Dir klar, dass Effekte NACHEINANDER abgearbeitet werden? Liegt in der Natur der Sache. So ist die Computerei nun mal. Die Adobe-Doku erklärts ...

Also: Zunächst arbeitet Premiere Pro am Effekt Schnelle Farbkorrektur. Den folgenden Effekt kennt es zu diesem Zeitpunkt noch nicht (ja, so gehts nun mal in der Computerei). Es ist im 32bit-Modus.

Dann folgt der Effekt, der in 8bit gerechnet wird. Und nun ist Premiere Pro im 8bit-Modus. Verursacht allein durch diesen Effekt, durch sonst nichts.
Du konntest also die Daten aus Head- und Footroom wegen der Abarbeitungsfolge noch retten, danach gibts den nicht mehr.

In der Luma-Wave siehst Du immer das Ergebnis aller Berechnungen in Folge. Völlig richtig hier also 8bit. Aber nach der schrittweisen Verabeitung der Effekte.
Wenn Du sehen willst, wie sich Arbeitsschritte einzeln auswirken, schalte alle Effekte zunächst ab, und dann nacheinander von oben nach unten wieder an.

Preisfrage: Sind in der Luma-Wave Foot- und Headroom noch da? Ja oder nein? - Ich meine nicht die Daten, die du VORHER runtergezogen hast.

-------

Jetzt mal was zum Spielen an diesem Beispiel.

1. Drehe mal bitte nicht an den Parametern im Effekt Fast Color.. Wo sind Head- und Footroom? Exportiere das File. Sind sie drin?

2. (für Fortgeschrittene):
Lass Dein Beispiel so, also mit angepasstem Tonwertumfang, aber verändere mal die Reihenfolge im Effektstapel.
Also ziehe ColorBalance einfach VOR Fast Color Correction.
Und nun? Was passiert? Wo sind Deine Daten hin? Du hast sie doch runtergezogen ...

Tja ...

---------

Sorry, Dienstag, ich kann Dir hier beim besten Willen keinen Grundkurs in Premiere Pro liefern. Wirst Du verstehen, oder? Das langweilt sicher nicht nur mich.

Wenn Du ernsthaft diskutieren willst, lass endlich diese Sonderfälle weg! Kein einziger, den Du hier bisher präsentiert hast (und die Liste ist lang), war zweckdienlich. Sie haben alle nur bestätigt, wo es hakt. Und mit jedem weiteren Sonderfall-Beispiel wirst Du mit sehr großer Wahrscheinlichkeit mehr davon zeigen.
Schau sie alle noch mal in Ruhe an. Wie viele willst Du noch abliefern? Ich könnte Dir gerne auch Tausend Sonderfälle basteln. Doch wozu?
Ich frage mich: Was willst Du eigentlich?

Nimm also für eigene Experimente endlich ganz einfach einen solchen echten 8-bit-Effekt und machs nochmal, ja? Alles andere ist Unsinn.

Und dann beantworte mir ganz schlicht meine Fragen:
Wo sind die Headroom-Daten hin? Und: Werden sie in einem daraus exportierten File enthalten sein? Ja oder nein?

Nur darum geht es. Und das beantwortets Du einfach nicht. Warum?

Beste Grüße,
Reiner



Antwort von dienstag_01:

Aus der Premiere Pro Doku:

Zitat:

Hinweis:

32-bpc-Effekte werden nur mit 32 Bit pro Kanal gerendert, wenn alle anderen Effekte in der Render-Pipeline ebenfalls 32-bpc-Effekte sind. Wenn Sie einen 8-bpc-Effekt in einer Sequenz platzieren, die einen 32-bpc-Effekt enthält, werden alle Effekte in der betreffenden Sequenz von Premiere Pro mit 8 Bit gerendert.


Alles klar? (Wenn nicht: Die Adobe-Doku bietet weitere Erläuterungen dazu). und: Steve Hoeg, one of the Premiere Pro engineers, provided some examples of how Premiere Pro will handle color precision in different scenarios:
1. A DV file with a blur and a color corrector exported to DV without the max bit depth flag. We will import the 8-bit DV file, apply the blur to get an 8-bit frame, apply the color corrector to the 8-bit frame to get another 8-bit frame, then write DV at 8-bit. Man ist scheinbar gelegentlich der Meinung, Adobe beherrscht die englische und deutsche Sprache nur unzureichend.
Im deutschen Text steht nicht, dass das Ergebnis in 8bit ist (nachdem alle Effekte in voller Auflösung gerechnet wurden), sondern dass jeder Effekt in 8 bit gerechnet wird. Im englischen Text steht es genauso.
Hmm, muss wohl trotzdem falsch sein.



Antwort von WoWu:

Ich möchte in die Diskussion ja nicht einsteigen, aber diese ganze 8/23 Bit Diskussion bei 8 Bit Material zu führen ist eigentlich überflüssig, weil spätestens beim Rücksprung nach 8 Bit jeder "vermeintliche" Vorteil wieder verpufft.
Was bleibt sind die Nachteile einer solchen ebenso wie einer RGB Bearbeitung.
Mal ganz abgesehen davon, dass ohnehin nicht alle Effekte durchgängig in 32 Bit zur Verfügung stehen und das umschalten nach 8 Bit immer zu Unschärfen führt. Und auch was den "vermeintlich" besseren Störabstand betrifft ... der ist bei dem 8 Bit Material bereits Bestandteil des Bildes, wird also vom 32 Bit "Vorzug" gar nicht erfasst. Bestenfalls aufgesetzte Grafiken ... und auch nur solange, wie es im Rechner ist. Spätestens wenn es 8 Bit werden ist das auch vorbei.
Warum also die 8/32 Bit Diskussion, wenn man mit 8 Bit umgeht ?
In der VFX-Welt kann ich das noch nachvollziehen, aber in der reinen Videobearbeitung ?

(Ich kenn das von andern Programmen übrigens auch nur so, dass pro Effekt auf 8Bit gegangen wird ... mag ja sein, dass Premiere das anders macht. Nur ist es ziemlich egal, weil bei jeder Umschaltung, egal ob Effektline oder individueller Effekt, das Bild immer an Schärfe verliert).



Antwort von dienstag_01:

@WoWu
Diese ganze Diskussion dreht sich gerade um den Punkt, dass Reiner M der Meinung ist, Head- und Footroomdaten seien nur nutzbar, wenn eine 32bit Verarbeitung erfolgt. In 8bit sei sowas gar nicht möglich.
Und ich sage dazu, ach, gähn...



Antwort von Reiner M:

Im deutschen Text steht nicht, dass das Ergebnis in 8bit ist (nachdem alle Effekte in voller Auflösung gerechnet wurden), sondern dass jeder Effekt in 8 bit gerechnet wird. Im englischen Text steht es genauso.
Hmm, muss wohl trotzdem falsch sein. Das kommt halt dabei raus, wenn man die Doku nicht liest, sondern einzelne Sätze rausfriemelt und nach Fällen sucht, die einen passen. ;)

Noch mal der Tipp:
Lies bitte die Doku.
Weil:
Ich kann Dir hier beim besten Willen keinen Grundkurs in Premiere Pro liefern. Wirst Du verstehen, oder? Und: Beantworte doch einfach meine Fragen! Geht das nicht?

Beste Grüße,
Reiner



Antwort von WoWu:

Ich verstehe, die Problemstallung hatte ich so bisher nicht verstanden.
Und warum soll das nur bei 32 Bit so sein ?
Der Arbeitsbereich ist doch nicht abhängig von der Verarbeitungstiefe ?
Oder hab ich da jetzt wieder was falsch verstanden ?



Antwort von Reiner M:

@WoWu
Diese ganze Diskussion dreht sich gerade um den Punkt, dass Reiner M der Meinung ist, Head- und Footroomdaten seien nur nutzbar, wenn eine 32bit Verarbeitung erfolgt. In 8bit sei sowas gar nicht möglich.
Und ich sage dazu, ach, gähn... Bisher hast Du dazu nicht einen einzigen Beweis geliefert. Nur solche, die, wenn überhaupt, belegen, dass es nur in 32bit geht. ;-))) Nicht bemerkt?

Ach ja: Wein DEIN Premiere Pro komplett in 8bit arbeitet - wie Du behauptest (meins tut das nie!): Was meint das. Ist das dann das ganze System? Das Projekt? Die Sequenz? Oder der Clip?

Bin gespannt ...

Beste Grüße,
Reiner



Antwort von dienstag_01:

Oder hab ich da jetzt wieder was falsch verstanden ? Sicher ;)



Antwort von Reiner M:

Ich verstehe, die Problemstallung hatte ich so bisher nicht verstanden.
Und warum soll das nur bei 32 Bit so sein ?
Der Arbeitsbereich ist doch nicht abhängig von der Verarbeitungstiefe ?
Oder hab ich da jetzt wieder was falsch verstanden ? Es ist ein ganz trivales Problem der Informatik, Wolfgang.

Premiere Pro nutzt bei 8bit-Effekten in RGB den Wertebereich 0-255. Logisch.
Der bildgebende Bereich der REC.709-Files (Y16-235) wird in Pr und Ae nach 0-255 gemappt. Alles außerhalb ist in RGB 0-255 nicht speicherbar und geht bei der Umrechnung folglich verloren. Faktisch geht damit der Head- und Footroom verloren und wird in exportierten Videos nicht wieder auftauchen. Kann man ganz leicht testen, sowohl in Pr wie in Ae.

Aber Dienstag will es nicht testen. Warum auch immer. Ich habe ihn schon xfach gebeten. ;)

Das ist genau das, was Du in dem von Dir gezeigten Adobe-Zitat weiter oben beschrieben steht. Man muss auf 32bit gehen (After Effects) oder dort bleiben (Premiere Pro) um diese Daten in negativen Werten und oberhalb 1.0 in RGB speichern zu können. Das sagt jedenfalls Adobe dazu.

Aber Dienstg mag diesen Artikel nicht und ignoriert ihn. Warum auch immer. ;)

Beste Grüße,
Reiner



Antwort von WoWu:

Es stellt sich also die Frage, wenn im 709 Bereich oberhalb von 235/240 und im unteren Bereich gar nichts ist, weil es sich in einem Standardsignal um Überschwinger handeln muss, die man, ausser bei einem Analogsignal ohnehin nicht mehr braucht, was man dann eigentlich speichern will.
Mit andern Worten. Wenn die Werte bei einem Mapping Y"CbCr=> RGB verloren gehen, -was verliert man ausser Störsignalen eigentlich ?

Und was passiert -wenn man wirklich solche Signale rübergerettet haben sollte, bei einem Rücksprung nach 709 damit.
Setzt man sich seine Störsignale dann wieder ins Bild ?
Oder selbst wenn da Nutzsignale drin gewesen sein sollten ... was passiert damit, wenn ich nach 709 Zielmaterial gehe ... werden meine illegalen Werte dann wieder eingesetzt und mein Kunde haut mir das dann bei der technischen Abnahme um die Ohren ?

Ich verstehe das Problem (und die Anwendung) einfach nicht ?



Antwort von dienstag_01:

Aber Dienstag will es nicht testen. Warum auch immer. Ich habe ihn schon xfach gebeten. ;) Ich hab es getestet und es funktioniert.
Leider habe ich mich an die Anweisungen von Adobe gehalten und die müssen falsch sein. Sonst müsste man annehmen, Adobe mapped die Werte nicht und Reiner M läge falsch. Wer will das?!



Antwort von dienstag_01:

Ich verstehe das Problem (und die Anwendung) einfach nicht ? Das Problem ist schon ziemlich speziell, stimmt. Aber es gibt nun mal Cams, die in diesem eigentlich illegalen Wertebereich aufnehmen, egal, ob man das gut findet oder nicht. Will man diese Daten nutzen, müssen sie natürlich in den legalen Bereich, das ist klar.



Antwort von Reiner M:

Mit andern Worten. Wenn die Werte bei einem Mapping Y"CbCr=> RGB verloren gehen, -was verliert man ausser Störsignalen eigentlich ? Nun, es könnten sinnvolle Inhalte sein. Dienstag hat ein wirklich hübsches Video gebastelt, wo das keine "Störsignale" sind, sondern Daten, die ein Bild ergeben. Für solche Testzwecke echt toll.
Und was passiert -wenn man wirklich solche Signale rübergerettet haben sollte, bei einem Rücksprung nach 709 damit.
Setzt man sich seine Störsignale dann wieder ins Bild ? Ja, sie werden bei allen Berechnungen berücksichtigt und im exportierten Video entsprechend (modifiziert gemeinsam mit allen Bilddaten) zu finden sein.
Könnten ja in der Kopie noch nützlich sein. Es gibt Anwendungsfälle.
Und mein Kunde haut mir das dann bei der technischen Abnahme um die Ohren ? Natürlich sollte man die Anfordungen seiner Kunden kennen.

Wenn man sie nicht braucht, oder sie unerwünscht sind, löscht man sie eben. Dann muss aber wissen, wann sie auftauchen , wann nicht, und wie sie nutzt oder wegwirft. ;)

Beste Grüße,
Reiner



Antwort von Reiner M:

Ich hab es getestet und es funktioniert.! Herzlichen Glückwunsch! ;)

Den Rest schenke ich mir. Kann ja jder andere auch ausprobieren ... ;)

Beste Grüße,
Reiner



Antwort von WoWu:

Das weiss ich, nur hat das nichts mit dem Videostandard zu tun und spätestens, wenn man das Zielfomat herstellt, erübrigen sich die Werte ohnehin, wenn man sie nicht vorher umgemapped hat.
Wobei sich auch da die Frage stellt, ob es sich (z.B. in der GH4) lediglich um ein anderes Mapping handelt -worauf es einige Hinweise gibt- oder tatsächlich um zusätzliche Werte.
Also auch da stellt sich die Sinnfrage.
Panasonic entspricht mit dem Y'CbCr/16-255 nur den Anforderungen der ATI in den USA um die Zulassung zu erhalten. Praktischen Zugewinn im Signal hat man davon eigentlich nicht.
Es stellt sich also immer die Frage, was in solchen Bereichen eigentlich übertragen wird und wozu man es nutzen kann und ob es nicht lediglich ein anderes Mapping ist. In dem Fall gibt es keine zusätzlichen Signale sondern nur eine falsche Platzierung.
Aber lassen wir's dabei.



Antwort von dienstag_01:

Es stellt sich also immer die Frage, was in solchen Bereichen eigentlich übertragen wird und wozu man es nutzen kann und ob es nicht lediglich ein anderes Mapping ist. In dem Fall gibt es keine zusätzlichen Signale sondern nur eine falsche Platzierung. Aber auch dann (oder gerade dann) muss man die Signale doch in seinem NLE in die Range holen, oder.



Antwort von WoWu:

Dazu brauchst Du aber keine 32 Bit.
Aber lass uns hier kein "neues Fass" aufmachen.



Antwort von Reiner M:

Das weiss ich, nur hat das nichts mit dem Videostandard zu tun und spätestens, wenn man das Zielfomat herstellt, erübrigen sich die Werte ohnehin, wenn man sie nicht vorher umgemapped hat. Genau.

Oder in den bildgebenden Bereich gerettet hat. Wie man es z. B. bei Dienstags Testvideo gut demonstrieren kann (hat er weiter oben mal gemacht). Und solche Anwendungsfälle gibt es innerhalb eines NLEs mit sehr praktischen Material häufig, nicht nur in Testszenarien.
Aber lassen wir's dabei. Gern.

Bis dann.

Reiner



Antwort von dienstag_01:

Dazu brauchst Du aber keine 32 Bit. Du bist ja schlimmer als die Adobe-Leute. Die umschreiben das wenigstens höfflich.



Antwort von Reiner M:

Beste Grüße,
Reiner

Edit:
WoWu hat Recht: Lassen wirs lieber. Zieht sich sonst womöglich, ohne neue Erkenntnisse zu liefern. ;)

Tschüs!



Antwort von dienstag_01:

Du bist ja schlimmer als die Adobe-Leute. Die umschreiben das wenigstens höfflich.

Und wo? Ich bitte dich, Reiner, mein kleines Beispiel oben steht exemplarisch für die *Nutzbarmachung* von Head- und Footroom-Daten. Ich habe mich dabei strikt an die Anweisungen von Adobe für einen 8bit Workflow gehalten. Da Adobe nicht explizit schreibt, dass es funktioniert, aber einen funktionierenden Workflow bereithält, nenne ich das Umschreibung. Naja, nicht so schön, vielleicht hast du ein besseres Wort dafür?



Antwort von EnricoPerei:

Der OP hat komplett synthetisch generiertes Material :-)

Irgendwann hat mal jemand dann noch was zu Kameras gefragt und das war dann Ansporn genug ;-) Hahaha, ich schmeiß mich wech!

Wir haben uns mit dem ganzen Quark, der hier beigemengt wurde selbst verwirrt...(; Enrico, das ist falsch. Da wird nichts interpoliert. Hast Du die Formel verstanden?

Vergiss bitte die Idee, dass die Wertebereiche "16-235" in YCbCr und RGB identische Inhalte hätten, oder wenigstens solche, die quasi 1:1 zugeordnet werden könnten. ... ganz ehrlich, was soll an der Formel so schwer verständlich sein?
Das ist eine simple Transformationsmatrix.
Jeder Gymnasiumabsolvent,der halbwegs aufgepaßt hat, versteht sowas.

Zudem gibt es nicht nur die eine auf Wikipedia.
Selbst bei dem offiziellen Link, den ich gepostet hatte gibt's mehrere.
Desweiteren, so großartig ich auch das Wikipedia Projekt finde, ich habe grundsätzlich ein Problem damit, das dort gepostete ungeprüft zu akzeptieren, kann doch jeder Hinz und Kunz dort herumeditieren...

Traditioneller Weise hast Du recht Reiner, das legale Videosignal ist zwischen 16-235 ("Studio swing").
Bitte beachte aber, daß die YCbCr Definition Werte darunter und darüber technisch zuläßt, wenn diese auch beim Senden/Darstellen laut rec.709 ignoriert/zerstört werden.
Modernes Equipment nutzt diesen Bereich aber zum speichern der extended oder full range / full swing.

Wollte man die Werte erhalten, wenn man die 16-235 YCbCr auf 0-255 RGB Formel anwendet, müßte man vorher den 0-255 YCbCr Bereich in den YCbCr 16-235 pressen (wodurch die Farben gestaucht würden).
Es ist viel besser hier statt dessen direkt von YCbCr 0-255 zu wandeln. -professionelle Arbeitsweise:
Das 8Bit Material in 32bit float wechseln
(dies ist keine Farbraumkonvertierung, nur eine Bittiefenveränderung!). Genaugenommen bedeutet dies sogar mehr als nur mit zusätzlichen Bits zu arbeiten, da sowohl negative als auch große Werte erhalten werden können. Floats verhalten sich allerdings anders als Integers, die darstellbaren Zahlenwerte sind nicht gleichmäßig verteilt. Jepp, ich wollte das ganze aber nicht noch verwirrender gestalten.
Schließlich kann float auch unendliche Werte, positiv und negativ, negativ zero und NaN,sowie natürlich über 1,0 und unter 0,0 darstellen. Hierdurch werden die vorher extrem groben 8 bit Abstufungen wesentlich feiner. Das ist leider falsch. Hä?
Das mußt Du aber erklären.

256 < 65536
Richtig?!

Ich meine natürlich nicht, daß durch den bloßen Wechsel in eine andere Bittiefe die Werte plötzliche feiner sind (; ... das hatten wir schon...
Ich spreche logischer Weise davon, daß Berechnungen in größeren Bittiefen genauere,detailliertere Ergebnisse liefern (z.B. der Verlauf eines Blurs:BANDING...). diese ganze 8/23 Bit Diskussion bei 8 Bit Material zu führen ist eigentlich überflüssig, weil spätestens beim Rücksprung nach 8 Bit jeder "vermeintliche" Vorteil wieder verpufft. Das Wichtige und Sinvolle in höchstmöglicher Bittiefe zu arbeiten ist schlichtweg, daß jede Berechnung die feinsten Details erzeugt, die möglich sind.
Selbst, wenn diese beim Wechsel in eine niedrigere Bittiefe grober werden, so werden die Bilder, die in hoher Bittiefe berechnet wurden fast immer wesentlich besser aussehen, als die, die in der niedrigen berechnet wurden.
Nicht umsonst wird sehr häufig cgi in doppelter Auflösung gerendert, und dann auf die Zielauflösung resized (selbes Prinzip, nur Auflösung statt Bittiefe).
Durch die ganzen mathematischen Rundungen, unterschiedliche Verhaltensweisen von Algorithmen bei unterschiedlichen Bittiefen und Wertebereichen (negativ/positiv,float) ist dies ja auch logisch.

Das ist übrigens eben nicht nur auf VFX beschränkt.
Jede Transformation mit Scaling, jeder Blur,Scharfzeichner, jeder Glow, jede Farbkorrektur, ja selbst viele cuts mit Blenden sind davon ebenso betroffen.
Zudem liegt heutzutage das meiste professionelle Material von 10-14Bit oder mehr vor und meist in logarithmischem Farbraum, dessen Umwandlung von hohen Bittiefen ebenso profitiert.

Daher ist es für mich auch absolut unverständlich, wenn jemand, der halbwegs ernsthaft und professionell arbeitet eine Software benutzt, die nicht in der Lage ist in allen gängigen Bittiefen und Farbräumen (oder wenigstens der allerhöchsten, verfügbaren) NATIV zu arbeiten!
Eine Software, die bei bestimmten Berechnungen auf die niedrigste Bittiefe zurückfällt, schließt sich für mich automatisch aus.
Was soll der Quatsch ?



Antwort von WoWu:

@Enrico

Du vermengst da jetzt aber auch wieder reichlich "Kessel Buntes".
Aber da wieder einzusteigen hiesse, das Karussell wieder einzuschalten. :-(



Antwort von EnricoPerei:

@Enrico

Du vermengst da jetzt aber auch wieder reichlich "Kessel Buntes".
Aber da wieder einzusteigen hiesse, das Karussell wieder einzuschalten. :-( Mußte ja auch auf viele Punkte und Diskussionspartner eingehen.

Habe zudem versucht, das ganze unter TL;DR zu halten.
Daß ich da nicht jedes einzelne Argument bis ins kleinste Detail (auf englisch auch BIT nennbar hehe) aufgedröselt habe, ist wohl klar.
Interpretiert, wie es gemeint ist, nicht wie man es rumdeuten könnte.

Ich setze mal voraus, wir sind hier Leute mit Kenntnissen und professioneller Erfahrung auf diesen Gebieten und es ist ja weder OP, noch dem Forum dienlich, hier pissing contests wie im Kindergarten zu veranstalten.

OP hat die Tipps bekommen, um das Material zu fixen.
Die ganze Bittiefen und Farbraum Diskussion ist derart Off Topic gerutscht, daß ich mich langsam frage, wer hier überhaupt noch weiß, wie Computer Information in Bits speichern...



Antwort von TheBubble:

Hierdurch werden die vorher extrem groben 8 bit Abstufungen wesentlich feiner. Das ist leider falsch. Hä?
Das mußt Du aber erklären.

256 < 65536
Richtig?! Wenn einmal auf den 8 Bit-Wertebereich gerundet wurde, dann ist eine vielleicht ursprünglich vorhandene höhere Genauigkeit verloren gegangen. Da ist nichts mehr zu retten.
Ich spreche logischer Weise davon, daß Berechnungen in größeren Bittiefen genauere,detailliertere Ergebnisse liefern (z.B. der Verlauf eines Blurs:BANDING...). Solange das Ziel wie das Ausgangsmaterial nur 8 Bit sind, verschiebst Du damit erstmal nur den Rundungsvorgang weiter nach hinten in die Verarbeitungskette. Sinn macht eine höhere Genauigkeit dann, wenn die Rundung nach einem explizit berechneten Zwischenschritt zu einem Genauigkeitsverlust führen würde.

Ja, das ist etwas kompliziert ausgedrückt, daher für alle, die etwas anschaulicheres brauchen, ein übertrieben einfaches Beispiel:

Wir berechnen mit Integern (d.h. ganzen Zahlen in einem endlichen Wertebereich) Wert_neu = Wert_alt / 2 * 2. Würde es sich um reelle Zahlen handeln, dann würde Hinsehen oder Vereinfachen ergeben, dass Wert_neu = Wert_alt gemeint ist. Aber leider soll mit Integern gerechnet werden.

Berechnet man also die Division, dann wird vor der Multiplikation gerundet. Dabei verliert man quasi 1 Bit Genauigkeit.

Noch interessanter ist es, wenn man vor der Division multipliziert: Werte, die den maximalen Wertebereich überschreiten, werden abgeschnitten (oder es kommt zum Überlauf), noch bevor dividiert wird.

Solche Probleme kann man durch die Nutzung von Floats vermeiden bzw. die Auswirkungen reduzieren.



Antwort von EnricoPerei:

Hierdurch werden die vorher extrem groben 8 bit Abstufungen wesentlich feiner. Das ist leider falsch. Hä?
Das mußt Du aber erklären.

256 < 65536
Richtig?! Wenn einmal auf den 8 Bit-Wertebereich gerundet wurde, dann ist eine vielleicht ursprünglich vorhandene höhere Genauigkeit verloren gegangen. Da ist nichts mehr zu retten.
Ich spreche logischer Weise davon, daß Berechnungen in größeren Bittiefen genauere,detailliertere Ergebnisse liefern (z.B. der Verlauf eines Blurs:BANDING...). Solange das Ziel wie das Ausgangsmaterial nur 8 Bit sind, verschiebst Du damit erstmal nur den Rundungsvorgang weiter nach hinten in die Verarbeitungskette. Sinn macht eine höhere Genauigkeit dann, wenn die Rundung nach einem explizit berechneten Zwischenschritt zu einem Genauigkeitsverlust führen würde.

Ja, das ist etwas kompliziert ausgedrückt, daher für alle, die etwas anschaulicheres brauchen, ein übertrieben einfaches Beispiel:

Wir berechnen mit Integern (d.h. ganzen Zahlen in einem endlichen Wertebereich) Wert_neu = Wert_alt / 2 * 2. Würde es sich um reelle Zahlen handeln, dann würde Hinsehen oder Vereinfachen ergeben, dass Wert_neu = Wert_alt gemeint ist. Aber leider soll mit Integern gerechnet werden.

Berechnet man also die Division, dann wird vor der Multiplikation gerundet. Dabei verliert man quasi 1 Bit Genauigkeit.

Noch interessanter ist es, wenn man vor der Division multipliziert: Werte, die den maximalen Wertebereich überschreiten, werden abgeschnitten (oder es kommt zum Überlauf), noch bevor dividiert wird.

Solche Probleme kann man durch die Nutzung von Floats vermeiden bzw. die Auswirkungen reduzieren. Werde ich hier gerade getrollt?

Es geht dabei doch nicht (nur) um Nachkommastellen!
Zitat:"Wert_neu = Wert_alt / 2 * 2"
Was wirklich passiert, ist wohl eher so:
wert_alt8bit : pixel mit 256 Farbabstufungen.
changeBitDepth 8 to 16 bit
wert_alt16bit=wert_alt8bit : pixel mit 256 Farbabstufungen im Fomat für 65536 Farbabstufungen
wert_neu16bit=wert_alt16bit * x + z *+-/...jede menge crap
changeBitDepth 16 to 8 bit
wert_neu8bit=wert_neu16bit mit 256 Farbabstufungen, statt 65536 Farbabstufungen

Vor allem, wenn die Farben nicht direkt nebeneinander liegen und wenn man Farbkorrekturen oder z.B. Blur benutzt, werden vollkommen andere Werte für den Übergang zwischen mehreren Farbabstufungen berechnet.
Diese sind dann beim Export in 8 bit zwar wieder grober, aber dennoch unterschiedlich zum reinen, groben 8 bit Processing.
Das ist doch eigentlich selbstverständlich und völlig logisch.
Ich hätte nicht gedacht, daß ich HIER tatsächlich die Bedeutung/Unterschiede von Bittiefen erklären muß...


...habe keine Lust, mir die Finger wund zu tippen, also guckst Du hier:
(top processed in 8bit int, bottom processed in 16bit int and exported to 8bit int)

zum Bild


original in 8 bit:

zum Bild


processed in 8bit:

zum Bild


processed in 16bit, exported to 8 bit

zum Bild


Zum selbermachen:
(Files siehe CompareBitdepth.zip)
(diese Werte habe ich genommen, andere funktionieren genauso...das Prinzip bleibt, nur die Unterschiede sind je nach Kombi stärker oder schwächer)

Man nehme "_8bit-original.0000.tga" und
1.
Blur = 5.0 (gaussian)
2.
Gamma = 1.07407
Contrast= 0.54629
Gain = 0.98148
Levels:
Low = 0.09000
High = 0.40909

Genau den Übergang anschauen (ggf. reinzoomen).


Sorry, sollte das wirklich nicht klar sein, warum das so ist, bin ich gern bereit das zu erklären.
Ich fühle mich momentan aber wirklich veralbert.

edit:
Ich habe das ganze in Fusion gemacht, da ich kein AE habe und Nuke nur in 32bit float rechnet.



Antwort von TheBubble:

Werde ich hier gerade getrollt? Könnte ich auch von mir behaupten, immerhin hast Du meinen Beitrag scheinbar nicht (richtig) gelesen.
Es geht dabei doch nicht (nur) um Nachkommastellen! Solange das Ziel immer nur 8 Bit/Sample sind, dient jede vorläufige Erweiterung der Bittiefe zur Erhöhung der Genauigkeit von Zwischenergebnissen.

"Zwischenergebnisse" müssen mindestens immer dann berechnet werden, wenn Daten von einem "Filter" an den Nächsten übergeben werden.
Was wirklich passiert, ist wohl eher so:
wert_alt8bit : pixel mit 256 Farbabstufungen.
changeBitDepth 8 to 16 bit
wert_alt16bit=wert_alt8bit : pixel mit 256 Farbabstufungen im Fomat für 65536 Farbabstufungen
wert_neu16bit=wert_alt16bit * x + z *+-/...jede menge crap
changeBitDepth 16 to 8 bit
wert_neu8bit=wert_neu16bit mit 256 Farbabstufungen, statt 65536 Farbabstufungen Ja, so könnte es intern laufen. Durch Deine vorläufige Erweiterung auf 65536 mögliche diskrete Werte kannst Du implizit die Zwischenergebnisse mit einer erhöhten Genauigkeit von zusätzlichen 8 Bit an festen Nachkommastellen ablegen.
Diese sind dann beim Export in 8 bit zwar wieder grober, aber dennoch unterschiedlich zum reinen, groben 8 bit Processing. Das sind sie, aber genau wegen der erhöhten Genauigkeit in den Zwischenergebnissen. Daher ist es für viele Fälle auch durchaus sinnvoll, in der Verarbeitungekette mit mehr als 8 Bit/Sample zu arbeiten.
Sorry, sollte das wirklich nicht klar sein, warum das so ist, bin ich gern bereit das zu erklären.
Ich fühle mich momentan aber wirklich veralbert. Vieleicht regst Du Dich wieder ab, wenn Du meinen Beitrag oben noch einmal aufmerksam liest.

Dann würdest Du feststellen, dass ich die Probleme einer reinen 8 Bit Verarbeitung beschrieben habe, insbesondere den Genauigkeitsverlust am Beispiel einer Rechnung, die bei rationalen Zwischenergebnissen (im Gegensatz zu 8 Bit Integern) den Ausgangswert in jedem Fall unverändert belassen würde. Du würdest dann auch feststellen, dass wir uns in dieser Diskussion hier vom Grundsatz her gar nicht widersprechen.



Antwort von EnricoPerei:

@TheBubble

Ich hätte Deinen Beitrag nicht als einzigen zum Gegenstand meiner Antwort machen sollen, entschuldige.
(auch dafür, daß ich dies im Grunde wieder mache)
Wollte aber auch keine endlosen Zitatwälder erzeugen und zig Seiten Text nachlesen, er war nunmal auch der frischeste.

Ich denke auch, Du und ich meinen im Grunde das Gleiche.

Hier im Thread wurde allerdings Sinngemäß mehrfach gesagt, daß eine Umwandlung von 8 bit auf 16/32 bit zur Bearbeitung mit anschließender Rückwandlung quasi keine Unterschiede machen würde(ausser in Sonderfällen), ergo man also ruhig in 8 bit rechnen könnte.
Das ist kein Mißverständnis,höchstens eine Vereinfachung/Überspitzung:
(sorry für das TL;DR aber ich habe schon richtig verstanden) -"Die Bearbeitung 16/32 wird nichts bringen, weil die Wortbreite von 8Bit hier bereits festliegt. " -"Ich möchte in die Diskussion ja nicht einsteigen, aber diese ganze 8/23 Bit Diskussion bei 8 Bit Material zu führen ist eigentlich überflüssig, weil spätestens beim Rücksprung nach 8 Bit jeder "vermeintliche" Vorteil wieder verpufft. " -"Hierdurch werden die vorher extrem groben 8 bit Abstufungen wesentlich feiner." "Das ist leider falsch." -"Wenn einmal auf den 8 Bit-Wertebereich gerundet wurde, dann ist eine vielleicht ursprünglich vorhandene höhere Genauigkeit verloren gegangen. Da ist nichts mehr zu retten." Dies stimmt natürlich, bestimmte Werte gehen verloren,aber diese allgemeine Aussage schließt die Unterschiede, die ich aufgezeigt habe mit ein, auch wenn Du das nicht so gemeint hast.
Sie sagt auch daß jede höhere Genauigkeit wieder verloren geht - auch wenn Du dies auch nicht so meintest. "Solange das Ziel wie das Ausgangsmaterial nur 8 Bit sind, verschiebst Du damit erstmal nur den Rundungsvorgang weiter nach hinten in die Verarbeitungskette." "Sinn macht eine höhere Genauigkeit dann, wenn die Rundung nach einem explizit berechneten Zwischenschritt zu einem Genauigkeitsverlust führen würde. " Dies impliziert, daß man in anderen (nicht spezial)Fällen sich die Wandlung in 32bit sparen kann.
Ehrlich gesagt, ist mir das daher viel zu unklar ausgedrückt.
Letztlich findet bei (nahezu) JEDER Berechnung Genauigkeitsverlust statt, wenn man das Ergebnis in niedrigere Bittiefen wandelt.
Ungeachtet dessen,wie hoch diese Differenz wirklich ist:
wie man ja an meinem Beispiel gesehen hat, handelt es sich hier um weit mehr, als ein paar Stellen Genauigkeit nach dem Komma.

Eigentlich führt man durch höhere Bittiefen neue Farben/feinere Farbabstufungen ein, dies sind streng genommen (vor allem bei integer) keine Rundungen/Genauigkeiten hinterm Komma sondern ein Array/Speicherbereich mit zusätzlichen Datenzellen.
(aber:Tomato/Tomato)

Dies kann dann, um wieder ON TOPIC zu gehen ggf. auch bei 8 Bit entstehendes BANDING verhindern/mindern.

Zudem führen gerade bei Farbkorrekturen und anderen Operationen (auch Merges,Blends,Glows,Blurs etc.) diese Genauigkeiten zu anderen Ergebnissen.
Diese werden auch beim Wechsel in niedrigere Bittiefen (großteils) erhalten (wie mein Beispiel aufzeigt)

Warum sonst würde man den ganzen zusätzlichen finanziellen, Daten-, Hardware- und Rechenaufwand auf sich nehmen, um in immer höheren Bittiefen zu arbeiten ?!


Der hier mitschwingenden Kernaussage musste ich einfach wehement widersprechen!!
Sorry, aber da kennt der Künstler, Perfektionist und Pixelfucker in mir kein Pardon.

edit:
Ich möchte hier auch nochmal einfügen, daß ich nicht "out of my ass" spreche, sondern neben meiner künstlerischen Tätigkeit mit Farbräumen und Bittiefen auch native Plugins in C++ programmiere und genau weiß, wie ich für Nuke, Shake und Fusion Bitdepth und Subpixeldepth (eigentlich Auflösung, aber im Grunde gleiches Vorgehen) kalkulieren/programmieren muß und welche Folgen bestimmte Algorithmen haben.
Fehler im Code könnten finanziell katastrophale Folgen haben...
/edit

Auch wenn Du oder andere bestimmte Feinheiten(pun intended) im dahinterliegenden Rechenverfahren etc. sehen, die meiner Aussage sogar unter Umständen zustimmen,
Neulinge nehmen nur wahr: "8bit,alles in Butter, nich' in 32 Bit wandeln, is' eh überflüssig und kost' nur Renderzeit."

Zugegeben, einiges der Bittiefen Diskussion lief im ersten Off Topic über den Farbraumwandel ab und hat somit noch andere Implikationen mit sich geführt.

Wer mir hier zustimmt, daß man IMMER (ja, nu hab' ich's auch mal gesagt hehe) mit der höchstmöglichen Bittiefe arbeiten sollte, kann das gerne sagen (Du hast's ja quasi schon), damit wir diesen eigentlich bereits gelösten Thread vom Off Topic befreit schließen können.
Bisher hat sich aber auch noch niemand zu meinem eindeutigen Beispiel geäußert, aber sei's drum.



Antwort von dienstag_01:

@EnricoPerei
Die eigentliche Kernaussage hier auf Slashcam ist (oder sollte man besser sagen, könnte sein), dass man
- im Originalformat (Bittiefe) arbeiten sollte. Die Wandlung des Quellmaterials von bspw. 8 nach 10bit bringt nichts, macht das File groß und beinhaltet Dithering.
- für das Processing, also die Berechnung, natürlich die höchstmögliche Bittiefe wählen sollte.

Ich verstehe deine Aussagen nicht anders. Liege ich da vielleicht falsch?



Antwort von WoWu:

@ Enrico

So, wie die oben gemachten "Pauschalisierenden" unscharf waren, so ist leider auch Deine Pauschalisierung gleichwohl unscharf.
H.264 benutzt eine Integer DCT, die weitestgehend mit Additionen und Shift Operationen auskommt und insofern Rundungsfehler weitgehend minimiert sind.

Wortbreiten bei 16 und 32 Bit sind entsprechend grösser, aber sobald darin statt 8 wieder 16 bzw. 32 Bit Effekte benutzt werden, wird das LSB ebenso abgeschnitten.
Vorteile ergeben sich also nur, wenn mit 8 Bit Effekten gearbeitet wird.

Du sagst sehr richtig, dass bei einem vergrösserten Arbeitsbereich lediglich grössere Adressräume zur Verfügung stehen.
Die Frage stellt sich also, womit werden sie bedient.
Auch bei grösseren Adressräumen stehen bei einer Videozuspielung nicht mehr Tonwerte (von einem 8 Bit Ausgangsmaterial) zur Verfügung.

Ein Grafiksignal wird neu berechnet werden und zusätzliche Werte einfügen.
Woher sollen diese Werte aber von einem bestehenden Content kommen ?
Es ist also entweder Dither, das ebensowenig Tonwerte enthält, weil es lediglich zwei Werte für die Pixelstruktur benutzt, aber keinen dritten Wert hinzufügt oder es wird ein dritter Wert interpoliert, was aber nicht mehr dem Bildoriginal entspricht.
Habe ich zwei farbige Objekte, (beispielsweise eins rot, eins grün), wird die Interpolation einen gelben Wert dazwischen errechnen, der im Original aber nicht vorhanden ist.
In 8Bit wäre das nicht passiert.
Frage ist auch, was mit diesem zusätzlichen Wert beim Rücksprung nach 8Bit passiert. Es kann also durchaus sein, dass durch solche Rechenoperationen zum "falschen Wert" hin gerechnet wird und sich der Abstand der Tonwerte im Endergebnis vergrössert haben. (Denn mehr werden es ja bekanntlich nicht.)
Darüber sollte Konsens herrschen.

16 und 32 Bit haben sicher ihren stärksten Vorteil im Störabstand (Rundungen). Es bringt nur nichts, weil in einem 8Bit Signal der Störabstand bereits festliegt und durch eine 16/32 Bit Berechnung um Nichts verbessert wird.
Auch der Gesamtstörabstand des Bildes liegt damit fest und der Vorteil verbesserter Störabstandswerte verteilt sich statistisch und wird das Bild nicht verändern oder gar verbessern.

Man muss also zwischen Computersignalverbesserungen und dem, was wirklich in einem Videofile passiert, deutlich differenzieren.
In VFX Bearbeitung haben solche Arbeitsbereiche sicher ihren Vorteil.
In einer 8Bit Videobearbeitung (mit einem fertig "gebackenen" Signal - also keiner 8 Bit Computerannimation) eher Nachteile.

ich hatte oben auch schon zitiert, was ADOBE dazu sagt und die Aussage ist eigentlich eindeutig.

Also: pauschal kann man gar nichts sagen.
Weder das Eine, noch das Andere.
Man wird sich immer anschauen müssen, mit was für einem Signal man umgeht, ob Computergrafik oder Content aus einer Kamera, welche und wieviele Effekte man nacheinander benutzt und welche Qualität sie haben und ob es zusätzliche Veränderungen des Bildes gibt und auch, mit welchen Methoden die Rechenoperationen durchgeführt werden.
Ein steht fest. Du wirst bei einem Roundtrip keinen einzigen zusätzlichen Tonwert erhalten und ich vermute mal, dass es sich bei Deinem Beispiel auch um einen Verlauf handelt, der vom Rechnet erstellt wurde.
Mach dasselbe mal mit einem Videobild, in dem bereits die Arbeitsprozesse eingeflossen sind, die Kamera und Codec beitragen.

Pauschal kann man daher leider gar nichts sagen.

Das war übrigens eine gute Frage: Warum sonst würde man den ganzen zusätzlichen finanziellen, Daten-, Hardware- und Rechenaufwand auf sich nehmen, um in immer höheren Bittiefen zu arbeiten ?!



Antwort von otaku:

@wowu

ich stimme dir 100% in jedem detail zu.
aber ich habe 2 fragen.

das eine ist, wie sieht so ein 8 bit workflow aus. also wenn ich h264 8bit footage aus meiner camera bekomme, was ja weit verbreitet ist.
dann schubse ich es in z.b. premiere in ein 8bit projekt, schneide und farbkorrigiere es, baue meine titel, bauchbinden, etc drauf und gebe es dann auch als 8bit h264 wieder raus?
ich will jetzt nicht grundsaetzlich sagen das ist falsch, aber da dreht sich mir der magen um wenn ich daran denke das mein master jetzt ein h264 master ist. nicht weil ich jetzt wirklich argumente habe warum ich das in unkompressed 10bit rausgeben sollte, aber gefuehlt denke ich das ist doch kernschrott, auch wenn mir durchaus klar ist das mein original material ja auch nicht besser ist.

muss ich da einfach umdenken?

das andere ist: was ist mit den generationen die ich da erzeuge? 10x h264 auf ein bild gerechnet sieht ja zweifelsfrei schlechter aus als 10x umkomprimiert umgerechnet.



Antwort von WoWu:

Ja, Du musst umdenken.
8Bit ist 8Bit und bleiben es auch und der H.264 ist derzeit der am weitesten entwickelte Codec.
Jede Transcodierung ist mit Fehlern behaftet.
Schon wenn Du in eine DCT (alter strickart) gehst, geht das schon los.
Pixelshift ist das zweite Problem.
Und die IntDCT hat man gerade gemacht, damit keine Rundungsfehler mehr auftreten.
Lässt man sie liegen, ist man da, wo wir vor 10 Jahren standen.

Und solche Beispiele, wie Enrico sie mit einem Grauverlauf (computeranimiert) gemacht hat, sind alles Andere als repräsentativ. Man darf nicht vergessen, dass ein Signal nicht nur aus einer Tonwertberechnung bestehet, in der die Differenzen nicht besonders gut zu sehen sind, sondern mindestens aus drei, die dann auch noch eine Farbe ergeben. Wo also Tonwertdifferenzen in einem solchen grauen Experiment noch vernachläsigbar sind, werden sie, dadurch, dass auch bei einer Werteabstufung zusätzliche, abweichende Farben entstehen, umso deutlicher sichtbar.

Also: H.264 hat man gemacht, weil man aus den Fehlern der Vergangenheit (auch bei den schlechten Implementierungen) gelernt hat.
Du hast mit alternativen Codecs keine bessere Wahl. Man kann noch über die GoP nachdenken, sofern die Probleme bereitet, aber dann würde ich auf ein AVC-I Frame gehen, um den Rechner zu schonen. Von der Bildqualität bringt das herzlich wenig, weil die Referenzen in den H.264 GoPs schon drastisch besser sind, als bei den (1-I-Frame only) Gops von MPEG2.

Also, Umdenken, wäre an der Zeit; denn wo sind die Alternativen ?
Denn ob man nun den besseren Codec 10x kopiert, oder den schlechteren Codec ... hmmm ... dann doch lieber den Besseren.



Antwort von otaku:

ja das genau ist ja meine frage. h264 kommt bei mir zustande wenn ich industrie/imagefilm mache. fuer werbung, spielfilm hab ich ja eh immer red material, da ist es egal. aber speziell bei industrie geht es ja sehr oft so, das man generische bilder braucht die man schon 100 mal gedreht/benutzt hat.
(menschen in einkaufsstrasse, sportler, menschen am konferenztisch... etc)
also dreht man die oft ja nicht neu sondern sagt, jo nehm die mal aus dem film den wir fuer ... gemacht haben.
jetzt ist mein gedanke der, egal wie ich drehe, ob h264, red, iphone, was auch immer. ich mache mein master unkomp. 10bit. d.h. ich verliehre einmal an aufloesung, bzw. stanze meine qualitaet einmal so fest. das aus meinem iphone footage jetzt nicht red footage geworden ist weil ich es "hoch kopiert" habe das ist mir klar. aber wenn ich es jetzt unkompimiert weiter benutze kann ich das in den naechten film schneiden, und den film wieder in den naechten usw. im prinzip so viele generationen wie ich will weil ich ja theoretisch bei unkomprimiert nichts verliehre, egal wieviele generationen ich ziehe.
mache ich das gleiche aber als h264 wuerde ich aus dem bauch heraus sagen, 3 kopien weiter ist das nur noch schrott weil ich ja eine heftige kompression ueber die naechste baller.

also sagen wir mein original hat ne kompression von 1:10, dann hat mein master bei gleicher kompression schon 1:100 und meine erste generation 1:1000.
mache ich das gleiche aber mit unkompremierten mastern habe ich 1:10 im master, dann geht mir etwas bei der umwandlung verlohren, danach bleibt es aber gleich, d.h. meine erste generation ist ca. faktor 100 besser.

wo ist da mein denkfehler?



Antwort von WoWu:

Du kaskadierst ja keine Kompressionen.
An der Stelle ist es die Frage, wie das NLE mit dem Codec umgeht, weil die H.264 GoP ja nicht so einfach aufgebaut ist, wie die in MPEG2.
Viele Programme lösen daher am Bearbeitungspunkt den Codec auf und verarbeiten transparent. Das kommt aber wirklich einwenig darauf an, welche Verarbeitung die Firmen da spendieren.
Die einfachste Lösung ist natürlich für die Firmen, ein Intermediate. Nur der ist auch nicht transparent.
In keinem Fall aber kumulieren die Kompressionen.

Nach wie vor halte ich persönlich den proxy Workflow noch für die beste Lösung, weil das ganze Problem der Generationen nicht mehr stattfindet und man immer mit der "guasi" ersten Generation arbeitet.
Wobei ich Deine transparente Variante dem fast gleich setzen würde, sofern wir über Transparenz sprechen und nicht über irgend einen andern Codec.
Sonst würde ich immer in der "Toolbox" des Originalcodecs bleiben und einen entsprechende Version mit mehr Referenzframes vorziehen. Wobei das ja bei H.264 ohnehin üppig ist denn da können ja selbst B-Frames zur Referenzierung benutzt werden.
Es kommt bei H.264 schon sehr darauf an, wie gut der Codec implementiert ist und wie die Firmen im NLE damit umgehen.
Nur so schlecht, dass ein Zwischencodec besser als der Umgang mit dem originalcodec ist, können firmen gar nicht implementieren. Dann lassen sie es nämlich gleich sein und können H.264 gar nicht unteren verarbeiten.
(Solls ja alles geben) :-) mache mein master unkomp. 10bit. Ich würde immer das Original nehmen und auch archivieren.
Du kannst Deinem Content nichts besseres tun als immer auf die ursprüngliche Kameraqualität zuzugreifen- auch in Bezug auf die Verarbeitungstiefe-.
Bei den 10 Bit muss man immer wissen, was in den restlichen 1000 Wertepositionen ist und wie die Software damit umgeht.
Das ist das Problem und das ist unabhängig davon, ob es codiert oder transparent ist.
Wir haben bei HD von Anfang an mit 10 Bit Kamerasignalen gearbeitet und trotzdem läuft in der Post immer ein 8Bit preview mit, wenn das Zielformat in 8Bit sein sollte. Und fast immer müssen Arbeitsschritte angepasst werden, um Überraschungen im Endprodukt beim Kunden zu vermeiden.
8 Bit ist nun mal wirklich "auf Kante genäht" und nicht gerade ein robustes Signal.



Antwort von otaku:

danke fuer die erklaehrung.

natuerlich hast du recht, auf originale zuzugreifen ist immer die erste wahl, aber das kennst du ja selber, wenn du aufnahmen von vor 2 jahren benutzen willst dann hast du ja keine ahnung mehr auf welchen baendern/files das ist, da greifen meiner erfahrung nach sehr viele zum master aus dem projekt und erspahren sich so das ganze gesuche.
da geht halt oekomomie vs. qualitaet ;-)

mit den 8bit und auf kante, naja 8bit ist eine farbtiefe aus sd zeiten, da hat es ja auch meistens gut funktioniert. ich hatte da selten mit banding zu kaempfen und ich fand digibeta konnte man wirklich prima bearbeiten.
aber wenn ich 256 luma stufen anstatt auf 768 auf 1920 pixel zerre kommen halt die unzulaenglichkeiten ehr ans tageslicht, ich finde 8bit nicht schlecht, es ist halt nur fuer hd nicht das richtige, und wenn 4k einzug haelt muss man halt tatsaechlich ueber 16bit nachdenken. gottseidank das wird ja noch ein bissel dauern ;-)



Antwort von WoWu:

Dann kommen die andern Probleme... wenn 4K bei 1/300 shutter landet ...
Aber wenigstens lassen wir mit der REC2020 ein paar alte Unzulänglichkeiten zurück und 8 Bit ist ja auch schon lange nicht mehr das einzige Format, was auch im Semi-Bereich interessant ist.
Es muss nur jetzt noch in den Köpfen stattfinden.



Antwort von otaku:

ist 2020 so ein grosser schritt? ich erkenne das aus der spezifikation nicht.
ich sehe das frame raten von bis zu 120fps enthalten sind, aber auch immer noch der ganze weg runter bis 24.
klar 4k und 8k sind mit drin. und die farbtiefe ist min. 12bit, das ist gut.
wenn ich das aber richtig verstehe ist immer noch der farbraum entsprechend rec709 oder ccir601 was ich wirklich wirklich wirklich fuer total daneben halte. die gehen immer noch von baendern aus wo ein timecode untergebracht werden muss.
das ist doch eines der themen die jeden amateur und jeden profi verruckt macht, was will ich jetzt broadcast farben oder computer farben. heute will man einfach immer beides in einem master, auf grund der verbreitung sollte sich broadcast da unterordnen. oder ist das nur meine unwissenheit?



Antwort von WoWu:

Ich finde das schon einen Schritt in die richtige Richtung:

Es wird kein Interlaced mehr geben.
8 Bit ist nicht mehr vorgesehen.
Der eingeschränkte Farbraum wird drastisch erweitert.
Die Bildwiederholfrequenz wird erhöht.
Da treten die 4K schon fast in den Hintergrund, weil die bei Weitem nicht die Qualitätsverbesserung machen.

Und die 709 taten eigentlich auch nur bei 8 Bit weh. in 10 Bit sowieso nicht mehr.
Und vielleicht gewöhnen sich die Softwarehersteller ja auch noch mal daran, dass es für Video andere Anforderungen gibt, als in der Druckindustrie, wofür deren Programme eigentlich mal gemacht waren.
Bei Apple hat es ja 20 Jahre gedauert, mal sehn, wie lange es bei ADOBE noch braucht.
Ich möchte auf der andern Seite nicht wissen, was für ein Chaos entsteht, wenn solche Hersteller Standards für TV festlegen ...
Die sollen sich mal lieber an Standards halten, damit wäre dann nämlich allen gedient.



Antwort von otaku:

au kein interlaced mehr, das hatte ich ueberlesen, geil, endlich



Antwort von EnricoPerei:

@WoWu
Meine Aussage/mein Beispiel ist Pauschal, weil es eben leider so ist.
Es gibt keine Sonder-/Ausnahmefälle, lediglich solche, bei denen die entstehenden Unterschiede vernachlässigbar sind (Stichwort Pixelfucking, Zielformat etc.).

Mein Beispiel funktioniert natürlich (leider) auch wunderbar mit nicht synthetischen Bildern:
(dies ist übrigens Auflösungsunabhängig und ist NUR von der Bittiefe abhängig, die ja die Farbabstufungen - oft auch leicht verwirrend Farbauflösung genannt - pro Kanal bestimmt)
processed in 8 bit

zum Bild

processed in 16 bit, exported to 8 bit

zum Bild

original

zum Bild


Hierein liegt dann auch die Antwort auf die eigentlich rhetorische Frage, warum der Bittiefenwahn.

Zum selberbauen:
1.Blur=5(gaussian)
2.Lift=0.1264,Gamma=0.48571,Contrast=0.73584,Levels:Low=0.12280,High=0.67836

Zu Deinem Comment:
Die reinen Berechnungen(Farbkorrektur etc.) haben zunächst nichts mit dem Codec zu tun, der ist jeweils am Anfang und Ende der internen Wandlungs-Berechnungs-Wandlungskette und richtet dann erst mehr oder weniger Schaden an.
Die Bittiefe, in welcher diese gesamte(!) Kette stattfindet erlaubt dann bei der Berechnung, als auch den Filtern des Wandlungscodecs mehr oder weniger Farbspielraum.

Ich hatte schon mehrfach betont, bei reinem Wechsel auf höhere Bittiefe entstehen KEINE zusätzlichen Farbabstufungen(wenn man mal dithering/Filter ignoriert).
Wenn dem so wäre, könnte man(absolut überdreht,unrealistisch und auf Auflösung gemünzt) in eine Totale zoomen und die Stoffaser der Kleidung oder die Moleküle der Haut plötzlich sehen.
(das hätten wir zwar sehr gern, ist natürlich absoluter Quatsch)

Was aber passiert:
sowie man eine Berechnung durhführt, verändert/verschiebt man die jeweiligen Farbkanalwerte der Pixel.
Diese neuen Werte haben nun ein wesentlich feineres Gitter in das sie rutschen können und ergeben somit neue, vorher im Material nicht existente Farbabstufungen.
Diese neuen Werte kommen NICHT aus dem Original sondern entstehen durch die Berechnungen(die natürlich das Original als Ausgangspunkt nehmen,darauf sozusagen aufbauen).
Viele dieser neuen Werte haben auch in 8bit ihre Entsprechungen (Rundungen wenn man so will), womit der Vorteil in hohen Bittiefen ALLES zu rechnen klar auf der Hand liegt.

Wenn man NUR in 8bit arbeitet, fehlen die eben genannten feineren Farbabstufungen, der Rechenprozess nimmt grobere Werte, rechnet in groben Abstufungen, somit sind auch die Ergebnisse grob.

Es ist auch zu beachten, daß wir hier mit digitalen Files arbeiten, keinem traditionellen Videosignal mehr und ALLES, auch eine Videobearbeitung im Schnitt(Dissolves,Blends,Overlays,Farbkorrekturen etc.) Berechnungen druchführt (selbst Softwareinterne Umwandlungen des Codecs in Farbkanäle zur Darstellung,Verarbeitung und zurück)


@dienstag_01

Jein (;

Wenn man NUR hard cuts schneidet und KEINE(absolut minimale) Farbkorrekturen oder Blends/Merges/Filter etc. durchführt und für Youtube o.Ä. arbeitet, dann "by all means", do it in 8bit.
(ehrlich gesagt, ist für Youtube auch mehr in 8bit machbar, der codec Zerstört meistens weit mehr, als man bei Bittiefen dazugewinnt)

Sobald man darüber hinaus etwas machen, sollte immer in der höchstmöglichen Bittiefe gearbeitet werden,richtig.

In der Tat ist es auf ersten Blick nicht notwendig das Originalmaterial in eine höhere Bittiefe zu wandeln.
Hierzu muß man aber wissen(!), daß das Programm intern immer mit hohen Bittiefen rechnet sonst wird bereits beim reinen decodieren und recodieren des Codecs in niedriger Bittiefe mit groberem Dither und Farbabstufungen gearbeitet.
Meistens sind die Unterschiede bei nur einmaligem umcodieren vernachlässigbar, dem muß aber nicht immer so sein, gerade, wenn das Zielformat in anderen Codec gewandelt oder stärker komprimiert wird.

Zudem bedeutet das ja eigentlich, daß bei jedem Effekt auf den gleichen Clip die Software zunächst das 8bit Material in sagen wir 32Bit wechselt, darin rechnet und wieder in 8 bit rückwandelt.
Bei mehreren Effekten auf selbem Clip wird ja entweder zig mal Bittiefe hin und hergewechselt, wobei natürlich neben Renderzeit auch Qualität flöten geht, oder das Programm ist intelligent genug und concatenated das ganze zu einem Arbeitsgang:
8bbit auf 32bit...Effekte,Effekte,Effekte...32bit auf 8 bit
Auch das muß man also genau wissen.
Wenn man dann ein Zwischenrendering macht, um wieder RT editing zu haben oder um den Clip an verschiedenen Stellen zu nutzen, liegt das Ding wieder nur in 8 bit vor (es sei denn man rendert das als 32Bit raus).
Auch hier hat man dann (Farb)qualität verloren, ganz zu schweigen bei weiteren Effekten auf den vorgerenderten Clip.

In diesem Zusammenhang sollte auch erwähnt werden, daß übliche Videocodecs zum Schneiden eigentlich ungeeignet sind, da unter anderem (grob ausgedrückt) Einzelbilder erst aus den Keyframes und Motionvektoren etc. errechnet werden.
(übrigens, auch hier ist interne Bittiefe von Bedeutung)

AVID MC und andere pro-Schnittsystme konvertieren daher grundsätzlich aus verschiedenen Gründen in ihr eigenes Format.

Es hat schon seine Gründe warum im pro Workflow das gesamte Material als Einzelbilder vorliegt, vorzugsweise nur lossless komprimiert.



Antwort von WoWu:

@Enrico

Wenn man NUR in 8bit arbeitet, fehlen die eben genannten feineren Farbabstufungen, der Rechenprozess nimmt grobere Werte, rechnet in groben Abstufungen, somit sind auch die Ergebnisse grob. Vielleicht vergisst Du, dabei, dass die "feinen Abstufungen bereits im Originalsignal vom Sensor (12-14 Bit) vorgelegen haben und dass die entstandenen 8 Bit das Resultat dieser "feinen Abstufung" ist.
Dass also solche Abstufungen nicht erst durch die Rechnung im NLE entstehen.
Wenn also das 8 Bit Signal einer Kamera bereits das feinstmögliche Resultat einer hoch spezialisierten Quantisierung und eines angepassten Mappings sind, warum sollten eine künstliche Verfeinerung der Schritte und eine erneute anschliessende Rückwandlung zu 8 Bit diese Ergebnisse verbessern ?

Du gewinnst keine neuen, zusätzlichen Signalwerte. Es ist die identische Menge, wie bei der ersten Wandlung von 12-14 Bit nach 8 Bit.

Es ist auch zu beachten, daß wir hier mit digitalen Files arbeiten, keinem traditionellen Videosignal mehr und ALLES, auch eine Videobearbeitung im Schnitt(Dissolves,Blends,Overlays,Farbkorrekturen etc.) Berechnungen druchführt (selbst Softwareinterne Umwandlungen des Codecs in Farbkanäle zur Darstellung,Verarbeitung und zurück) Das ist ja gerade das Leiden denn hätten wir es mit analogen Signalen zu tun, die einer Quantisierung erst zugeführt würden, hätte eine höherwertige Verarbeitung durchaus Vorteile.
Nicht aber im digitalen Umfeld -das von 8 Bit kommt- und können so nicht einmal zu einem verbesserten Störabstand führen.
Insofern spielt es eine ganz wesentliche Rolle, ob es sich um ein, im Computer generiertes Signal handelt oder ein Signal, das aus einer Videokamera in 8 Bit kommt, denn da ist der entsprechend geringe Störabstand bereits Bildbestandteil und als Artefakte ins Bild "eingebacken" und vermeintlich bessere Störverhältnisse in der Nachbearbeitung können 1000 mal darunter liegen, sie verändern nichts mehr am eigentlichen Störabstand des Bildes.
Daher sind auch Computersignale für solche PSNR Vergleiche irrelevant.
Die reinen Berechnungen(Farbkorrektur etc.) haben zunächst nichts mit dem Codec zu tun Das war auch nicht mein Ansatz.
der codec Zerstört meistens weit mehr, als man bei Bittiefen dazugewinnt) Nicht der Codec zerstört es denn H.264 ist auch z.B. für 10 Bit nutzbar.
Es ist die falsche Auswahl der verwendeten Tools und ggf. eine zu geringe Datenrate.
Solche pauschalen Aussagen sind untauglich, weil falsch.
sonst wird bereits beim reinen decodieren und recodieren des Codecs in niedriger Bittiefe mit groberem Dither und Farbabstufungen gearbeitet. Der Codec ist gar nicht in der Lage Dither hinzuzufügen, weil er gar nicht mit den Algorithmen ausgestattet ist und verändert auch nicht selbsttätig die Menge der Tonwerte.
Bei mehreren Effekten auf selbem Clip wird ja entweder zig mal Bittiefe hin und hergewechselt, wobei natürlich neben Renderzeit auch Qualität flöten geht, oder das Programm ist intelligent genug und concatenated das ganze zu einem Arbeitsgang:
8bbit auf 32bit...Effekte,Effekte,Effekte...32bit auf 8 bit
Auch das muß man also genau wissen. Das ist nicht ganz so, denn bei einer Wortbreite von z.B. 32 Bit werden alle Rechnungen, z.B. ein 8 Bit Effekt und ein 16 Bit Effekt durchgeführt, und erst bei Erreichen der Wortbreite, also 8+16+8 (3 Effekte oder 2 16er oder 1 32er Effekt) wird das LSB abgeschnitten.
Die Rechengenauigkeit geht also gleichwohl auch verloren, wenn die Wortbreite erreicht bzw. überschritten wird.

Auch hier hat man dann (Farb)qualität verloren, ganz zu schweigen bei weiteren Effekten auf den vorgerenderten Clip. Nicht nur da, auch bei 32 Bit Verarbeitung geht über die Rundung und das Abschneiden des letzten Bits Genauigkeit verloren.
In diesem Zusammenhang sollte auch erwähnt werden, daß übliche Videocodecs zum Schneiden eigentlich ungeeignet sind, da unter anderem (grob ausgedrückt) Einzelbilder erst aus den Keyframes und Motionvektoren etc. errechnet werden.
(übrigens, auch hier ist interne Bittiefe von Bedeutung) Was willst Du uns damit sagen ... keinen Codec zu benutzen oder alles als aus Komputeranimation zu machen ?
Leider leben wir in einer Welt der Datereduktion und ob wir Qualität beim Schnitt durch die Wandlung verlieren oder bereits bevor wir mit dem Schnitt beginnen, in einer Wandlung, ist eine Frage des geringeren Übels.
Es hat schon seine Gründe warum im pro Workflow das gesamte Material als Einzelbilder vorliegt, vorzugsweise nur lossless komprimiert. Die Einzelbilder, also das Bildformat hat nichts mit Encodingeigenschaften zu tun und auch "eigene Codecs" bestehen aus den "alten Bekannten", etwa MPEG2 bei ProRes, mit der alten DCT.

Und "lossless" heisst nicht anderes, als dass durch hohe Datenraten andere, z.Tl. weniger verlustbehaftete Tools angewandt werden.
Das macht auch unheimlich Sinn, wenn man von einem hoch komprimierten Codec kommt, deren wesentliche Inhalte bereits reduziert sind. :-((

Und ich kann auch nicht so ganz das Gerede über BLUR nachvollziehen.
Wenn ich Bilder oder teile meines Contents mit Unschärfe überlagern muss, um einen andern Fehler zu verdecken dann stimmt doch irgend etwas im Workflow nicht.
Mein Ansatz liegt nicht darin, meine Bilder schlechter zu machen, damit man den Fehler nicht sieht, sondern darin, möglichst gute Bilder zu erzeugen.
Blur gehört ausgesprochen nicht dazu.



Antwort von otaku:

@enrico

ne dein beispiel ist nicht richtig. wolfgang schreibt ja auch das bei vfx anwendung es durchaus sinn machen kann das bild hoch zu mappen, lass deinen blur raus und das ergebniss kann total anders ausgehen.
wenn du 8bit auf 16bit mapst ist es immer noch 8bit, wenn du es aber blurst wird es 16bit.

beim keyen von 8bit h268 mache ich ja das gleiche - ich mappe auf 16 oder 32 bit - wandele rgb in yuv - blur auf u und v - wandlung zurueck auf rgb und dann erst kommt der key, funktioniert weil ich meiner farbe mehr abstufungen hinzu fuege. ist legitim, hat aber wie wolfgang ja sagt nichts mit dem originalbild zu tuen.

wolfgang sagt ja nicht das kann man nicht machen, oder es macht keinen sinn, er sagt nur man naehert sich dadurch dem original nicht an sondern man erzeugt was neues und anderes.



Antwort von WoWu:

Man kann für die Bearbeitung diverse Schritte einbringen, bis hin dazu, mit illegalen Farben zu arbeiten. Geht alles und wenn es den Workflow vereinfacht, umso besser.
Nur sollte man einen 8 Bit Preview im Auge behalten, um rechtzeitig zu erkennen, wo man hinterher landet und das nicht erst beim Kunden feststellen muss.



Antwort von EnricoPerei:

Und ich kann auch nicht so ganz das Gerede über BLUR nachvollziehen. Blur wird entweder generell als Effekt (z.B. auch im Glow) genutzt oder "versteckt" sich grob gesagt als Filter in Transformationen, Resizing und vielem Anderen und ist einer, bei dem zusätzliche Bittiefe viel bringen kann.

Zudem kann man eben bei gerade niedrigen Bittiefen auftretendem Banding (wie bereits vor Ewigkeiten gesagt, passiert das auch in hohen Bittiefen) dieses korrigieren.
Es ging ja letztlich hier darum, BANDING zu bekämpfen.
Es macht halt oft die Kombination aus verschiedenen Effekten aus und ist nicht undbedingt auf eine einzelne Rechnung rückführbar.

Beim beliebten DOF existieren sehr unscharfe Bereiche, die mitunter schnell auseinanderfallen.
Hier einen Blur (oder korrekteren Defocus) drüberzuziehen hilft dann enorm, ohne die vorhandene Bildinformation sonderlich zu (zer)stören.

Und das wir in der Post Probleme fixen ist ja nichts Neues und hat nicht unbedingt etwas mit schlechtem Workflow zu tun.
(wobei man durchaus ein 8bit Quellformat als schlechten Workflow bezeichnen könnte...)

Ehrlich gesagt, ermüdet mich die Diskussion hier, da wir uns arg im Kreis drehen.
Ich könnte wieder auf eine Reihe Comments eingehen, aber die Texte werden hier immer länger...

Ich rede hier auch schon seit mehreren Posts davon, daß ich mich nicht dem Original nähere oder "verlorengegangene Farbabstufungen wiederfinde", warum wird das noch immer erwähnt?

Das Ganze ist auch nicht auf VFX beschränkt, man kann das garnicht mehr so abtrennen, denn vor allem im Semipro und Amateurbereich finden beim Editing auch viele Berechnungen statt, bei denen die Bittiefe relevant ist.
Ganz zu schweigen von Pro-Cuttern, die ihre neuen Plugins zum Besten geben...
Ich cutte seit Ewigkeiten selbst auch und sehe hier genau die Problembereiche.
Nicht zuletzt bieten ja NLE's jede Menge Filter und andere Effekte an (ja selbst ein Overlay), die im Grunde dann schon in den Bereich VFX einzuordnen wären.
(Stichwort eierlegende Wollmilchsau)

Wenn man NUR in 8bit arbeitet, fehlen die eben genannten feineren Farbabstufungen, der Rechenprozess nimmt grobere Werte, rechnet in groben Abstufungen, somit sind auch die Ergebnisse grob. Vielleicht vergisst Du, dabei, dass die "feinen Abstufungen bereits im Originalsignal vom Sensor (12-14 Bit) vorgelegen haben und dass die entstandenen 8 Bit das Resultat dieser "feinen Abstufung" ist. Das vorliegende Material, mit dem wir nun arbeiten ist in 8 Bit.
Wie und woraus es gewonnen wurde, ist absolut unerheblich.
Die neuen Abstufungen haben doch keine Korrelation zu denen, die vor dem Erstellen des 8Bit Bildes existierten.
(wenn man auch genau genommen, zumindest Teilweise diese rückrechnen/interpolieren könnte, so ist es doch nicht das, was ich sage!!)

Ich glaube hier ist ein Grundsätzliches Verständnisproblem, das möglicherweise auch aus Vermengung von verschiedenen technischen Ansätzen, Informatik und Bildverarbeitung herrührt.
(wir reden mittlerweile einfach von zu vielen unterschiedlichen,wenn auch mit einander verbundenen Dingen und mit jedem neuen Post wird der Wust immer größer)
Dass also solche Abstufungen nicht erst durch die Rechnung im NLE entstehen.
Wenn also das 8 Bit Signal einer Kamera bereits das feinstmögliche Resultat einer Unterabtastung sind, warum sollten eine künstliche Verfeinerung der Schritte und eine erneute anschliessende Rückwandlung zu 8 Bit diese Ergebnisse verbessern ? Das 8bit Resultat aus der Kamera ist das feinstmögliche, aus dem Bildgewinnungsprozeß(inkl.des oft enormen komprimierens), NICHT aus dem nun in der Post folgenden Bearbeitungsprozeß!!!
Denn sehr wohl, wie ich bereits ausgeführt hatte, fügen Berechnungen potentiell neue Farbabstufungen hinzu (die noch nichteinmal in der Kamera aufgenommen wurden, da dort die jetzige post Berechnung nicht angewendet wurde)
Dies ist wie gesagt, keine neue Bildinformation, sondern feine Berechnungsinformation und hat auch NICHTS mit den realen Gegebenheiten zu tun, die aufgenommen oder aus optisch/technischen Gründen nicht aufgenommen werden konnten!

Warum Du die Kamera nun beimengst und dieses ewige Mißverständnis um die "magische" Erzeugung von Bildinformation, das ich zig mal geklärt habe, noch immer erwähnt wird, ist mir schleierhaft.

Auf Deine Comments zum Codec möchte ich nun nicht eingehen, da auch dies,wie ich bereits gesagt habe von den (Effekt-)Berechnungen und den Bittiefen getrennt zu sehen ist und nur noch mehr Textlänge brächte.

Nur soviel: In diesem Zusammenhang sollte auch erwähnt werden, daß übliche Videocodecs zum Schneiden eigentlich ungeeignet sind, da unter anderem (grob ausgedrückt) Einzelbilder erst aus den Keyframes und Motionvektoren etc. errechnet werden.
(übrigens, auch hier ist interne Bittiefe von Bedeutung) Was willst Du uns damit sagen ... keinen Codec zu benutzen oder alles als aus Komputeranimation zu machen ?
Leider leben wir in einer Welt der Datereduktion und ob wir Qualität beim Schnitt durch die Wandlung verlieren oder bereits bevor wir mit dem Schnitt beginnen, in einer Wandlung, ist eine Frage des geringeren Übels. ...ehrlich?
Weißt Du echt nicht, was ich damit meinte, obwohl ich es auch noch ausgeführt hatte oder füttere ich den Troll?

Scrubbe mal einen üblichen Codec oder springe zu einem Frame.
Du wirst (vor allem bei höheren Datenraten/Auflösungen) Ruckler feststellen, die unter Anderem daher kommen, weil das System erst aus den Keyframes und anderen Informationen das Bild ERRECHNEN muß.
(Je besser der Rechner, desto schneller passiert das natürlich...)

Liegen die Sequenzen als Einzelbilder vor, müssen sie nur geladen und ggf.decodiert werden, ergo besser geeignet zum editieren.

Zudem wird durch das Speichern in Einzelbildern der ganze Kompressionsmüll über Motionvektoren,GOPs Keyframes etc. umgangen.
MJPEG beispielsweise ist ein älterer Video Codec, um zumindest dies zu umgehen.

...und in der Tat sollten diese Einzelbilder als lossless compressed oder
uncompressed (eigentlich unnötig) vorliegen.

Dies ist nunmal ein wichtiger Punkt, um ab(!) dem Capturen,schon beim Speichern von der Kamera, in lossless compressed Einzelframes die bestmögliche Qualität zu erhalten.
Nur so erhält man die zumindest technisch bestmöglichen Bilder, von denen Du, ja wir alle sprechen.
Nur so funktioniert das im wirklich professionellen Workflow.

Natürlich wird das bereits Codec komprimierte Material nicht besser, wenn man es nun als Bildersequenz speichert.
Ich habe auch nicht gesagt, daß man seine iPhone Clips so speichern soll, obwohl es dem Gurkenmaterial auch nicht schaden kann...
...ernsthaft, wo sind wir hier?
Noch habe ich gesagt, daß dies bei weniger anspruchsvollem Zielformat gemacht werden soll, aber höhere Bittiefen sind nunmal ein Faktor zu höherer Qualität, unabhängig ob es ein Amateur, Semipro oder Profi macht.

Mit "lossless" ist natürlich gemeint, daß mathematisch keine Information verlorengeht, im Gegenteil zu lossy compression.

Im übrigen meinte ich, daß der Bildqualitätsgewinn, den wir bei hohen Bittiefen unter Umständen bekommen durch den bei Youtube verwendeten Codec untergeht, da dieser weitaus schlimmere Dinge mit unserem Material macht.

...und mir wurde vorgeworfen, nicht richtig verstanden/gelesen zu haben...

Ich wollte doch nicht Codecs dissen, entschuldige, wenn ich Dir zu nahe getreten bin.
Bin weder Gegner noch verfechter von Codecs.
Sie sind oft nötig, man muß aber auch wissen, dass jeder noch so großartige (auch egal in welcher Bittiefe) lossy Codec (auch der von Red) Originalinformation zerstört und eine mehr oder weniger akkurate Schätzung darstellt.
Sorry, das ist nunmal eine RICHTIGE Aussage.

Meine Güte....
Du gewinnst keine neuen, zusätzlichen Signalwerte. Es ist die identische Menge, wie bei der ersten Wandlung von 12-14 Bit nach 8 Bit. Es ist eine ganz andere(!) Datenmenge, denn durch Berechnung verändere/verschiebe ich,füge hinzu/nehme weg
Da nur 8bit vorliegen hat der Algorithmus natürlich auch keine Kenntnis über die in der Kamera vorliegenden Daten und "Rückberechnet" die auch nicht.
Und nochmal, Du gewinnst neue Signalwerte, da Deine mathematische Operation Dein Signal verändert und dieses dann beim Wechsel in niedrigere Bittiefe "neu abgetastet" wird.

...nun habe ich mich doch wieder zu einzelcomments hinreißen lassen (; und es ist für mein Geschmack wieder viel zu viel Text entstanden...
...ich lasse es lieber...
...und entschuldige mich für den uninteressanten Roman

Bei dem ganzen hin und her sind wir noch nichteinmal richtig auf float eingeganen, bei dem ein noch größerer Farbspielraum für die Post(berechnungen) entsteht und welcher unter anderem auch clippingprobleme(nur bei Berechnungen, NICHT beim Capturen) meist löst.

Denn um es nochmal zu sagen, 32bit float ist momentan die Bittiefe in der Post stattfinden sollte.

Warum und überhaupt, daß ich diese Grundregel der Postproduction hier teilweise verteidigen/rechtfertigen muß entzieht sich meinem Verständnis und ich habe auch keine Lust mehr darauf !

Ich bin ja nun wirklich nicht der Bittiefenhüter der Welt.

Bei wem sein bisheriger Workflow funktioniert der kann das doch BITteschön auch so weitermachen.


Wir sind hier ohnehin derart in die Metaphysik der mathematischen Esoterik abgerutscht, daß man vergessen hat, daß die meisten, die nicht vom Fach sind und die klötzchenkomprimierte Videos auf ihrem Handy anschauen sich fragend an den Kopf fassen, was das denn für eine Obsession ist, der wir frönen...

Ich schau' mir jetzt erstmal Katzenvideos an...



Antwort von WoWu:

Ich lasse es -auch- sein. Da kommst Du mir sehr entgegen. Vielen Dank.

Wir unterscheiden uns einfach darin, dass es mir auf eine mö&#65532;glichst genaue Reproduktion der Kameraaufnahme ankommt und Dir darum, Bilderfehler, z.B. durch Blur, also durch Unschärfen im Bild, zu kaschieren.
(Um damit wieder zum Ausgangspunkt des Threads zurück zu kehren)

Das sind zwei unterschiedliche Ansätz.

Unschärfen im Bild, also z.B. Blur betrachte ich bereits als Fehler-per-se.
Und einen Fehler durch einen andern zu verdecken ist nicht mein Ding.

Daher werden wir hier keinen gemeinsamen Nenner finden.
Es ist offensichtlich eine Definitionsfrage, ob man eine möglichst genaue Kamerareproduktion als gutes Bild ansieht, oder ein repartiertes Bild.

Mein Ansatz liegt in der Vermeidung, Deiner in der Verdeckung.
Beide Wege führen,- wenn auch zu unterschiedlichen- Zielen.



Antwort von prime:

Wir unterscheiden uns einfach darin, dass es mir auf eine mö&#65532;glichst genaue Reproduktion der Kameraaufnahme ankommt und Dir darum, Bilderfehler, z.B. durch Blur, also durch Unschärfen im Bild, zu kaschieren. Huh? Hier geht es einfach darum:
Soll das Bild stark gefiltert werden dann hohe Bittiefe verwenden.
Soll das Bild nicht gefiltert werden dann ursprünglich Bittiefe behalten.
Es geht um keine Kaschierung von Fehlern im Ausgangsmaterial (abgesehen von der Frage des 700D-Posters). Unschärfe war einer der Beispiel-Filter bei denen das Endergebnis (eindeutig) profitiert wenn man nicht geizt mit der Farbtiefe BEIM bearbeiten. Ja natürlich wird damit Ursprungsmaterial nicht gleich HDR oder whatever.
(Um damit wieder zum Ausgangspunkt des Threads zurück zu kehren) Der Ausgangspunkt des Threads war ein anderer. Da ging es um synthetisches (Computer generiertes) Material. Das kann durchaus extrem hohe *ECHTE* Farbtiefe haben.
Unschärfen im Bild, also z.B. Blur betrachte ich bereits als Fehler-per-se.
Und einen Fehler durch einen andern zu verdecken ist nicht mein Ding. Darum geht es doch gar nicht.
Mein Ansatz liegt in der Vermeidung, Deiner in der Verdeckung. Wie gesagt - starkes Filtern in der Post bei 8bit führt zu Banding, das kann man vermeiden in dem man bei 16/32bpc arbeitet. Das Endergebnis ist dann immer noch besser als direkt 8bit -> Filter -> 8bit.
Wenn dem so wäre, könnte man(absolut überdreht,unrealistisch und auf Auflösung gemünzt) in eine Totale zoomen und die Stoffaser der Kleidung oder die Moleküle der Haut plötzlich sehen. Nichts für ungut aber da irrst du dich leider. Ich habe schon oft im (amerikanischen) Serien/Filmen gesehen wie so lange gezoomt wird bis der Täter erkennbar ist.. das Zauberwort heisst hier "Enhance"...

;-P



Antwort von WoWu:

Dann hast vermutlich Teile des Threads nicht oder zu flüchtig gelesen... Vor allem, wenn die Farben nicht direkt nebeneinander liegen und wenn man Farbkorrekturen oder z.B. Blur benutzt, werden vollkommen andere Werte für den Übergang zwischen mehreren Farbabstufungen berechnet.
Diese sind dann beim Export in 8 bit zwar wieder grober, aber dennoch unterschiedlich zum reinen, groben 8 bit Processing. Man nehme "_8bit-original.0000.tga" und
1.
Blur = 5.0 (gaussian)
2.
Gamma = 1.07407.... Blur wird entweder generell als Effekt (z.B. auch im Glow) genutzt oder "versteckt" sich grob gesagt als Filter in Transformationen, Resizing und vielem Anderen und ist einer, bei dem zusätzliche Bittiefe viel bringen kann.
Aber durch Wiederholung werden Behauptungen auch nicht zu Fakten und zur Klärung tragen solche Wiederholungen auch nicht bei.: Das Endergebnis ist dann immer noch besser als direkt 8bit -> Filter -> 8bit.



Antwort von prime:

Dann hast vermutlich Teile des Threads nicht oder zu flüchtig gelesen... Falsch, was Enrico geschrieben hat ist sehr eindeutig und verdeutlicht was er ewig versucht hier zu erklären.
Effekt (z.B. auch im Glow) Da zitierst du die wichtige Stelle selber und trotzdem verstehst du es nicht?
Starkes Filtern, z.B. als Effekt profiert von hohe Farbtiefe. Komm mal weg von der Schiene das wir Fehler im Ausgangsmaterial entfernen wollen. Davon redest nur du und der 700D-Mensch.
Aber durch Wiederholung werden Behauptungen auch nicht zu Fakten: Das ist eine harte Aussage... Enrico hat Bilder gepostet - sind ziemlich eindeutig. Also die hier:
zum Bild

processed in 16 bit, exported to 8 bit

zum Bild

original

zum Bild
Meinst du er hat sie manipuliert? Kannst du gerne nachkochen und deine Ergebnisse posten.



Antwort von WoWu:

Wir "kochen" Bilder in HD seit über 10 Jahren.
Zeit genug, nicht auf fremde Gerichte angewiesen zu sein, von denen man die Zutaten nur vom "Hörensagen" kennt.
Und von denen man auch nicht weiss, ob die Bearbeitung aus den Programmen auch für alle Software-NLEs Gültigkeit haben.
Grafikprogramme unterscheiden sich bekanntlich deutlich von NLEs.

:-) Nichts für Ungut, aber Enrico ist auch nicht der Einzige, der Erfahrungen sammeln konnte.

Nachdem aber nun offenbar nicht wirklich festzumachen ist, warum sie voneinander abweichen, wir aber unsere Bilder nicht so extrem verfärben müssen, um überhaupt Effekte sichtbar zu machen, bleibe ich bei der Methode, möglichst im Workflow bereits Fehler zu vermeiden, die ich hinterher dann erst gar nicht bearbeiten muss.
Mal ganz abgesehen davon, dass wir ohnehin "Dynamic Rounding" einsetzen, um Rundungsfehler zu umgehen.

Jeder muss wissen, was für seinem Content am Besten ist.



Antwort von TheBubble:

Kannst du gerne nachkochen und deine Ergebnisse posten. Wende den Blur-Effekt mal versuchsweise zuletzt, also nach den Farbänderungen, an.