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.Roland Schulz hat geschrieben: ↑Sa 17 Feb, 2018 12:14 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.
kommt drauf an in welcher Codierung das vorliegt.Banana_Joe_2000 hat geschrieben: ↑Sa 17 Feb, 2018 11:48 ... 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...
ja -- prinzipiell hast du da schon recht, und so wird das in der regel auch häufig vor augen gefüht.
Nö. Fernsehen, DVD, Blu-ray - alles 8 Bit ohne Banding. Ist eine Frage der Verarbeitung. Im TV sehr oft auch von 8Bit kommend (XDCAM).Roland Schulz hat geschrieben: ↑Sa 17 Feb, 2018 12:14 Wird die Datei aber nur in 8bit wiedergegeben sieht man den ganzen Mist trotzdem wieder.
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!!!Jott hat geschrieben: ↑Sa 17 Feb, 2018 22:36Nö. Fernsehen, DVD, Blu-ray - alles 8 Bit ohne Banding. Ist eine Frage der Verarbeitung. Im TV sehr oft auch von 8Bit kommend (XDCAM).Roland Schulz hat geschrieben: ↑Sa 17 Feb, 2018 12:14 Wird die Datei aber nur in 8bit wiedergegeben sieht man den ganzen Mist trotzdem wieder.
dein genereller verbrauch an ausrufezeichen ist recht bemerkenswertRoland Schulz hat geschrieben: ↑Sa 17 Feb, 2018 23:13Genau, 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 Timeline in HEVC Main10 rendern 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!!
Meine ich! Liegt aber vielleicht auch an den TVs die bei einigen im Einsatz sind, das scheint nicht durchweg "High-End" Zeugs zu sein.
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.Roland Schulz hat geschrieben: ↑Sa 17 Feb, 2018 23:13Genau, 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 Timeline in HEVC Main10 rendern 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.
Diese Behauptung ist grundsätzlich falsch, falsch und falsch!!
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.Roland Schulz hat geschrieben: ↑So 18 Feb, 2018 08:37Diese Behauptung ist grundsätzlich falsch, falsch und falsch!!
HEVC ist vom Codec 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.
„kleine Speicherkarten“ schreiben heute
Es geht doch überhaupt nicht darum dass Banding durch fünffache Umkomprimierung verschwindet oder nicht, das hat erstmalJost hat geschrieben: ↑So 18 Feb, 2018 08:57 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.
...geht nicht mit der Qualität einer a6500 aus dem „Handtäschchen“ raus mit nem Einhandgimbal ;-)!!
Völlig richtig, nur haben die Birnen (Druck) eine weit über die Äpfel (UHD Darstellung) hinausreichende Auflösung ;-)!mash_gh4 hat geschrieben: ↑So 18 Feb, 2018 13:12 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.
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.
wie gesagt, schau dir einmal folgende ganz einfache erklärung an:
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.Roland Schulz hat geschrieben: ↑So 18 Feb, 2018 22:19 Wenn man allerdings sowas wie nen Blur o.ä. über die Aufnahme drüberlegt ist man mit dem Histogramm 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.
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. :)Roland Schulz hat geschrieben: ↑So 18 Feb, 2018 22:19Wenn man allerdings sowas wie nen Blur o.ä. über die Aufnahme drüberlegt ist man mit dem Histogramm 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.
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.mash_gh4 hat geschrieben: ↑Mo 19 Feb, 2018 00:18ja -- 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. :)Roland Schulz hat geschrieben: ↑So 18 Feb, 2018 22:19Wenn man allerdings sowas wie nen Blur o.ä. über die Aufnahme drüberlegt ist man mit dem Histogramm 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.
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.
NEAT Video arbeitet aber gar nicht in 10bit ;-)!
Reiner schöner Tagtraum oder hab ich eine Gerüchteküche verpasst?Roland Schulz hat geschrieben: ↑Sa 17 Feb, 2018 23:13Kann´s kaum erwarten dass ne a6700 hoffentlich auch UHD 10bit kann, zudem "sauber" (!!) aus nem recht ordentlichen APS-C Sensor!!
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.Roland Schulz hat geschrieben: ↑Mo 19 Feb, 2018 07:14 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.