cantsin hat geschrieben: ↑Fr 26 Feb, 2021 18:57
Ich sehe Linux als Video-Workstation-Betriebssystem gerade - leider - am Scheideweg, weil auf Systemebene die Entwicklungen momentan nicht gut laufen (mal abgesehen vom mittlerweile jahrzehntealten Drama unzulänglicher Open Source-Schnittsoftware).
natürlich kann ich dir hier in den meistsen punkten nicht ernsthaft widersprechen bzw. teile deine unzufriedenheit natürlich über weite strecken.
cantsin hat geschrieben: ↑Fr 26 Feb, 2021 18:57
Bei MacOS gibt's mittlerweile Display-P3 (+ Colorsync), bei Windows mit Nvidia-Karten mittlerweile den Nvidia-Studio-Treiber mit 10bit-Bildschirmansteuerung, sowie Windows-interner HDR-Unterstütztung.
die 10bit opengl- und vulkan-ausgabe über nvidia-karten und intel grafik geht im prinzip unter linux schon recht lange, nur gibt's leider im zusammenspiel mit vielen anwendungen, die das nicht wahrhaben wollen, noch immer recht ungute begleiterscheinungen bzw. probleme. ganz speziell betrifft das chrome, und damit auch alle elekron-anwendungen (also zb. auch editoren wie atom od. vscode). die zeigen im falle einer 10bit X11 umgebung nur mehr ganz verrückte farben...
dort aber, wo man ohnehin nur eine bildschirmfüllende saubere video- oder bildvorschau auf einem der schrime benötigt, ist das kein ernsthaftes problem. dort ist derartiges also tatsächlich auch jetzt bereits sauber bzw. mit jeder art von kalibrierungskorrekturen nutzbar.
cantsin hat geschrieben: ↑Fr 26 Feb, 2021 18:57
Linux bleibt nicht nur auf 8bit hängen, sondern verliert mit der Umstellung von X11 auf Wayland und dem verwaisten (und auf aktuellen Distributionen nicht mehr laufenden) DisplayCal seine Farbkalibrierungs-Fähigkeiten.
auf den ersten blick mag das zwar so erscheinen, aber dafür löst eben wayland und noch viel mehr
pipewire ganz wichtige probleme, um den video-zugriff deutlich sicher zu gestalten und entsprechende anwendungen vernünftig in sandboxed envrionments zu packen.
gerade im zusammenhang mit closed source anwendungen, die regelmäßig ohne zustimmung des nutzers nach hause telefonieren und mit großem selbstvertrauen bzw. fast unbeschränkten zugriffsrechten tür und tor für angriffe von außen öffenen, ist das eine nicht zu unterschätzende errungenschaft.
im hintergrund wird allerdings ohnehin bereits daran gearbeitet, auch diesen neuen ausgabemöglichkeiten wieder zeitgemäßere darstellungsmöglichkeiten zu eröffnen.
in der praxis verhält es sich dabei ähnlich wie bei den consumergeräten. man ist also vordergründig gar nicht so sehr an unseren völlig übertrieben ansprüchen in puncto bittiefe und farbtreuheit interessiert, sondern versucht einfach nur gängige HDR wiedergabe zu ermöglichen bzwd dem angebot der unterhaltungsindustrie gerecht zu werden. dabei fällt quasi unser steckenpferd nur ganz am rande als nebenprodukt ab. prinzipiell ist aber auch in wayland und dem darunter werkenden DRM zumindest 16bit farbtiefe bereits jetzt verfügbar.
https://gitlab.freedesktop.org/swick/wa ... /color.rst
https://www.collabora.com/news-and-blog ... mic-range/
was übrigens dein klagen über die python3 inkompatibilität im displaycal vor einiger zeit betrifft, habe ich mir die sache mittlerweile einmal näher angeschaut. das eigentliche problem dabei ist leider gar nicht so sehr die python3 umstellung, sonder das dort verwendete WxPython. das herumärgern mit dieser software würde ich mir ehrlich gestanden auch lieber ersparen. :(
gleichzeitig war das aber auch wieder ein anstoß, mir den code von AgyllCMS wiedereinmal ein bisserl näher anzuschauen, und ein paar relvante teile versuchsweise nach webassembly zu übersetzten, was problemlos funktioniert!
damit eröffenen sich ganz interessante möglichkeiten! -- weshalb es auf meinen schreibtisch seither ungefähr so aussieht:
farben.jpg
bei den kleinen dingern links vorne im bild handelt es sich um winzige XYZ-farb- und spektralsensoren, mit denen man vermutlich auf recht günstige weise und in noch höherer qualität als mit den bekannten fertigprodukten eine saubere farbkalibrierung mit freien mitteln hinbringen dürfte -- rundum natürlich jede menge chaos um via WLAN+Raspi per JTAG die verwendeten RISC-V µCs mit rust code zu füttern, etc. ;)
schau ma einmal, ob dabei über kurz od. lang wirklich etwas brauchbares herauskommt, oder sich letztlich doch wieder unüberwindbare schwierigkeiten in den weg stellen?
cantsin hat geschrieben: ↑Fr 26 Feb, 2021 18:57
Das es so läuft, ist natürlich kein Zufall, sondern liegt daran, dass die Linux-Entwicklung heute massiv industriegetrieben und -finanziert ist (übrigens mit Microsoft als einer der größten Kräfte) und da das Interesse ausschließlich auf Server/Cloud- sowie Embedded/Mobil/Industrie-Systemen (Android & Co.) liegt.
ja -- in dem punkt stimme ich dir leider weitestgehend zu -- wobei es halt neben der industrie auch noch das akademische umfeld gibt, von dem weiterhin deutlich innovativeres in die frei software szene einfließt, und durchaus auch ein paar ganz interessante fördertöpfe existieren, um andere dinge zu entwickeln, wenn man damit nicht unbedingt sofort reich werden will, sondern sich vielmehr damit begnügt, schlecht od. recht zu überleben.
ganz so pessimistisch bin ich also dann letztlich doch wieder nicht, auch wenn es natürlich im augenblick kaum etwas herausragendes zu vermelden gibt, dass uns allen wieder neue hoffung geben würde.
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.