carstenkurz hat geschrieben: ↑Di 26 Jan, 2021 13:51
Das Argument ist bullshit, und das weisst Du auch. Sofern mir die nötigen Durchgriffsmöglichkeiten auf die Grafikausgabe gewährt werden (da braucht's nicht viel), reicht natürlich notfalls ein Raspberry PI Zero als Testsignalgenerator. Und ähnlich rudimentär kriegt man auch die Zugriffe für so eine Spezialanwendung unter einem notfalls handgetunten Linux hin.
Das ist aber was ganz Anderes, als bei einer Videoschnittanwendung aus verschiedensten Gründen auf den Unterbau eines vollständigen Betriebssystems mit nicht umgehbarer Treiberarchitektur und Grafik-APIs setzen zu MÜSSEN. Und da beisst sich deine Argumentation in den ***, genau DESWEGEN gibt es die Decklink Karten, weil BMD bei denen vollkommen frei selbst entscheiden kann, was auf die Leitung geht.
nein -- man braucht wirklich nicht viel!
die meisten video-ausgaben nutzen techniken, die in cantsins diagramm ganz rechts angeordnet sind -- d.h. sie überspringt die GUI-zwischenschichten bzw.
retained mode grafik aufbereitung und kommunzieren relativ harwarenah mit der GPU. das geschieht mittlerweile unter linux und windows derart ähnlich, dass man im genannten diagramm problemlos manche bezeichnungen einfach abändern könnte, und es würde perfekt auf das andere system zutreffen.
bei der ausgabe in einzelne fester od. bildschirmbereiche sind ohnehin einige beschränkungen vorgegeben, die nicht on-the-fly geändert werden können, ohne alles umgebende völlig durcheinander zu bringen, aber zumindest im full-screen mode, wie man ihn sinnvollerweise auch zum abspielen von clips in ganz einfachen video-playern nutzen sollte, um ein möglichst befriedigende darstellung zu erhalten, fallen viele dieser einschränkungen völlig weg.
uns geht's hier aber ohnehin nur um die farben.
die werden heute praktisch in jeder ernsthaften video-anwendung nicht mehr in der selben weise behandelt, wie man sie über das kabel an video-monitore schickt (also in YCbCr codierung mit ganzzahligen 8- od. 10bit-bit werten), sondern im regelfall als RGB in 32bit-fließkommadarstellung und bei den besseren programmen auch noch in relativ großen linearen bearbeitungsfarbräumen, die charakteristiken aufweisen, die mit den physikalischen gesetzmäßigkeiten der farbmischung besser harmonieren als es bei operationen innerhalb typischer display referred farbräume bzw. werteangaben, wie man sie im monitorkabel antrifft, der fall wäre. erst am ende der verarbeitungskette werden die bilder dann doch wieder in solch einfache werteangaben übersetzt, die man über normierte übertragungsprotokolle (HDMI etc.) an die ausgabegeräte schickt.
wäre letzteres nicht ganz klar spezifiziert und technisch sehr eng festgelegt, würden geräte verschiedener hersteller wohl kaum austauschbar die selben bilder zeigen.
ich glaub, so weit ist uns das allen aus dem alltag vertraut, dass man an diesen ganz elementaren errungenschaften des fortschritts und der techn. standardisierung nicht unbedingt zweifeln muss.
was nun die frage einer möglichst korrekten farbwiedergabe betrifft, gibt's tatsächlich ein paar feinheiten, die auf den ersten blick überraschen bzw. mit feinheiten der entsprechender ausgabetechniken zu tun haben.
so arbeite z.b. OpenGL grundsätzlich colorspace agnostic -- d.h. die RGB fließkommawerte mit denen man dort operiert, sind nicht ohne weites und direkt in sinnvolle farbangaben am monitor zu übersetzten. den notwendigen kontext einer korrekten zuordnung, verwaltung der referenzangaben für ein- und ausgaben anderer bildquellen und die notwendigen umrechnung muss tatsächlich die anwendung selbst unter zuhilfenahme div. dafür geeigneter hilfsmittel bereitstellen. das ändert aber nichts daran, dass es für eine derartige anwendung trotzdem eine relative triviale anforderung bleibt, am ende dann doch wieder nur ein tripple aus drei zahlenwerten an den monitor zu schicken -- und dieses geht dann, wenn man einige details beachtet, auch tatsächlich in genau dieser weise ohne großartige veränderungen, vor denen man sich fürchten müsste, dorthin raus!
es wirklich ziemlich erhellend, wenn man sich anschaut, wie das dafür notwendige vorgehen bzw. zusammenspiel mit der systemweiten-farbverwaltung in div. apple entwicker-anleitungen am beispiel von OpenGL und anderer non-color managed frameworks beschreiben wird:
https://developer.apple.com/library/arc ... NT_EXAMPLE
die apple doku macht hier deshalb sinn, weil dort systemweites color-managment schon länger eine selbstverständlichkeit darstellt, weil man ja sonst kaum seine kunden mit eingebauten P3-diplays zufriedenstellen könnte.
natürlich ist die ganze geschichte im detail dann doch wieder relativ kompliziert, auf allen systemen wieder ein klein wenig anders und voller fallstricke und stolpersteine. trotzdem -- von einem programm wie resolve, muss man einfach erwarten, dass es diese aufgabe befriedigend bewältigt und tatsächlich eine brauchbare farbvorschau bietet. ohne diesen punkt einzulösen, bleibt das ganze ein lustiges spiel mit bunten farben, dem jeder feste grund und orientierungsrahmen fehlt.
wie gesagt, es gibt wirklich genug programme, die das deutlich befriediegender umsetzten.
