10Bit Master nach 8Bit exportieren = Banding

[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

[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

[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.

[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.

[WoWu]

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

[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

[dienstag_01]

Dazu brauchst Du aber keine 32 Bit.

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

[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!

[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?

[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 ?

[WoWu]

@Enrico

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

[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...

[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.

[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)


original in 8 bit:


processed in 8bit:


processed in 16bit, exported to 8 bit


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.

[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.

[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.

[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?

[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 ?!

[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.

[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.

[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?

[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.

[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 ;-)

[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.

[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?

[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.

[otaku]

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

[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

processed in 16 bit, exported to 8 bit

original


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.

[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.

[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.

[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.

[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...

[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.

[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

[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.