CameraRick
Beiträge: 4806

Re: Asiatische ColorChecker Alternative für wenig Geld - EYEPHOTO

Beitrag von CameraRick »

Ist natürlich neuer, sonst wäre er ja eh nicht mehr "gut", man "darf" ja nur zwei Jahre; meiner ist etwa 1 :)

Ich habe die Daten natürlich immer noch nur daheim, gleiche also heute Abend mal ab. Wobei ich gleich sagen kann, dass die #4 die vorher gut gepasst hat dann doch nicht so akkurat ist wie angenommen :)
Resolve wird ja vermutlich die neuere Korrektur drin haben, nehme ich an.



freezer
Beiträge: 3247

Re: Asiatische ColorChecker Alternative für wenig Geld - EYEPHOTO

Beitrag von freezer »

CameraRick hat geschrieben:Ist natürlich neuer, sonst wäre er ja eh nicht mehr "gut", man "darf" ja nur zwei Jahre; meiner ist etwa 1 :)

Ich habe die Daten natürlich immer noch nur daheim, gleiche also heute Abend mal ab. Wobei ich gleich sagen kann, dass die #4 die vorher gut gepasst hat dann doch nicht so akkurat ist wie angenommen :)
Resolve wird ja vermutlich die neuere Korrektur drin haben, nehme ich an.
Hab gerade nachgeschaut, auf den CC PPs steht leider gar kein Datum, das ist nur auf den großen Charts.

Ich fürchte, dass Resolve noch die alten Werte verwendet, denn X-Rite hat die Supportseite mit den Werten des CC PPs nie angepasst.
Hab das jetzt auch mal im BMD-Supportforum angesprochen, mal sehen.

Ich habe übrigens noch einen CC PP mit den alten Werten. Vor allem die Primärfarben sind gedämpfter als bei meinem neuen CC SG, mit dem sich der CC PP ja 24 der Felder teilt.
Mein CC PP Video sieht nochmals anders aus, da sind die Farben so angepasst, dass sie mit dem Vectorscope übereinstimmen sollten.
LAUFBILDkommission
Robert Niessner - Graz - Austria
Blackmagic Cinema Blog
www.laufbildkommission.wordpress.com



CameraRick
Beiträge: 4806

Re: Asiatische ColorChecker Alternative für wenig Geld - EYEPHOTO

Beitrag von CameraRick »

Aber wenn der Checker noch alte Werte hat, hast ihn dann drei Jahre "eingepackt" gelassen, oder wie? Man soll sie ja nur zwei jahre nutzen, sonst kann man sich ja eh nicht mehr verlassen.
Vielleicht ist meiner natürlich auch viel älter, und lag lange im Lager. Muss mal schauen ob ich die Packung noch finde, vielleicht ist da ein Sticker drauf oder so.

Ist natürlich kritisch wenn die Software die man zum Abgleichen nutzt auf andere Werte setzt, da ist dann ein X-Rite so wenig akkurat wie eine generische China-Tafel.
Wobei es ja so scheint, dass die Tafel ohnehin nicht dem entspricht, was sie soll, was generell die Frage aufwirft wie akkurat das sein kann, und ob die China Tafel dann so fatal zu benutzen wäre



mash_gh4
Beiträge: 4716

Re: Asiatische ColorChecker Alternative für wenig Geld - EYEPHOTO

Beitrag von mash_gh4 »

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.



CameraRick
Beiträge: 4806

Re: Asiatische ColorChecker Alternative für wenig Geld - EYEPHOTO

Beitrag von CameraRick »

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.
Da hast Du selbstredend recht. Ich hab mich ein wenig zu sehr darauf versteift, nachdem Du das Nuke Gizmo erwähnt hattest. Zugegeben finde ich die die Nutzung im Nuke und Natron zum Arbeiten auch eher uninteressant (habe das erwähnte Gizmo nicht mal installiert), aber zumindest im Nuke wäre es zur Analyse doch ganz spannend. Natron kommt ja ohne Scopes etc, da macht es das noch etwas schwierig, aber auch dort hat man eben eine ganz andere Kontrolle über Bilddaten. Ich zumindest schwinge mich nicht in den Resolve, wenn ich ein Bild kritisch betrachten will, aber ich bin da auch vorgeschädigt... :)
den punkt kann man leider gar nicht deutlich genug hervorheben.
An diesem Punkt muss man aber auch einhakend nachfragen, wie wichtig das nachher wirklich ist. Also, nicht zur Bildanalyse sondern für den praktischen Nutzen - etwa im Resolve. Eine 100% Genauigkeit werde ich nie erreichen können, einfach auch deswegen weil man ja die Variablen nicht kennt. Etwa die real genutzten Werte im Resolve, ggf auf dem eigenen Checker, und dann die Ungewissheit ob mein 70€ Stück Plastik auch wirklich akkurat ist - offenbar ists das nämlich nicht.
Sprich, wir haben viele Fehlerquellen bevor wir überhaupt drüber nachdenken können wie differenziert wir an die Analyse der Patches gehen sollten; denn irgendwann ists ja auch mehr hinderlich als zuträglich zu detailliert zu werden, wenn wir schon "wissen" dass die aufgenommenen Werte nicht richtig sind :o)

Hier auch eine Nachfrage. Du sagst ja schon, die Einbindung in Resolve sei sehr primitiv; was sie aber zumindest anscheinend macht ist die Berücksichtigung des Farbraums. Das machen ja Argyll und Co nicht?
Denn ob ich eine Farbe in LogC oder Rec709 aufnehme macht ja schon einen gravierenden Unterschied für die Korrektur; gerade die Grau-Patches. Insofern ist eine Einbindung in zB Nuke oder Natron einer standalone-GUI schon vorzuziehen, da diese Softwares ja ohnehin nur richtig arbeiten, wenn Du vorher alles linearisierst. Außer natürlich man baut LUTs ein, die vor der Erfassung greifen, oder so.
diesen wunsch kann ich ehrlich gestanden nicht ganz nachvollziehen. ?:)
Das ist eher eine persönliche Sache die mit diesem Thema hier nichts zu tun hat, die Farbmatrix ergibt da schon mehr Sinn. War ein Spruch am Rande, verzeih die Ablenkung :)
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 :(
Daran hatte ich nun gar nicht gedacht. Ich stecke da in der Materie aber auch nicht all zu tief in der Materie der ICC Profile drin. Die Frage ist halt, ob man hier schon von "gut genug" sprechen kann, oder nicht - in Anbetracht des "Variablen Problems" von oben reicht es ja wenn es nah kommt...?
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.
Kann der 3D LUT Creator das nicht, halbwegs zufrieden stellend? Ich finde das Tool ja sehr spannend, aber ich finde den Preis unverschämt. Also zumindest von der Handhabe her; wenn es teuer ist, Ok, aber nur weil ich kein Russe bin soll ich mal eben den vierfachen Preis zahlen? Der Entwickler zeigt sich auch "gütig" und bietet einem dann 20% an (obwohl eine Aktion über 20% für alle gerade läuft).
So, sorry für den Rant :) jedenfalls, das Tool selbst konnte ich mal zum Spielen benutzen, finde ich ganz witzig. Wie nützlich es ist kann ich nur erahnen; ein Freund von mir, der "ein wenig" tiefer in der Technik drin steht, hat das Tool und ist recht angetan davon. Und da Farbe irgendwie sein Job ist, vertraue ich ihm da schon irgendwie; nur noch nicht genug, um dieses Tool auch mal anzuschaffen... :)



mash_gh4
Beiträge: 4716

Re: Asiatische ColorChecker Alternative für wenig Geld - EYEPHOTO

Beitrag von mash_gh4 »

CameraRick hat geschrieben:An diesem Punkt muss man aber auch einhakend nachfragen, wie wichtig das nachher wirklich ist. Also, nicht zur Bildanalyse sondern für den praktischen Nutzen - etwa im Resolve. Eine 100% Genauigkeit werde ich nie erreichen können, einfach auch deswegen weil man ja die Variablen nicht kennt. Etwa die real genutzten Werte im Resolve, ggf auf dem eigenen Checker, und dann die Ungewissheit ob mein 70€ Stück Plastik auch wirklich akkurat ist - offenbar ists das nämlich nicht.
ja -- ich glaube auch, dass man hier ganz klar zw. zwei möglichen verwendungsweisen bzw. ansprüchen und erwartungen unterscheiden muss:

a) wenn man das ganze nur benutzt, um bereits halbwegs richtig aufbereitetes material (=mit korrekter IDT importiert) zu matchen, wird es vermutlich auch in der ganz einfachen variante ziemlich gut funktionieren. es leistet dann allerdings auch nicht viel mehr als ein etwas aufwendiger weißabgleich. in dem fall sind auch abweichungen der farben auf den testkarten ziemlich gleichgültig, weil man am besten ohnehin gleich zwei aufnahmen der selben karte auf diese weise aneinander angleicht, statt sich auf irgendwelche externen werte zu verlassen.

b) die zweite variante, die meiner beobachtung nach von relativ vielen resolve benutzern versucht oder ersehnt wird, besteht darin, dass man mit diesem mittel fehlende kameraprofile zu ersetzten versucht. dieser zugang scheint mir eher zum scheitern verurteilt bzw. mit derart einfachen mitteln nicht wirklich ausreichend gut umsetzbar zu sein. dafür sind eben diese anderen werkzeuge, die sich ganz bewusst als hilfmittel zur aufwändigeren profilerstellung für die RAW entwicklung verstehen, besser geeignet.
CameraRick hat geschrieben:Hier auch eine Nachfrage. Du sagst ja schon, die Einbindung in Resolve sei sehr primitiv; was sie aber zumindest anscheinend macht ist die Berücksichtigung des Farbraums. Das machen ja Argyll und Co nicht?
Denn ob ich eine Farbe in LogC oder Rec709 aufnehme macht ja schon einen gravierenden Unterschied für die Korrektur; gerade die Grau-Patches.
natürlich spielt dieser aspekt eine wichtige rolle!

normalerweise verwendete man für argyll 16bit tifs mit linearem werten, die man z.b. direkt mit dem dcraw aus rohen sensordaten gewinnt bzw. sich unmittelbar auf die dort vorgefundenen werte beziehen. das ist ohnehin sehr nahe an dem dran, was auch nuke und natron intern verwenden. aber es geht zur not natürlich auch mit entsprechendem nachträglichen linearisieren von sRGB oder rec709 ausgangsmaterial.

wie weit das ganze aber tatsächlich mit den üblichen rec709 einschränkungen zu gebrauchen ist, oder eben doch nur bei relativ hochwertigerem ausgangsmaterial sinn macht, ist schwer zu beantworten?

ich hab jedenfalls meine versuche, für die GH4 nachträgliche entzerrungen der farbdarstellung in den klassischen bildprofilen zu rechnen, irgendwann aufgegeben, weil mir bewusst geworden ist, dass sich manche kamerainternen eingriffe -- speziell im zusammenhang mit der gamutkompression, dem weißabgleich und anderem einstellungsabhängigem internem hokuspokus -- mit überschaubarem aufwand nachträglich nicht mehr wirklich eindeutig und sauber umkehren lassen. :(

ich würde also eher sagen, dass eine derartige profilerrechnung im zusammenspiel mit sensorrohdatenn wirklich gut und einfach funktioniert, nicht aber mit fertig gebackenem videomaterial, wie es die meisten kameras liefern. mit div. log-repräsentationen schaut es da zwar schon wieder ein wenig besser aus, aber damit gibt's dann halt wieder andere bekannte probleme.

andere sehen das aber natürlich wesentlich optimistischer und vertrauen auf ihre jeweiligen zauber-LUTs die das offenbar, wenigstens für sie, völlig ausreichend lösen. ;)



cantsin
Beiträge: 14145

Re: Asiatische ColorChecker Alternative für wenig Geld - EYEPHOTO

Beitrag von cantsin »

Der Sichtweise "Farbkarte=bessere Graukarte" kann ich beipflichten. Die Color Matching-Funktion von Resolve taugt zwar nicht zur Farbkalibrierung (bzw. Farbraumtransformation). Aber ca. 90% der Leute, die heute in Log oder Raw drehen und dann fürchterlich farbvergurkte Ergebnisse auf YouTube und Vimeo stellen, kämen damit besser zum Ziel.

(Die Color Matching-Funktion von Resolve unterstützt die meisten kameraspezifischen Log-Profile wie z.B. SLog2.)



CameraRick
Beiträge: 4806

Re: Asiatische ColorChecker Alternative für wenig Geld - EYEPHOTO

Beitrag von CameraRick »

mash_gh4 hat geschrieben: a) wenn man das ganze nur benutzt, um bereits halbwegs richtig aufbereitetes material (=mit korrekter IDT importiert) zu matchen, wird es vermutlich auch in der ganz einfachen variante ziemlich gut funktionieren. es leistet dann allerdings auch nicht viel mehr als ein etwas aufwendiger weißabgleich. in dem fall sind auch abweichungen der farben auf den testkarten ziemlich gleichgültig, weil man am besten ohnehin gleich zwei aufnahmen der selben karte auf diese weise aneinander angleicht, statt sich auf irgendwelche externen werte zu verlassen.
Sobald Du aber mit IDT usw ran gehst ist die Variante aber insgesamt auch nicht mehr so ganz einfach, haha :)
Zur Angleichung sind die Werte natürlich nicht so immens wichtig, wenn sie aber im Ansatz schon verdreht sind hast Du halt statt einer dann zwei ruinierte Files. Etwa, wenn die Sättigung vom Rot falsch ausgelegt wird und auf einmal überall zu satt wird.
mash_gh4 hat geschrieben: b) die zweite variante, die meiner beobachtung nach von relativ vielen resolve benutzern versucht oder ersehnt wird, besteht darin, dass man mit diesem mittel fehlende kameraprofile zu ersetzten versucht. dieser zugang scheint mir eher zum scheitern verurteilt bzw. mit derart einfachen mitteln nicht wirklich ausreichend gut umsetzbar zu sein. dafür sind eben diese anderen werkzeuge, die sich ganz bewusst als hilfmittel zur aufwändigeren profilerstellung für die RAW entwicklung verstehen, besser geeignet.
In einer perfekten Welt wäre das ja auch irgendwie wünschenswert. Ich glaube halt man sollte mit dieser Methodik auch nicht zu stark an RAW gebunden sein, weil ich da ja schon von Haus aus andere Werkzeuge nutzen kann was solche Charts ggf auch obsolet machen könnte.
Interessant ist es ja schon irgendwie bei gebackenem Material, was ja auch nicht schlecht sein muss, je nach Quelle. Ich meine eine DSLR kriege ich damit nicht gescheit nach LogC gewandelt, aber um eine Sony und eine Canon auf einen gemeinsamen Nenner zu bekommen wäre natürlich nett. Etwas weit hergeholt, aber gescannter Film ist ja auch ein fertig gebackenes Bild, das würde ja auch funktionieren können - weniger weit hergeholt wäre eine Alexa oder BMD auf Prores (ich hoffe iasi liest nicht mit).
Im Grunde wäre es wie zB die simple, in Nuke/Natron implementierte Linearisierung auf Steroiden, weil es nicht nur die feste Konvertierung anhand einer LOG-Kurve durchführt, sondern auch die tatsächlich im Bild vorkommenen Farben berücksichtigt.
Was ich im Grading aber nützlicher fände als alles in den gleichen Spielraum zu werfen, wäre eine Kamera als Referenz festzulegen und dann die anderen Cams auf diese Referenzwerte zu bringen. Das könnte man mit einer eigenen Argyll-Lösung natürlich ganz gut umsetzen? Denn wenn ich einfach nur alle Kameras in den gleichen Raum bringe heißt das ja auch, dass ich in diesem Raum arbeiten muss, aber vielleicht gar nicht will. Sondern lieber in einem gegebenem Raum, wo die B oder C Kamera besser dran angepasst werden soll
mash_gh4 hat geschrieben: normalerweise verwendete man für argyll 16bit tifs mit linearem werten, die man z.b. direkt mit dem dcraw aus rohen sensordaten gewinnt bzw. sich unmittelbar auf die dort vorgefundenen werte beziehen. das ist ohnehin sehr nahe an dem dran, was auch nuke und natron intern verwenden. aber es geht zur not natürlich auch mit entsprechendem nachträglichen linearisieren von sRGB oder rec709 ausgangsmaterial.
Verstehe, das ergibt natürlich Sinn. Muss man natürlich im Kopf behalten die Referenz-Colorchecker-Werte auch so anzuliefern (also nicht nur deren Tabelle abschreiben?). Wenn es dann aber ein einzelnes Tool wäre, bräuchte man schon die Linearisierung innerhalb des Programms, sonst würde das ja schon echt ätzend werden wenn ich den Zwischenhalt im Resolve oder Nuke machen müsste, um das Material immer vorher zu linearisieren.
Solang das nur für RAW wirklich funktioniert ist die Lösung in meinen Augen mega uninteressant, da dort einfach gar nicht die Probleme herrschen die ich mit gebackenem Material versuche zu erreichen.

Das Ergebnis hängt natürlich von der Güte des Materials ab, ich kann eine GoPro schlecht in LogC wandeln wollen und erwarten dass das irgendwie gescheit funktioniert, das ist ja klar. Der Colorchecker macht hier das Angleichen einfacher, und sicherlich auch besser, aber nicht unbedingt gut :)
Aber das ist ja auch ein kritischer Punkt: wenn man sich als Ziel steckt seine Handykamera auf Alexa-colurscience zu hieven ist das natürlich zum Scheitern verurteilt. Genau wie wenn ich mein Material bei 3200K gedreht habe wo es 5600K hätten sein müssen. Das kriegt man ja alles nicht mehr weg. Aber so die "typischen Kleinigkeiten" damit korrigieren bzw angleichen, da sehe ich nicht so die Problematik
mash_gh4 hat geschrieben: ich hab jedenfalls meine versuche, für die GH4 nachträgliche entzerrungen der farbdarstellung in den klassischen bildprofilen zu rechnen, irgendwann aufgegeben, weil mir bewusst geworden ist, dass sich manche kamerainternen eingriffe -- speziell im zusammenhang mit der gamutkompression, dem weißabgleich und anderem einstellungsabhängigem internem hokuspokus -- mit überschaubarem aufwand nachträglich nicht mehr wirklich eindeutig und sauber umkehren lassen. :(

ich würde also eher sagen, dass eine derartige profilerrechnung im zusammenspiel mit sensorrohdatenn wirklich gut und einfach funktioniert, nicht aber mit fertig gebackenem videomaterial, wie es die meisten kameras liefern. mit div. log-repräsentationen schaut es da zwar schon wieder ein wenig besser aus, aber damit gibt's dann halt wieder andere bekannte probleme.
Wohin wolltest Du die GH4 denn wandeln? Die hat an und für sich ja generell nicht so das optimale Material, also nicht nur aus Perspektive eines Colorcheckers.
Mit RAW klappt ist sicherlich besser, aber dann könnte ich mir das zB auch schenken. Bei Projekten die wir auf RAW aufzeichnen wird ohnehin ein Colorist gebucht der da ohnehin nicht so die Schwierigkeiten mit dem Angleichen hat, der Colorchecker ist in meinen Augen eher eine Homebrew-Lösung für Hansel wie mich, die schnell mal was abgleichen müssen :)

Das setzt aber voraus, dass der Checker erstmal richtige Farben abgibt. Und zwar die Farben, die meine Software auch erwartet. Vermutlich wäre es gut, wenn man ein Tablet mit "perfekt" kalibrietem Display dafür nutzten würde, wo man ja auch Einfluss auf die Werte hat. Reflektierende Displays machen das zunichte, aber hey :)
(Die Color Matching-Funktion von Resolve unterstützt die meisten kameraspezifischen Log-Profile wie z.B. SLog2.)
Gerade noch einmal rein geschaut, echt toll wie viele Farbräume sie mittlerweile bieten, haben das stark aufgebohrt. Super!
Jetzt müssten sie nur auch mal die Log-Kurve ihrer eigenen Kameras offen legen, dieser Homebrew-Mist um das Ganze in anderer Software als Resolve gangbar zu machen geht mir echt auf die Klötze. Fängt ja schon bei der Aufzeichnung an, wo ich mittleres grau belichten soll, deren Ansicht nach. Und wo weiß/schwarz liegen. Ich mein ich habs ausgelesen, aber wäre schön mal Whitepapers dazu zu lesen, veröffentlich doch jeder andere auch :(


Zum Thema bessere Graukarte:
Anekdote am Rande, habe neulich mal eine Graukarte gekauft. So eine ganz billige, faltbare für 5€ ist es geworden, mal aus Jucks.
Hab die nach Erhalt durchgemessen, die ist akkurater bei Mittelgrau als die Graukarte des Colorcheckers :) auch lustig: zum Basteln habe ich eine Hartschaumplatte gekauft, eine Seite schwarz und eine grau. Selbst die ist näher dran als der Colorchecker. Dazu noch sehr dick, und bei 5€ für 60x40 echt günstig... :o)



freezer
Beiträge: 3247

Re: Asiatische ColorChecker Alternative für wenig Geld - EYEPHOTO

Beitrag von freezer »

CameraRick hat geschrieben: Zum Thema bessere Graukarte:
Anekdote am Rande, habe neulich mal eine Graukarte gekauft. So eine ganz billige, faltbare für 5€ ist es geworden, mal aus Jucks.
Hab die nach Erhalt durchgemessen, die ist akkurater bei Mittelgrau als die Graukarte des Colorcheckers :) auch lustig: zum Basteln habe ich eine Hartschaumplatte gekauft, eine Seite schwarz und eine grau. Selbst die ist näher dran als der Colorchecker. Dazu noch sehr dick, und bei 5€ für 60x40 echt günstig... :o)
Die Frage ist halt: ist die billige Graukarte dann auch unter allen Lichtbedingungen neutral, oder nicht?
Die Color Checker Karten reflektieren ein neutrales Spektrum unter allen Lichtbedingungen.
Und die größere "Graukarte" des CC PP ist übrigens KEIN 18% Grau, das wäre dann das graue Feld #22 (Schwarz = #24).
LAUFBILDkommission
Robert Niessner - Graz - Austria
Blackmagic Cinema Blog
www.laufbildkommission.wordpress.com



CameraRick
Beiträge: 4806

Re: Asiatische ColorChecker Alternative für wenig Geld - EYEPHOTO

Beitrag von CameraRick »

Die Frage ist eben auch wie wichtig das dann ist wenn die Farben von vornherein nicht stimmen :)

Ist freilich etwas schwerer zu testen, auch weil ich nicht jede Lichtquelle da habe, aber könnte es natürlich mal versuchen.
#24 sollte doch eher dunkelgrau sein, oder nicht? Also nicht 0% reflektierend (schwarz) sondern ein paar Prozent (2, 3%)?



mash_gh4
Beiträge: 4716

Re: Asiatische ColorChecker Alternative für wenig Geld - EYEPHOTO

Beitrag von mash_gh4 »

CameraRick hat geschrieben:Ist freilich etwas schwerer zu testen, auch weil ich nicht jede Lichtquelle da habe, aber könnte es natürlich mal versuchen.
es gibt ohnehin mehre unabhängige quellen, die saubere messungen des entsprechenden spektralverhaltens der Rite ColoerChecker produkte enthalten, wie man sie auch für komplizierte rechnungen in diesem umfeld benötigt:

Bild

das ändert aber nichts daran, dass freezer hier sehr einseitig nur die vorzüge dieses produkts herausstreicht, ohne auch nur im ansatz zu akzeptieren, dass es eben auch bedeutsame schwächen und probleme damit gibt. deshalb ist es in vielen fällen sehr vorteilhaft, wenn man sich nicht ausschließlich nur darauf stützt, sondern auch andere targets einbezieht od. bevorzugt.



freezer
Beiträge: 3247

Re: Asiatische ColorChecker Alternative für wenig Geld - EYEPHOTO

Beitrag von freezer »

mash_gh4 hat geschrieben: das ändert aber nichts daran, dass freezer hier sehr einseitig nur die vorzüge dieses produkts herausstreicht, ohne auch nur im ansatz zu akzeptieren, dass es eben auch bedeutsame schwächen und probleme damit gibt.
??? Wo akzeptiere ich nicht mal im Ansatz die Schwächen?
Du interpretierst ein bisschen viel in meinen Text rein, mein lieber mash_gh4.
LAUFBILDkommission
Robert Niessner - Graz - Austria
Blackmagic Cinema Blog
www.laufbildkommission.wordpress.com



CameraRick
Beiträge: 4806

Re: Asiatische ColorChecker Alternative für wenig Geld - EYEPHOTO

Beitrag von CameraRick »

Na ja, das Gefühl erschließt sich wohl etwas dadurch, dass Du zwar andere produkte spürbar in Frage stellst, aber die Unzureichende Farbgenauigkeit des Colorcheckers eher nicht so schwierig zu finden scheinst.
Ist ein Eindruck den man zumindest bekommen kann :(



mash_gh4
Beiträge: 4716

Re: Asiatische ColorChecker Alternative für wenig Geld - EYEPHOTO

Beitrag von mash_gh4 »

freezer hat geschrieben:??? Wo akzeptiere ich nicht mal im Ansatz die Schwächen?
Du interpretierst ein bisschen viel in meinen Text rein, mein lieber mash_gh4.
ich denke nicht, dass das der fall ist!
du schreibst zwar:"Die Color Checker Karten reflektieren ein neutrales Spektrum unter allen Lichtbedingungen." -- was natürlich nur innerhalb gewisser grenzen bzw. klar spezifizierbarer rahmenbedingungen sinn macht, negierst aber konsequent alle bereits sehr früh hier aufgeworfenen einwände bzgl. des relativ problematischen gamut-umfangs bzw. fehlender unterschiedlicher sättigung von testfeldern, wie man sie für anspruchsvollere korrekturen fast zwingend benötigt.

ich weiß schon, du wirst darauf sicher antworten, dass man dafür eben die größeren ausgaben mit mehr meßfeldern von x-rite od.ä. verwenden wird. das trifft aber leider nur einen teil der sache, weil eben manche diese probleme einfach mit den herstellungsbedingten besonderheiten dieser targets zu tun haben -- sich also einfach nicht besser umsetzten lassen, ohne andere eigenschaften zu beeinträchtigen. so haben dann letztlich doch auch wieder ganz billiger tintenstrahlausdrucke od. belichtete targets auf hochwertigem fotopapier z.t. eigenschaften und qualitäten, die diese bekannten lösungen in bestimmten bereichen deutlich übertreffen. natürlich wird man in der praxis die vorzüge von beidem zu verbinden suchen, aber man sollte eben auch nicht ganz blind nur die eine seite der medaille zu sehen und hervorzuheben versuchen.



freezer
Beiträge: 3247

Re: Asiatische ColorChecker Alternative für wenig Geld - EYEPHOTO

Beitrag von freezer »

Sorry, aber wenn ihr hier mit Unterstellungen anfangt zu argumentieren, dann halte ich mich ab jetzt hier raus. Auf dem Niveau interessiert mich das Thema nicht weiter. Mir ist völlig egal ob ihr die CC Produkte für gut oder schlecht hält, ich verteidige da gar nichts, warum auch. Ich war an einer sachlichen Diskussion zu Vor- und Nachteilen interessiert und die scheint wohl nicht mehr gegeben zu sein.
LAUFBILDkommission
Robert Niessner - Graz - Austria
Blackmagic Cinema Blog
www.laufbildkommission.wordpress.com



CameraRick
Beiträge: 4806

Re: Asiatische ColorChecker Alternative für wenig Geld - EYEPHOTO

Beitrag von CameraRick »

Ich wollte Dir nichts unterstellen, nur versuchen zu erklären warum ich denke dass der Eindruck entsteht. Bei mir nämlich ein wenig auch :(

Dann frage ich ganz sachlich:
Findest Du es nicht problematisch, dass die Colorpatches des X-Rite nicht mal in optimaler Umgebung ihre Farbwerte erreichen, und dass es selbst wenn sie es täten schwierig zu nutzen sind, weil man nicht wissen kann ob eine Software alte oder neue Werte nutzt?´
Das stellt doch die positiven Eigenschaften, in allen Spektren gleich zu reflektieren, schon irgendwie in den Schatten?

Ich frage so präzise weil Du für meine Begriffe bisher viele Lösungen kritisiert hast, aber auf die Farbproblematik keinen Kommentar angegeben hast :o



mash_gh4
Beiträge: 4716

Re: Asiatische ColorChecker Alternative für wenig Geld - EYEPHOTO

Beitrag von mash_gh4 »

freezer hat geschrieben:Ich war an einer sachlichen Diskussion zu Vor- und Nachteilen interessiert und die scheint wohl nicht mehr gegeben zu sein.
bitte freezer nimm das nicht persönlich!
mir geht's wirklich auch um die sachliche seite der ganzen geschichte.

es kann schon sein, dass wir da beide zwei ziemlich unterschiedliche und nicht ganz kompatible sichtweisen vertreten, aber mir ist trotzdem jeder, der dazu überhaupt eine meinung hat und sich um entsprechende handwerliche qualitäten bemüht, deutlich lieber als jene, die sich um solche qualitäten gar nicht kümmern. ;)



nachtaktiv
Beiträge: 3169

Re: Asiatische ColorChecker Alternative für wenig Geld - EYEPHOTO

Beitrag von nachtaktiv »

den chinachecker gibts übrigens mittlerweile fürn zwanni in der bucht.

https://www.ebay.de/itm/24Patch-Farben- ... OSwldRaPJJ~
Die Ignore Funktion ist ein Segen <3



cantsin
Beiträge: 14145

Re: Asiatische ColorChecker Alternative für wenig Geld - EYEPHOTO

Beitrag von cantsin »

Das Problem ist, dass das Ding eine proprietäre Farbtabelle hat, die durch keine mir bekannte Software unterstützt wird...



nachtaktiv
Beiträge: 3169

Re: Asiatische ColorChecker Alternative für wenig Geld - EYEPHOTO

Beitrag von nachtaktiv »

?? das sind doch die gleichen felder wie beim X rite.

https://www.ebay.de/itm/X-Rite-Colorche ... 2ab4b16b99
Die Ignore Funktion ist ein Segen <3



Sammy D
Beiträge: 2270

Re: Asiatische ColorChecker Alternative für wenig Geld - EYEPHOTO

Beitrag von Sammy D »

nachtaktiv hat geschrieben: Sa 15 Sep, 2018 17:47 ?? das sind doch die gleichen felder wie beim X rite.

https://www.ebay.de/itm/X-Rite-Colorche ... 2ab4b16b99
Die RGB-Werte sind teilweise voellig unterschiedlich.



Mediamind

Re: Asiatische ColorChecker Alternative für wenig Geld - EYEPHOTO

Beitrag von Mediamind »

Bei meinen Hochzeiten verwende ich verschiedene Blickwinkel mit verschiedenen Kameras. Dies sind die GH5 und die GH5s, die Panasonic HC-X1 und als Backup die AX100. Whitebalance habe ich im Griff, die Kameras sind aber bei der Farbdarstellung unterschiedlich. GH5 und GH5s sind fast identisch, die HC-X1 und die AX100 sind aber schon stark abweichend. Bei der HC-X1 nehme ich Cinelike-D, die GH5/s verwende ich mit V-Log. Seht Ihr einen Weg, mit solch einem Colorchecker zum Farbausgleich zu gelangen? Gerade in der Kirche und im Standesamt mit Multicam zu arbeiten kostet mir in den Post einfach zu viiel Zeit und Mühe.
Alternativ überlege ich den X-Rite Colorchecker und Color Finale anzuschaffen. Ich möchte das ganze gerne in FCPX belassen. Ich habe bisher außer der Kombination von Color Finale und X-Rite keinen Weg eines schnellen und automatischen Farbabgleichs gefunden. Kennt Ihr noch andere Wege, die in der hektischen Welt des Hochzeitsfilms praktikabel sind?



 Aktuelle Beiträge [alle Foren]
 
» Mac SSD Speed Messung?
von R S K - Do 17:27
» Neues SIGMA 50mm F1,2 DG DN | Art Objektiv wiegt 745g
von cantsin - Do 17:19
» Red Komodo 6K + Gimbal, Advanced Ring Grip und viel Zubehör
von Sevenz - Do 16:35
» Firmwareupdates für Sony Alpha 1, 7 IV, 7S III, 7R V, 7CR, 7CII, ZV-E1
von klusterdegenerierung - Do 16:08
» Tieraufnahmen mit dem MKE600 + H1 Essential rauschen
von Swat - Do 16:06
» 4 Gründe hartes Licht zu nutzen
von ruessel - Do 15:45
» Blackmagic Camera 8.6 Public Beta
von Frank Glencairn - Do 15:12
» [gelöst] 3.5mm Klinkenstecker Überwurfmutter
von Skeptiker - Do 14:42
» Panasonic S5 - Allgemeine Fragen, Tipps und Tricks, Zeig deine Bilder/Videos usw.
von Darth Schneider - Do 13:49
» -SONY FX- Erfahrungsaustausch
von rush - Do 13:40
» AOC bringt 44.5" OLED-Riesenmonitor mit 98.5% DCI-P3
von MK - Do 12:07
» Adobe führt die neue Funktion "Structure Reference" in Firefly ein
von slashCAM - Do 10:54
» Sondergagen - Wer aufmuckt, wird nicht mehr besetzt
von stip - Do 9:49
» Was schaust Du gerade?
von Frank Glencairn - Do 9:00
» Nikon stellt NIKKOR Z 28-400mm f/4-8 VR Superzoom-Objektiv vor
von rush - Do 8:51
» Exhuma - die Südkoreaner können erfolgreiche Filme drehen
von -paleface- - Do 8:46
» FCPX/Motion, DaVinci/Fusion... Tipps&Tricks
von Frank Glencairn - Do 4:00
» Was hörst Du gerade?
von roki100 - Do 0:22
» Sony A9 III im Praxistest - ein echter Überraschungscoup auch für Filmer
von Mantas - Mi 23:27
» Video Pro X stürzt beim Multi Cam Schnitt ab
von MisterX - Mi 21:47
» Uwe Boll: Wie man Filme produziert ohne pleite zu gehen!
von iasi - Mi 19:53
» Nach 7 Jahren mit der OG BMPCC finde ich das Bild noch immer schön.
von Darth Schneider - Mi 18:58
» Verschachtelte Timeline im richtigen Seitenformat
von Clemens Schiesko - Mi 18:43
» Untertitel in FCPX bei vorhandener Textdatei?
von R S K - Mi 18:34
» Deckenlicht mobil abschatten
von Frank Glencairn - Mi 17:31
» LUTs für Canon R6 Mark II
von TomStg - Mi 12:24
» RED versucht User nach Übernahme durch Nikon zu beruhigen
von dienstag_01 - Mi 11:52
» Entfesseltes Storytelling mit der Video-KI Sora?
von Frank Glencairn - Mi 5:54
» Slashcam 2001 - Das Internet vergisst nichts!
von macaw - Di 21:37
» Dehancer Pro - Filmsimulation auf höchstem Niveau
von Frank Glencairn - Di 18:54
» Wie Dune Teil 2 entstand - DoP Greig Fraser und Hans Zimmer im Interview
von iasi - Di 13:32
» 3 Body Problem - so verfilmt man heute Bücher
von stip - Di 8:30
» Neue Sora Version
von Frank Glencairn - Di 7:54
» IDEENFINDUNG: Wie man spannende Filme entwickelt! mit Vi-Dan Tran (Actiondesigner DUNE)
von berlin123 - Di 6:47
» Kafka Serie
von rabe131 - Mo 23:09