Roland Schulz hat geschrieben: ↑Do 10 Aug, 2017 16:15
....nochmal das Bild dazu, ziemlich genau 1 Jahr her.
diese konkrete darstellung finde ich persönlich keine sehr gute illustration, weil es auch eine ziemliche wichtige rolle spielt, wie die unterabtastung genau angeordnet ist. bei 4:2:0 zeichnet man sie deshalb besser in der mitte der vier betroffenen pixel ein, damit auch dieser aspekt sinnfällig verdeutlicht wird. schließlich gibt es aus historischen gründen unterabtastungsvarianten, wo die betroffenen farbbezüge ungewöhnlich platziert sind -- mehr dazu, aber auch hinweise auf ältere hist. vorformen mit ähnlicher notation, die evtl. etwas mit wowus betrachtungsweise zu tun haben könnten, gibt's hier: http://dougkerr.net/pumpkin/articles/Subsampling.pdf
Zuletzt geändert von mash_gh4 am Do 10 Aug, 2017 16:57, insgesamt 2-mal geändert.
Roland Schulz hat geschrieben: ↑Do 10 Aug, 2017 15:45
"Oh man..." ????? ...was hat der Codec mit den SDI Anschlüssen zu tun wenn wir oben (TomStg) in ein "vielleicht intern mögliches Downscaling" eingestiegen sind und das von UHD zu FHD gewonnene 4:4:4 Material in 4:4:4 aufnehmen wollen??? Erklärung!!!????
4444 RAW????? -> Oh Mann!!!!!! Hier fehlt echt jeglicher Boden für einen Grundstein!
Du hast in dem Zusammenhang von Codec gesprochen nicht ich!
Du hast Dich gefragt wie Atomos das downgescalete UHD in 444 abspeichern soll, wenn es nicht mal einen Codec zu Verfügung hat.
Diesen braucht es aber eben auch nicht, da aus gewöhnlichen SDI Outputs kein 444 sondern nur 422 rauskommt.
Somit wäre ein 444 fähiger Codec im Atomos Perlen vor die ***.
Im Gegensatz zu den Raw DNGs, diese werden als 444 Subsampling aufgezeichnet, aber eben auch nur da und nicht als ProRes,
also braucht der Atomos an der Stelle auch keinen 444 Codec.
Wenn Deine Theorien stimmen würden, wäre es ein leichtes für Atomos oder Convergent solche einen Codes zu implementieren,
denn beide besitzen die Fähigkeit 4K auf 2K intern down zu samplen.
Da knüpfe ich an Tom an, denn die wären wohl nicht so blöd und würden dieses galaktische feature nicht implementieren!
Im übrigen finde ich es schon sehr geschmack- & respektlos wie Du hier die User angehst.
Es ist eine Sache für etwas zu brennen, aber Du muß deswegen hier nicht immer ständig alle beleidigen!!
Sorry Guido, Dein Post fing´ mit "Oh man..." an, ist nicht die diplomatischste Einleitung, oder?! Da komme ich mir gleich für doof verkauft vor.
Wir waren laut TomStg dabei dass der Recorder das über SDI zugespielte 4:2:0 UHD Signal intern auf FHD runterskalieren sollte - und wenn ihr es noch 100 Jahre in Frage stellt, das 4:4:4 (!!!!) Signal dann auch entsprechend aufzeichnen kann. Das habe ich ausgeschlossen, da Atomos gar keinen 4:4:4 Codec hat, Convergent Design dagegen schon. Deine "Begründung" dass das nicht notwendig sei weil die SDIs nur 4:2:0 sind hebt sich durch den internen Downscale aus, 4:4:4 ensteht erst durch den internen Downscale.
Ob das in der Praxis mit den Dingern intern alles funktioniert kann ich nicht sagen, aber warum fragt ihr Atomos und/oder CD zwecks Implementierung nicht einfach mal an?
10-bit würde im Zusammenhang auch einen Vorteil ergeben (Y Kanal) - wenn´s auch in keinem Fall "echtes 10-bit" werden wird.
Mein "Oh mann" war dann durch dein "4444 RAW" begründet - was es weder auf dem tom noch dem Ody gibt! 4444 ist 4:4:4 plus Alphakanal und nur aus Gründen der Codecstandards (Avid/Apple) für 4:4:4 mit an Bord, ...4 ergibt bei der Aufzeichnung aber keinen Vorteil.
...ich muss mich zudem trotzdem weiter wundern warum die meiner Ansicht nach gut erklärten einfachen Zusammenhänge entweder nicht verstanden werden oder bewußt torpediert werden. Ich werde hier kein Denkmal setzen wenn der ein- oder andere doch mal zugibt dass es ist wie es ist, denke dann hätten wir was erreicht und das Ganze würde irgendwo mal den Sinn ergeben, über Austausch vom ein- oder anderen zu lernen.
Zuletzt geändert von Roland Schulz am Do 10 Aug, 2017 17:01, insgesamt 1-mal geändert.
Roland Schulz hat geschrieben: ↑Do 10 Aug, 2017 16:15
....nochmal das Bild dazu, ziemlich genau 1 Jahr her.
diese konkrete darstellung finde ich persönlich keine sehr gute illustration, weil auch eine ziemliche wichtige rolle spielt, wie die unterabtastung genau angeordnet ist. bei 4:2:0 zeichnet man sie deshalb besser in der mitte der vier betroffenen pixel ein, damit auch dieser aspekt sinnfällig verdeutlicht wird. schließlich gibt es aus historischen gründen unterabtastungsvarianten, wo die betroffenen farbbezüge ungewöhnlich platziert sind -- mehr dazu, aber auch hinweise auf ältere hist. vorformen mit ähnlicher notation, die evtl. etwas mit wowus betrachtungsweise zu tun haben könnten, gibt's hier: http://dougkerr.net/pumpkin/articles/Subsampling.pdf
Da hast Du nicht ganz unrecht, die Abtastposition würde bei den heutigen Codecs tatsächlich eher in der Mitte zwischen den 4 Helligkeitsinformationen liegen (MPEG-1 (??)hatte das mal so wie dargestellt).
Vom Sinn und der Aussage ist die Grafik aber trotzdem richtig, zeigt so auch besser dass 3 von 4 Helligkeitsinformationen beider horiz. wie vert. Halbierung in die vierte überführt werden und an dieser Stelle nun schon die ursprüngliche Farbinformation liegt. Das sehe ich zur Darstellung als Vorteil, man erkennt auch gleich die Halbierung des Rasters.
Das Ding habe ich irgendwann mal zwischen zwei Besprechungen zusammengeschossen, finde aber die Originaldatei nicht mehr und habe keine Lust alle noch mal neu zu zeichnen.
mash_gh4 hat geschrieben: ↑Do 10 Aug, 2017 16:51
...diese konkrete darstellung finde ich persönlich keine sehr gute illustration, weil es auch eine ziemliche wichtige rolle spielt, wie die unterabtastung genau angeordnet ist. bei 4:2:0 zeichnet man sie deshalb besser in der mitte der vier betroffenen pixel ein, damit auch dieser aspekt sinnfällig verdeutlicht wird. schließlich gibt es aus historischen gründen unterabtastungsvarianten, wo die betroffenen farbbezüge ungewöhnlich platziert sind -- mehr dazu, aber auch hinweise auf ältere hist. vorformen mit ähnlicher notation, die evtl. etwas mit wowus betrachtungsweise zu tun haben könnten, gibt's hier: http://dougkerr.net/pumpkin/articles/Subsampling.pdf
Na ja, auf Seite 3, b macht er es aber GENAU SO wie ich ;-), auch jeweils oben links im 2x2er Block, ebenfalls "im Raster"!
Roland Schulz hat geschrieben: ↑Do 10 Aug, 2017 16:55 Deine "Begründung" dass das nicht notwendig sei weil die SDIs nur 4:2:0 sind hebt sich durch den internen Downscale aus, 4:4:4 ensteht erst durch den internen Downscale.
Weiß nicht warum das so schwer für Dich ist?
Wenn ein Recorder kein 444 aufzeichnen kann, braucht er auch keinen 444 Codec!!!!
Das er diesen für einen Downsale nach Deiner Methodik bräuchte steht doch ausser Frage!
Aber wie gesagt,
Atomos würde dieses feature mit Kußhand aufnehmen und dann auch einen 444 Codec zum internen verarbeiten mitbringen.
Roland Schulz hat geschrieben: ↑Do 10 Aug, 2017 16:55 Deine "Begründung" dass das nicht notwendig sei weil die SDIs nur 4:2:0 sind hebt sich durch den internen Downscale aus, 4:4:4 ensteht erst durch den internen Downscale.
Weiß nicht warum das so schwer für Dich ist?
Wenn ein Recorder kein 444 aufzeichnen kann, braucht er auch keinen 444 Codec!!!!
Das er diesen für einen Downsale nach Deiner Methodik bräuchte steht doch ausser Frage!
Aber wie gesagt,
Atomos würde dieses feature mit Kußhand aufnehmen und dann auch einen 444 Codec zum internen verarbeiten mitbringen.
Guido, was bedeutet 4:4:4??? Beschreibe das "bitte" mal mit Deinen Worten!
...wenn der Rec. UHD downscalen kann und man unbedingt in FHD aufzeichnen möchte (ergibt für mich weiterhin sehr wenig Sinn!!) würde ein 4:4:4 Codec Sinn machen!
Atomos macht das ggf. nicht weil sowohl Apple als auch AVID noch mal die Hand für die Codeclizenz aufhalten werden. CD hat zudem 4:4:4 Codecs an Bord!!
Du willst es einfach nicht verstehen oder?
Wenn der Atomos Recorder nicht in 444 sondern nur in 422 aufzeichnen kann, dann braucht der Atomos keinen Codec der 444 fähig ist.
Du hattest behauptet, wenn man diesen Codec nicht hat, könne man kein 444 Signal oder auch downgesampletes UHD 422 zu FHD 444 aufzeichnen.
Da Atomos so einen Codec nunmal nicht an Bort hat, würde auch nix aus Deiner UHD 422 zu FHD 444 Nummer!
Wäre Atomos der Meinung das Deine Theorie funktioniert,
hätten sie sicherlich diese funktion intergriert und somit dann zwangsläufig auch einen 444Codec wie ihn Convergent besitzt mitgebracht.
Aber Convergent scheint entweder zu blöde für Deine Nummer zu sein, oder sie ist ihnen genauso Schnuppe wie mir!
So, Antwort von Jim Beethe von Convergent Design erhalten: Der Ody 7Q+ kann intern kein Downscale von UHD, also fällt auch die eventuell mögliche UHD-> 4:4:4 FHD Nummer aus.
Roland Schulz hat geschrieben: ↑Do 10 Aug, 2017 18:18
Guido, was bedeutet 4:4:4??? Beschreibe das "bitte" mal mit Deinen Worten!
Oh man Roland..... ach ich sags lieber nicht!
Roland Schulz hat geschrieben: ↑Do 10 Aug, 2017 19:57
So, Antwort von Jim Beethe von Convergent Design erhalten: Der Ody 7Q+ kann intern kein Downscale von UHD, also fällt auch die eventuell mögliche UHD-> 4:4:4 FHD Nummer aus.
Und, hast Du ihn auch gefragt ob er weiß ob Deine UHD zu FHD Nummer funktioniert?
Bei einem 4:4:4 Bild findet per Definition und in Anlehnung u.A. an die ITU-R BT.2077-0, Fig.1-A3 keine Farbunterabtastung statt, d.h. jeder Pixel besitzt zusätzlich zur individuellen Y-Helligkeitsinformation eine eigene, individuelle UV-Farbinformation.
Bei einem 4:2:0 Bild findet eine Farbunterabtastung statt. Im Fall von 4:2:0 teilt sich in Anlehung u.A. an die ITU-R BT.2077-0, Fig.1-A3, jeder 2x2 Pixel (h/v) große Pixelblock eine gemeinsame Farbinformation.
Findet bei einem 4:2:0 Bild nun eine Halbierung der horizontalen wie vertikalen Auflösung statt (Downscale Faktor 2, UHD -> FHD) bleibt folglich von jedem ursprünglich 2x2 Pixel (h/v) großen Pixelblock eine gemeinsame Helligkeits- und die ursprünglich gemeinsame Farbinformation pro neuem Pixel übrig.
Jeder Pixel im Zielbild hat also wieder eine eigene Helligkeitsinformation, jetzt aber auch eine eigene Farbinformation.
Das Bild ist somit nicht mehr farbunterabgetastet -> folglich ein 4:4:4 Bild!!
Roland wie infantil bist Du eigentlich zu glauben das ich Dir hier wie ein Dackel aufs Wort parriere und Dir gebe was Du befiehlst?
Selbst WENN ich nicht gewußt hätte was 444 bedeutet, hätte ich es aus jedem erstbesten Wiki entnehmen können,
aber Du meint Doch nicht im Ernst das ich wieder und wieder auf Dein kindliches Ablenkungsmanöver eingehe?
Du weißt doch Roland, wer schon im Kindergarten nicht damit umgehen konnte,
das man ihm seine Bauklötzchenburg kaputt gemacht hat, der kann es später auch nicht,
genausau kann man solche KINDER später auch nicht leiden, da nützt auch Deine alberne Schreifettschrift nix!
Du machst Dich einfach nur noch lächerlich!
Wenn es für Dich funktioniert ist gut, aber hör auf andere damit zu belästigen, irgendwann ist gut!!
a) Wie viele Farbinformationen hat ein 2x2 Pixelblock in 4:2:0?? Antwort: 1!!!!
b) Wie viele Helligkeitsinformationen bleiben aus einem 2x2 Pixelblock übrig wenn man ihn horizontal wie vertikal halbiert? Antwort: 1!!!!
c) Welche Farbe bleibt übrig wenn man eine 2x2 Pixel große EINFARBIGE (1!!!!) "Kachel" (vgl. a) ) horizontal wie vertikal halbiert? Antwort: die gleiche eine (1!!!!) Farbe wie vorher!!!!
Guido, Du (und ein paar andere in Frage stellende) verstehst 1=1 nicht - das ist lächerlich!! Einfacher, deutlicher und nachvollziehbarer kann man es kaum mehr erklären.
Das hat auch nix mit Dackeln, Kindergarten, Bauklötzen oder Ablenkungsmanövern zu tun mit denen Du vielleicht mal negative Erfahrungen gesammelt hast sondern mit purer Provokation, Unhöflichkeit, Undankbarkeit bzw. Unbelehrbarkeit und Dummheit!
Ich sage 1 ist 1 und Du stellst dich nach Definition und Belegen durch Normen immer noch hin und sagst es ist nicht 1.
Hier können Leute in der Menge der natürlichen Zahlen anscheinend nicht 2 bzw. 1 durch 2 teilen. Da geht nix "kaputt"!! Es ergibt 1 - jeder 1te - JEDER!!!!
Schade, ich dachte wir wären hier leicht über Grundschulniveau...
Ich kann Provokation, Unhöflichkeit, Undankbarkeit und Dummheit, besonders in Kombination nicht leiden, auch nicht bei erwachsenen Kindern.
Ich komme mir hier manchmal vor wie Kinder im Zoo die Affen das Fliegen beibringen wollen.
Ich finde jeder kann mal auf nem falschen Dampfer sein, aber man sollte irgendwann mal die Eier in der Hose haben das auch einzusehen und zuzugeben, dafür wird man seltenst gehängt.
aber gan so einfach ist es dann ja auch nicht. Theoretisch stimmt es natürlich - von UHD in 420 hat genau so viele inidivduelle Farbwerte wie HD 444.
Aber so bekommst Du es ja nicht skaliert. Welchen Skalierungsfilter, in irgendeiner Anwendung, willst Du denn nutzen um genau das heraus zu bekommen? Ein Nearest Neighbour gibt Dir doch ein anderes Ergebnis als ein Bicubic, als ein Rifman, als ein Lanczos. Gleiches gilt für die Luminanz. In jedem Fall wird etwas gefiltert. Wir skalieren ja nur, und arbeiten nicht mit der CbCr information in nativer Auflösung, wo die Sache wieder etwas anders läge.
Und das bezieht noch nicht einmal mit ein, was für Falschfarben und Unreinheiten beim 420 Recording dazu gekommen sind; denn die bleiben. Dann hast zwar ein theoretisches 444 Signal, aber doch nichts zum Anfassen.
Wenn ihr zwei schon beim Eierstreit seid - kann mir jemand sagen was ich davon habe? Also nehmen wir mal an ich gehe von 8bit UHD 420 Material aus, und skaliere das zu HD - mathematisch dann mit 8bit HD 444. GUT. Nur machen die meisten dann erst wieder 8bit HD 420 drauss. Autsch, da hab ich wenig davon.
Einen Vorteil sehe ich, wenn ich keyen möchte, und das 8bit 420 UHD Material in die timeline eines HD Projekts lege. Ist meine NLE brav skaliert die runter, erledigt mit 444 das keying.
Aber gar keinen Vorteil sehe ich wenn ich in UHD Auflösung bleibe, was mit UHD-TVs mehr und mehr (langsam aber doch) kommen dürfte. Da habe ich dann von einer 10bit UHD 422 Aufzeichnung einfach mehr.
Und wenn ich als Zielformat HD will - dann filme ich auch gleich in HD 10bit 422. Können ja mehr und mehr Geräte.
Also so gesehen ist die ganze Diskussion in absehbarer Zeit überholt.
CameraRick hat geschrieben: ↑Fr 11 Aug, 2017 11:29
...Theoretisch stimmt es natürlich - von UHD in 420 hat genau so viele inidivduelle Farbwerte wie HD 444.
...
...und ich dachte schon hier wäre alles verloren ;-)!
CameraRick hat geschrieben: ↑Fr 11 Aug, 2017 11:29
Aber so bekommst Du es ja nicht skaliert. Welchen Skalierungsfilter, in irgendeiner Anwendung, willst Du denn nutzen um genau das heraus zu bekommen? Ein Nearest Neighbour gibt Dir doch ein anderes Ergebnis als ein Bicubic, als ein Rifman, als ein Lanczos. Gleiches gilt für die Luminanz. In jedem Fall wird etwas gefiltert. Wir skalieren ja nur, und arbeiten nicht mit der CbCr information in nativer Auflösung, wo die Sache wieder etwas anders läge.
Wenn meine Skalierung die Auflösung mindert, und das behauptest Du, dann ist die Skalierung vielleicht suboptimal. Darüber können wir jetzt aber wieder seitenweise diskutieren ob es sinnvoll ist mit der "Motivauflösung" die Grenzauflösung des Systems auszureizen und Aliasing etc. zu riskieren.
Ich stelle auch noch mal die Sinnhaftigkeit eines UHD Downscales in Frage - das macht ohnehin maximal dann Sinn wenn meine Kette nur FHD weiterverarbeiten bzw. darstellen kann, dass dann mindestens 4:2:2 oder besser 4:4:4 ist.
CameraRick hat geschrieben: ↑Fr 11 Aug, 2017 11:29
Und das bezieht noch nicht einmal mit ein, was für Falschfarben und Unreinheiten beim 420 Recording dazu gekommen sind; denn die bleiben. Dann hast zwar ein theoretisches 444 Signal, aber doch nichts zum Anfassen.
Es ist kein theoretisches 4:4:4 Signal sondern ein echtes praktisches! Jeder Pixel hat eine eigene Farbinformation - mehr sagt 4:4:4 nicht aus, es sagt nichts über irgendwelche Fehler aus die irgendwie irgendwo mal da reingekommen sind!
Auch der Ansatz den mash_gh4 hier teilweise verfolgt ist richtig bzw. ist die Behauptung von Wowu falsch in der er sagt, dass zwischen einem grünen und einem roten Pixel durch Farbunterabtastung immer ein gelber Pixel entsteht. Ist der drin bleibt der beim Downscale "wahrscheinlich" (nicht mehr) auch drin, er muss aber nicht zwingend entstanden sein!! Das hängt nur von der Methode ab welche die Farbunterabtastung, die Reduktion der Farbauflösung vornimmt.
Aber nochmal, die Effekte die entstehen können sind nicht systembedingt an 4:4:4 oder 4:2:2 oder 4:2:0 gekoppelt. 4:4:4 sagt nur aus, dass jeder Pixel im Bild eine eigene, individuelle Farbinformation annehmen kann. Was man da reinpackt und wie es vorher ggf. versaut wurde spielt keine Rolle!
Ob ein downgescaletes 4:4:4 Bild einer ursprünglichen 4:4:4 Aufnahme exakt entspricht habe ich nie behauptet oder in Frage gestellt, wobei in nativen 4:4:4 Aufnahmen auch Effekte entstehen können die eigentlich theoretisch in 4:4:4 nicht entstehen würden (Effekte aus Debayering, Pixelshifting etc...).
Wenn Du etwas herunterskalierst, dann verminderst Du die Auflösung nun mal irgendwie... :) wie willst Du denn sonst 3/4 der Information weg geben, ohne die Auflösung zu vermindern? Wie ginge es optimaler?
Es ist kein theoretisches 4:4:4 Signal sondern ein echtes praktisches! Jeder Pixel hat eine eigene Farbinformation - mehr sagt 4:4:4 nicht aus, es sagt nichts über irgendwelche Fehler aus die irgendwie irgendwo mal da reingekommen sind!
Aber so läuft es eben nicht. Mathematisch, ja, hast Du ja schon schön ausgeführt. Aber so läuft es ja nicht im Programm.
Welches Programm belässt Die denn die CbCr Kanäle in ihrer nativen Auflösung, sodass Du nur noch den Luma-Kanal herunterskalierst (auf welche Weise jetzt auch immer)? Mir ist keine bekannt. Du arbeitest immer schon auf der aufgeblasenen Datei mit interpolierten Werten. Es sind ja nicht mal die echten nativen Infos, die Du da bekommst, sondern skalierte Interpolierte. Das ist ein großer, qualitativer Unterschied.
Wenn Du jetzt nur auf dem Grundsatz herum reiten willst dass 444 bedeuted dass es individuelle Werte gibt könntest Du auch nur einen leichten Blur auf die CbCr Kanäle legen und erneut als .dpx heraus rendern, da ist jeder Pixel indivuell, aber das ist ja nicht Sinn der Sache.
wolfgang hat geschrieben: ↑Fr 11 Aug, 2017 11:43
Wenn ihr zwei schon beim Eierstreit seid - kann mir jemand sagen was ich davon habe? Also nehmen wir mal an ich gehe von 8bit UHD 420 Material aus, und skaliere das zu HD - mathematisch dann mit 8bit HD 444. GUT. Nur machen die meisten dann erst wieder 8bit HD 420 drauss. Autsch, da hab ich wenig davon.
Einen Vorteil sehe ich, wenn ich keyen möchte, und das 8bit 420 UHD Material in die timeline eines HD Projekts lege. Ist meine NLE brav skaliert die runter, erledigt mit 444 das keying.
Aber gar keinen Vorteil sehe ich wenn ich in UHD Auflösung bleibe, was mit UHD-TVs mehr und mehr (langsam aber doch) kommen dürfte. Da habe ich dann von einer 10bit UHD 422 Aufzeichnung einfach mehr.
Und wenn ich als Zielformat HD will - dann filme ich auch gleich in HD 10bit 422. Können ja mehr und mehr Geräte.
Also so gesehen ist die ganze Diskussion in absehbarer Zeit überholt.
Hallo Wolfgang,
es ging mir primär um den technischen Aspekt - und der gilt und steht!
Andere (Panasonic DVX200 unter Barry Green) haben ja auch hier und da mit firmeneigenen "Tech Sheets" die Werbetrommel gerührt, da allerdings falsch in dem aus 8-bit noch 10-bit wurde (was allein auf die Farbkanäle bezogen falsch ist).
"Meine Meinung" zum Downscale habe ich mehrfach wiederholt - man gewinnt hier nichts, im Gegenteil! Wenn meine Kette nur FHD, dann aber min 4:2:2 oder gar 4:4:4 kann hat man nen gewissen Benefit, sonst ist das Quatsch und eigentlich falsch!!
Ich gewinne keine Informationen, ich minimiere nur Verluste bei einem ggf. erforderlichen Downscale.
Ich finde es nur interessant dass viele den Zusammenhang bzw. 4:2:2/4:4:4 FHD aus 4:2:0 UHD als so wichtig und interessant und "unerreichbar" ansehen - viele haben einfach nicht verstanden was da passiert. "4:4:4 können nur die allerüberbesten Highendkameras" - in den Specs und im Codec! "Das soll man jetzt mit ner "normalen" Cam erreichen?!"
KAUM EINE (bis keine) Highendkamera erreicht "echtes" 4:4:4! Der Codec oder das Aufzeichnungsformat vielleicht, der debayernde Sensor oder der Pixelshiftalgorithmus usw. aber nicht.
Davon ab erreichen die meisten Kameras auch kaum "echtes" 4:2:0. Die Systemgrenzauflösung stellt eigentlich kein System dar - das wäre bezogen auf Aliasing auch nicht unbedingt wünschenswert.
wolfgang hat geschrieben: ↑Fr 11 Aug, 2017 11:43
Also nehmen wir mal an ich gehe von 8bit UHD 420 Material aus, und skaliere das zu HD - mathematisch dann mit 8bit HD 444. GUT. Nur machen die meisten dann erst wieder 8bit HD 420 drauss. Autsch, da hab ich wenig davon.
im amateur und broadcastumfeld stimmt das sicher, aber wenn du z.b. saubere 2K DCPs als ausgabe anstrebst, wie sie bei einreichungen für festivals heute üblich ist, kommt 4:4:4 auch im finalen resultat eine relevante rolle zu. diesen anwendungsfall halte ich im übrigen fast für realistischer bzw. bedeutsamer als die eignung fürs keyen.
CameraRick hat geschrieben: ↑Fr 11 Aug, 2017 12:30
Welches Programm belässt Die denn die CbCr Kanäle in ihrer nativen Auflösung, sodass Du nur noch den Luma-Kanal herunterskalierst (auf welche Weise jetzt auch immer)? Mir ist keine bekannt.
wie schon zwei mal hier erwähnt, gibt es mittlerweile eine ganze menge tools, wie man sie normalerweise zur generierung von all-intra intermediates nutzt (hybrid, dali...), die derartiges, aber auch die in diesem zusammenhang sinnvolle ausschöpfung einer größeren bittiefe, quasi auf knopfduck bzw. mit dafür fertig vorbereiteten transcoding-profilen abzuwickeln erlauben. es ist wirklich ganz dem anwender überlassen, ob er sich die damit verbundenen etwas längeren berechnungszeiten und verhälnismäßig platzraubenden zwischenformate antut.
wie weit derartige zusätzliche schritte aber überhauot nötig sind, wenn die genutzte software für die endbearbeitungs alles sauber macht, ist allerdings wieder ein ganz ander frage -- dort kommt dann nämlich wieder jener ganze einfache theoretische zusammenhang zum tragen, von dem roland hier spricht, denn fast alle diese programme arbeiten intern im RGB raum und brauchen einfach nur die nötige info für alle zur weiteren berechnung notwendigen pixel.
mash_gh4 hat geschrieben: ↑Fr 11 Aug, 2017 13:20
wie schon zwei mal hier erwähnt, gibt es mittlerweile eine ganze menge tools, wie man sie normalerweise zur generierung von all-intra intermediates nutzt (hybrid, dali...), die derartiges, aber auch die in diesem zusammenhang sinnvolle ausschöpfung einer größeren bittiefe, quasi auf knopfduck bzw. mit dafür fertig vorbereiteten transcoding-profilen abzuwickeln erlauben. es ist wirklich ganz dem anwender überlassen, ob er sich die damit verbundenen etwas längeren berechnungszeiten und verhälnismäßig platzraubenden zwischenformate antut.
Ich bezweifle halt ein wenig, dass genau das passiert. Es sind eben Transcoding-Profile, und ich habe Schwierigkeiten zu glauben dass da mit nativen Kanälen gearbeitet wird. Und das klärt ja auch nicht die Frage, wie skaliert wird, welcher Filter, wie aggressiv. Ich hab immer das Gefühl dass hier "Skalierung" immer nur als Regler betrachtet wird, und nicht als eine Operation die man auch ordentlich verhunzen kann.
CameraRick hat geschrieben: ↑Fr 11 Aug, 2017 12:30
Wenn Du etwas herunterskalierst, dann verminderst Du die Auflösung nun mal irgendwie... :) wie willst Du denn sonst 3/4 der Information weg geben, ohne die Auflösung zu vermindern? Wie ginge es optimaler?
Völlig richtig bezogen auf den Lumakanal im Downscale - die Infos aus dem Chromakanal möchten wir aber möglichst erhalten wenn die Zielmatrix das hergibt - und diese entspricht eben genau der Farb-Quellmatrix in UHD!
CameraRick hat geschrieben: ↑Fr 11 Aug, 2017 12:30
Es ist kein theoretisches 4:4:4 Signal sondern ein echtes praktisches! Jeder Pixel hat eine eigene Farbinformation - mehr sagt 4:4:4 nicht aus, es sagt nichts über irgendwelche Fehler aus die irgendwie irgendwo mal da reingekommen sind!
Aber so läuft es eben nicht. Mathematisch, ja, hast Du ja schon schön ausgeführt. Aber so läuft es ja nicht im Programm.
Welches Programm belässt Die denn die CbCr Kanäle in ihrer nativen Auflösung, sodass Du nur noch den Luma-Kanal herunterskalierst (auf welche Weise jetzt auch immer)? Mir ist keine bekannt. Du arbeitest immer schon auf der aufgeblasenen Datei mit interpolierten Werten. Es sind ja nicht mal die echten nativen Infos, die Du da bekommst, sondern skalierte Interpolierte. Das ist ein großer, qualitativer Unterschied.
Das ist maximal statistisch "überprüfbar" - bzw. ist die Anwendung "schlecht".
Anders: Wenn du eine Linie in einem Diagramm o.ä. in Photoshop mit Near Neighbour runterskalierst hat jeder Pixel eine eigene Farbe, die mit dem nächstgelegenen nichts zu tun haben muss.
Deine Ausgangsgrafik (synthetisches Balken-, Säulen- etc. Diagramm o.ä.) kann aber als 4:2:0 JPEG übergeben worden sein/vorgelegen haben.
Near Neighbor ist möglich und manchmal auch gar nicht so verkehrt, kann zumindest die Systemgrenze erreichen.
Alle anderen Algorithmen oder Filterungen/Glättungen sind in irgendeiner Form aber auch in jeder anderen Form der Aufnahme etc. zu erwarten, sonst kriegst du da bereits Aliasing! Es ändert sich also nichts, zudem ändert sich weiterhin auch nichts daran dass jeder Pixel im Ziel weiterhin eine eigene Farbe annehmen kann. Diese kann ja nach Filterung als Farbe sogar zwischen den Farben der ursprünglich benachbarten Pixel liegen. Ein 4:2:0 kann einem benachbarten Pixel aber gar keine andere Farbe sondern nur eine andere Helligkeit geben. Erst jeder zweite Pixel kann hier eine andere Farbe annehmen! Vorteil 4:4:4 auch beim Downscale mit "Filterung"!
CameraRick hat geschrieben: ↑Fr 11 Aug, 2017 12:30
Wenn Du jetzt nur auf dem Grundsatz herum reiten willst dass 444 bedeuted dass es individuelle Werte gibt könntest Du auch nur einen leichten Blur auf die CbCr Kanäle legen und erneut als .dpx heraus rendern, da ist jeder Pixel indivuell, aber das ist ja nicht Sinn der Sache.
Wenn man das auf ein 4:2:0 UHD Bild anwendet muss das Zielformat ebenfalls 4:4:4 sein, tatsächlich kriegt dann jeder Pixel ne andere Farbe und es ist 4:4:4 - allerdings geblurt und damit in geringerer Auflösung als die Zielmatrix (UHD) hergeben würde - noch unsinniger als UHD > FHD. Es ist aber trotzdem ein 4:4:4 Bild, in 4:2:0 würde der Blur Effekt andere Inhalte annehmen!
"Ich" halte "diese Betrachtung" allerdings für völlig sinnfrei ;-), der Nutzen erschliesst sich mir überhaupt nicht.
CameraRick hat geschrieben: ↑Fr 11 Aug, 2017 13:32
Ich bezweifle halt ein wenig, dass genau das passiert. Es sind eben Transcoding-Profile, und ich habe Schwierigkeiten zu glauben dass da mit nativen Kanälen gearbeitet wird.
schau, das hybrid ist doch einfach nur ein GUI, das im hintergrund ffmpeg für die eigentliche abwicklung konfiguriert. die profile die es dazu dann letztendlich benutzt, kann man sehr einfach überprüfen. und im gegenständlich fall nutzt es eben jene ziemlich komplizierten befehlszeilen, wie sie hier ausgetüftelt und beschrieben wurden: http://www.personal-view.com/talks/disc ... ress-topic
CameraRick hat geschrieben: ↑Fr 11 Aug, 2017 13:32
Und das klärt ja auch nicht die Frage, wie skaliert wird, welcher Filter, wie aggressiv. Ich hab immer das Gefühl dass hier "Skalierung" immer nur als Regler betrachtet wird, und nicht als eine Operation die man auch ordentlich verhunzen kann.
auch das kannst du an den konkret benutzen ffmpeg-befehlen sehr genau nachvollziehen, studieren und ggf. ganz nach deinen wünschen und verbesserungsvorstellungen modifizieren.
ich persönlich finde es in diesem zusammenhang allerdings wichtiger, dass man sich hier ein bisserl vom ganz einfachen pixelzählen und bilderbuchbeispielen löst und wenigstens ansatzweise einzubeziehen und verstehen lernt, wie derartige dinge in komplizierterer aktueller software, etwa im zusammenhang mit shadern, abgewickelt werden. das ist nämlich insofern wichtig, als hier nicht so sehr die ausgangsauflösung die entscheidende rolle für den ablauf der verarbeitung bildet, sondern die zu generierenden pixel des zielformats. die werden im idealfall möglichst unabhängig von ihrer umgebung behandelt, so dass die dafür notwendigen operationen auch parallel auf den unzähligen recheneinheiten der grafikkarte durchgeführt werden können. für einen zu generierenden ausgabepixel greifen die entsprechenden berechnungen nur auf jene paar pixel im ursprünglichen ausgangsbild zu, die dafür unbedingt notwendig sind. das kann bei skalierungen sehr oft überlappungen von benachbarten pixeln bzw. entsprechende interpolation zw. ihnen bedingen, trozdem kommt auch hier zum tragen, dass eben die vier quadratisch benachbarten pixel in 4:2:0 ausgangsmaterial die selbe farbinfomation zeigen. es ist also nicht unbedingt notwendig, dass man die betreffenden barbeitungsschritte ganz modellhaft voneinander isoliert und getrennt abwickelt, sondern es stellen sich einfach auch auf anderem weg ganz die selben folgen ein, wenn benachbarte pixel im ausgansmaterial die selbe information beihalten -- dort kommt dann eben mehr der theoretisch begründete zusammenhang zu tragen als die überschwängliche begeisterung für das spiel mit der modelleisenbahn.
für diejenigen, die sich für solche sachen interessieren bzw. auch die technischen hintergründe und optimierungsmöglichkeiten verstehen wollen, ist es vieleicht ganz spannend, einen blick in das kapitel "C-7 Image formats and color spaces in Mistika" (s. 30ff) im mistka benutzerhandbuch zu werfen. das ist nämlich insofern spannend, also dort -- im gegensatz zu vielen anderen programmen, wo das vor den benutzern oft völlig geheim gehalten wird -- ziemlich genau erklärt wird [obwohl manches darin vermutlich schon ein bisserl veraltet und überholt sein dürfte], wie derartige farbunterabtastung vom programm genutzt wird um die I/O-last auf ein minimum zu reduzieren bzw. warum man sich auch im rahmen des intern genutzten datenformats möglichst nahe an den technischen gegebenheiten der SDI ein- und ausgabedatenströmen zu orientieren versucht. ganz klar wird dabei aufgezeigt, warum hier etwa die nutzung von 10bit statt 8bit od. eine geringere farbunterabtastung unweigerlich zu massiven performanceverschlechterungen führen muss...
ich finde derartiges immer ausgesprochen interessante und hilfreich, um gewissermaßen mit einsicht und rücksichtnahme auf die tatsächlichen technischen gegebenheiten der programme ein maximum herauszuholen, statt mit dem kopf gegen die wand zu rennen und sich mit falschen erwartungen bzw. ineffizienten workflows das leben unnötig schwer zu machen.
..."YUVA 4:4:4:4 at 10 bits per canal" das kommt mir spanisch vor ;-)...
Sehr gut mash_gh4!!! Das Ding ist wirklich nicht schlecht, für die 100%igen dann wo wir hier auch nah an der Theorie und Definition waren aber an der ein- oder anderen Stelle auch schon mal etwas holperig wenn z.B. YUV 4:2:2 als "unkomprimiertes" Format geführt wird wo Farbunterabtastung vielleicht eine der ältesten Formen der Bandbreitenreduktion überhaupt ist.
Vielleicht ist das einfach schon zu selbstverständlich geworden...
Roland Schulz hat geschrieben: ↑Sa 12 Aug, 2017 15:37
..."YUVA 4:4:4:4 at 10 bits per canal" das kommt mir spanisch vor ;-)...
ja, mir sind auch ein paar winzige ungereimtheiten aufgefallen [bspw. auf s.32: "RGB 4:4:4 linear at 8 bits per channel. (3 bytes per channel)"], über dich lieber schulterzuckend hinweggelesen hab... aber das ändert meines erachten nichts am tatsächlich informativen bzw. nützlichen gehalt.
Rechtliche Notiz: Wir übernehmen keine Verantwortung für den Inhalt der Beiträge
und behalten uns das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
