leider dürftest du mit den meisten einwänden und bedenken recht haben. :(
CameraRick hat geschrieben:Verstehe; das umzusetzen wäre wohl wirklich nicht so kompliziert. Da ist das "Programmieren" des Grids vermutlich noch am Ehesten das Problem, der Natron ist ja hier gern launisch, gerade mit On-Screen Controls :o) der Rest, also die Erstellung der Liste, sollte dann nicht so komplex sein.
ja -- wobei ich persönlich es halt für nicht ganz optimal halte, wenn als fixe vorgabe nur der CC24 raster abgetastet wird. in der hinsicht finde ich die umsetzung von scanin weitsichtiger, wo eben auch einige andere farbkarten unterstützt werden bzw. eine adaptierung an neue produkte verhältnismäßig einfach vorzunehmen ist. diese einschränkung auf sehr ernige unterstützte farbtafeln nervt mich ja auch am resolve ganz ungemein.
aber ganz abgesehen von den umsetzungsdetails, stellt sich einfach auch die generelle frage, wie man sich so etwas bspw. im natron wirklich wünschen würde bzw. gedanklich ausmalen könnte?
irgendwie passen derartige werkzeuge, die doch einiges an GUI benötigen und sich viel mehr an einem konkreten referenzbild orientieren, statt wie die meisten openfx-plugins den laufenden bilderstrom zu modifizieren, nicht wirklich gut rein in jene rahmenvorgaben, an denen sich natron u. nuke orientieren.
ich bin mir nicht sicher, ob es nicht einfacher und zielführender wäre, hier irgendein externes hilfsprogramm zu basteln, das als ausgabe irgendwas generiert, dass dann im natron wieder eingelesen werden kann? damit könte es aber natürlich auch noch umständlicher werden als es durch die
single shot orientierung von nuke/natron ohnehin bereits der fall ist.
ich bin da wirklich unschlüssig, wie man sich derartiges im idealfall vorstellen soll, so dass es für benutzer tatsächlich sinn macht und die arbeit auch parktisch erleichtert?
CameraRick hat geschrieben:Die eine Liste ist ja die Referenzliste, richtig?
ja -- genau!
wobei man diese zweite liste gar nicht erst mühsam händisch eingeben muss, weil sie sich ja, wie auch sehr viele andere nützliche konstanten, ohnehin bereits in der verwendeten python library findet (
https://colour.readthedocs.io/en/latest ... nates.html). die dortigen referenzangaben sind allerdings auf den CIE xyY farbraum bezogen, was ja durchaus sinn macht, aber eben auch das problem berührt, dass normalerweise einige kleinere zusätzlich rechenschritte notwendig sind, um entsprechende farbangaben aus der empirischen wirklichkeit bzw. den dort vorherrschenden beleuchtungsbedingungen in die welt der theoretisch idealen betrachtung zu übersetzten . ;)
den punkt kann man leider gar nicht deutlich genug hervorheben. hier tut sich nämlich wirklich eine unüberwindbare kluft zwischen den verhältnismäßig einfachen traditionellen werkzeugen und berechnungsmethoden und jenen deutlich anspruchsvolleren zugängen auf, die eben tatsächlich auch die spektralen chrakteristiken der verwendeten farbtafeln und kamerasensoren in die berechnung miteinbeziehen. das ist auch der grund, warum ich in diesem zusammenhang immer wieder so fasziniert von
dcamprof schwärme. dort werden nämlich tatsächlich auch diese dinge berücksichtigt, die freezer ohnehin bereits angesprochen hat, aber eben leider zu dem zeitpunkt, als jene kommentare zum oben verlinkten test verfasst wurden, die er übernommen hat, noch für niemanden von uns überwindbar waren. heute ist das anders. man kann auch diesen aspekt miteinbeziehen. tlw. mit völlig frei zugänglichen lösungen sogar besser als mit mit teuren kommerziellen produkten.
CameraRick hat geschrieben:Wobei ich es trotzdem spannend fände, parallel-arbeitende Grades zu haben, das wäre doch spannend (wenn auch Schwierig)
diesen wunsch kann ich ehrlich gestanden nicht ganz nachvollziehen. ?:)
die variante mit der korrektur via ColorMatrix hat natürlich ihre technischen grenzen. damit funktioniert es zwar ausgesprochen ressourcenschonend und in vielen fällen ausreichend, aber natürlich gibt es farbverzerrungen, die sich damit prinzipiell nicht in den griff bekommen lassen. dort führt dann gewöhnlich ohnehin kein weg mehr an komplizierterem (LUTs u.ä.) vorbei.
aber ganz unabhängig von der komplexität der angestrebten korrektur halte ich die grafische aufbereitungs und anzeige der notwendigen korrekturen und farbabweichungen oft für fast wichtiger und zielführender als eine möglichst benutzerfreundliche automatisierung aller notwendigen korrekturschritte.
manche dinge, die sich einfach nicht korrigieren lassen, weil es die verwendeten mittel gar nicht erst erlauben, werden einem erst auf diese weise richtig bewusst bzw. vernünftig erkennbar.
in dieser hinsicht finde ich
imatest ganz brauchbar, mit dem du ja auch entsprechende korrekturmatrizen generieren kannst.
CameraRick hat geschrieben:Dennoch muss man das ja auch erst irgendwie einbinden, ich glaube da ist der Punkt wo ich schnell aufgeben muss. Schaut man sich die Primary Dependencies an, trifft man übrigens auch wieder auf den alten Bekannten, Numpy :)
ja -- da hast du natürlich wieder recht! :)
das ist mir gestern dann leider auch erst wieder ins auge gestochen, als ich den beispielcode in der colour-science.org dokumentation kurz überflogen hab. natürlich verwenden sie numpy. macht ja auch wirklich sinn. fast alles in der digtalen bildverarbeitung lässt sich mit derartigen darstellungs- und verarbeitungsmitteln deutlich effizienter abwickeln.
dass ich das ursprünglich abgestritten habe, hat damit zu tun, dass ich im kopf viel zu sehr darauf fixiert war, an das einlesen und verarbeiten der eigentlichen bildinhalte mittels numpy zu denken, was ja bekanntlich im nuke/natron grundsätzlich nicht vorgesehen ist, weil es die performance massiv untergraben würde.
ich denke zwar, dass es kein großes problem sein dürfte, dem natron die notwendigen numpy erweiterungen unterzuschieben, muss das aber vorsichtshalber einmal in ruhe selber ausprobieren, bevor ich hier etwas falsches behaupte.
CameraRick hat geschrieben:ja -- prinzipiell kann man dem scanin relativ einfach mit komandozeilenangaben die koordinaten der eckpunkte des testmusters an hand eines overlays übergeben.
Gut, viele behaupten immer dass man in einer Kommandozeile sehr viele Dinge relativ einfach machen kann, ich halte es ja für ein Gerücht... :)
naja -- da hast schon recht!
wirklich ideal sind derartig komplizierte kommandozeilen basierenden modularen lösungen nicht. das betrifft gar nicht so sehr nur den schier "unmenschlichen" aspekt, sondern auch das problem, dass die einbindung derartiger unterprogramme in GUI wrapper u.ä. nicht ganz unproblematisch ist. da gibt's dann so kleinigkeiten wie z.b. die tatsache, dass je nach spracheinstellung ein komma statt einem punkt in der zahlendarstellung verewendet werden kann, was dann plötzlich zu wildesten fehlern führt...
so gesehen ist es auch aus der sicht von programmierern of besser, wenn man auf entsprechende fertig verfügbare hilfsmittel gleich eine schicht tiefer zugreifen kann -- also besser eine library mit sauberen parameterübergabemechanismen nutzt, statt diesen altmodischen umweg über text-basierende ein- und ausgabe bzw. steuerung.
aber gegenüber wunderhübschen oberflächlichen reizen benutzerfreundlicher grafischer lösungen, die sich meist gar nicht erst weiter in eigene basteleien einbinden lassen, sind auch die wildesten ungetüme aus der steinzeit komandozeielorientierter benutzung oft eine wahre wohltat. ;)
so dinge wie nuke und natron, die da irgendwo dazwischen liegen, und die vorteile von beidem möglichst sinnvoll zu verbinden suchen, finde ich allerdings auch wesentlich zeitgemäßer und attraktiver.
als ich vor ein-zwei jahren hunderte von automtisch generierten testbildern mit farbtafeln für meine arbeiten rund um die ACES unterstützung für die GH4 analysieren musste, wollte ich das ursprünglich auch im natron umsetzten. damals hat allerdings noch eine ganz wesentliche funktion in der ImageStatistics node gefehlt, so dass man aus dem pythen heraus die messwerte noch nicht auslesen konnte. dass das heute verhältnismäßig problemlos geht, hat damit zu tun, dass die betreffenden entwickler auf meinen diesbezüglichen bug report/feature request sofort reagiert haben und einen entsprechenden zugriff eingebaut haben. trotzdem habe ich dann letztlich das ganze doch lieber mit verhältnismäßig einfachen scripts und scanin abgewickelt.
ich hab zwar schon auch das gefühl, dass eine derartiges werkzeug im natron ganz nützlich sein könnte und auch andere anwender freuen würde, aber es spricht eben doch auch einiges dagegen. das meiste davon dürften wir hier ohnehin bereits berührt haben. ich hab aber auch das gefühl, dass es gerade im zusammenhang mit natron wirklich wichtig ist, dass nicht zu viel grob vereinfachende amateurlösungen veröffentlicht werden, sondern wirklich nur saubere und handwerklich korrekte lösungen, die auch professionellen ansprüchen stand halten. es ist zwar nett, wenn irgendwelche neu hinzugekommenen kollegen mit größter euphorie wilde hacks fabrizieren und ganz stolz mit uns umstehenden teilen, aber dem größeren projket tun sie damit nicht immer unbedingt etwas gutes.
das die geschichte mit der automatischen farbkorrektur in dieser hinsicht nicht ganz so einfach und mit einer simplen lösungen abzuwickeln ist, dürfte unsere diskussion hier vermutlich ohnehin ganz wunderbar belegen. es ist halt auch ein recht gutes beispiel für jene klasse von problemen, wo man erst bei der praktischen beschäftigung damit bzw. beim versuch, es selber besser umzusetzten, so richtig entdeckt, welche grundsätzlichen probleme und anforderen sich einem in den weg stellen. wenn man dafür einmal die nötige sensibilisierung entwickelt hat, sieht man auch die fertig verfügbaren lösungen in anderen programmen mit völlig neuen augen. das ist ja auch der grund, warum ich über das entsprechende feature im resolve derart lästerlich herziehe. wenn man einmal weiß, wie derartiges technisch funktioniert bzw. mit welch unterschiedlichen ansprüchen an die umsetzungsqulität man derartiges programmieren kann, weicht die beeindrucke faszination einer derartigen one-click-lösung schnell der desillusionierung. es lässt sich einfach kaum in befriedigender weise ganz so einfach umsetzten. will man derartiges tatsächlich sauber nutzen, braucht es fast komplizierte mittel, die man je nach den realen umständen jeweils anders miteinander kombinieren muss -- und dann ist man ja ohnehin gleich wieder bei diesen komplizierten werkzeugsammlungen und ihrem schier unüberblickbarem wust an kommandozeilenparametern, wie wir sie ohnehin auch jetzt schon haben. ;)
CameraRick hat geschrieben:Wenn ich das richtig verstehe, geht
CoCa in die Richtung, oder nicht? Bin grad leider nicht in der Lage das näher anzuschauen, ob es sich da eignet.
genau das hab ich gemeint, aber eben auf die schnelle nicht mehr gefunden! :)
CameraRick hat geschrieben:Gibt wohl .icc aus, aber das kann man ja zur Not mit DisplayCal zu einer .cube wandeln
das ist leider ein ganz zentrales problem an der ganzen geschichte!
speziell argyll ist ausgesprochen eng an ICC, und damit auch an den paradigmatischen eingrenzungen durch
display referred darstellungskonventionen, orientiert :(
abgesehen davon, dass ICC ganz generell eine verdammt undurchsichtige und komplizierte geschichte ist, kann man zwar die betreffenden LUTs tlw. automatisch übersetzen (siehe:
opencolorio baking LUTs), aber damit wird quasi nur der formale äußere teil erfasst. die tiefer liegenden probleme und unvereinbarkeiten der prinzipiell unterschiedlichen herangehensweise werden damit leider nicht vollständig oder befriedigend erfasst.
das ist ein leider ziemliches problem, dass die nutzung der meisten programme, die eher für bildschirmkalibration u.ä. geschaffen wurden, deutlich von jenen wenigen lösungen trennt, die derartiges auch innerhalb zeitgemäßer videobearbeitungs sauber umzusetzten versuchen. auf die schnellen fallen mir eigentlich fast nur sündteure lösungen von FilmLight ein, wo das wirklich in vorbildlicher weise gänzlich anders gehandhabt wird.