Infoseite // Blackmagic DaVinci Resolve 17 ist final

Newsmeldung von slashCAM:



Am 9. November hat Blackmagic die Version 17 seines beliebten Grading-/Editing-/Finishing-/Compositing- und Audiopost-Programms angekündigt und zu diesem Termin die typis...



Hier geht es zur Newsmeldung auf den slashCAM Magazin-Seiten:
Blackmagic DaVinci Resolve 17 ist final



Antwort von lensoperator:

Und im Vergleich

What's new in Blackmagic Fusion Studio 17
Anim curves modifier for convenient easing and shaping of animations.
Support for user customization of the Fusion toolbar above the node editor.
Initial support for a GPU accelerated 2D shapes toolkit for motion graphics.
Improved optical flow behavior in Fusion tools.
Support for bookmarks to switch between different views in the node editor.
Support for activation keys for Fusion Studio.
Support for improved inspector with tabs and keyframes.
Multiple performance and stability improvements.

Wird Fusion Studio sterben?
Und warum machen die es nicht so das zumindest in beiden Version die selben Features sind?

Gibt mir leider noch keine Motivation AfterFx aus der Cloud zu werfen.



Antwort von cantsin:

IMHO das nützlichste neue Feature sind die HDR-Grading-Drehregler. Im Gegensatz zu ihrem Namen sind sie nicht nur für HDR-Grades extrem nützlich, sondern auch für konventionelle SDR-Grades, weil man mit ihnen jeweils die Helligkeit sowie die Farbsättigung von Schatten, Mitten und Spitzlichtern sehr einfach korrigieren kann, ohne dass es (wie bei Lift/Gamma/Gain) weitere Auswirkungen aufs Bild hat. D.h. im Gegensatz z.B. zu einer Gamma-Absenkung verändert die HDR-Tools-Helligkeitsabsenkung der Mitten nicht die Farbsättigung des Gesamtbilds.

Was noch immer nervt, sind diverse Unzulänglichkeiten und Bugs des Untertitel-Editors (u.a.: einmal definierte Stile können nicht gespeichert und wiederverwendet bzw. nur mit Tricks auf andere Untertitel-Spuren angewendet werden, Copy-Paste fügt Text zweimal ein, Anführungszeichen lassen sich nicht eintippen.)



Antwort von Frank Glencairn:

cantsin hat geschrieben:
Anführungszeichen lassen sich nicht eintippen.)
16142679445028820173430572394470.jpg



Antwort von MK:

Die Keycard die heute kam ist auch schon mit Resolve 17 bedruckt... wurde wohl schon 2020 hergestellt dem Copyright-Hinweis nach zu urteilen :D



Antwort von Bruno Peter:

Hat schon jetzt jemand überprüft ob aus der "Delivery" heraus gleichwertige h.264 - Videoqualität wie im Falle Handbrake exportiert werden kann?



Antwort von Frank Glencairn:

Ja, vor allem erstaunlich schnell (bei mittelprächtigen EInstellungen) - bis zu 40 FPS auf einem recht alten Hobel.



Antwort von mash_gh4:

"Bruno Peter"]Hat schon jetzt jemand überprüft ob aus der "Delivery" heraus gleichwertige h.264 - Videoqualität wie im Falle Handbrake exportiert werden kann? [quote="Frank Glencairn" hat geschrieben:
Ja, ... auf welche weise hast du die qualität überprüft?



Antwort von Frank Glencairn:

Optisch






Antwort von mash_gh4:

"Frank Glencairn" hat geschrieben:
Optisch ok. -- dann vergessen wir das am besten schnell wieder...

es ist zwar nicht gesagt, dass man nicht auch mir anderen codecs tatsächlich die selbe qualität wie mit libx264 erreichen kann, oder BMD endlich eine lizenz für diese freie lösung erworben hat, aber so einfach und freihändig lässt sich das auf keinen fall beurteilen.



Antwort von Frank Glencairn:

mash_gh4 hat geschrieben:

ok. -- dann vergessen wir das am besten schnell wieder...

... aber so einfach und freihändig lässt sich das auf keinen fall beurteilen.
Warum?
mash_gh4 hat geschrieben:

es ist zwar nicht gesagt, dass man nicht auch mir anderen codecs tatsächlich die selbe qualität wie mit libx264 erreichen kann, oder BMD endlich eine lizenz für diese freie lösung erworben hat, Natürlich ist das libx264.
BM stellt sowieso nur die Schnittstelle zur Verfügung, das x264 plugin ist von einem Forenmitglied, wie auch das DPP AS-11 Plugin. MainConcept bastelt gerade an eigenen Implementationen (HEVC 8K z.B.)



Antwort von mash_gh4:

"Frank Glencairn" hat geschrieben:
mash_gh4 hat geschrieben:

ok. -- dann vergessen wir das am besten schnell wieder...

... aber so einfach und freihändig lässt sich das auf keinen fall beurteilen.
Warum? weil man so etwas mit den dafür gebräuchlichen metriken beurteilt.
genauso, wie man halt zur beurteilung belichtiung vernünftigerweise auch hin und wieder einen belichtungsmesser zu rate zieht, statt einfach zu behaupten: "passt schon -- optisch!"

eine derartige sauber nachvollziehbare qualitätsmessung ist auch nicht sonderlich kompliziert. ich hab's hier im forum ohnehein bereits einige male erklärt.
"Frank Glencairn" hat geschrieben:
mash_gh4 hat geschrieben:

es ist zwar nicht gesagt, dass man nicht auch mir anderen codecs tatsächlich die selbe qualität wie mit libx264 erreichen kann, oder BMD endlich eine lizenz für diese freie lösung erworben hat, Natürlich ist das libx264.
BM stellt sowieso nur die Schnittstelle zur Verfügung, das x264 plugin ist von einem Forenmitglied, wie auch das DPP AS-11 Plugin. MainConcept bastelt gerade an eigenen Implementationen (HEVC 8K z.B.) so einfach geht das nicht!

man kann zwar eine kommerzielle lizenz von x264 erwerben, und braucht zusätzlich auch noch eine von den mpeg-verwertern, ansonsten darf man das zeug nicht in einer closed source anwendung nutzen!

die GPL untersagt auch ganz eindeutig eine nutzung in form von plugins bzw. dynamisch geladenen code in unfreien programmen!

nur über den umweg externer prozesse kann man das tlw. umgehen, aber dafür ist das eine technisch nicht besonders hübsche variante, die auch performance-nachteile mit sich bringt. aber gut, BMD trau ich bekanntlich jede blödsinn zu, wenn er sich nur möglichst billig gestaltet und nicht die geringsten zugeständnisse im hinblick auf die öffnung der eigenen software abverlangt.

die main concept codecs sind jedenfalls aus diesem grund schon seit jahren die gebräuchlichste alternative, die ohnehin in den meisten käuflichen video-anwendungen genutzt wird.



Antwort von rdcl:

Welche Probleme kann man denn mit h264 haben? Egal ob Resolve, oder Media Encoder, oder sogar Avid, ein fertiger Film als h264 mit ausreichender Datenrate unterscheidet sich 0,0 von einem fertigen Prores oder DNxHD. Ich habe das schon unzählige Male übereinander verglichen. Solange man das mp4 nicht weiter bearbeitet geht das doch mittlerweile mit jedem Programm optisch vollkommen verlustfrei.



Antwort von Frank Glencairn:

mash_gh4 hat geschrieben:

weil man so etwas mit den dafür gebräuchlichen metriken beurteilt.

eine derartige sauber nachvollziehbare qualitätsmessung ist auch nicht sonderlich kompliziert. Wir wissen hier alle wie das geht.
Aber für gewöhnlich schaut man so einen Film mit den Augen an, und nicht mit einem Messprogramm.
Wenn die Augen keinen Unterschied sehen können,
dann ist das Ziel zu 100% erreicht, alles andere ist nur noch Selbstzweck (oder Pixelficken, wenn du so willst).
Aber wenn man außer unsichtbares Zeug messen sonst keine Hobbys hat, warum nicht...
mash_gh4 hat geschrieben:
man kann zwar eine kommerzielle lizenz von x264 erwerben, Kann man sicher machen, wenn man irgendwas verkaufen will,
wenn man es einfach nur im Forum verschenkt, dann eher nicht.



Antwort von mash_gh4:

rdcl hat geschrieben:
Welche Probleme kann man denn mit h264 haben? Egal ob Resolve, oder Media Encoder, oder sogar Avid, ein fertiger Film als h264 mit ausreichender Datenrate unterscheidet sich 0,0 von einem fertigen Prores oder DNxHD. selbst zwischen den codecs der selben art, gibt es leider in der praxis ganz gewaltige qualitäts- bzw. effizienzunterschiede!


zum Bild


ich hab leider gerade keine aktuelleren vergleiche bei der hand, weil mittlerweile h.264 keine so große rolle mehr spielt, und deshalb fast nur mehr h.265, AV1 u.ä. getestet wird.
rdcl hat geschrieben:
Ich habe das schon unzählige Male übereinander verglichen. Solange man das mp4 nicht weiter bearbeitet geht das doch mittlerweile mit jedem Programm optisch vollkommen verlustfrei. wie gesagt, wenn man das ein bisserl genauer untersucht, kommt man da zu etwas anderen erkenntnissen -- wobei die durchaus nützlich sind, um tartsächlich die verfügbaren bandbreiten sinnvoll auszunutzen bzw. möglichst hochwertige bilder im netz zugänglich zu machen.



Antwort von rdcl:

mash_gh4 hat geschrieben:
rdcl hat geschrieben:
Welche Probleme kann man denn mit h264 haben? Egal ob Resolve, oder Media Encoder, oder sogar Avid, ein fertiger Film als h264 mit ausreichender Datenrate unterscheidet sich 0,0 von einem fertigen Prores oder DNxHD. selbst zwischen den codecs der selben art, gibt es leider in der praxis ganz gewaltige qualitäts- bzw. effizienzunterschiede!


zum Bild


ich hab leider gerade keine aktuelleren vergleiche bei der hand, weil mittlerweile h.264 keine so große rolle mehr spielt, und deshalb fast nur mehr h.265, AV1 u.ä. getestet wird.
rdcl hat geschrieben:
Ich habe das schon unzählige Male übereinander verglichen. Solange man das mp4 nicht weiter bearbeitet geht das doch mittlerweile mit jedem Programm optisch vollkommen verlustfrei. wie gesagt, wenn man das ein bisserl genauer untersucht, kommt man da zu etwas anderen erkenntnissen -- wobei die durchaus nützlich sind, um tartsächlich die verfügbaren bandbreiten sinnvoll auszunutzen bzw. möglichst hochwertige bilder im netz zugänglich zu machen. Aber wenn das File die max. Dateigröße die es haben darf nicht überschreitet und im direkten Vergleich im NLE kein Unterschied zu sehen ist, welche Relevanz hat das dann? Vielleicht sprechen wir einfach von verschiedenen Anwendungsgebieten, aber die einzigen h264 Files die ich anliefere landen meistens auf Plattformen, auf denen sie sowieso nochmal komprimiert werden. Und meistens sind die Specs auch vorgegeben.

Ich komme leider die nächsten Wochen wahrscheinlich nicht dazu, aber wir können ja gerne mal mp4 oder DNx spielen :D



Antwort von mash_gh4:

"Frank Glencairn" hat geschrieben:
Aber für gewöhnlich schaut man so einen Film mit den Augen an, und nicht mit einem Messprogramm.
Wenn die Augen keinen Unterschied sehen können,
dann ist das Ziel zu 100% erreicht, die heute üblichen anspruchsvolleren video-qualitätsmetriken (bspw. VMAF) orientieren sich natürlich an genau dieser visuellen wahrnehmung in größeren versuchsgruppen -- liefern also u.a. ganz klare aussagen darüber, wann entprechende kompressionsartefakte bzw. qualitätsminderung auf unterschiedlichen wiedergabegeräten tatsächlich für gewöhnlich wahrgenommen wird.

https://de.wikipedia.org/wiki/Video_Mul ... ent_Fusion
https://streaminglearningcenter.com/blo ... urces.html





Antwort von prime:

mash_gh4 hat geschrieben:
die GPL untersagt auch ganz eindeutig eine nutzung in form von plugins bzw. dynamisch geladenen code in unfreien programmen! Huh? Geht doch größtenteils um die Distribution und nicht um die Nutzung. Wenn ich eine nichtfreie Version von ffmpeg kompiliere, dann darf ich die nicht weitergeben, verwenden aber definitiv.






Antwort von mash_gh4:

prime hat geschrieben:
mash_gh4 hat geschrieben:
die GPL untersagt auch ganz eindeutig eine nutzung in form von plugins bzw. dynamisch geladenen code in unfreien programmen! Huh? Geht doch größtenteils um die Distribution und nicht um die Nutzung. Wenn ich eine nichtfreie Version von ffmpeg kompiliere, dann darf ich die nicht weitergeben, verwenden aber definitiv. ja -- die einschränkungen beziehen sich tatsächlich nur auf die weitergabe.
du darfst beliebige änderungen am code vornehmen, die du nicht veröffentlichen musst, so lange du auch das entsprechende fertige programm nicht weitergibst.

das hat damit zu tun, dass die GPL ja tatsächlich nur erreichen will, dass der code zugängliche bleibt -- was eben erzwungen wird, wenn man ihn zusammen mit darauf aufbauenden produkten immer zugänglich machen muss -- , damit nicht irgendwo, wenn plötzlich geld zu verdienen ist, die verwendeten mittel wieder im verborgenen gehalten werden und nicht mehr von den benutzern verändert, weiterentwickelt und modifiziert werden können.

allerdings ist das ganze doch zumindest so konsequent geregelt, dass es eben auch nicht zulässig ist, freie libraries od. plugins einfach nur als geschlossene einheit zu betrachten, und sie in größeren unfreien closed source programmen als dynamisch ladbares modul zu nutzen, weil das den entsprechende schutz sonst völlig aushebeln und ad absurdum führen würde.

es geht dabei aber im grunde gar nicht darum, die kommerzielle verwertung zu behindern, sondern einfach nur sicherzustellen, dass geistiges eigentum, das von der gemeinschaft eingebracht wurde, auch tatsächlich längerfristig für alle zugänglich bleibt.

das ganz hat in seinen ursprüngen sehr viel mit den erfahrungen von entwicklern im akademischen umfeld zu tun, die immer wieder miterleben mussten, wie ursprünglich offene projekte im rahmen der kommerziellen nutzung plötzlich nicht mehr verfügbar waren od. nur mehr in völlig unzugänglicher weise im verborgenen von firmen ohne rückfluss der der veränderungen weiterentwickelt wurden.



Antwort von Bruno Peter:

"Frank Glencairn" hat geschrieben:
Ja, vor allem erstaunlich schnell (bei mittelprächtigen EInstellungen) - bis zu 40 FPS auf einem recht alten Hobel. Der Export läuft auf meinem Rechner wirklich wahnsinnig schnell.
Ein solches Tempo habe ich nicht erlebt.

Ich muss mir das noch genauer ansehen...



Antwort von cantsin:

"Frank Glencairn" hat geschrieben:
cantsin hat geschrieben:
Anführungszeichen lassen sich nicht eintippen.)

16142679445028820173430572394470.jpg Stellt sich raus: nur unter Linux, bei "EN-US-Intl"-Tastaturen, die doppelte Anführungszeichen, Umlaute und sonstige Buchstaben mit Akzenten auf zwei hintereinander gedrückte Tasten legen. Auch wenn das auf OS-Ebene eingestellt ist, hat Resolve da einen Bug bzw. eine Unzulänglichkeit. Man kann mit Copy-Paste aus anderen Programmen helfen, aber dann landet der eingefügt Inhalt (wie gesagt) doppelt im Resolve-Titel...



Antwort von cantsin:

mash_gh4 hat geschrieben:
Hat schon jetzt jemand überprüft ob aus der "Delivery" heraus gleichwertige h.264 - Videoqualität wie im Falle Handbrake exportiert werden kann?
auf welche weise hast du die qualität überprüft? Hab den Test jetzt mal spaßeshalber gemacht, mit relativ anspruchsvollem Testmaterial (Action-Aufnahmen mit viel Bewegung, Low Light mit Bildrauschen und Regen, aus Braw-Referenzdateien aus der Pocket 6K und 4K von Blackmagics Website).

Tatsächlich sind die Ergebnisse des direkten h264-Exports aus Resolve und des Umwegs Resolve -> DNxHR 10bit -> Handbrake x264 optisch praktisch nicht unterscheidbar. Habe bei Handbrake das schnellste Encoding-Preset gewählt sowie eine Qualitätsstufe, bei der am Ende die gleiche Dateigröße wie beim Resolve-Direktexport (160MB bei 5.15 Sek. in UltraHD) resultierte.

Die Ergebnisse sehen in der Tat ziemlich nach x264 aus...
1-resolve_internal.jpg Resolve 17
1-handbrake.jpg Handbrake/x264

2-resolve_internal.jpg Resolve 17
2-handbrake.jpg Handbrake/x264

4-resolve_internal.jpg Resolve 17
4-handbrake.jpg Handbrake/x264


Geht leider nur in der Windows-, nicht der Linux-Version von Resolve Studio, weshalb ich stark davon ausgehe, dass Blackmagic hier eine Lizenz gekauft hat.



Antwort von SangOne:

Schöner Test, danke!

Haben beide auch die gleiche Renderzeit bei gleicher Dateigröße gehabt?
Wurde auch die GPU angesprochen?



Antwort von cantsin:

SangOne hat geschrieben:
Schöner Test, danke!

Haben beide auch die gleiche Renderzeit bei gleicher Dateigröße gehabt?
Wurde auch die GPU angesprochen? Renderzeiten subjektiv gleich, ob die GPU angesprochen wurde, habe ich nicht geprüft. (Der Standard-x264-Codec ist nicht GPU-beschleunigt.)



Antwort von mash_gh4:

cantsin hat geschrieben:
Hab den Test jetzt mal spaßeshalber gemacht, mit relativ anspruchsvollem Testmaterial (Action-Aufnahmen mit viel Bewegung, Low Light mit Bildrauschen und Regen, aus Braw-Referenzdateien aus der Pocket 6K und 4K von Blackmagics Website). mit derartigen visuellen gegenüberstellungen kann man natürlich stunden verbringen, trotzdem halte ich es für wesentlich vernünftiger, solche vergleiche bzw. beurteilungen mit geeigneteren mitteln anzustellen...
cantsin hat geschrieben:
Tatsächlich sind die Ergebnisse des direkten h264-Exports aus Resolve und des Umwegs Resolve -> DNxHR 10bit -> Handbrake x264 optisch praktisch nicht unterscheidbar. Habe bei Handbrake das schnellste Encoding-Preset gewählt sowie eine Qualitätsstufe, bei der am Ende die gleiche Dateigröße wie beim Resolve-Direktexport (160MB bei 5.15 Sek. in UltraHD) resultierte. mir kommen immer wieder einzelne tests unter, wo intel quicksync oder die nvidia encoder zumindest in den schnellen verarbeitungsmodi besser abschneiden als libx264. mittlerweile dürften also auch diese anderen implemenationen fast alle details übernommen haben, die ursprünglich den qualitativen vorsprung von x264 ausgemacht haben.

in der zwischenzeit hat sich die ganze geschichte allerdings auch weitstgehend erledigt, weil neue codecs an dessen stelle getreten sind.



Antwort von Bruno Peter:

Das Referenz Manual entspricht noch nicht der finalen Programm-Version 17, man hat in das Menü Help einfach die PDF der Vorversion eingebunden!



Antwort von Frank Glencairn:

Ich glaube wir reden hier über verschiedene Dinge.

1. h264 Export, wahlweise auf der CPU oder GPU gerechnet (wenn man ne Nvidia Karte hat) - das ging ja schon lange vor der 17.

2. x264 Export über die neue Schnittstelle mit entsprechendem Plugin.

Und dann gibt's noch Handbrake, wo man auch zwischen CPU/GPU wählen kann, mit unterschiedlichen Ergebnissen.

Nach allem was ich bisher probiert hatte, entspricht der CPU Handbrake Export, dem Export aus Resolve über das x264 Plugin, und der GPU Export von Handbrake (Nvidia), emtspricht dem GPU Export in Resolve - was beides eigentlich auch so zu erwarten war, da ja die selben Librarys und die selbe Hardware zum Einsatz kommen - nur das UI ist ein anderes.






Antwort von cantsin:

Hab jetzt mal das x264-Third-Party-Plugin unter Resolve Studio/Linux ausprobiert. Die wichtigsten Optionen des Codecs (wie: Geschwindigkeits-Presets, Tune-Parameter, CRF/Bitrate) können im Resolve-Exportmodul eingestellt werden, aber die Performance ist suboptimal. Komme beim Rendern auf eine CPU-Auslastung von ca. 250% mit einem AMD Ryzen 3900x und ca. 5fps beim Exportieren einer 2K-Timeline bei CRF 19 im "veryslow"-Preset, während x264 via ffmpeg oder Handbrake praktisch perfekt auf die 12 CPU-Kerne skaliert und ca. 15fps bei den gleichen Qualitätseinstellungen erreicht. :-(



Antwort von mash_gh4:

"Frank Glencairn" hat geschrieben:
Ich glaube wir reden hier über verschiedene Dinge. nein -- bisher haben wir alle einfach nur über das default h.264 encoding im resolve jenseits aller plugins und modifikationen geredet.
"Frank Glencairn" hat geschrieben:
1. h264 Export, wahlweise auf der CPU oder GPU gerechnet (wenn man ne Nvidia Karte hat) - das ging ja schon lange vor der 17. eh -- klar!
es wurd zwar bisher hier nicht wirklich klargestellt, umwelche der beiden varianten es sich handelt, die da einigen nun so flott vorkommt, und auf welchem betriebssystem das der fall ist, aber zumindest kannte ich den betreffenden beiträgen entnehmen, dass es sich dabei um eine auffallende änderung im verhalten des programms handeln dürfte.
"Frank Glencairn" hat geschrieben:
2. x264 Export über die neue Schnittstelle mit entsprechendem Plugin. das klammern wir vielleicht besser aus der diskusion aus, weil deratige erweiterung, die sich auf GNU lizenz geschützte software stützen, in unfreier software nicht genützt werden dürfen. damit verhält es sich also nicht wesentlich anders, als wenn ich hier leuten erklären würde, dass sie dumm sind, wenn sie creative cloud abos bezahlen, wo man doch auf irgendwelchen servern im darknet immer hacks findet, um die entsprechenen schutzmechanismen zu umgehen.
"Frank Glencairn" hat geschrieben:
Und dann gibt's noch Handbrake, wo man auch zwischen CPU/GPU wählen kann, mit unterschiedlichen Ergebnissen. ja. handbracke ist nur eine grafische oberfläche für das ffmpeg. und dieses erlaubt die nutzung ganz vieler verschiedener codecs. libx264 ist nur einer darunter. daneben stehen aber auch einige andere für das selbe format zur verfügung -- tlw. hardware bschleunigt, tlw. nicht.
"Frank Glencairn" hat geschrieben:
Nach allem was ich bisher probiert hatte, entspricht der CPU Handbrake Export, dem Export aus Resolve über das x264 Plugin, und der GPU Export von Handbrake (Nvidia), emtspricht dem GPU Export in Resolve - was beides eigentlich auch so zu erwarten war, da ja die selben Librarys und die selbe Hardware zum Einsatz kommen - nur das UI ist ein anderes. wie gesagt -- dass evtl. letzt eine brauchbare qualität herauskommt, würde mich weiter nicht verwundern. in dem punkt waren die bisherigen leistungen von resolve ja auch nicht wirklich schwer zu überbieten.

dass es sich dabei aber um die nutzung von libx264 handelt bzw. BMD dafür eine lizenz erworben hat, kann ich mir ehrlich gestanden weiterhin nicht vorstellen.

die unterschiede zwischen verschiedenen codecs sind wirklich derart subtil, dass man mit einfachen standbildvergleichen od. visueller beurteilung des laufenden videos sicher keine klärenden anhaltspunkte finden wird. wenn man diese frage tatsächlich klären will, müsste man das reale verhalten der software genauer analysieren. dabei stellen sich immer einige details in den weg, die eine wirklich saubere reproduktion der ergebnisse bzw. einen objektiven nachvollzug nicht ganz einfach gestalten. vielleicht könnte man damit aber zumindest in glaubwürdiger/überzeugender weise eruieren, ob die jetzige h.264-ausgabe im resolve tatsächlich mit anderen softwarealternativen konkurrieren kann -- was ja bisher definitiv nicht der fall war.



Antwort von Frank Glencairn:

Exportierst du einen fertigen Film, oder muss Resolve nebenbei auch noch die Korrekturen, Debayering, und Effekte berechnen?



Antwort von mash_gh4:

cantsin hat geschrieben:
Hab jetzt mal das x264-Third-Party-Plugin unter Resolve Studio/Linux ausprobiert. kannst du im prozessbaum ('pstree' od.ä.) erkennen, ob sie das ganze tatsächlich in einem losgelösten subprozess realisiert haben -- was u.u. die mangelhafte performance erklären könnte --, oder ob man sich dort einfach über die GPL, die ganz klar eine nutzung von GNU software in form von dynamisch ladbarer modulen in unfreier software untersagt, hinweg setzt?



Antwort von cantsin:

mash_gh4 hat geschrieben:
cantsin hat geschrieben:
Hab jetzt mal das x264-Third-Party-Plugin unter Resolve Studio/Linux ausprobiert. kannst du im prozessbaum ('pstree' od.ä.) erkennen, ob sie das ganze tatsächlich in einem losgelösten subprozess realisiert haben -- was u.u. die mangelhafte performance erklären könnte --, oder ob man sich dort einfach über die GPL, die ganz klar eine nutzung von GNU software in form von dynamisch ladbarer modulen in unfreier software untersagt, hinweg setzt? Bei mir läuft der Gnome-Desktop, weshalb alle laufenden GUI-Anwendung in den meisten Tools monolithisch als "GUI Thread" angezeigt werden. Einen separaten x264-Prozess sehe ich nicht.

Allerdings ist das x264-Plugin ja sowieso ein inoffizielles DIY-Third-Party-Plugin, für das es nur einen Dropbox-Download gibt.



Antwort von freezer:

Weiß nicht, ob das wer kennt:
https://www.danieltufvesson.com/makeresolvedeb

Bin da grad drübergestolpert.
Damit lässt sich ein Installerpaket von Resolve für Debian erzeugen, offiziell lässt sich die Linuxversion von Resolve nur auf CentOS installieren.



Antwort von cantsin:

freezer hat geschrieben:
Weiß nicht, ob das wer kennt:
https://www.danieltufvesson.com/makeresolvedeb Verwende das schon seit Jahr und Tag, funktioniert tadellos.



Antwort von mash_gh4:

cantsin hat geschrieben:
Bei mir läuft der Gnome-Desktop, weshalb alle laufenden GUI-Anwendung in den meisten Tools monolithisch als "GUI Thread" angezeigt werden. Einen separaten x264-Prozess sehe ich nicht. hmm -- gnome sollte daran eigentlich nichts ändern.
man kann ja resolve auch von der cmd-line aus starten, damit es ggf ein bisserl transparenter wird und mit 'pstree -la | less' leichter aufzufinden ist.
aber so wichtig ist die geschichte dann auch wieder nicht... ;)
cantsin hat geschrieben:
Allerdings ist das x264-Plugin ja sowieso ein inoffizielles DIY-Third-Party-Plugin, für das es nur einen Dropbox-Download gibt. natürlich kann man diese problematik auch einfach ignorieren.

das macht sogar insofern sinn, als die GPL ja keineswegs die freiheit der benutzer zu beschränken versucht, sondern genau auf das gegenteil abzielt.

in der praxis stellt es aber -- sofern nicht nicht der umweg über subprozesse und pipes od.ä. genutzt wird -- doch aus eine gravierende verletzung der entsprechenden lizenzbedingungen dar, wie es sie auch in der vergangenheit bereits immer wieder in form ähnlicher "produkte" gegeben hat.

meist geht man damit ohnehin relativ wohlwollend und nachsichtig um, solange es sich dabei eher nur um ein kreatives rebellisches aufbegehren aus der freien software szene heraus und freien code handelt. überall dort, wo sich diese ansätze dann aber tatsächlich wieder als einfach zu nutzende fertige kompiliert downloadbare "produkte" zu etablieren versuchen, geht man dann aber in regel wieder ein wenig konsequenter dagegen vor. das ist auch der grund, warum all die ähnlich gelagerten ansätze, die es in der vergangeheit bereits gab, schnell wieder von der bildfläche verschwunden sind.



Antwort von mash_gh4:

cantsin hat geschrieben:
Verwende das schon seit Jahr und Tag, funktioniert tadellos. genau! -- ohne derartige mühselige umwege kann man resolve auf den meistverbreiteten linux distributionen (ubuntu/debian/mint) leider einfach noch immer nicht out of the box nutzen.

es ist allerdings völlig unverständlich, warum das auch nach jahren und unzähligen bemühungen seitens der betroffenen benutzer, daran endlich etwas zu ändern -- was ja für die hersteller ein leichtes wäre! --, noch immer nicht zufriedenstellender gelöst ist. :(






Antwort von Frank Glencairn:

Weil selbst die großen Posthäuser entweder ein Turnkey-System kaufen, oder sowieso weg von Linux gehen, weil es nur noch in minimalen Nischen-Spezialanwendungen irgendeinen Vorteil gegenüber Win/Mac bringt. - und für den Massenmarkt ist Linux sowieso kein Thema.



Antwort von mash_gh4:

"Frank Glencairn" hat geschrieben:
Weil selbst die großen Posthäuser entweder ein Turnkey-System kaufen, oder sowieso weg von Linux gehen, weil es nur noch in minimalen Nischen-Spezialanwendungen irgendeinen Vorteil gegenüber Win/Mac bringt. - und für den Massenmarkt ist Linux sowieso kein Thema. nachdem du ja als linux-experte in dieser frage gewiss ein unanfechtbare autorität darstellst bzw. ganz bestimmt recht haben wirst, wage ich es natürlich nicht, dieser fürchterlich profunden einschätzung zu widersprechen! ;)



Antwort von Frank Glencairn:

Dazu muß man kein Experte sein.
Linux ist und bleibt ein absolutes Nischenprodukt und spielt deshalb im Massenmarkt keine Rolle.

os-market-share-august-2019 (1).png


Wo ich mich aber auskenne ist Postproduction, und da seh ich den Trend - weg von Linux - schon seit ner ganzen Weile.
Als ich auf ner Dinci Renaissance 888 Ende der 90er Colorgrading gelernt hab (damals noch auf ner SGI, später Linux) und dann in den frühen 2000ern gabs noch viel mehr Linux/Unix, so wie ein paar andere Exotische Sachen wie Alpha. Das meiste davon dem läuft heute überwiegend unter MAc/Win Systemen.
Das kannst du natürlich weiterhin leugnen, so lange du willst, ändert aber nix an der Realität.



Antwort von roki100:

mash_gh4 hat geschrieben:
cantsin hat geschrieben:
Verwende das schon seit Jahr und Tag, funktioniert tadellos. genau! -- ohne derartige mühselige umwege kann man resolve auf den meistverbreiteten linux distributionen (ubuntu/debian/mint) leider einfach noch immer nicht out of the box nutzen. Äh, jetzt übertreibst Du aber ;) Das wäre doch keine Neuigkeit unter Linux. Als Linux User weiß man eben, dass es immer wieder fälle gibt, wofür kein fertiges Paket vorhanden ist, da muss man dann eben selbst tun und machen und kompilieren (das kann echt einem die Zeit rauben). Das sich Drittsoftware nicht auf einfach Wege installiert lassen, ist doch keine Seltenheit unter Linux und das weißt Du. ;) Selbst manch eigene Distributionspakete muss man quasi durch eigene kompilierte Sachen ersetzen (weil sie veraltet sind, weil benötigte Patches fehlen usw. usf.). Von Nvidia....bis Kernel & Co. Blackmagic ist da keine besondere Ausnahme. Und wo ist das Problem? Ganz einfach, jeder kocht sein eigenes Linux, die führen mittlerweile Wettbewerbe welches besser, schneller, stabiler ist als die anderen.... BESSER wäre es aber, die tun sich alle zusammen und es gibt nur eine Distribution, wodurch die Softwarehersteller es einfacher hätten, aber so gibt es unterschiedliche Distributionen, mit unterschiedliche (z.B.) Xorg&Co. Versionen und Patches uvm. Selbst die tausenden freie Entwickler von Distribution X/Y verlieren den Überblick unter sich, geschweige denn, irgendein Softwarehersteller mit wenig Mitarbeiter, die auch alle andere Distributionen erfassen müssen und bei jede Änderung/Linux Aktualisierung daran denken müssen, BMD DR&Co. damit wieder kompatibel zu machen....



Antwort von Frank Glencairn:

Das ist für viele halt auch ein Hobby da rumzufrickeln - einfach weils ihnen Spaß macht.
Aber die meisten wollen sich halt nicht mehr als absolut nötig mit ihrem OS beschäftigen.
Win - und sogar Mac - generieren im Alltag schon genug Probleme, da haben die wenigsten Appetit auch noch zu lernen wie man
sein eigenes Zeug kompiliert, nur weil die neue Grafikkarte sonst nicht läuft.



Antwort von mash_gh4:

...den Trend - weg von Linux... ich stimme dir durchaus zu, dass sich die unterschiede zwischen den systemen mittlerweile sehr stark eingeebnet haben. es macht also für die anwender oft keinen großen unterschied mehr, welches betriebssystem sie bevorzugen. das mittlerweile oft wirklich nur mehr eine geschmacksfrage.

allerdings ist esin gleicher weise auch für die hersteller viele viel einfacher geworden platfformübergreifende lösungen anzubieten. es ist wirklich keine große kunst mehr auch linux sauber mit zu untersützen, wenn man ohnehin windows und apple anforderungen gleichzeitig abdecken will.

resolve hat hier urspünglich auch noch den vorteil mitgebracht, dass es ursprünglich auf unix systemen entwickelt und genutz wurde, und mit ein bisserl bemühen auch weiterhin unter linux ähnlich befriediegend genutz werden hätte können, wie auf den anderen beiden systemen. leider hat BMD diesem punkt keine besonders große beachtung geschenkt und die linux ausgabe, wie so viel anders auch, wirklich nur als werbemascherl benutzt.

so einfache dinge, wie die unterstützung der meistgenützen distribution bzw. alle tatsächlich von den betroffen benutzern eingebrachten verbesserungswünsche (bspw. im hinblick auf die nutzung von codecs bzw. ohnehein am system bereits installierter software) werden einfach seit jahr und tag ignoriert, so dass man resolve mittlerweile linux benutzer kam mehr als tatsächliche gleichwertige software zu den ausgaben auf den anderen systemen empfehlen kann.

das dir das völlig egal ist, wundert mich nicht weiter.
es gibt auch keinen grund, warum du es anders sehen solltest.

trotzdem solltest du dich vielleicht in dieser frage ein wenig zurück halten bzw. besser den leuten zuhören, die mit den angesprochenen problemen tatsächlich in der praxis konfrontiert sind -- kurz: dieses konkrete betriebsystem genauso selbstverständlich für all ihre tägliche arbeit nutzen, wie das andere auf ihrem mac od windows auch tun! auch bei den verschiedenen anderen betriebsystemen fragt man sich schließlich immer wieder, warum sie sich das manche nutzer noch immer antun und dafür sogar noch geld beim fenster rauswerfen bzw. die offensichtlichen einschränkungen der jeweiligen firmenideologie in kauf nehmen?



Antwort von roki100:

mash_gh4 hat geschrieben:
allerdings ist esin gleicher weise auch für die hersteller viele viel einfacher geworden platfformübergreifende lösungen anzubieten. es ist wirklich keine große kunst mehr auch linux sauber mit zu untersützen, wenn man ohnehin windows und apple anforderungen gleichzeitig abdecken will. Da ist aber das Problem: es gibt kein ein Linux, sondern Distributionen.

Jeder Entwickler der sein Brot damit verdient, weißt wie es schwierig sein kann, wenn man für mehrere Distributionen Support geben muss. Diese vermeidet eben für verschiedene X/Y Distributionen zu entwickeln, weil die Distributionen sich von heute auf Morgen so massiv verändern können, dass man schon wieder die Software anpassen muss ....das kostet Zeit, ist aufwendig, die gesamte Firma hätte dann mehr zu tun. Daher verstehe ich ganz gut warum BMD einfach nur CentOS gewählt haben. Früher haben die Softwarehersteller, die auch für Linux Entwickelt haben, höchstens für Red Hat, Suse und Mandrake entwickelt (Debian weniger). Heute ist das, aufgrund unzählig entstandene Distributionen, eben schwierig für jeden Softwarehersteller. Diese müssen die Distribution bei Namen benennen, wie z.B. "Kompatibel mit CentOS" und stellt dann passendes Paket zur Verfügung.



Antwort von mash_gh4:

roki100 hat geschrieben:
Da ist aber das Problem: es gibt kein ein Linux, sondern Distributionen. es gibt aber auch ganz klare standardisierungsbemühungen bzw. empfehlungen, die für alle linux distributionen gelten.

bspw. den Filesystem Hierarchy Standard (FHS).

wenn man sich daran hält, fällt bereits eine ganze menge jener probleme weg, die eben durch dieses script vom daniel tuvesson auf die eine oder andere weise umständlich korrigiert werden müssen.
roki100 hat geschrieben:
Jeder Entwickler der sein Brot damit verdient, weißt wie es schwierig sein kann, wenn man für mehrere Distributionen Support geben muss. meines erachtens macht genau das wirklich gute progammierer aus, dass sie nicht in einer weise herumpfuschen, die nur "irgendwie" in der gerade genutzen umgebung funktionieren, sondern eben auch auf standards und kompatibilitätserfordernissen vorausschauend rücksicht nehmen. meist macht sich der damit verbundene zusätzliche aufwand längerfristig ohnehin bezahlt.

im übrigen besteht für mich der sinn des programmieres noch immer hauptsächlich darin, anderen mitmenschen irgendwelche stupiden sich wiederholenden arbeitsabläufe abzunehmen bzw. zu erleichtern -- also genau so etwas, wie die anwendung dieser idiotischen umpack-scripts mit ein paar zeilen modifizierten code für alle betroffen und die absehbare zukunft einfach aus der welt zu schaffen!

zur gegenwärtigen relevanz bzw. marktanteilen der verschiedenen linux distributionen:
https://w3techs.com/technologies/details/os-linux



Antwort von roki100:

mash_gh4 hat geschrieben:
roki100 hat geschrieben:
Da ist aber das Problem: es gibt kein ein Linux, sondern Distributionen. es gibt aber auch ganz klare standardisierungsbemühungen bzw. empfehlungen, die für alle linux distributionen gelten.

bspw. den Filesystem Hierarchy Standard (FHS).
So was wie FHS ist das kleinste Problem. Wobei es auch da Probleme gibt, plötzlich läuft das eine nicht, weil irgendwelche *.so Verlinkung falsch ist, oder anders verlinkt werden muss. Ein exWindows und nun Linux User, der quasi nur Desktop/GUI bedienen kann, wird selbstverständlich nicht auf die Idee kommen Resolve aus der Konsole zu starten um zu sehen warum es nicht startet oder warum cuda nicht läuft und dann auch noch wissen muss ln -s /usr/lib/x86_64-linux-gnu/libcuda.so /usr/lib64/libcuda.so (aus makeresolvedeb Script) auszuführen. Das kann dann wiederum bei andere Distributionen völlig anderes sein. Die Anfrage nach Lösung landen dann immer wieder bei Softwarehersteller, die das dann bearbeiten müssen.

Aber gut, es gibt dann eben Leute die sich drum kümmern, wie derjenige der makeresolvedeb erstellt/pflegt.






Antwort von mash_gh4:

roki100 hat geschrieben:
Ein Linux User der quasi nur Desktop/GUI bedienen kann, wird selbstverständlich nicht auf die Idee kommen Resolve aus der Konsole zu starten um zu sehen warum es nicht startet oder warum cuda nicht läuft und dann auch noch wissen muss ln -s /usr/lib/x86_64-linux-gnu/libcuda.so /usr/lib64/libcuda.so (aus dem makedeb Script) auszuführen. wenn er das tatsächlich in dieser weise zu lösen versucht bzw. entsprechenden ratschlägen in diversen foren blind folgt, ist er ohnehin ein idiot, dem man kaum mehr zu helfen vermag, weil er damit einen der wichtigsten und begründeten punkte verletzt, die unter dem titel "Don't Break Debian" linux-anfängern ohnehin immer wieder nahe gelegt werden.

dieses konkrete detail betrifft übrigens nicht nur debian alleine, sondern auch alle davon abgeleiten distros (ubuntu, mint, etc.), also in der praxis die deutlich überwiegende mehrheit aller heutigen linux nutzer.



Antwort von roki100:

Wie bereits erwähnt, das ist keine Seltenheit, egal welche Distribution. Selbst unter (m.M.) stabilstes Unix System BSD hat man immer wieder solche Problematik ohne Dritt-Software.... (letztens z.B. certbot, da musste ich manuell passend verlinken. Ohne manuelle Behebung, keine SSL Zertifikate.... )
Linux Distribution X/Y Entwickler unter sich, verlieren da auch den überblick und dann manchmal so fälle wie grub nicht richtig verlinkt - dann startet das System natürlich nicht mehr. Leute wie Frank werden dann eben nicht auf die Idee kommen von einer CD oder USB Linux zu booten und dann über chroot etc. grub zu reparieren. Er macht vll. einmal zweimal die Erfahrung und schon ist er zurück zu Windows.



Antwort von mash_gh4:

roki100 hat geschrieben:
Wie bereits erwähnt, das ist keine Seltenheit, egal welche Distribution.
...
Linux Distribution X/Y Entwickler unter sich, verlieren da auch den überblick... nein -- das stimmt einfach nicht!

die paar inkompatibilitäten, die es tatsächlich gibt, sind allen geübteren programmierern und system-administratoren leider nur zu gut bekannt, und in der praxis meist ohnehin sehr einfach zu vermeiden, wenn man sich darum bemüht.

du solltest dir einmal anschauen, um wieviel komplizierter es sich bspw. gestaltet, all die altlasten und eigenheiten der verschiedenen historischen windows varianten, die z.t. noch immer benutzt werden, beim programmieren sauber abzudecken. das ist der wirklich wahnsinn, wo man vor lauter sumpf gar nicht mehr von der stelle kommt!

die real anzutreffenden linux-systeme, egal welcher distribution, wirken im vergleich dazu relativ homogen, weil hier ohnehein jeder problemlos und ohne irgendwelche kosten die gesamte software auf einem einigermaßen aktuellen stand halten kann, und damit in der praxis auch eine sehr große ähnlichkeit der anzutreffen software-umgebung geschaffen wird.



Antwort von roki100:

mash_gh4 hat geschrieben:
roki100 hat geschrieben:
Wie bereits erwähnt, das ist keine Seltenheit, egal welche Distribution. nein -- das stimmt einfach nicht!
Natürlich stimmt das und das weißt Du! ;)
die paar inkompatibilitäten, die es tatsächlich gibt, sind allen geübteren programmierern und system-administratoren leider nur zu gut bekannt und in der praxis alle sehr einfach zu vermeiden, wenn man sich darum bemüht. Betroffen ist dann der genervte Nutzer oder eben der Softwarehersteller, der sein Programm schon wieder umschreiben muss... weil die Distribution Bugfixes langsamer sind. Der Nutzer kann nicht warten usw. usf.



Antwort von mash_gh4:

roki100 hat geschrieben:
eben. Und das ist leider nicht immer der Fall. Betroffen ist dann der genervte Nutzer oder eben der Softwarehersteller, der sein Programm umschreiben muss... ja -- aber das hätten die resolve programmierer mitterweile eben wirklich schon vor jahren bereinigen können!

die paar zeilen an trivialen änderung im installer-code, die ganz konkret nötig wären, um das umpack-script vom daniel tufvesson überflüssig zu machen bzw. eine installation auf distributionen der redhat-line, genauso wie auf debian-deriavaten zu erlauben, sind wirklich locker in einem nachmittag umzusetzen.

und natürlich hätten wir auch alle zusammengeholfen, um die damit beauftragten entwicker dabei nach kräften zu unterstützen. so aber, kann man wirklich nur festhalten, dass BMD in geradezu ungekannt sturer weise seit jahren jeder diesbezügliche verbesserung verweigert, und die angesprochen probleme und unannehmlichkeiten für die benutzer daher natürlich auch noch immer die selben sind. :(



Antwort von Frank Glencairn:

mash_gh4 hat geschrieben:

resolve hat hier urspünglich auch noch den vorteil mitgebracht, dass es ursprünglich auf unix systemen entwickelt und genutz wurde, und mit ein bisserl bemühen auch weiterhin unter linux ähnlich befriediegend genutz werden hätte können, wie auf den anderen beiden systemen. leider hat BMD diesem punkt keine besonders große beachtung geschenkt und die linux ausgabe, wie so viel anders auch, wirklich nur als werbemascherl benutzt.
Hast du schon mal mit einem Turnkey-Linux System von BM gearbeitet?
Ich meine das Komplettsystem das mit der großen Konsole geliefert wurde?



Antwort von roki100:

@mash_gh4
ich weiß genau was Du meinst. Die Softwarehersteller machen sich dann eben einfacher, indem sie eine Distribution aussuchen und eigene Software (samt Installer) dafür anpassen. BMD ist damit aber kein Einzelfall, denn öfter handelt es sich um Probleme, wo sich Softwarehersteller nicht als verantwortlicher sieht, es zu beheben, die einen beschuldigen dann die anderen (übrigens, auch unter Windows immer wieder ein Problem, siehe z.B. Microsoft und HP) usw. usf.



Antwort von mash_gh4:

"Frank Glencairn" hat geschrieben:
Hast du schon mal mit einem Turnkey-Linux System von BM gearbeitet? nein -- aber dafür über nunmehr fast 30 jahre hinweg immer wieder kleine rechenzentren aufgebaut bzw. jede menge linux basierender server eingerichtet und betreut, so dass mir doch eine ganze menge über die diesbezüglichen vorzüge/probleme, anpassungsmöglichkeiten und die reale performance optimierter linux installationen bekannt ist.

ich hab längst keine großen missionarischen ansprüche mehr, jedem linux ans herz zu legen -- im gegenteil: jeder soll nutzen, was ihm persönlich gefällt --, aber ich will eben einfach auch in meiner diesbezüglichen wahl bzw. präferenz durchaus ernst genommen werden bzw. software, die nach außen hin vorgibt, dieses system zu unterstützen, auch tatsächlich vernünftig auf dieser plattform nutzen können. andere software produkte, die das von haus aus gar nicht erst großartig versprechen -- bspw. das ganze adobe angbot oder apple spezifische lösungen -- tangieren mich dagegen ohnehin nicht weiter.



Antwort von Frank Glencairn:

mash_gh4 hat geschrieben:

bzw. software, die nach außen hin vorgibt, dieses system zu unterstützen, auch tatsächlich vernünftig auf dieser plattform nutzen können. NA ja - BM sagt ausdrücklich für CentOS - wenn du dann versuchst es mit Gewalt auf was anderem laufen zu lassen, darfst du halt auch nicht meckern.






Antwort von roki100:

mash_gh4 hat geschrieben:
"Frank Glencairn" hat geschrieben:
Hast du schon mal mit einem Turnkey-Linux System von BM gearbeitet? nein -- aber dafür über nunmehr fast 30 jahre hinweg immer wieder kleine rechenzentren aufgebaut bzw. jede menge linux basierender server eingerichtet und betreut, so dass mir doch eine ganze menge über die diesbezüglichen vorzüge/probleme, anpassungsmöglichkeiten und die reale performance optimierter linux installationen bekannt ist. Server ist da was anderes. Aber auch da hast Du bestimmt die Erfahrung gemacht, dass manche kostenpflichtige WebBasierte Plattformen (wo eben Support angeboten wird und die Software gepflegt wird) von Distribution abhängig ist. Die Softwareentwickler bieten also keine WebProgramme an, die man sich herunterlädt was man dann z.B. nach /var/www etc. entpackt, mysql Datenbank erstellt, mysql Connect in config.php anpasst und fertig aus ist die maus, sondern das WebBasierte Programm wird mit dem gesamten Server und z.B. Debian Distribution verkauft.

Aktuell geht das einfacher, dank Docker etc. ;)



Antwort von mash_gh4:

roki100 hat geschrieben:
@mash_gh4
ich weiß genau was Du meinst. Die Softwarehersteller machen sich dann eben einfacher, indem sie eine Distribution aussuchen und eigene Software (samt Installer) dafür anpassen. es gibt ja unter linux so tools wie bspw. 'alien', die einem die mühen des entsprechenden umpackens weitestgehend abnehmen bzw. automatisieren.

wenn betreffende software einigermaßen sauber gestaltet ist funktioniert das auch prima -- z.b. nuke intalliere ich immer auf diese weise, weil man sich sonst doch gerne die systeme ziemlich zumüllt bzw. software nicht mehr so sauber und rückstandfrei wieder deinstallieren kann, wie man das im linux-umfeld von den diversen packet-managment-systmen gewohnt ist. im falle von resolve steht dieser weg leider nicht offen, weil einfach zu wilde inkompatibilitäten, die sich allerdings ausgesprochen einfach beseitigen lassen würden, im weg stehen.

daneben gibt's aber auch noch die möglichkeit, dass die hersteller den anwendern auch diesen schritt des umpackens auch noch abnehmen können, was z.b. über services wie OBS und diverse CI/CD lösungen mittlerweile ohnehin rechte einfach geworden ist, und auch eine ausgesprochen nützliche hilfe darstellt, inkompatibitäten gleich im produktionsprozess automatisch zu erkennen. mittlerweile ist das ohnehin mehr oder weniger der übliche weg, wie man größere software entwickelt, automatisch kontrolliert und in fertig packetierter weise für unterschiedliche plattformen bereitstellt.



Antwort von mash_gh4:

"Frank Glencairn" hat geschrieben:
BM sagt ausdrücklich für CentOS... CentOS in seiner bisherigen form gibt's ja nun bekanntlich nimmer! :)



Antwort von roki100:

mash_gh4 hat geschrieben:
roki100 hat geschrieben:
@mash_gh4
ich weiß genau was Du meinst. Die Softwarehersteller machen sich dann eben einfacher, indem sie eine Distribution aussuchen und eigene Software (samt Installer) dafür anpassen. es gibt ja unter linux so tools wie bspw. 'alien', die einem die mühen des entsprechenden umpackens weitestgehend abnehmen bzw. automatisieren. das ist natürlich toll, wenn das immer funktionieren würde...

Aber hei, seien wir doch froh dass da draußen große linux Community existiert, die dann wissen wie man z.B. DR CentOS Source Paket in andere "sauber" umwandelt. Schau dir das MakeResolvedeb script mal an :)



Antwort von mash_gh4:

roki100 hat geschrieben:
Server ist da was anderes. ja -- dort hat's mitterlweile wirklich einen wandel gegeben, so dass mittlerweile praktisch alles nur mehr in containern verpackt und via kubernetes koordiniert wird. die einzelnen maschinen und konkrete hardware spielen dabei längst keine große rolle mehr. das ist völlig anders als früher einmal...

aber natürlich sind die konkreten installationen dann doch immer viel komplizierter und auf ein zusammenspiel ganz vieler komponenten angewiesen -- nur hat das mit distributionen od, binärabhängigkeiten kaum mehr etwas zu tun -- außer natürlich, dass x86_64 software bzw. container natürlich nicht auf ARM clustern genutzt werden können und umgekehrt. ;)
roki100 hat geschrieben:
Aktuell geht das einfacher, dank Docker etc. ;) ja, für sehr viele dinge ist das tatsächlich eine ziemlich gute lösung.

ein bisserl schwieriger ist es halt, gerade bei video-anwendungen, auch die bildschirm-ausgabe und GPU-nutzung in zufriedenstellender weise über die containergrenzen hinweg zu teilen, aber es geht.

eine zeit lange habe ich ja auch ein umpacken von resolve in derartige nvidia-docker-container gepfelgt und natürlich auch selbst genutzt, weil das tatsächlich eine technisch sauberere lösung als das script von daniel tufvesson darstellt bzw. eben wirklich die nutzung ein völlig unmodifiziertes CentOS innerhalb des containers erlaubt. mittlerweile habe ich es schon sehr lange (2 jahre / release 15.2.4, wie ich gerade sehe) nicht mehr aktualisiert, weil diese herangehensweise für die meisten benutzer ohnehin viel zu kompliziert ist, und ich mich selbst auch nicht mehr so gern mit resolve herumschlage.
Aber hei, seien wir doch froh dass da draußen große linux Community existiert, die dann wissen wie man z.B. DR CentOS Source Paket in andere "sauber" umwandelt. Schau dir das MakeResolvedeb script mal an :) wie du dem oben erwähnten vermutlich entnehmen kannst, kenn ich sowohl das script von D.T. wie auch die innere funktionsweise des resolve installers sehr genau, sonst hätte ich das ding nicht in ganz ähnlicher weise zerlegen und im container kontext nutzen können...

ich hab mich auch wirklich über jahre hinweg im resolve forum darum bemüht, die entwickler dazu zu bewegen, all diese unbefriedigenden notlösungen endlich durch eine saubere korrektur im installer überflüssig zu machen, aber das ist leider bei der firma wirklich hoffnungslos. :(



Antwort von roki100:

Leider muss man sich auch in bisschen anpassen. Ich z.B. so:
Video/Audio/Grafikbearbeitung: bzw. Desktop: MacOS (über 20+ Jahre habe ich vorher Linux benutzt, mein umstieg ist nicht unbegründet....)
Server: nur Linux und BSD (gar kein Desktop/WM.... ssh/konsole ist mein Arbeitsgebiet... )
Spielkonsole: Windows ;) Spiele aber seit längere Zeit nicht mehr....



Antwort von mash_gh4:

roki100 hat geschrieben:
Leider muss man sich auch in bisschen anpassen. Ich z.B. so:
Video/Audio/Grafikbearbeitung: bzw. Desktop: MacOS (über 20+ Jahre habe ich vorher Linux benutzt, mein umstieg ist nicht unbegründet....) bei mir war es umgekehrt -- ich hab zwar in den 80 und 90er jahren auch hauptsächlich mit apples gearbeitet und darauf zb. pascal und C programmieren gelernt, aber natürlich auch danach noch sehr lange mac benutzer in ihren alltäglichen problemen betreut, aber seit den späten 90er jahren verwende ich für meine eigene arbeit wirklich kaum mehr etwas anderes als linux.

du hast schon recht, dass damit nicht unbedingt alles einfacher und komfortabler von der hand geht, aber dafür sind damit sachen möglich, die auf den kommerziellen plattformen praktisch nicht umsetzbar wären. im meinem fall betrifft das hauptsächlich die arbeit an projektbezogenen spziallösungen bzw. die entwicklung von software für kunstprojekte, mit denen man tatsächlich völliges neuland betritt bzw. eben sachen zu realisieren versucht, für die es noch keine einfach zu erstehenden fertig käuflichen lösungen gibt. dort kommen dann auch die vorzüge der open source umgebung wirklich zum tragen. dass man linux dann auch für alles übrige nutzt, ist eher eine frage der gewohnheit od. vielleicht sogar eine notwendigkeit, weil man gerade in der überwindung von schwierigkeiten und problemen oft sehr viel darüber lernt, wie man die eigenen grenzen erweitern kann. ;)

im laufe dieser jahre habe ich auch die erfahrung gemacht, dass fast alles, wofür es unter linux bzw. im freien software-umfeld anfänglich noch keinen gute ersatz gab, irgendwann in deutlich befriedigender weise dazu gekommen ist. so hab ich z.b. früher tatsächlich vmware und ein paar kommerzielle elektronik-design-anwendungen nutzen müssen, die sich heute gegenüber qemu-kvm und dem was laufend an freien ECAD- und FPGA-tools dazu kommt kaum mehr sonderlich verlockend ausnehmen.

längerfristig wird das sicher auch im bezug auf grafik und video-verarbeitungsprogrammen der fall sein, obwohl das halt leider wirklich nur eine ganz kleine zielgruppe interessiert, die in der regel nicht unbedingt die optimalen voraussetzungen mitbringt, sich ihre eigenen werkzeuge zu bauen bzw. diese zu verbessern. dort aber, wo das tatsächlich passiert, zeigen sich darin sehr oft design-entscheidungen, die sich von produkten aus der entfremdeten softwareindustrie deutlich unterscheiden bzw. eben viel eher meinen wünschen, erwartungen und qualitätsansprüchen bspw. in puncto eigener eingriffsmöglichkeiten gerecht werden.

aber wie gesagt: ich will niemandem einreden, dass man unbedingt mit linux und freier software arbeiten muss, oder im supermarkt immer zu den doppelt so teueren handgemachten bioqualitätsprodukten greifen sollte, vielmehr kämpfe ich eher darum, dass eben auch dieser ausschnitt der realität von anderen zumindest wahrgenommen wird. immerhin passiert ein sehr großer teil des tatsächlichen computergestützten geschehens heute hinter den kulissen auf genau diesen produktionsmitteln, auch wenn sie den meisten desktop usern weiterhin gänzlich fremd und unzugänglich sind -- weshalb ja auch die künstlerische auseinandersetzung damit noch immer nicht völlig überflüssig geworden ist, obwohl das in der praxis immer schwieriger wird, weil die sachen von jahr zu jahr komplexer und immer schwerer real handhabbar und gestaltbar werden.



Antwort von roki100:

ich meinte auch privat. Beruflich ist das natürlich anders, so:
MacOS: die Konsole für ssh, Web Browser für WenInterfaces...
Server: nur Linux und Unix (Samba, Squid, Web-Dienste usw.)
...
Spielkonsole: keine ;)



Antwort von cantsin:

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).

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.

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.

Ansonsten ist immer noch das Hauptargument für Linux die Kommandozeile, ihre tiefe Integration ins System (anstatt nur als Terminal-Aufsatz wie bei MacOS und Windows) und die umfangreiche Bereitsstellung und gute Aktualisierung/Pflege von Kommandzeilenwerkzeugen sowie Netzwerk- und Entwicklersoftware in den Standarddistributionen, daneben noch die Abwesenheit von überflüssigen Kompatibilitätslayern und -komponenten, vorinstallierter Müllsoftware, resourcefressenden DRM-Subsystemen, Virtual Machines und dergleichen, und natürlich die Abwesenheit vom Vendor-Lock-In (wo man z.B. Microsoft ausgeliefert ist, wenn die Firma lokale Nutzerkonten abschafft und Windows-Nutzer auf Microsoft-IDs zwingen).

Dass 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.






Antwort von mash_gh4:

cantsin hat geschrieben:
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:
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:
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:
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.



Antwort von cantsin:

Nochmal zurück zu Resolve 17 und seinen neuen Funktionen:

Ein echtes verborgenes Killer-Feature ist IMHO die neue "OOTF" ("opto-optical transfer function")-Option bei Farbraumumwandlungen, z.B. von Log nach Rec709. Die Option "Apply Forward OOTF". Wenn ich sie in der Theorie richtig verstehe, gleicht sie die Helligkeit des Zielfarbraums besser an. In der Praxis führt sie IMHO schlicht zu besseren Ergebnissen, die händische Farbkorrekturen nach der Umwandlung oft überflüssig machen.

Hier ein Beispiel mit Fuji F-Log:
log.jpg originales Log-Material

LUT_1.10.4.T.jpg Fujis offizielles F-Log -> Rec709 LUT

no-ootf.jpg Resolves 'Color Space Transform' mit aktivem Tone und Gamut Mapping, unterstützt seit Version 17 auch F-Log (sowie Nikon N-Log), IMHO deutlich bessere Zeichnung/Abstufung u.a. der Hauttöne (z.B. an den Wangen) als mit Fujis LUT.

ootf_fwd.jpg Resolves 'Color Space Transform' mit aktivem Tone und Gamut Mapping + Forward OOTF -> praktisch fertiges out-of-the-box Bild, enspricht der Lichtstimmung bei der Aufnahme; sozusagen eine 'magic sauce', die das Material auf den fertigen Look bringt.

grade_1.10.1.T.jpg (Finales grading: leichtes Aufwärmen der Farbtemperatur + Diffusion)


Hier die Einstellungen:
Screenshot from 2021-02-26 23-54-56.png



Antwort von srone:

@cantsin

ich finde die letzten 2, ein wenig "schattenreich", dass dritte ganz leicht in tiefsten tiefen gecrusht, wäre mein favorit.

lg

srone



Antwort von mash_gh4:

cantsin hat geschrieben:
Ein echtes verborgenes Killer-Feature ist IMHO die neue "OOTF" ("opto-electronic transfer function")-Option bei Farbraumumwandlungen, z.B. von Log nach Rec709. Die Option "Apply Forward OOTF". ich nehme, du meinst in wahrheit "OETF"

das ist eigentlich nichts neues, sondern einfach nur die anwendung der gamma funktion bei der übertragung von linearem od. log codierten bild nach rec.709 od. ähnlichen display referred helligkeitsangaben.

ich bin mir nicht ganz sicher, wie weit es im resolve sinn macht, diese funktion aus dem größeren zusammenhang heraus zu lösen? es ermutigt höchstens irgendwelche experimentierfreudigen zeitgenossen, damit sachen anzustellen, für die es eigentlich gar nicht gedacht ist.



Antwort von cantsin:

mash_gh4 hat geschrieben:
cantsin hat geschrieben:
Ein echtes verborgenes Killer-Feature ist IMHO die neue "OOTF" ("opto-electronic transfer function")-Option bei Farbraumumwandlungen, z.B. von Log nach Rec709. Die Option "Apply Forward OOTF". ich nehme, du meinst in wahrheit "OETF" Nein, OOTF, sorry, ich meinte "opto-optical transfer function", nicht "opto-electrical transfer function". Wenn ich das richtig verstehe, handelt es sich um die Anwendung eines psychovisuellen Modells.



Antwort von cantsin:

srone hat geschrieben:
@cantsin

ich finde die letzten 2, ein wenig "schattenreich", dass dritte ganz leicht in tiefsten tiefen gecrusht, wäre mein favorit. Aber auch deren Schattenreichtum kann man mit dem neuen HDR-Tool extrem leicht korrigieren, ohne dass es zu Gamma-Shifts, Anhebungen des Schwarzwerts, Veränderung der Sättigung oder sonstigen Bildcharakteristiken kommt, indem man einfach den HDR-"Shadow"-"Exp"-Regler leicht hochdreht, hier auf z.B. den Wert 0.25:
lift-shadow_1.10.2.POST.jpg
bzw. 0.4:
1.10.3.lift-0.4_1.10.3.POST.jpg



Antwort von srone:

ok danke, dass schau ich mir an, wenn ich meine derzeit 2 bestehenden "grossprojekte" in der version 16 fertig habe...;-)

lg

srone



Antwort von mash_gh4:

cantsin hat geschrieben:
Nein, OOTF, sorry, ich meinte "opto-optical transfer function", nicht "opto-electrical transfer function". Wenn ich das richtig verstehe, handelt es sich um die Anwendung eines psychovisuellen Modells. o.k. -- dann ist es natürlich wirklich etwas anderes...

wobei mich wenigstens mein gefühl nicht darin getäuscht hat, dass es sich bei dieser namensgebung um eine zusammenfassung von OETF und EOTF handeln müsste:

https://en.wikipedia.org/wiki/Transfer_ ... Definition

https://cran.r-project.org/web/packages ... television

damit wird wohl in der praxis am ehesten die helligkeitswiedergabe eines gesamtsystems aus filmemulsionen, kameras und darstellungsmethoden (stichwort: HDR) beschrieben bzw. nachgeahmt, so wie man das in ähnlicher weise mit 3D LUTs schon länger macht .

oder lieg ich da falsch?



Antwort von cantsin:

Hier ein IEEE-Paper dazu, leider hinter Bezahlschranke, weshalb ich nur den Abstract lesen konnte: "The opto-optical transfer function (OOTF) is a psychovisual adjustment to ensure perceptually consistent images."
https://ieeexplore.ieee.org/document/7574905






Antwort von mash_gh4:

cantsin hat geschrieben:
Hier ein IEEE-Paper dazu, leider hinter Bezahlschranke, weshalb ich nur den Abstract lesen konnte: "The opto-optical transfer function (OOTF) is a psychovisual adjustment to ensure perceptually consistent images."
https://ieeexplore.ieee.org/document/7574905 ich glaube, dieses "psychovisual adjustment" betrifft hauptsächlich die verschiedenen methoden, HDR kontrastumfänge auf die reale darstellungsmöglichkeiten und SDR im besonderen umzumappen -- also: PQ / HLG / dolby vision etc. --, aber ansonsten bzw. im kontext der gebräuchlicheren video-datenformate und deren gamma-kurven macht es in meinen augen weit weniger sinn, diesen aspekt ausdrücklich hervorzuheben.

es ist allerdings so, dass sich auch schon in den traditionellen formaten ganz charakterische wiedergabeverzerrungen im sinne der OOTF einstellen, weil sich auch dort die vorgesehenen OETF- und EOTF-kurven zum teil nicht völlig aufheben. das passt schon, weil wir ja nicht unbedingt wollen, dass die helligkeitswerte am bildschirm einfach nur der realität des abgebildeten entsprechen, sondern der ursprüngliche motivkontrast bzw. erfasste dynamikumfang möglichst gut auf die tatsächlichen wiedergabemöglichkeiten übertragen wird. das verlangt in der praxis fast immer eine stauchung und vereinfachung der abbildung, wie sie im rahmen entsprechender fernsehnormen ohnehin schon seit langer zeit bewirkt wird.

wo und wie man diese zusammenhänge aber nun tatsächlich korrekt einsetzen od. gar gestalterisch modifizieren sollte, ist wieder eine ganz andere frage, in der ich mich lieber nicht zu sehr auf psychovisuelle schwarze magie verlassen oder rausreden würde.



Antwort von cantsin:

mash_gh4 hat geschrieben:
ich glaube, dieses "psychovisual adjustment" betrifft hauptsächlich die verschiedenen methoden, HDR kontrastumfänge auf die reale darstellungsmöglichkeiten und SDR im besonderen umzumappen -- also: PQ / HLG / dolby vision etc. --, aber ansonsten bzw. im kontext der gebräuchlicheren video-datenformate und deren gamma-kurven macht es in meinen augen weit weniger sinn, diesen aspekt ausdrücklich hervorzuheben. Naja, faktisch sind alle Log-Formate (also auch herstellereigene Log-Formate wie FLog, NLog, SLog2/3, VLog) HDR-Formate und bringen bei Umwandlung in Rec709 dasselbe Problem mit sich, wie man den höheren Kontrastumfang des Ausgangsformats in den niedrigeren Kontrastumfang des Zielformats übersetzt.

Also passt da OOTF.



Antwort von mash_gh4:

cantsin hat geschrieben:
Naja, faktisch sind alle Log-Formate (also auch herstellereigene Log-Formate wie FLog, NLog, SLog2/3, VLog) HDR-Formate und bringen bei Umwandlung in Rec709 dasselbe Problem mit sich, wie man den höheren Kontrastumfang des Ausgangsformats in den niedrigeren Kontrastumfang des Zielformats übersetzt.

Also passt da OOTF. ja -- im prinzip sehe ich das schon sehr ähnlich wie du.

die heutigen kameras bilden tatsächlich derart hohe dynamikumfänge ab, dass die erfassten bilder nur mehr schwer in die klassischen rahmenvorgaben gepresst werden können.

trotzdem empfinde ich es noch immer als handwerklichen pfusch, wenn zeitgenossen bspw. einfach keinen unterschied zw. LOG und rec.709 ausgangsmaterial machen, und beides mit den gleichen reglern glatt zu bügeln versuchen. ungefähr so würde ich eben auch eine missbräuchliche od. unreflektierte verwendung dieses HDR->SDR helligkeitsmappings in form eines willkürlichen ankreuzens dieser OOTF checkbox sehen.

ich kann mir aber gut vorstellen, dass wir uns über kurz oder lang tatsächlich so sehr an das aussehen von umgemappten HDR-produktionen gewöhnen, dass wir es als völlig "normal" bzw. anzustrebendes schönheitsideal empfinden.

ehrlich gestanden habe ich zu dieser frage bisher noch keine wirklich feste meinung, weil ich selber noch nie an einer HDR- oder hybridproduktion gearbeitet habe und auch über keine entsprechenden wiedergabegeräte verfüge -- mich also bisher noch nie ernsthafter mit diesen details und meinem persönlichen zugang dazu beschäftigen musste.



Antwort von Jörg:

Was bedeutet die als neu bezeichnete Option
" support for a floating videoscopes window in dual screen layouts"?
ich hatte gehofft, das man das Teil dann endlich mal irgendwo annageln kann.



Antwort von iasi:

Die Zeichnung in den Augen geht durch das "Abdunkeln" zu sehr verloren.
Die Zähne stechen wiederum hervor, statt dass das Gesicht betont wird.

Geht da eigentlich nicht mehr?
Im log-File scheint doch genügend Zeichnung zu stecken.