Logo Logo
/// 

upsampling von 8bit auf 10bit erkennen - wie?



Noch was unklar? Dann in unserem Forum nachfragen
Zum Original-Thread / Zum Postproduktion allgemein-Forum

Frage von Banana_Joe_2000:


Hi,

kennt jemand eine Möglichkeit, upgesampletes Material zu identifizieren? Also, wenn ein Videoclip der ursprünglich 8Bit war nun einfach als 10 bit exportiert wurde?

Unbearbeitet exportiert müsste der Clip dann ja 2 sinnfreie bits mitschleppen...

Danke für hilfreiche Hinweise im Voraus,

banana



Antwort von Roland Schulz:

Denke das wird unmöglich sobald jemand beim Grading auf 10bit rausgerendert hat.
Bei unverändertem Material könnte man das vielleicht noch irgendwie über die LSB"s rauskriegen.

Ich z.B. rendere mein 8bit a6500 Material als 10bit raus und habe so weniger Verluste beim Grading. Sinnvoll ist das deshalb, da es heute Möglichkeiten gibt 10bit auch direkt wiederzugeben, z.B. als HEVC Main10 auf nem halbwegs modernen Fernseher oder über ne nVidia Grafikkarte.
Wo eine 8bit Aufnahme in eine 8bit Ausgabe nach dem Grading schnell mal Banding z.B. im blauen Himmel erkennen lässt ist das als 10bit Ausgabe kein wirkliches Thema mehr. Wird die Datei aber nur in 8bit wiedergegeben sieht man den ganzen Mist trotzdem wieder.
Richtiges Nachweisen halte ich aber trotzdem für schwierig und wenn es möglich ist würde ich auch immer die Aufnahme in 10bit bevorzugen.



Antwort von mash_gh4:


Denke das wird unmöglich sobald jemand beim Grading auf 10bit rausgerendert hat.
Bei unverändertem Material könnte man das vielleicht noch irgendwie über die LSB"s rauskriegen.

im wesentlichen muss ich hier roland zustimmen. in einer idealen welt bzw. bei ganz primitiven umsetzungsformen, würde sich das relativ einfach überprüfen lassen, nicht aber in jenen formen, mit denen man es normalerweise zu tun hat.

aber z.b. bei RAW-Photos od. RAW-videomaterial, wo man es gewöhnlich mit verlustfreie komprimierten daten zu tun hat, die häufig in formate geschrieben werden, die prinzipiell auch die aufzeichnung höherer bittiefen erlauben, kann man tatsächlich auch in der praxis den ersteren fall antreffen. dort ist es dann wirklich so, dass die letzten stellen (least significant bit) der entsprechenden zahlendarstellung in binärform nur nullen enthalten. das kann man sehr einfach und effizient überprüfen, wenn man alle enthaltenen werte mit einer bitweisen 'oder' operation zusammenzieht. zeigen sich dann im resultat in den letzten stellen nullen, ist das ein recht zuverlässiger hinweis darauf, dass mögliche werte, zumindest im verwendeten ausgangsbild, tatsächlich nie benutzt wurden.

aber diese extrem einfach überprüfung versagt, wenn die werte in der verarbeitungskette in fließkommazahlen umgewandelt wurden, in ihrem umfang gespreitz od. gestaucht wurden, mit rundungsfehlern behaftet sind oder gar komplexe verlustbehaftete kompressionstechniken genutzt wurden. hier kann man am ehesten noch an hand der statistischen verteilung der werte noch irgendwelche hinweise auf ihre ursprüngliche ausgangsgenauigkeit finden. man betrachtet dazu das 'histogramm' -- wobei hier nicht so die entsprechende kurvenanzeige in den div. videoverarbeitungsprogrammen gemeint ist, sondern wirklich deren zugrundeliegende techn.-math. funktion, weil man in deren praktischer umsetzung fast immer vereinfachungen vorgenommen werden, die eine derart exakte beurteilung, wie sie im vorliegenden fall nötig wäre, weitestgehend verunmöglichen. jedenfalls kann man an hand der werteverteilung u.u. erkennen, ob sich das verhältnis einer bestimmten anzahl von tatsächlich vorgefundenen werten gegenüber dem rest signifikant unterscheidet. eine wichtige rolle, spielt aber auch hier wieder das genutzte ausgangsbild -- ein testbild mit farbbalken eignet sich dazu weit weniger als irgendwelche ganz unscharfe aufnahmen, die im sinne von fließenden helligkeitsverläufen große wertebereiche gleichmäßig abdecken.

die variante, die ich persönlich für noch zielführender halten würde, ist wieder einen schritt komplizierter:
man betrachtet dazu nicht mehr so sehr die absoluten werte selbst, sondern die differenzen zw. nebeneinanderliegenden pixen -- also gewissermaßen: die erste abgeleitete funktion. damit ist zwar auch erst ein anfang gesetzt, der dann in ganz ähnlicher weis wie im letzten abschnitt noch weiter untersucht werden müsste, aber man kann auf dieser weise die wertesprünge über den gesamten ursprünglichen ausgangsbereich viel besser zusammenfassen bzw. eben auf genau diese gesuchte charaktersitik hin analysieren. jedenfalls lässt sich damit vermutlich auch in der praxis mit vertretbarem aufwand herausfinden, mit welchen kleinsten wertesprüngen man es zu tun hat.

ich fürchte zwar, dass dass diese erklärung für den ursprünglich fragenden insofern ein bisserl unbefriedigend wirken dürfte, als sie sich auf mittel stützt, die man in gebräuchlichen videobearbeitungsprogrammen nicht fertig vorfindet. es ist aber nicht sonderlich kompliziert, sich mit bild- und videodaten auf dieser etwas technisch-mathematischen weise zu spielen. z.b. numeric python bzw. die image processing routinen im SciPy bieten hier einen ziemlich erträglichen einstieg. damit kann man sich dann auch, wenigstens vom elementaren grundverständnis, an kompliziertere sachen herantasten. machine learning modelle zur auswertung visueller information, wie sie mich zur zeit ziemlich interessieren, bauen alle auf derart abstrakt wirkenden zugängen auf.

was aber die praktische relevanz derartiger 8-vs.-10bit nachweise betrifft, habe ich ohnehin ganz andere zweifel. ich schätze zwar möglichst unverfälschtes und genaues videoausgangsmaterial und die damit verbundenen spielräume in der nachbearbeitung auch sehr, halte aber die notwendigkeit einer umgekehrten bittiefenreduktion durch sauberes dithering in der abschließenden ausgabe und übertragung in der praxis für fast noch bedeutender. in wahrheit ist es nämlich viel öfter einer mangelhaften umsetzung dieses notwendigen abschließenden aufbereitungsschritts zuzuschreiben, wenn man störendem banding in realen videoproduktionen begegnet.








Antwort von wolfgang:

Bei einer sehr starken Spreizung des Luminanzbereiches erkennt man bei 8bit in einem HistogrammHistogramm im Glossar erklärt schneller Lücken als bei 10bit. Vielleicht funktioniert das zumindest als Hinweis.



Antwort von Alf_300:

Noch garnicht lange her, da war man sich hier im Forum einig, dass solche aufgeblasene Videos von den TV-Anstalten erkannt und abgelehnt werden.



Antwort von dosaris:


... eine Möglichkeit, upgesampletes Material zu identifizieren? Also, wenn ein Videoclip der ursprünglich 8Bit war nun einfach als 10 bit exportiert wurde?

Unbearbeitet exportiert müsste der Clip dann ja 2 sinnfreie bits mitschleppen...

kommt drauf an in welcher Codierung das vorliegt.

Uncompressed kann man wohl beim durchfiltern "unten" 2 BitBit im Glossar erklärt anhängen.
Da steht dann immer dasselbe pattern drin.

Bei compressed 8Bit-Vorlage läuft das ja dann auf ein re-encoding hinaus.
In den unteren beiden (neuen) Bits hätte man dann aber den Rundungsfehler des
bisherigen (8Bit-)LSB als Pseudo-Info drin, was aber nur die Qualität eines Rauschens hat.
Es erschwert aber die Identifizierung bei der Analyse.

Im realen Leben kannste mal mit den QCtools da reinsehen.
Man kann damit in die Auflösung hinein zoomen und
somit die Helligkeitslevel "horizontal" einschätzen.



Antwort von mash_gh4:


Bei einer sehr starken Spreizung des Luminanzbereiches erkennt man bei 8bit in einem HistogrammHistogramm im Glossar erklärt schneller Lücken als bei 10bit. Vielleicht funktioniert das zumindest als Hinweis.

ja -- prinzipiell hast du da schon recht, und so wird das in der regel auch häufig vor augen gefüht.
ich hab das deswegen in meiner erklärung oben ein bisserl in frage gestellt, weil mir erst im zuge eigener umsetzungsversuche an histogram- und waveform-scopes für freie software so richtig bewusst geworden ist, wie problematisch sich die technischen rahmenbedingungen derartiger messanzeigen darstellen. abgesehen davon, dass histogramm-berechnungen sich unheimlich schwer parallelisieren lassen, bzw. sich nicht wirklich gut für effizente umsetzungen auf der GPU eignen -- und deswegen in der praxis sehr oft zu gunsten fließender echtzeitabspielbarkeit bzw. befriedigenderen video-wiedergabe vereinfacht werden --, stellt sich hier vor allem das problem der zu wählenden bin size, also der zu nutzenden werteauflösung. letzters führt dazu, dass man in den den histogrammanzeigen gängiger videobearbeitungsprogramme diese kammartigen resultate, aber auch hellere horizontale striche in den waveforms, immer mit einiger gewissen vorsicht genießen muss. sie müssen nämlich nicht unbedingt immer nur von jenen wertehäufungen stammen, die wir im hier angesprochnen fall suchen, sondern können tlw. auch auch durch interferenzen im zusammenspiel mit den implementationsspezifischen grenzziehungen der bins verursacht sein. während dieses detail in anderen alltäglichen anwendungsfällen keine nennenswerte rolle spielt, können also entsprechende anzeigen in diesem speziellen fall leider doch manchmal auch in die irre führen.



Antwort von Jott:

Wird die Datei aber nur in 8bit wiedergegeben sieht man den ganzen Mist trotzdem wieder.

Nö. Fernsehen, DVD, Blu-ray - alles 8 BitBit im Glossar erklärt ohne Banding. Ist eine Frage der Verarbeitung. Im TV sehr oft auch von 8Bit kommend (XDCAM).



Antwort von Roland Schulz:


Wird die Datei aber nur in 8bit wiedergegeben sieht man den ganzen Mist trotzdem wieder.

Nö. Fernsehen, DVD, Blu-ray - alles 8 BitBit im Glossar erklärt ohne Banding. Ist eine Frage der Verarbeitung. Im TV sehr oft auch von 8Bit kommend (XDCAM).

Genau, ganz besonders im Fernsehen kommt oft nur Müll an - zudem auch mit Banding und besonders wenn wieder kämpfende N.... im Dunkeln laufen!!!

Hab das alles durch, a6500 in 8bit mit Farb-/Kontrastkorrektur in 8bit H.264 wieder raus und zack, Abrisse im blauen "Polfilterhimmel" :-(!!
Glaubst gar nicht wie dankbar ich GrassValley bin dass ich endlich ohne Umwege in 10bit aus der TimelineTimeline im Glossar erklärt in HEVC Main10 rendernrendern im Glossar erklärt kann, was der TV auch direkt versteht! Das sind Unterschiede, im Himmel, auf dem Wasser und auf sonst glänzenden Flächen!
Kann"s kaum erwarten dass ne a6700 hoffentlich auch UHD 10bit kann, zudem "sauber" (!!) aus nem recht ordentlichen APS-C Sensor!!

Wenn man direkt mit 10bit startet (aufnimmt) kommt man am Ende sicherlich auch mit 8bit schon ganz gut über die Runden - kann die a6500 aber nicht.



Antwort von Sheldon Cooper:



Nö. Fernsehen, DVD, Blu-ray - alles 8 BitBit im Glossar erklärt ohne Banding. Ist eine Frage der Verarbeitung. Im TV sehr oft auch von 8Bit kommend (XDCAM).

Genau, ganz besonders im Fernsehen kommt oft nur Müll an - zudem auch mit Banding und besonders wenn wieder kämpfende N.... im Dunkeln laufen!!!

Hab das alles durch, a6500 in 8bit mit Farb-/Kontrastkorrektur in 8bit H.264 wieder raus und zack, Abrisse im blauen "Polfilterhimmel" :-(!!
Glaubst gar nicht wie dankbar ich GrassValley bin dass ich endlich ohne Umwege in 10bit aus der TimelineTimeline im Glossar erklärt in HEVC Main10 rendernrendern im Glossar erklärt kann, was der TV auch direkt versteht! Das sind Unterschiede, im Himmel, auf dem Wasser und auf sonst glänzenden Flächen!
Kann"s kaum erwarten dass ne a6700 hoffentlich auch UHD 10bit kann, zudem "sauber" (!!) aus nem recht ordentlichen APS-C Sensor!!

dein genereller verbrauch an ausrufezeichen ist recht bemerkenswert



Antwort von Jott:

Wenn du meinst, Roland.



Antwort von Roland Schulz:


Wenn du meinst, Roland.

Meine ich! Liegt aber vielleicht auch an den TVs die bei einigen im Einsatz sind, das scheint nicht durchweg "High-End" Zeugs zu sein.
Auf nem recht hellen und kontraststarken, großen Display sieht man Banding auch viel eher als auf "flacheren" 32" Schirmen aus 4m.
Das ist bei mir auch erst mit dem aktuellen TV richtig aufgefallen. Früher mit der ~350cd Kiste war"s auch nur halb so schlimm.








Antwort von cantsin:

Nochmal zurück zur Ausgangsfrage:

Das Problem könnte sich auf der Kommandozeile erledigen lassen. Imagemagick kann die Anzahl der tatsächlich verwendeten Farben in einem Standbild anzeigen (mit dem Kommando "identify -format %k xy.tif"). Wenn man mit ffmpeg eine Videodatei in 16bit-TIFs extrahiert und diese dann mit imagemagick zu einem Bild ineinanderblendet, könnte der Output des "identify"-Kommandos Aufschluss über die tatsächliche Bittiefe geben.

Bei einem (nicht-überblendeten) Testframe aus einem eigenen Video kam ich übrigens auf knapp 170.000 individuelle Farben in der exportierten 8bit 4:2:04:2:0 im Glossar erklärt h264-Datei und 1,56 Millionen individuelle Farben in der exportierten 12bit DNxHR 4:2:2-Datei. (Kameramaterial war Blackmagic CinemaDNG.) Wenn die DNxHR-Datei aus 8bit h264 upgesampelt gewesen wäre, hätte es diesen Unterschied nicht geben müssen.



Antwort von Jost:



Nö. Fernsehen, DVD, Blu-ray - alles 8 BitBit im Glossar erklärt ohne Banding. Ist eine Frage der Verarbeitung. Im TV sehr oft auch von 8Bit kommend (XDCAM).

Genau, ganz besonders im Fernsehen kommt oft nur Müll an - zudem auch mit Banding und besonders wenn wieder kämpfende N.... im Dunkeln laufen!!!

Hab das alles durch, a6500 in 8bit mit Farb-/Kontrastkorrektur in 8bit H.264 wieder raus und zack, Abrisse im blauen "Polfilterhimmel" :-(!!
Glaubst gar nicht wie dankbar ich GrassValley bin dass ich endlich ohne Umwege in 10bit aus der TimelineTimeline im Glossar erklärt in HEVC Main10 rendernrendern im Glossar erklärt kann, was der TV auch direkt versteht! Das sind Unterschiede, im Himmel, auf dem Wasser und auf sonst glänzenden Flächen!
Kann"s kaum erwarten dass ne a6700 hoffentlich auch UHD 10bit kann, zudem "sauber" (!!) aus nem recht ordentlichen APS-C Sensor!!

Wenn man direkt mit 10bit startet (aufnimmt) kommt man am Ende sicherlich auch mit 8bit schon ganz gut über die Runden - kann die a6500 aber nicht.

Durch die Wandlung von H.264 auf H.265 wird noch mehr wegkomprimiert. Die Dateien werden ja kleiner und nicht größer. Bei zb ProRes422 ist das in der Regel umgekehrt.
Der Hinweis auf Wandlung in H.265 ist dennoch sehr gut. Davinci bietet das noch nicht an.



Antwort von Roland Schulz:


Durch die Wandlung von H.264 auf H.265 wird noch mehr wegkomprimiert.

Diese Behauptung ist grundsätzlich falsch, falsch und falsch!!
HEVC ist vom CodecCodec im Glossar erklärt effizienter als AVC, wie gut die Implementierung ist und ob weitere Verluste auftreten lässt sich so pauschal überhaupt nicht aussagen!

Weiterhin kann "HEVC" auch verlustfrei arbeiten was die Behauptung pauschal betrachtet als ebenfalls falsch darstellt!

Wir wollten zudem 8bit nach "Processing" zu 10bit exportieren, was dem verarbeiteten Ergebnis gegenüber einem 8bit Export zugute kommt.

HEVC MAIN10 erreicht eine größere Akzeptanz bei der Wiedergabe.
Viele UHD Standalone Mediaplayer bieten die Wiedergabe von 10bit HEVC, UHD Fernseher ebenfalls, nvdec unterstützt das, jedoch bietet kaum ein Player die Wiedergabe von AVC 10bit an.
Das war der Hauptgrund für den Vorschlag von HEVC Main10 - die Kompatibilität!
Der CodecCodec im Glossar erklärt hat aber erstmal überhaupt nichts mit dem Topic und dem Zusammenhang zu tun.



Antwort von Jost:



Durch die Wandlung von H.264 auf H.265 wird noch mehr wegkomprimiert.

Diese Behauptung ist grundsätzlich falsch, falsch und falsch!!
HEVC ist vom CodecCodec im Glossar erklärt effizienter als AVC, wie gut die Implementierung ist und ob weitere Verluste auftreten lässt sich so pauschal überhaupt nicht aussagen!

Weiterhin kann "HEVC" auch verlustfrei arbeiten was die Behauptung pauschal betrachtet als ebenfalls falsch darstellt!

Wir wollten zudem 8bit nach "Processing" zu 10bit exportieren, was dem verarbeiteten Ergebnis gegenüber einem 8bit Export zugute kommt.

Missverständnis: Selbstverständlich ist H.265 effizienter als H.264. Wäre es anders, könnte man die kleinen Speicherkarten nicht mehr weiter benutzen.
Die H.265-Datei wird dennoch kleiner als die H.264-Ursprungsdatei. Außerdem werden keine Sensordaten durch H.265 komprimiert, sondern eine bereits komprimierte H.264-Datei. Das ist eine Zweifach-Komprimierung.
Ich zweifele kein Stück daran, dass dadurch das Banding verschwindet.
Ob das Banding bleibt, wenn H.264 verlustfrei in H.265 gewandelt wird, bleibt auszutesten.



Antwort von Roland Schulz:


Missverständnis: Selbstverständlich ist H.265 effizienter als H.264. Wäre es anders, könnte man die kleinen Speicherkarten nicht mehr weiter benutzen.

"kleine Speicherkarten" schreiben heute
>200MB/s weg - das muss man erstmal "sinnvoll" gefüllt kriegen!
Glaube in der Praxis muss auch erstmal nen Encoder programmiert werden der die Theorie der höheren Effizienz auch tatsächlich nachweist.

Die H.265-Datei wird dennoch kleiner als die H.264-Ursprungsdatei. Außerdem werden keine Sensordaten durch H.265 komprimiert, sondern eine bereits komprimierte H.264-Datei. Das ist eine Zweifach-Komprimierung.
Ich zweifele kein Stück daran, dass dadurch das Banding verschwindet.
Ob das Banding bleibt, wenn H.264 verlustfrei in H.265 gewandelt wird, bleibt auszutesten.

Es geht doch überhaupt nicht darum dass Banding durch fünffache Umkomprimierung verschwindet oder nicht, das hat erstmal
überhaupt keinen Zusammenhang bzw. Einfluss!

Die ursprünglichen 8bit Abstufungen werden NICHT behoben oder verbessert, es wird lediglich der zusätzliche Verlust verringert der entstehen würde, wenn man 8bit in 8bit graden würde!
Die Zielwerte die durch die Transformation entstehen finden in einem 10bit Raster einen genaueren "Partner" als in einem 8bit Raster!
Das in 8bit vorhandene Banding wird einfach "nicht" noch weiter verstärkt - darum geht es!
Es bleibt am Ende immerhin ~8bit, wird nicht je nach Eingriff zu ~6-7bit degradiert.

Es gibt nur keine alternative Möglichkeit zu HEVC Main10 das als 10bit in der Senke auch wiederzugeben!



Antwort von wolfgang:

Es gibt immer eine andere Möglichkeit- nämlich gleich in 10bit zu Filmen. Ist ja heute keine Hexerei mehr.



Antwort von Roland Schulz:


Es gibt immer eine andere Möglichkeit- nämlich gleich in 10bit zu Filmen. Ist ja heute keine Hexerei mehr.

...geht nicht mit der Qualität einer a6500 aus dem "Handtäschchen" raus mit nem Einhandgimbal ;-)!!
Die a6700 oder wie auch immer sie heißen wird hat den Markt noch nicht erreicht.



Antwort von Funless:

Also wenn du wirklich so felsenfest davon überzeugt bist, dass das Nachfolgemodell der A6500 in 10Bit intern aufnehmen können wird, kann ich dir nur sagen: träum‘ weiter.



Antwort von mash_gh4:

manchmal kommen wir diese diskussionen hier im forum fast so vor, als würde ein haufen rotzlöffel im pausenhof herumstehen und sich mit irgendwelchen losgelösten werten auf quartett-karten gegenseitig zu übertrumpfen versuchen...

natürlich macht es sinn, höhere bittiefen als effiziente übertragungsvariante zu nutzen, um div. visuelle artefakte zu minimieren. so gesehen ist eine 10bit übertragung mit ihren feinen abstufen einfach einer geditherten 8bit variante, die sich nicht so gut komprimieren lässt, oder sonst sofort wieder diese unguten störungen hervortreten lässt, überlegen.

trotzdem sollte man das nicht überbewerten. man kann auch visuelle ausgesprochen befriedigende ausgaben unter beschränkung auf 8 od. gar 6bit pro farbkanal realisieren!

zur erinnerung: im druck auf papier begnügt man sich in der regel noch immer mit 1bit darstellungstechniken -- also auschließlich: farbe oder nicht-farbe -- im richtigen zusammenspiel mit geeigneten mitteln der rasterung wirkt das in handwerklich sauber umgesetzten trotzdem erträglich und weitestgehend frei von störenden stufen in den farbübergängen.








Antwort von Funless:

Ich persönlich benötige keine 10Bit (oder höher) Aufnahme, ich komme mit 8Bit bestens klar. Dieses ganze 10Bit (und höher) Geschwafel ist für mich nach dem Hautton Hype, dem Auflösungsporn und der Dynamic Ranger Mission einfach die aktuellste Trend-Sau die durch‘s Dorf getrieben wird.

Wenn die anderen hier andere Anforderungen/Wünsche haben und deswegen die o.g. Begehrlichkeiten wecken, dann ist es halt so. Nicht mein Problem.



Antwort von Roland Schulz:


zur erinnerung: im druck auf papier begnügt man sich in der regel noch immer mit 1bit darstellungstechniken -- also auschließlich: farbe oder nicht-farbe -- im richtigen zusammenspiel mit geeigneten mitteln der rasterung wirkt das in handwerklich sauber umgesetzten trotzdem erträglich und weitestgehend frei von störenden stufen in den farbübergängen.

Völlig richtig, nur haben die Birnen (Druck) eine weit über die Äpfel (UHD Darstellung) hinausreichende Auflösung ;-)!
Diese geht über die Auflösung zumindest meiner Augen hinaus und lässt den "Schwindel" unerkannt.



Antwort von wolfgang:

Der sinnlose Vergleich verschiedener Technologien bringt nur leider nix.

Entweder man meint dass man so Dinge wie Banding vermeiden will und mehr Spielraum in der Post mag, dann wählt man halt eine entsprechende Technologie aus passenden Sensor und Codec. Oder man wählt das eben nicht. Wo ist das Problem?



Antwort von mash_gh4:


Der sinnlose Vergleich verschiedener Technologien bringt nur leider nix.

diesen hinweis auf die drucktechnik hab ich nur eingeworfen, weil das dort üblichen rastern mit dem dithern in der elektr. bildverarbeitung sehr viel gemeinsam hat.

Entweder man meint dass man so Dinge wie Banding vermeiden will und mehr Spielraum in der Post mag, dann wählt man halt eine entsprechende Technologie aus passenden Sensor und Codec. Oder man wählt das eben nicht. Wo ist das Problem?

wie gesagt, schau dir einmal folgende ganz einfache erklärung an:

https://de.wikipedia.org/wiki/Dithering ... arbeitung)

und dann frag dich vielleicht, ob das bevorzugte videobearbeitungsprogramm deiner wahl irgendwelche vorkehrungen bzw. ausgabeaufbereitungsmöglichkeiten besitzt, um in diesem sinne auch deine schönen 10bit-produktionen auf gebräuchlichen 8bit-abspielgeräten ohne störendes bandig wiederzugeben?



Antwort von Roland Schulz:

...glaube wir schweifen ab - es ging darum ob nachgewiesen werden kann ob ein 8bit Video auf 10bit hochgerechnet wurde und ich würde Wolfgangs Vorschlag unterstützen, dass man es bei genauer Betrachtung an einem lückenbehafteten HistogrammHistogramm im Glossar erklärt erkennen müsste, da das "Processing" zwar neue Zwischenwerte treffen wird die in 8bit nicht existent wären, dazwischen aber weiterhin Lücken entstehen da zunächst keine Interpolation zwischen Pixeln vorgenommen wird.
Wenn man allerdings sowas wie nen BlurBlur im Glossar erklärt o.ä. über die Aufnahme drüberlegt ist man mit dem HistogrammHistogramm im Glossar erklärt auch wieder am Ende, dann würden tatsächlich Übergänge zwischen Pixeln bzgl. des "Farbtons" interpoliert und jeder Nachweis würde technisch unmöglich denke ich.
In ganz flachen Verläufen würde das zwar ggf. nach wie vor etwas auffällig aussehen, der technische Nachweis würde aber sehr schwierig.

...und nochwas: selbst wenn man 10bit in 10bit gradet entstehen Lücken (!) ;-) - jetzt brauchen wir nur noch jemanden der abschätzt wo es wie viele sein dürfen.

Wolfgang, hilft alles nix, einer von uns muss ne 16bit RED kaufen um zu zeigen dass es da über einen weiten Bereich mindestens 10bit bleiben ;-)! ...mach Du das, ich spare für nen 991.2 GT3 RS ;-)!



Antwort von cantsin:


Wenn man allerdings sowas wie nen BlurBlur im Glossar erklärt o.ä. über die Aufnahme drüberlegt ist man mit dem HistogrammHistogramm im Glossar erklärt auch wieder am Ende, dann würden tatsächlich Übergänge zwischen Pixeln bzgl. des "Farbtons" interpoliert und jeder Nachweis würde technisch unmöglich denke ich.
In ganz flachen Verläufen würde das zwar ggf. nach wie vor etwas auffällig aussehen, der technische Nachweis würde aber sehr schwierig.

Man würde das vor allem an Farbkanten bzw -säumen sehen, die dann ja nicht mehr scharf verlaufen, sondern ineinander geblendet sind. Da verhält sich aufgeblasene Farbauflösung prinzipiell nicht anders als aufgeblasene Pixelauflösung.



Antwort von Roland Schulz:

...das würde vor allem dann sichtbar wenn man dem Export nochmal ne starke Kontrastanpassung verpasst.

Ganz ehrlich, bei 8- in 10bit erkenne ich bei "humanen" Anpassungen kein Banding mehr - das gleiche bei 8 in 8 kann dagegen schon Probleme bereiten.



Antwort von mash_gh4:

Wenn man allerdings sowas wie nen BlurBlur im Glossar erklärt o.ä. über die Aufnahme drüberlegt ist man mit dem HistogrammHistogramm im Glossar erklärt auch wieder am Ende, dann würden tatsächlich Übergänge zwischen Pixeln bzgl. des "Farbtons" interpoliert und jeder Nachweis würde technisch unmöglich denke ich.

ja -- ich würde zu dem zweck ein ganz schwaches rauschen drüber legen (addieren), das nur genau diese (vier) möglichen werte, die in den lücken liegen, ausfüllt bzw. zufällig variiert. obwohl man das nicht sieht, wirkt sich das im zusammenspiel mit anderen vorangegangenen eingriffen am bild im übrigen auch sehr vorteilhaft aus, falls du es danach versehentlich doch einmal auf einem 8bit-ausgabegerät ansehen solltest. :)

ein blur alleine bewirkt leider genau das gegenteil. damit kann man, wenn keine vorkehrungen dagegen getroffen werden, in der tat ungute banding-artefakte hervorrufen oder verstärken. das tritt normalerweise, bzw. bei bildern direkt aus der kamera, kaum in dieser störenden weise in erscheinung, weil deren sensoren ja bekanntlich noch viel schrecklicher rauschen, oder eben findige kollegen sich hier etwas nützliches im zuge der datenaufbereitung aus den höher aufgelösten raw-daten des sensors einfallen haben lassen.



Antwort von Roland Schulz:


Wenn man allerdings sowas wie nen BlurBlur im Glossar erklärt o.ä. über die Aufnahme drüberlegt ist man mit dem HistogrammHistogramm im Glossar erklärt auch wieder am Ende, dann würden tatsächlich Übergänge zwischen Pixeln bzgl. des "Farbtons" interpoliert und jeder Nachweis würde technisch unmöglich denke ich.

ja -- ich würde zu dem zweck ein ganz schwaches rauschen drüber legen (addieren), das nur genau diese (vier) möglichen werte, die in den lücken liegen, ausfüllt bzw. zufällig variiert. obwohl man das nicht sieht, wirkt sich das im zusammenspiel mit anderen vorangegangenen eingriffen am bild im übrigen auch sehr vorteilhaft aus, falls du es danach versehentlich doch einmal auf einem 8bit-ausgabegerät ansehen solltest. :)

ein blur alleine bewirkt leider genau das gegenteil. damit kann man, wenn keine vorkehrungen dagegen getroffen werden, in der tat ungute banding-artefakte hervorrufen oder verstärken. das tritt normalerweise, bzw. bei bildern direkt aus der kamera, kaum in dieser störenden weise in erscheinung, weil deren sensoren ja bekanntlich noch viel schrecklicher rauschen, oder eben findige kollegen sich hier etwas nützliches im zuge der datenaufbereitung aus den höher aufgelösten raw-daten des sensors einfallen haben lassen.

Das Hinzufügen von Rauschen macht überhaupt keinen Sinn da das zunächst nur den nachgeschalteten Encoder unnötigt belastet und dieser bei (eventueller) Rauschfilterung (z.B. für geringe Zieldatenrate) genau in den urspünglichen Bereichen wieder zusammenfasst/integriert/denoised, damit die ursprünglichen Abrisse wieder auftauchen werden. Bereichsübergreifend werden bei dieser Methode keine Interaktionen durchgeführt.

Ein BlurBlur im Glossar erklärt ist das einzige was "ideal" "betrügt". Dazu den eigentlichen Track kopieren und nen "relativ großen" Blur-Bereich (Bildkonturen deutlich schwächen, Inhalt aber nach wie vor erkennbar lassen) wählen und mit ~0,4% (entspricht ~2 LSB/4 Inkrementen) dem ursprünglichen Track überlagern. Das wirkt dann ähnlich wie ein Bandingfilter.
Da der BlurBlur im Glossar erklärt bereits anwendungsintern in 10bit durchgeführt wird entsteht hier kein zusätzliches Banding.
Echte Bildinformationen sind in den letzten 2 LSB ohnehin nicht vorhanden, von daher schadet die Blur-Überlagerung mit 0,4% nicht!

Denke mit der 0,4% Blur-Methode wird es tatsächlich unmöglich nachzuweisen, dass das Ausgangsmaterial nur 8bit hatte.








Antwort von cantsin:

Qualitativ besser und eventuell noch unsichtbarer wäre ein temporales Entrauschen, wie es u.a. Neat Video anbietet, weil es die Farbwerte zwischen Frames in interpoliert, und das in der (größeren) Bittiefe der Timeline. Ev. sogar in Verbindung mit mashs Vorschlag: Leichtes (10bit-) Rauschen drüber als Dithering von Banding, dann temporales Entrauschen drüber, das ein Fake-10bit-Bild daraus glattrechnet.



Antwort von Roland Schulz:


Qualitativ besser und eventuell noch unsichtbarer wäre ein temporales Entrauschen, wie es u.a. Neat Video anbietet, weil es die Farbwerte zwischen Frames in interpoliert, und das in der (größeren) Bittiefe der Timeline.

NEAT Video arbeitet aber gar nicht in 10bit ;-)!

Man muss irgendwas machen um Kanten im Bild zu "verschmieren" - warum NEAT Video das jetzt tun sollte erschließt sich mir nicht.
Der BlurBlur im Glossar erklärt Filter macht das und ganz dezent (~0,4% überlagert) eingesetzt macht man damit auch nichts weiter kaputt.



Antwort von Axel:

Kann"s kaum erwarten dass ne a6700 hoffentlich auch UHD 10bit kann, zudem "sauber" (!!) aus nem recht ordentlichen APS-C Sensor!!

Reiner schöner Tagtraum oder hab ich eine Gerüchteküche verpasst?



Antwort von mash_gh4:


Das Hinzufügen von Rauschen macht überhaupt keinen Sinn da das zunächst nur den nachgeschalteten Encoder unnötigt belastet und dieser bei (eventueller) Rauschfilterung (z.B. für geringe Zieldatenrate) genau in den urspünglichen Bereichen wieder zusammenfasst/integriert/denoised, damit die ursprünglichen Abrisse wieder auftauchen werden.

dem kann ich zwar leider nicht widersprechen, da sich rauschen aufs komprimieren immer denkbar ungünstig auswirkt, trotzdem ist es die antwort, warum du normalerweise bei heutigen kameras auch in der 8bit aufzeichnung (wobei hier natürlich höhere ursprüngliche bittiefe vorleigt bzw. ein tatsächlich sinnvolles dithern moglich ist) kaum banding in material von ausreichender aufzeichnungsbandbreite entdecken wirst. ein bloßes hinzufügen von rauschen ohne bittifenreduktion bringt zwar diesebezüglich keine qualitative verbesserung, ahmt aber echtes material von entsprechender bittiefe vermutlich täuschender nach.

leider ist ja banding alleine durch die nutzung von 10bit farbtiefe nicht gänzlich aus der welt geschaffen. es ist zwar dort weit seltener bzw. in viermal mehr unscheinbare bänder aufgegliedert, trotzdem sind derartige artefakte auch hier weiterhin möglich bzw. wahrnehmbar:

zum Bild http://users.mur.at/ms/attachments/banding1.png
zum Bild http://users.mur.at/ms/attachments/banding2.png

es macht daher duchaus sinn, auch im 10bit umfeld sorgsam mit davon bedrohten weichen farbübergängen umzugehen. aus ganz pragmatischen erwägungen heraus -- weil damit zu rechnen ist, dass 10bit produktionen noch eine weile hauptsächlich auf 8bit geräten wiedergegeben werden dürften --, sogar in ganz besonderem maße.

banding ist diesbezüglich wirklich eine verdammt kontraintuitive erscheinung. gerade wenn man alles besonders sauber zu machen versucht und die übergänge glättet, tritt es erst richtig störend in erscheinung. ;)

aber dem TO ging's ja offenbar mehr darum, wie man entsprechende qualitätsüberprüfungen möglichst zielführend irritieren kann. da sind wahrscheinlich alle techniken, die variationen der vorhandenen 8bit-werte in der bereits spezifizierten geringfügigen intensität bewirken, vermutlich ähnlich brauchbar. dass man sie auch bei genauer überprüfung nicht entdecken könnte, würde ich allerdings gefühlsmäßig eher bezweifeln.



Antwort von Roland Schulz:

Nicht weils jetzt von mir kam, aber ich finde die vorgeschlagene 0,4% Überlagerungs-Blur-Methode sollte das bisher beste Ergebnis zeigen - das 8bit Rauschen wäre im 99,6% Basistrack ja auch immer noch drin, von daher auch keine Angst bzgl. eventuellem, theoretischem "10bit Banding".

"Breitere Bänder" würden mit der Methode verschmiert/geglättet und wären auch mit keiner Kontrastverstärkung direkt wieder herstellbar.

Es wird trotzdem kein echtes 10bit da man so keine echten 10bit Nuancen der Szene abbilden kann - sichtbare Abrisse würde es so aber auch keine mehr geben.



Antwort von Roland Schulz:


Kann"s kaum erwarten dass ne a6700 hoffentlich auch UHD 10bit kann, zudem "sauber" (!!) aus nem recht ordentlichen APS-C Sensor!!

Reiner schöner Tagtraum oder hab ich eine Gerüchteküche verpasst?

Ist nur ne Vermutung bzw. müsste das irgendwann die logische Konsequenz auf die GH5/s sein.
Irgendwas muss kommen, 50p UHD und/oder 10bit (die wahrscheinlich dann nur in 25p).
Wir werden sehen - irgendwann...



Antwort von cantsin:


NEAT Video arbeitet aber gar nicht in 10bit ;-)!

Man muss irgendwas machen um Kanten im Bild zu "verschmieren" - warum NEAT Video das jetzt tun sollte erschließt sich mir nicht.

Doch, die Pro-Version arbeitet in 10bit und höher: https://www.neatvideo.com/features/map-all

Auch bei 8bit-Aufnahme wirst Du zwischen zwei Frames auf einem PixelPixel im Glossar erklärt keine identischen Farbwerte haben. Der temporale Rauschfilter berechnet einen Zwischenwert zwischen diesen beiden (oder noch mehreren) Pixeln, interpoliert aber in mehr Bittiefe, in Zwischenwerte, die feiner sind als das 8bit-Raster. Das gleiche Prinzip wie bei Super Resolution, nur auf die Farb- statt auf die räumliche Auflösung angewendet.



Antwort von Axel:



Reiner schöner Tagtraum oder hab ich eine Gerüchteküche verpasst?

Ist nur ne Vermutung bzw. müsste das irgendwann die logische Konsequenz auf die GH5/s sein.
Irgendwas muss kommen, 50p UHD und/oder 10bit (die wahrscheinlich dann nur in 25p).
Wir werden sehen - irgendwann...

Eine A6700
- mit 2160 50/60p
- mit 10-bit, meinetwegen auch "nur" in SFR

Dann hieße es "GH was?"



Antwort von Roland Schulz:



NEAT Video arbeitet aber gar nicht in 10bit ;-)!

Man muss irgendwas machen um Kanten im Bild zu "verschmieren" - warum NEAT Video das jetzt tun sollte erschließt sich mir nicht.

Doch, die Pro-Version arbeitet in 10bit und höher: https://www.neatvideo.com/features/map-all

Auch bei 8bit-Aufnahme wirst Du zwischen zwei Frames auf einem PixelPixel im Glossar erklärt keine identischen Farbwerte haben. Der temporale Rauschfilter berechnet einen Zwischenwert zwischen diesen beiden (oder noch mehreren) Pixeln, interpoliert aber in mehr Bittiefe, in Zwischenwerte, die feiner sind als das 8bit-Raster. Das gleiche Prinzip wie bei Super Resolution, nur auf die Farb- statt auf die räumliche Auflösung angewendet.

Stimmt, bei EDIUS (habe NEAT Video Pro) allerdings immer nur 8bit :-(, funktioniert aber immerhin im 10bit Projekt!
Bringt uns hier trotzdem nicht weiter...








Antwort von WoWu:

Die einfachste Methode ein upsampling zu erkennen, ist das Auslesen der Stuck Bits mit einem WFM, (z.B. dem 2200 oder 4000 von Tek.) so wie es auch die Broadcaster in der technischen Abnahme machen. Dabei wird ein Balken für jedes BitBit im Glossar erklärt angezeigt, das sich wiederholend ändert (H/L).
Ändert sich nichts, ist das ein Anzeichen für 8 in 10 Bits.
Man muss also schon hergehen und reichlich DitherDither im Glossar erklärt einfügen, um das zu umgehen, dann sieht aber das Bild entsprechend matschig aus.



Antwort von dosaris:



Ändert sich nichts, ist das ein Anzeichen für 8 in 10 Bits.
Man muss also schon hergehen und reichlich DitherDither im Glossar erklärt einfügen, um das zu umgehen, dann sieht aber das Bild entsprechend matschig aus.

oder 2 BitBit im Glossar erklärt Rauschen unten drunter kleben ...
Dann bleibt's beim 8Bit-Eindruck.



Antwort von Roland Schulz:

Stuck Bits haben wir nach den oben beschriebenen Verfahren nicht mehr. Stuck Bits würden nur auftauchen wenn wir 8bit ohne jegliche Verarbeitung primitiv in 10bit überführen würden, also einfach 2 LSB anhängen würden.

Da sind wir hier schon ein paar Schritte weiter mit unseren "Betrugsversuchen" ;-).
Meine Idee war das ursprüngliche Bild in 10bit "etwas" geblured (z.B. Gausscher Weichzeichner) mit ~0,4% (entspricht +2bit / 2 LSB) dem eigentlichen Bild zu überlagern. Dann hätten wir die ursprünglichen Abrisse tatsächlich mit interpolierten Informationen gefüllt und es würden keine Bits mehr "klemmen".



Antwort von WoWu:

Dann erkennst aber anhand der Darstellung, dass die Bits so gut wie gleichzeitig beide Zustände annehmen.
Aber wenn jemand Rauschen absichtlich zufügt, wäre es leichter die Ladenkasse der nächsten Tankstelle zu beklauen.



Antwort von Roland Schulz:



Ändert sich nichts, ist das ein Anzeichen für 8 in 10 Bits.
Man muss also schon hergehen und reichlich DitherDither im Glossar erklärt einfügen, um das zu umgehen, dann sieht aber das Bild entsprechend matschig aus.

oder 2 BitBit im Glossar erklärt Rauschen unten drunter kleben ...
Dann bleibt's beim 8Bit-Eindruck.

Hatten wir auch schon, funktioniert nur bedingt bzw. kann wiederhergestellt werden. Hast Du eine Fläche sagen wir mal in der Helligkeit 940 und daneben eine Fläche in 936 kannst Du das zwar mit 10bit Rauschen faken, legst Du am Ende aber wieder eine Integration/Rauschunterdrückung/starke KompressionKompression im Glossar erklärt drüber kommt wieder 940 und 936 raus. Du erkennst also die 8bit Abstufung wieder :-(!

Legst Du aber einen BlurBlur im Glossar erklärt mit ~0,4% drüber (~0,4% Deckkraft des geblurten Clip, der dem ursprünglichen Clip überlagert wird) wird die "Kante" aufgeweicht. Du kriegst also fließende Werte von 936 - 940 (937, 938, 939).
Denke das kriegt man dann nicht mehr reproduziert, wüsste nicht wie.



Antwort von Roland Schulz:

...vielleicht ist noch nicht ganz klar was ich meine: Das Ausgangs 8bit Bild wird in einer Kopie in 10bit Umgebung "geblurred", anschließend mit ca. 0,4% Deckkraft (entspricht ca. 2 LSB / 2 zusätzliche Bits) dem Original 8bit Bild innerhalb eines 10bit Workflows überlagert. Harte 8bit Übergänge erhalten so interpolierte 10bit Informationen.

Übertrieben dargestellt würde das dann so aussehen:
8to10bit.jpg

Das kann man später mit keinem Denoising/Integration o.ä. wieder reproduzieren, alle 10bits "leben"!



Antwort von dosaris:



Legst Du aber einen BlurBlur im Glossar erklärt mit ~0,4% drüber (~0,4% Deckkraft des geblurten Clip, der dem ursprünglichen Clip überlagert wird) wird die "Kante" aufgeweicht. Du kriegst also fließende Werte von 936 - 940 (937, 938, 939).
Denke das kriegt man dann nicht mehr reproduziert, wüsste nicht wie.

ja,
wird wohl funktionieren.

Aber da wir ja ohnehin (überwiegend) von verlustbehaftetem Encoding sprechen,
das eine Bit-identische decodierung zum Ursprungssignal unmöglich macht, wird
sich das re-Encoding einer 8Bit-Vorlage nach 10Bit-Encoding automatisch in
diesem bluring auswirken. Früher - bei MPEG2MPEG2 im Glossar erklärt - erzeugte hartes encoding zB Mosquito-noise.
Dies Problem ist ua durch die Qpels bei AVC fast verschwunden (bzw liegt nun innerhalb
des selben Pixels). Aber derartige Encoding-Fehler sind ohnehin nix anderes als "gefärbtes"
zusätzliches Rauschen. Natürlich unten (bei den LSBs) am stärksten.
et voila: 10 BitBit im Glossar erklärt hergezaubert.
o.k.: dies zaubern geht umso "besser" je härter das Encoding und/oder je
unterschiedlicher die Encoder-Parametrierung ist.
(ok, ist etwas vereinfacht dargestellt)



Antwort von cantsin:

So, hab' jetzt mal meine Vermutung getestet, ob sich mit temporalem Rauschfilter die Farbauflösung analog zu Super Resolution künstlich vergrößern lässt - und das Ergebnis ist eindeutig.

Ausgangmaterial waren in VLog aufgenommene 1080p1080p im Glossar erklärt 8bit 4:2:04:2:0 im Glossar erklärt h264-Kameradateien der GH5, die hier zum Download bereit liegen: https://www.43rumors.com/new-gh5-video-for-download/

Ich habe für meinen Test den Clip "Pete Fire Hand.MP4" verwendet (weil sein Motiv mehr Farbvarianz hat als die anderen), in Resolve importiert und einen unbearbeiteten FrameFrame im Glossar erklärt als unkomprimierte 16bit TIFF-Datei exportiert. In diesem TIFF erkennt Imagemagick bzw. "identify -format %k" 17.210 diskrete Farben.

Danach habe ich auf den Clip Neat Video Pro (OFX-Plugin) gelegt, nur den temporalen Filter angewendet, mit fünf Referenzframes und in der höchsten Qualitätsstufe. Danach wiederum denselben FrameFrame im Glossar erklärt als 16bit TIFF exportiert. Statt 17.210 erkennt Imagemagick nun 1.194.446 verschiedene Farben, beinahe eine Versiebzigfachung:

Capture.PNG

Die beiden TIFF-Dateien hab ich hier zum Download bereitgestellt:
http://data.pleintekst.nl/chroma-upsampling.zip (13 MB)

EDIT: Wenn ich den mit Neat gefilterten FrameFrame im Glossar erklärt als unkomprimiertes 8bit-TIFF statt als 16bit-TIFF exportiere, bleiben nur noch 39.471 diskrete Farben. Es wird also definitiv in die höhere Bittiefe interpoliert.

EDIT 2: Und die 39.471 Farben in 8bit sind auch kein Bug von Resolve. Wenn ich statt 8Bit TIFF zu exportieren das zuvor exportierte, gefilterte 1,1 Millionen-Farben-16bit-TIFF mit Imagemagick zu 8bit TIFF umwandle, resultieren 39.473 diskrete Farben.



Antwort von Roland Schulz:


Danach habe ich auf den Clip Neat Video Pro (OFX-Plugin) gelegt, nur den temporalen Filter angewendet, mit fünf Referenzframes und in der höchsten Qualitätsstufe. Danach wiederum denselben FrameFrame im Glossar erklärt als 16bit TIFF exportiert. Statt 17.210 erkennt Imagemagick nun 1.194.446 verschiedene Farben, beinahe eine Versiebzigfachung:

-> rechnerisch 4^3 = 64

Wir stellen fest, verschiedene Wege führen nach Rom. Aus 8bit kann man 10bit machen und keiner kann Anhand des Materials nachweisen dass es vorher 8bit war.

Bzgl. statischen Bildern müsste die NEAT Video Methode sogar die bessere sein, da über die Wahrscheinlichkeitsbetrachtung der Ausgangswert näher am Original (Szene) sein müsste.
Dafür versagt die Methode recht schnell bei Bewegung.








Antwort von cantsin:



Danach habe ich auf den Clip Neat Video Pro (OFX-Plugin) gelegt, nur den temporalen Filter angewendet, mit fünf Referenzframes und in der höchsten Qualitätsstufe. Danach wiederum denselben FrameFrame im Glossar erklärt als 16bit TIFF exportiert. Statt 17.210 erkennt Imagemagick nun 1.194.446 verschiedene Farben, beinahe eine Versiebzigfachung:

-> rechnerisch 4^3 = 64

Was in der Tat genau eine Vervierfachung pro Farbkanal ist, bzw. eine Zunahme um den Faktor zwei hoch zwei = 2 bit, also der Sprung von 8 bit zu 10bit.

(Mir ist klar, dass Dir das klar war, ich versuch's nur, nochmal auf allgemeinverständliche Weise auszudrücken.)

Und das Tolle ist ja, dass man sich mit diesem Verfahren keine ArtefakteArtefakte im Glossar erklärt einhandelt, sondern im Gegenteil ArtefakteArtefakte im Glossar erklärt wie Rauschen und Makroblocking vermindert.



Antwort von mash_gh4:



naja -- leider nur "fast alle" artifakte. so weit es mögliches banding betrifft, ist leider auch diese variante eher kontraproduktiv. wenn man das rauschen weitetstegehend unterdrückt und die feinen übergänge glatt bügelt, landet man schnell einmal bei genau den problemen, wie man sie vor allem aus animes und den dort anzutreffenden künstlich geschaffenen farbverläufen in den zeichnungen kennt.

dieses problem muss man zwar natürlich nicht weiter ernst nehmen, wenn es einem wirklich nur darum geht, footage an primitiven qualitätskontrollen vorbeizuschummeln, aber für diejenigen von uns, die vielmehr an möglichst befriediegenden formen der produktion interessiert sind, ist das vermutlich schon eine ganz zentrale frage.

ich glaub, dass es gerne unterschätzt wird, wie problematisch es sich darstellt, wenn man zwar in perfekten 10bit-kontrollumgebungen produziert, aber keine weiteren vorkehrungen und kontrollmaßnahmen im hinblick auf sich zeigende artefakte bei der wiedergabe auf 8bit wiedergabegeräten einbezieht. auf diese weise kann man mit wunderbar fortschrittlichem werkzeug ergebnisse produzieren, die im alltag bzw. auf den tatsächlich genutzten wiedergabegerätschaften unbefriedigender wirken als wenn sie mit weit primitiveren mitteln geschaffen worden wären. dort wären die angsprochenen banding-artefakte dem verantwortlichen gestalter nämlich sofort ins auge gesprungen bzw. vorsorglich vermindert worden.

das ganze problem würde sich auch nicht weiter stellen, wenn alle typischen postproduktionstools in dieser hinsicht die notwendigen vorkehrungen beim export anbieten würden, oder die wiedergabemittel mehr rücksicht auf dieses problem nehmen würden. beides ist aber in der praxis nicht in ausreichendem maß anzutreffen, weshalb man hier einfach selber mitdenken bzw. dafür sorge tragen muss.



Antwort von cantsin:


naja -- leider nur "fast alle" artifakte. so weit es mögliches banding betrifft, ist leider auch diese variante eher kontraproduktiv. wenn man das rauschen weitetstegehend unterdrückt und die feinen übergänge glatt bügelt,

Das passiert ja vor allem bei spatialer Rauschunterdrückung, weniger bei temporaler.



Antwort von Roland Schulz:

...so schaut‘s - allerdings krankt die temporale weiterhin bei stark bewegten Szenen.

Denke wir sind durch, 8bit lässt sich wenn man sich geschickt anstellt in 10bit nicht nachweisen.

Trotzdem bietet echtes 10bit den Vorteil der Aufnahme und Wiedergabe der echten Graduation.



Antwort von mash_gh4:


Das passiert ja vor allem bei spatialer Rauschunterdrückung, weniger bei temporaler.

ich glaub, es hängt auch sehr stark vom jeweiligen motiv ab.

aber stell dir einfach jene ganz einfachen bekannten problemfälle vor: eine ruhige einstellung mit feinen farbverläufen am himmel.

ganz egal, wie du so etwas vom enthaltenen rauschen befreist, die klaren feinen grenzziehungen zwischen den farbabstufungen treten immer deutlicher/störender hervor.

evtl. täusche ich mich da, aber ich vermute, dass es hier wirklich nicht viel unterschied macht, ob du dazu spatiale od. temporale NR nutzt.



Antwort von cantsin:


Denke wir sind durch, 8bit lässt sich wenn man sich geschickt anstellt in 10bit nicht nachweisen.

Trotzdem bietet echtes 10bit den Vorteil der Aufnahme und Wiedergabe der echten Graduation.

Jepp. (Ist halt das gleiche wie mit echter hoher optischer Auflösung versus nachgeschärfter oder per Superresolution berechneter optischer Auflösung.)



Antwort von WoWu:


Hi,

kennt jemand eine Möglichkeit, upgesampletes Material zu identifizieren? Also, wenn ein Videoclip der ursprünglich 8Bit war nun einfach als 10 bit exportiert wurde?

Unbearbeitet exportiert müsste der Clip dann ja 2 sinnfreie bits mitschleppen...

Danke für hilfreiche Hinweise im Voraus,

banana

Tja, schade dass die Frage nicht war, wie man betrügen kann, sondern wie man up-gesampeltes Material erkennt.



Antwort von Roland Schulz:

Wolfgang, Du hast Recht, auch vorher schon mit dem Tektronix!!

Allerdings war die Frage von Bud Spencer doch etwas falsch oder unwissend gestellt - denn bei reinem Verpacken/Exportieren von 8bit Material in 10bit Streams findet gar kein hinterfragtes "Upsampling" statt, richtig ;-)?!

EDIT: "...unbearbeitetes Material..." - Jungs, da sind wir viel zu weit gerannt, auch wenn Upsampling mit drin stand.
Unpräzise Aufgabenstellung ;-p !!!

Meine erste Antwort traf es noch bevor wir hier abgedriftet sind:

"Denke das wird unmöglich sobald jemand beim Grading auf 10bit rausgerendert hat.
Bei unverändertem Material könnte man das vielleicht noch irgendwie über die LSB"s rauskriegen."


Unverändert kriegt man es über die letzten beiden LSBs raus!!



Antwort von mash_gh4:

Ich habe für meinen Test den Clip "Pete Fire Hand.MP4" verwendet (weil sein Motiv mehr Farbvarianz hat als die anderen), in Resolve importiert und einen unbearbeiteten FrameFrame im Glossar erklärt als unkomprimierte 16bit TIFF-Datei exportiert. In diesem TIFF erkennt Imagemagick bzw. "identify -format %k" 17.210 diskrete Farben.

ich hab das jetzt, weil es mich doch interessiert hat, mit einer etwas anderen methode überprüft.

ich wollte mir anschauen, ob man, wenn man die 10bit werte jeweils durch 4 dividiert, und dabei nur den zurückbleibenden rest betrachtet -- also die werte 0, 1, 2, 3 --, an hand der häufigkeit des vorkommens jeder dieser vier werte einen rückschluss auf das ursprüngliche material ziehen kann...

wenn man das aber ganz praktisch versucht, sieht man sofort, dass das vorgeschlagene ausgang- bzw. vergleichsbild ("unfiltered-0086401.tif") in seiner werteverteilung bereits derart viele einträge enthält, die sich in einem 8bit-werteraster gar nicht erst darstellen lassen dürften, dass man es eigentlich nicht als bsp. für unmodifiziertes upsampling heranziehen kann... da sind offenbar selbst im zuge dieser minimalen bearbeitung im resolve bereits fast mehr störende bzw. täuschende einflüsse eingeflossen als wir sie hier ersinnen wollten. ;)


import numpy as np
import cv2
unfiltered = np.asarray(cv2.imread("unfiltered-0086401.tif", -1))>>6
np.unique(np.remainder(unfiltered, 4), return_counts=True)

# liefert als output:

(array(, dtype=uint16),
array())









Antwort von cantsin:

Wobei das Werteraster jetzt nicht so interessant ist (denn das ist ja nur die Farbpalette - hier rechnet Resolve natürlich in 32bit Float und von dort aus in 16bit TIFF), sondern die diskreten Farbwerte. (Schon die Umrechnung von Rec709 zu sRGB dürfte diverse Rundungsfehler provozieren und daher Deinen Test beeinträchtigen.)

Und da ist eben auch beim TIFF-Export das Ergebnis 8bit-typisch, sogar noch am Low End von 8bit, wenn man es mit den diskreten Farbwerten im entrauschten 8bit vergleicht. Und wenige diskrete Farbwerte über eine breite Palette verteilt, bedeutet ja einfach nur banding.

Das eigentliche Erstaunliche finde ich, dass sich durchs temporale Denoising die diskreten Farbwerte tatsächlich um annährend denselben Faktor (64) vermehren wie die verfügbaren Farben in der 10bit- ggü. der 8bit-Palette.

Hab's in der Zwischenzeit auch noch mit Resolves internem temporalen Denoiser getestet, mit dem gleichen Ergebnis.



Antwort von mash_gh4:


Wobei das Werteraster jetzt nicht so interessant ist (denn das ist ja nur die Farbpalette - hier rechnet Resolve natürlich in 32bit Float und von dort aus in 16bit TIFF), sondern die diskreten Farbwerte. (Schon die Umrechnung von Rec709 zu sRGB dürfte diverse Rundungsfehler provozieren und daher Deinen Test beeinträchtigen.)

naja -- der werteraster scheint mir schon ziemlich bedeutsam zu sein.
in dem punkt teile ich ausnahmsweise einmal WoWus hinweis auf die stuck bits.
das ausszählen der konkret vorfindlichen farbwerte halte ich im vergleich dazu für eher weniger aussagekäftig od. zielführend.
zumindest aber zählst du dabei ganz viele farben mehrfach, die sich in wahrheit nur in der 16bit darstellung unterschieden, aber bei reduktion auf 10bit YUVYUV im Glossar erklärt rec709 wieder zusammenfallen.

was allerdings mögliche fehler durch die rec709->sRGB, YUV->RGB und float->16bit->10bit wandlung betrifft, stimme ich dir leider vollkommen zu. ich verwende deshalb für solche sachen auch lieber uncompressed yuv rawvideo frames direkt aus dem ffmpeg als realistischen ausgangspunkt, wo sich dieses problem nicht stellt.

(wobei ich mir ehrlich gestanden nicht so sicher wäre, ob resolve beim tiff-export tatsächlich eine korrekte farbraum-umwandlung vornimmt. ;))

Das eigentliche Erstaunliche finde ich, dass sich durchs temporale Denoising die diskreten Farbwerte tatsächlich um annährend denselben Faktor (64) vermehren wie die verfügbaren Farben in der 10bit- ggü. der 8bit-Palette.

ja -- erstaunlich ist das natürlich tatsächlich -- nur hätte ich so meine probleme, das wirklich ganz sauber zu erklären und in beziehung zum tatsächlichen video-inhalt zu setzten bzw. daraus etwas allgemeines abzuleiten, das in allen fällen befriedigend funktioniert.

ich war vorhin schon fast geneigt, einen kleinen shader zu schreiben, der vor allem im hinblick auf die von roland beschriebene variante vielleicht ein bisserl nachvollziehbarer visualisieren könnte, in welchen bildbereichen das besonders gut funktioniert, und wo wieder nicht so gut.

aber das sind ja alles nur völlig sinnlose spielereien und fingerübungen, auf die man nicht zu viel zeit verschwendenden sollte.

Hab's in der Zwischenzeit auch noch mit Resolves internem temporalen Denoiser getestet, mit dem gleichen Ergebnis.

das temporale denoisen ist halt leider auch eine variante, die sich mit typischen videobearbeitungsmitteln fast leichter realisieren lässt als mit einfachen zahlenmodellen, dafür hat man dann halt mit all diesen vielfältigen begeleiterscheinungen des umgebenden processings zu kämpfen, die man von der wirkung des eigentlich untersuchten effekts kaum mehr trennen kann.



Antwort von mash_gh4:

Schon die Umrechnung von Rec709 zu sRGB dürfte diverse Rundungsfehler provozieren und daher Deinen Test beeinträchtigen.

nachdem mir dieser hinweis auf diesen ganz grundsätzlichen fehler richtig peinlich war, hab ich jetzt nocheinmal mit geeigneteren mitteln nachzustellen versucht.

ich hab mich dabei videoseitig ausschließlich auf unkomprimierte YCbCr-ausgabe aus dem ffmpeg und zwei dort enthaltene denoiser gestützt.

das ganze ist hier genauer dokumentiert und mit ein paar grafiken versehen. falls wer selber damit herumspielen will, hab ich auch das verwendete jupyter notebook zum downloaden auf den server gelegt.

aufregende unterschiede zum vorigen test habe ich leider auch diesmal nicht ausmachen können. :(

die auswirkungen der vorgeschlagenen eingriffen zeigen -- zumindest in dieser konkreten umsetzungsvariante -- bei weitem nicht jene signifikante änderung, die man erwarten würde.

wenn man die kanäle getrennt betrachtet, kommt es definitiv zu keinem nennenswerten wertezuwachs. im gegenteil, es werden tlw. durch das denoisen sogar weniger! das könnte allerdings u.u. seine ursache darin haben, dass die denoiser im ffmpeg evtl. nur im 8bit-modus arbeiten. :(


Y Cb Cr
roh: 157 38 24
hqdn3d: 153 37 23
atadenoise: 156 41 24

was die verteilung auf die zwischenwerte im raster betrifft, kann man am ehesten noch in den farbkanälen irgendwelche nenneswerten veränderungen erkennen. aber selbst da bleibt es weit hinter den erwartungen zurück.

ich hab das jetzt natürlich nur ganz schnell umzusetzten versucht, weil es mir keine ruhe gelassen hat. mit ein bisserl nachdenken und trickreichen änderungen, könnte man es aber vermutlich wieder in ganz andere bahnen lenken.



Antwort von TheBubble:

Ihr könnt versuchen ein HistogrammHistogramm im Glossar erklärt über möglichst viele Samples aus vielen Frames zu erstellen. Mit Glück sind die "echten" Helligkeiten/Farben erkennbar häufiger vertreten, als die "Rundungsfehler". Die Anzahl der "echten" Helligkeiten/Farben erlaubt dann einen Rückschluss auf die Bittiefe der ursprünglichen Aufnahmen.

PS: Habe grade gesehen, dass so etwas schon vorgeschlagen wurde. Klar kann man das per BlurBlur im Glossar erklärt o.ä. versuchen zu maskieren, aber das macht doch keiner, der die Qualität nicht bewusst senken will.



Antwort von dosaris:


... kann man das per BlurBlur im Glossar erklärt o.ä. versuchen zu maskieren, aber das macht doch keiner, der die Qualität nicht bewusst senken will.

Qualität senken?

nur bei freaks, die auch daran glauben, dass Lautsprecher mit 22kHz Wiedergabe schlechter
sind als andere mit 24 kHz.
(hat 'mal jemand in den letzten Jahren ein Audiogramm seiner Ohren messen lassen?)

Man könnte als blur ganz stumpf 1 BitBit im Glossar erklärt auf den 10Bit-Wert addieren (also unter 1 promille Fehler)
und niemand würde dies wahrnehmen, aber díe LSBs sind anders.

Aber - wie schon angemerkt - es wird bei verlustbehafteter Codierung dieser BlurBlur im Glossar erklärt automatisch anfallen,
je härter encodiert desto stärker der Blur-Anteil. Und der schlägt sich natürlich besonders in den LSBs nieder.
Wäre es nicht so dann hätte man mit Zaubertrick eine
verlustfreie Codierung mit verlustbehafteten Encodern erfunden.

Bei verlustfreien Encodern (HuffYUV & Co) ist das natürlich anders.



Antwort von mash_gh4:


Ihr könnt versuchen ein HistogrammHistogramm im Glossar erklärt über möglichst viele Samples aus vielen Frames zu erstellen. Mit Glück sind die "echten" Helligkeiten/Farben erkennbar häufiger vertreten, als die "Rundungsfehler". Die Anzahl der "echten" Helligkeiten/Farben erlaubt dann einen Rückschluss auf die Bittiefe der ursprünglichen Aufnahmen.

wie gesagt, natürlich ist das der weg, an den man als erstes denkt, und der im alltag und hausgebrauch sicher auch oft nützlich ist. trotzdem sind histogramme immer mit großer vorsicht zu genießen.

gehen wir ganz praktisch von jenem material aus, das uns cantsin oben nahe gelegt hat, und konzentrieren wir uns der einfachheit halber nur auf die enthalte helligkeitsinformation, allerdings in genau jener YCbCr datenrepräsenstation, wie sie in farbunterabgetasteter 4:2:04:2:0 im Glossar erklärt und 4:2:24:2:2 im Glossar erklärt videoübertragung üblicherweise genutzt wird, und worauf sich unsere 10bit genauigkeitsangabe eben tatsächlich bezieht.
zum Bild http://users.mur.at/ms/attachments/catsin_luma.png

auch wenn man sich davon ein sehr genau gerechnetes histogram ansieht, kann man leider noch immer nicht so recht sagen, ob das nun von 8bit od. 10bit ausgangsmaterial stammt -- obwohl es natürlich diese auffälligen spitzen zeigt:
zum Bild http://users.mur.at/ms/attachments/catsin_luma_hist.png

wirklich deutlich wird es erst, wenn man sich ansieht, welche helligkeitswerte im bild tatsächlich genutzt werden und welche darin nicht vorkommen:


Y:



wenn man sich diese geordnete liste mit werten ansieht, wird auf den ersten blick klar, dass da ganz offensichtlich gleichförmige lücken zwischen den viel zu wenigen tatsächlich benützten werten zu entdecken sind.

das spannende dran ist allerdings die tatsache, dass sie nicht exakt auf jenem raster zu liegen kommen, den man erwarten würde. statt dass zwischen den vorfindlichen werten immer 3 unbenutze liegen, ist der abstand zwischen ihnen in wahrheit oft kleiner:




ich fürchte, dass man diese erscheinung im gegenständlichen fall vermutlich einfach damit erklären kann, dass beim einlesen des ursprünglichen 8bit ausgangmaterials bzw. dessen weiterer verarbeitung eine stauchung von "full range" nach "legal" vorgenommen wurde.

ganz abgesehen davon, dass man das natürlich auch schlicht als schlampigkeitsfehler meinerseits werten könnte, ist es es doch insofern interessant, als dadurch einfache überprüfungsmethoden, die WoWu ("Stuck Bits") und ich ("bitweise OR" und betrachtung der restwerte bei ganzzahliger division durch 2**2) bereits weiter oben angesprochen haben, aufs glatteis geführt werden. es ist zwar ganz eindeutig, das nur ein viertel der werte genutzte wird, aber dadurch, dass sie in einer weise gestreut sind, die mit einfachen bitmasken nicht mehr erfasst werden kann, erkennt man das mit den betreffenden überprüfungsmethoden trotzdem nicht.



Antwort von Banana_Joe_2000:

@mash_gh4

vielen Dank für Deine ausführliche Antwort. Es geht bei uns tatsächlich um unbearbeitetes Material, welches ohne weiteres grading / Schnitt (...) wieder gespeichert wird. Die offeenbar wissenschaftliche Herangehensweise mit numeric Python etc. muss ich mir mal ansehen. Da habe ich überhaupt keine Idee, was da auf mich zukommen könnte.

Ich bin tatsächlich von einem Tool ausgegangen, welches so ähnlich aussehen könnte wie eine RGB-Parade. Im Falle eines "echten" 10-Bit-Inhaltes ist halt (fast) der gesamte Wertebereich der 1024 möglichen Werte abgedeckt. Bei "unechtem" 10 BitBit im Glossar erklärt, also 8 oder weniger, fehlt halt "untenrum" etwas.

Deine Bemerkung zum Dithering kann ich nur unterschreiben - genau wie bei der bittiefenreduktion bei audio...

@Wolfgang
...starken Spreizung des Luminanzbereiches... - genau, aber wie mash_gh4 weiter unten bemerkt, manchmal unzuverlässig. Ich bin selber darauf gestoßen, da genau das nicht zuverlässig zu funktionieren scheint. Sehr Motivabhängig. Fällt im Alltag aber nicht auf. Die Auflösung der Software-Instrumente ist auch von Schnittprogramm zu Schnittprogramm sehr unterschiedlich, wie ich meine. Einen qualitativen Vergleich habe ich aber nicht gemacht.

@Dosaris
...kannste mal mit den QCtools da reinsehen... - ja, klasse Tool. Danke für den Tip!

@Cantsin
...mit dem Kommando "identify -format %k xy.tif"... - ok, auch ein Versuch wert. Hört sich für mich als Mathematik-legastheniker erstmal leichter an, als numericPython und co... Danke!

@WoWu
...Auslesen der Stuck Bits mit einem WFM, (z.B. dem 2200 oder 4000 von Tek.)... - ok, das hört sich schon mal gut an. Werde ich auch weiterverfolgen - Danke!

@Roland Schulz
...Aus 8bit kann man 10bit machen und keiner kann Anhand des Materials nachweisen dass es vorher 8bit war.... - ja, nach diverser Bearbeitungstechnik. Das war zwar nicht meine ursprüngliche Intention bei der Erstellung des Threads, aber hat sich interessant entwickelt.

Insgesamt vielen Dank an Alle, die Sich hier beteiligt haben.

besten Gruß,

banana



Antwort von TheBubble:


das spannende dran ist allerdings die tatsache, dass sie nicht exakt auf jenem raster zu liegen kommen, den man erwarten würde. statt dass zwischen den vorfindlichen werten immer 3 unbenutze liegen, ist der abstand zwischen ihnen in wahrheit oft kleiner:




Die leicht wechselnden Abstände machen doch gar nichts, es ist damit doch deutlich gezeigt, dass es Lücken in regelmäßigen Abständen (+/- 1) gibt.

Wobei man natürlich immer erwähnen sollte, dass solche Lücken auch beim Grading entstehen können (z.B. indem man die mittleren Helligkeiten spreizt oder wenn man mit einer anderen Gamma-Kurve aufgezeichnet hat und diese dann später wieder entzerrt), d.h. Lücken sind ein Indiz für eine ursprünglich geringere Bitttiefe, aber kein Beweis.

Mehr kann man da nicht machen. Wobei, vielleicht könnte man es mit Machine Lerning probieren. :D



Antwort von mash_gh4:


Die leicht wechselnden Abstände machen doch gar nichts, es ist damit doch deutlich gezeigt, dass es Lücken in regelmäßigen Abständen (+/- 1) gibt.

du hat natürlich völlig recht. für das praktische arbeiten mit dem material macht's natürlich überhaupt keinen unterschied. spannend ist es nur, weil dadurch überprüfungen mittels bitmaske ihre aussagekraft verlieren.

Lücken sind ein Indiz für eine ursprünglich geringere Bitttiefe, aber kein Beweis.

ja, das würde ich auch so sehen.

Mehr kann man da nicht machen. Wobei, vielleicht könnte man es mit Machine Lerning probieren. :D

unbedingt! -- machine learning ist ein wunderbares mittel, um uns anschaulicher vor augen zu führen, wie fürchterlich unintelligent unsere technischen fragen, interessen und aufgabenstellungen doch ständig sind. :)








Antwort von wolfgang:


wie gesagt, schau dir einmal folgende ganz einfache erklärung an:

https://de.wikipedia.org/wiki/Dithering ... arbeitung)

und dann frag dich vielleicht, ob das bevorzugte videobearbeitungsprogramm deiner wahl irgendwelche vorkehrungen bzw. ausgabeaufbereitungsmöglichkeiten besitzt, um in diesem sinne auch deine schönen 10bit-produktionen auf gebräuchlichen 8bit-abspielgeräten ohne störendes bandig wiederzugeben?

Ich kenne weder aus Vegas noch aus Edius explizite Filter die Dithering generieren würden. Ja vielleicht mit den diversen Unschärfefilter - oder ich kenne die eben nicht.

In der Praxis allerdings ist das kein Problem. Denn ich gehe davon aus dass über kurz oder lang eben ein 10bit fähiges Display auch bei mir im Wohnzimmer steht, einfach weil das HDR benötigt. Dann gibt man eben zu 10bit HEVC aus und gut ist es.



Antwort von mash_gh4:

In der Praxis allerdings ist das kein Problem. Denn ich gehe davon aus dass über kurz oder lang eben ein 10bit fähiges Display auch bei mir im Wohnzimmer steht, ...

ja -- für begeisterte urlaubs- und freizeitfilmer und den damit verbundenen wiedergabemöglichkeiten in den eigenen vier wänden ist diese lösung natürlich völlig ausreichend. für diejenigen aber, die für einen größeren kreis potentieller zuseher produzieren, und mit der trägheit des entsprechenden wandels vermutlich noch länger konfrontiert sein werden, könnte sich diese problematik ein klein wenig komplizierter darstellen.




Noch was unklar? Dann in unserem Forum nachfragen
Zum Original-Thread / Zum Postproduktion allgemein-Forum

Antworten zu ähnlichen Fragen:
Keying: UHD 8Bit o. FHD 10Bit?
GH5 10bit Extern und gleichzeitig 8bit
Brauche Einsteigertipps für Premiere Pro (8bit vs. 10bit, V-LOG, HLG, etc)
Wie TV Aufnahmen erkennen?
deutsche Tonspur und Subtitles erkennen - wie/womit?
Motion Tracking - Bewegungsmuster erkennen und aufzeichnen (wie Heatmap)
Wie? - eig. Videos von Kamera auf PC und dann auf DVD
Player erkennen Länge von MPEG-2-Fernsehaufnahmen falsch
Kinofassung vs. Director's Cut auf DVD erkennen
Wie herausfinden, ob echtes 10-bit video vorliegt o. 8bit Quelle in 10-bit Container?
Wie wichtig ist eine Aufnahme mit 10bit?
Hülfe: von DV-Cam auf DVD-RAM auf DVD(+/-R).WIE?
Umstieg von FCPX auf Premiere CC wie?
Wie nehmt ihr von der TV-Karte auf?
für Anfänger: wie von DV-Cam auf DVD?
Wie Filme von DVD-Recorder via PC auf Disk brennen?
Wie kann man Livevideo von webcam auf Fernrechner übertragen???
Digitalen Stream von D-Box 1 auf PC-Festplatte schreiben, wie geht das?
Wie lade ich von meiner Sony Kamera Bilder auf die Festplatte??
Neu: Fujifilm X-T3 zeichnet 4K/60fps intern mit 10bit auf // Photokina 2018
wie kommt der Film von der Kamera auf den PC?
8Bit 4:2:0 vs 8Bit 4:2:2
Mein 8Bit Experiment!
Schnitt automatisch erkennen
Automatisch Szenenwechsel erkennen
VBR/CBR erkennen

















weitere Themen:
Spezialthemen


16:9
3D
4K
ARD
ARTE
AVCHD
AVI
Adapter
Adobe After Effects
Adobe Premiere Pro
After effects
Akku
Akkus
Apple Final Cut Pro
Audio
Aufnahme
Aufnahmen
Avid
Band
Bild
Bit
Blackmagic
Blackmagic DaVinci Resolve
Blackmagic Design DaVinci Resolve
Blende
Book
Brennen
Cam
Camcorder
Camera
Canon
Canon EOS 5D MKII
Canon EOS C300
Capture
Capturing
Cinema
Clip
ClipKanal
Clips
Codec
Codecs
DSLR
Datei
Digital
EDIUS
ENG
EOS
Effect
Effekt
Effekte
Export
Fehler
Festplatte
File
Film
Filme
Filmen
Filter
Final Cut
Final Cut Pro
Firmware
Format
Formate
Foto
Frage
Frame
GoPro
Grass Valley Edius
HDMI
HDR
Hilfe
Import
JVC
Kabel
Kamera
Kanal
Kauf
Kaufe
Kaufen
Kurzfilm
Layer
Licht
Live
Lösung
MAGIX video deLuxe
MPEG
MPEG-2
MPEG2
Mac
Magix
Magix Vegas Pro
Menü
Mikro
Mikrofon
Mikrophone
Monitor
Movie
Musik
Musikvideo
NAB
Nero
News
Nikon
Objektiv
Objektive
PC
Panasonic
Panasonic GH2
Panasonic HC-X1
Panasonic S1 mit V-Log
Pinnacle
Pinnacle Studio
Player
Plugin
Plugins
Premiere
Projekt
RAW
RED
Recorder
Red
Render
Rendern
Schnitt
Software
Sony
Sound
Speicher
Stativ
Stative
Streaming
Studio
TV
Test
Titel
Ton
USB
Umwandeln
Update
Vegas
Video
Video-DSLR
Videos
Videoschnitt
Windows
YouTube
Zoom

Specialsschraeg
15. August - 15. November / Düsseldorf
upfront! young european video award
30-31. Oktober / Espelkamp
Filmfestival SPITZiale
6-8. November / Freyung
Kurzfilmfest Dreiländereck
27. November / Bielefeld
31. Bilderbeben zum Thema „Abschied“
alle Termine und Einreichfristen