Infoseite // Asiatische ColorChecker Alternative für wenig Geld - EYEPHOTO

Newsmeldung von slashCAM:


ColorChecker können ja sehr hilfreich sein, wenn man auf exakte Farben in seinen Videos oder auf seinen Wiedergabe-Geräten angewiesen ist. Doch diese exakten Farbkarten l...



Hier geht es zur Newsmeldung auf den slashCAM Magazin-Seiten:
Asiatische ColorChecker Alternative für wenig Geld - EYEPHOTO



Antwort von cantsin:

Hab mal ein Testfoto von dem Eyephoto Color Checker direkt neben dem X-Rite Color Checker Passport gemacht:
http://data.pleintekst.nl/eyephoto-vs-xrite.dng
(Kamera: Sony A7s + Sony-Zeiss 55mm/1.8, Bildformat: Sony Raw/ARW konvertiert nach DNG mit dem Adobe DNG Converter.)

Anbei zwei Renderings des Testbilds aus Resolve, bei dem automatische Colorchecker-Farbabgleich (1.) auf den Xrite und (2.) auf den Eyephoto gemacht wurde.



Antwort von iasi:

erhebliche Unterschiede

für Resolve scheint das 20€-Kärtchen nicht zu taugen.



Antwort von CameraRick:

Nicht wenns genau sein muss, zum Angleichen aber sicherlich.

Bin ja fast gewillt so ein Ding mal zu bestellen und durchzumessen, Apparat dafür hab ich daheim :)



Antwort von Rudolf Max:

Weiss jemand die genauen RGB oder auch CMYK Werte der einzelnen Felder für so eine Karte...?

Könnte man dann allenfalls auch selber ausdrucken... mit einem guten Drucker natürlich...

Rudolf



Antwort von -paleface-:

Weiss jemand die genauen RGB oder auch CMYK Werte der einzelnen Felder für so eine Karte...?

Könnte man dann allenfalls auch selber ausdrucken... mit einem guten Drucker natürlich...

Rudolf Das wird nicht funktionieren.

Das ganze System mit den Color Charts funktioniert ja nur weil es genormt ist.

Man kann vermutlich auch das 20$ Ding nehmen WENN Resolve in seinem Tool darauf abgestimmt wäre.



Antwort von dosaris:

Weiss jemand die genauen RGB oder auch CMYK Werte der einzelnen Felder für so eine Karte...?f die Werte stehen auf der Rückseite.
Im Film bei 0:34.

Eine Referenzkarte mit einem Drucker undefinierter Farbcharakteristik
zu printen kann man wohl eher vergessen.

Die Karte gibt's auch bei ebay für den etwa 4fachen Preis.



Antwort von Rudolf Max:

Okay... Danke...



Antwort von mash_gh4:

Eine Referenzkarte mit einem Drucker undefinierter Farbcharakteristik
zu printen kann man wohl eher vergessen. nicht unbedingt, wenn du dir die wirklich interessanten ausführungen hier ansiehst:

https://www.ludd.ltu.se/~torger/dcamprof.html
http://www.ludd.ltu.se/~torger/photogra ... iling.html

mich überzeugt das hier vorgeschlagene produkt ehrlich gestanden nicht besonders. die abweichungen gegenüber den gebräuchlichen targets sind mit freiem auge erkennbar! :(

übrigens nutzen CC24 targets kein genormter standard, sondern nur völlig frei festgelegte hersteller-konvention, die von einigen nachgeahmt wurden. es gibt aber bspw. im resolve keine möglichkeiten, die entsprechenden werte an andere farbtafeln anzupassen.

ich persönlich finde die IT8.7 charts vom wolf faust für viele anwendungszwecke ohnehin weit sinnvoller (weil sie deutlich mehr und unterschiedlich gesättigte farben zeigen) und auch genauer. dabei sind die auch ausgesprochen günstig -- nur eben bspw. fürs resolve nicht zu gebrauchen.

http://www.targets.coloraid.de/






Antwort von klusterdegenerierung:

..puh, bei den Seiten bekommt man aber Augenkrebs! ;-)



Antwort von klusterdegenerierung:

Hab mal ein Testfoto von dem Eyephoto Color Checker direkt neben dem X-Rite Color Checker Passport gemacht:
http://data.pleintekst.nl/eyephoto-vs-xrite.dng
(Kamera: Sony A7s + Sony-Zeiss 55mm/1.8, Bildformat: Sony Raw/ARW konvertiert nach DNG mit dem Adobe DNG Converter.)

Anbei zwei Renderings des Testbilds aus Resolve, bei dem automatische Colorchecker-Farbabgleich (1.) auf den Xrite und (2.) auf den Eyephoto gemacht wurde. Sehe ich das richtig, das die Farbdarstellung die gleiche ist, nur die Sättigung etwas geringer ist? Das wäre ja kein großes Problem.
Wo hast Du das Ding bestellt und wie hast Du es in Resolve benutzt?
Erkennt Resolve es als Colochecker an?



Antwort von freezer:

Die IT8.7 Charts kannst Du für Video vergessen - das ist glänzendes Fotopapier. Spielt für seine eigentliche Funktion als Scanner-Target keine Rolle weil das Licht anders einfällt, aber bei Video klappt das selten.

Das teure an den Colorchecker Targets ist ja das diffuse Material, welches auf seitliches Licht kaum mit einer Veränderung der Wiedergabe reagiert. Und dann noch eine gleichbleibende Qualität und Farbstabilität über die Zeit.

Wer mehr Farben benötigt um eine höhere Genauigkeit zu erreichen, kann sich das Colorchecker Digital SG zulegen.

Spartipp: Kostet bei Amazon.de € 325,-, bei Amazon.fr € 225,-
Man kann mit dem gleichen Account überall bei Amazon bestellen.



Antwort von CameraRick:

Erkennt Resolve es als Colochecker an? Resolve hat ja im Endeffekt nur Masken von verschiedenen Checker-Typen, und erwartet eben einen gewissen Aufbau an Farben. Solang die Chart also die Farben so angeordnet hat wie ein klassisches Macbeth Chart, ist alles gut.
Wie akkurat das Ergebnis ist steht eben auf einem anderen Blatt - inwiefern das Ganze problematisch ist, wenn dem nicht so ist, aber auch.

Ich hab einen Colorchecker daheim, den X-Rite; man muss sich ja auch mal den Spaß machen so einen druchzumessen... :)



Antwort von mash_gh4:

Die IT8.7 Charts kannst Du für Video vergessen - das ist glänzendes Fotopapier. Spielt für seine eigentliche Funktion als Scanner-Target keine Rolle weil das Licht anders einfällt, aber bei Video klappt das selten. natürlich muss man die reflexe bei entsprechenden tests berücksichtigen -- aber in wahrheit auch noch wesentlich mehr -- speziell was das licht bzw. die tageszeit der aufnahme betrifft...

trotzdem wird genau dieses target von fast allen benutzt, die mit freier software (argyll cms etc.) arbeiten.

irgendwo hab ich einmal einen ziemlich guten test gefunden, in dem die wolf faust targets seriös mit verschiedenen anderen pigment- und fotopapierbasierenden color targets verglichen wurden. auch dort hat diese verhältnismäßig erschwingliche lösung überraschend gut abgeschnitten, was ja z.t. auch damit zu tun hat, dass jede charge vom wolf faust vor auslieferung exakt ausgemessen wird und entsprechende daten mitgeliefert werden, während ja bei den meisten anderen produkten nur fixe referenzwerte genutzt werden.

https://stephenstuff.wordpress.com/2011 ... profiling/

der hersteller empfiehlt allerdings ganz selbstverständlich, die farbtafeln nur dunkel und trocken zu lagern und nach wenigen jahren auszutauschen -- aber das ist auch bei sehr viel teureren targets (DSC Labs etc.) nicht viel anders.

wie gesagt, mit dem resolve kann man es leider nicht nutzten, weil das überhaupt keine it8.7 targets unterstützt, aber auch kein importieren von derart genau ausgemessenen referenzwerten erlaubt.

das was resolve in diesem zusammenhang rechnerisch macht, ist aber ohnehin ausgesproch primitiv im vergleich zu richtiger kameraprofilerstellung. letzteres ist mit den paar messfeldern der normalen CC24 charts auch fast nicht vernünftig zu bewerkstelligen.

in wahrheit hab ich natürlich beides hier -- also zumindest auch einen CC passport.
aber wie gesagt, für die anspruchsvolleren aufgaben ist letzterer einfach nicht zu gebrauchen.



Antwort von cantsin:

Sehe ich das richtig, das die Farbdarstellung die gleiche ist, nur die Sättigung etwas geringer ist? Nee, vergleich mal das Blau im zweiten Quadrat oben links.



Antwort von klusterdegenerierung:

Ups!! Boah, ist mir nicht aufgefallen, jetzt wo Du es sagst!
Das ist natürlich schon arg daneben! Ist die Frage was das in der Summe macht, oder ob man mal genau diesen Farbton filmt. ;-)



Antwort von freezer:

Sehe ich das richtig, das die Farbdarstellung die gleiche ist, nur die Sättigung etwas geringer ist? Nee, vergleich mal das Blau im zweiten Quadrat oben links. Nicht nur das Blau, sieh Dir mal den 15er Patch Rot an - wie willst Du da korrekte Rottöne bekommen?
trotzdem wird genau dieses target von fast allen benutzt, die mit freier software (argyll cms etc.) arbeiten. Tja, nur weil das fast alle benutzen die mit freier Software arbeiten, heißt das noch lange nicht, dass es sinnvoll ist ein Target außerhalb seines Einsatzgebietes zweckzuentfremden.

irgendwo hab ich einmal einen ziemlich guten test gefunden, in dem die wolf faust targets seriös mit verschiedenen anderen pigment- und fotopapierbasierenden color targets verglichen wurden. auch dort hat diese verhältnismäßig erschwingliche lösung überraschend gut abgeschnitten, was ja z.t. auch damit zu tun hat, dass jede charge vom wolf faust vor auslieferung exakt ausgemessen wird und entsprechende daten mitgeliefert werden, während ja bei den meisten anderen produkten nur fixe referenzwerte genutzt werden. Das Hauptproblem der Targets auf Fotopapier ist, dass sich sämtliche Farben ausschließlich aus den 3 Farbebenen des Papiers zusammensetzen. Diese sehen für das menschliche Auge korrekt aus, aber für Kamerasensoren, die anders auf die Spektren reagieren, passt das möglicherweise gar nicht. Wie gesagt, das IT8.7 wurde für Scannerkalibration entwickelt, welche CCDs nutzen, während die aktuellen Kameras alle mit CMOS arbeiten.
Dazu kommt noch, dass im Fotopapier optische Aufheller verwendet werden, welche auf die UV-Anteile reagieren und damit ins Blaue gehen. Deswegen sollte man seinen Weißabgleich ja auch nicht mit einem weißen Blatt Papier machen.

Die Colorchecker Farbfelder bestehen hingegen aus jeweils eigenen entsprechenden Pigmenten, deren reflektierte Spektren mehr der Realität entsprechen.
in wahrheit hab ich natürlich beides hier -- also zumindest auch einen CC passport.
aber wie gesagt, für die anspruchsvolleren aufgaben ist letzterer einfach nicht zu gebrauchen. Dafür gibt es ja den CC SG mit 140 Farbfeldern.



Antwort von CameraRick:

Ich hab gestern mal meinen Colorchecker durchgemessen.
Das ganze zu vergleichen ist etwas ätzend da man nirgendwo einheitliche Referenzfarbwerte findet, habe mich mal auf die von Wikipedia verlassen.

Und was soll man sagen, der von X-Rite liegt halt auch nicht wirklich da, wo er liegen sollte.
Also stellt sich die Frage: kann man mit dem "Original" überhaupt korrekte Farbtöne bekommen?






Antwort von Frank B.:

Ich sehe bei Aliexpress nicht die Möglichkeit mit Paypal zu zahlen. Geht das doch irgendwie? Mir würde diese Karte reichen, weil es mir im Grunde nur um die Angleichung mehrerer Kameras geht.



Antwort von freezer:

Ich hab gestern mal meinen Colorchecker durchgemessen.
Das ganze zu vergleichen ist etwas ätzend da man nirgendwo einheitliche Referenzfarbwerte findet, habe mich mal auf die von Wikipedia verlassen.

Und was soll man sagen, der von X-Rite liegt halt auch nicht wirklich da, wo er liegen sollte.
Also stellt sich die Frage: kann man mit dem "Original" überhaupt korrekte Farbtöne bekommen? http://xritephoto.com/ph_product_overvi ... ortID=5159

Und die kolorimetrischen Werte für den Colorchecker SG:
http://xritephoto.com/documents/apps/pu ... _l_a_b.txt

Und hier alle neuen Farbspezifikationen der CC Classic und SG ab November 2014:
http://xritephoto.com/ph_product_overvi ... 4&catid=28



Antwort von Starshine Pictures:

Gibt es denn für Premiere eigentlich auch so ein Plugin dass man den ColorChecker ähnlich wie in Resolve einlesen kann? Hab so ein Ding hier rum liegen aber nach dem Auspacken noch nie genutzt. Wenn es dieses Plugin nicht gibt kann ich von dem Color Checker Passport ja praktisch nur den Weissabgleich verwenden. Eine Farbkalibrierung ist ja dann nicht möglich. Oder gibt es da einen Roundtrip via Photoshop? Da ist das glaub integriert.


Grüsse, Stephan



Antwort von Sammy D:

Gibt es denn für Premiere eigentlich auch so ein Plugin dass man den ColorChecker ähnlich wie in Resolve einlesen kann? Hab so ein Ding hier rum liegen aber nach dem Auspacken noch nie genutzt. Wenn es dieses Plugin nicht gibt kann ich von dem Color Checker Passport ja praktisch nur den Weissabgleich verwenden. Eine Farbkalibrierung ist ja dann nicht möglich. Oder gibt es da einen Roundtrip via Photoshop? Da ist das glaub integriert.


Grüsse, Stephan Kenn mich mit Premiere nicht aus. Du kannst aber einen LUT in DaVinci erstellen, diesen exportieren und dann in den NLE werfen.
So mache ich das manchmal fuer Final Cut.



Antwort von freezer:

Du könntest eine Testaufnahme mit dem Colorchecker machen, diese in Resolve laden und die Kalibration anwenden. Das Ergebnis lässt sich als LUT exportieren und in Premiere per Lumetri anwenden.



Antwort von cantsin:

http://xritephoto.com/ph_product_overvi ... ortID=5159 Aha, da stehen ganz andere RGB-Werte als bei dem Eyephoto-Checker (siehe angehängte Foto unten). Hier die Werte des Xrite:

zum Bild

Also ist der Eyephoto nur eine Schein-Kopie des Xrite.



Antwort von CameraRick:

http://xritephoto.com/ph_product_overvi ... ortID=5159 Ah Danke Dir, dann schaue ich heute abend noch einmal nach. Hab die Daten leider auf dem NAS gespeichert, nicht in meiner Cloud :(

bzgl der Nutzung in Premiere:

Ein direktes Plugin ist mir nicht bekannt (anders als FCPX, da gibts doch dieses Color Finale?)
Ansonsten gibt es natürlich viele andere Wege das zu schaffen, einer umständlicher als der andere :)

Resolve zum LUT Exportieren wurde schon erwähnt, streng genommen kann man auch hier so etwas verwenden: https://generator.iwltbap.com/ etwas gleiches ginge auch in Fusion oder Nuke, wenn man das zur Hand hat.
Eine andere, über die Checker-Nutzung hinaus starke Software wäre der 3D LUT Creator, solang Du keine Russen kennst ist das aber ein teurer Spaß.

Da Resolve die meiste Kontrolle über die angewendete Konversion gibt würde ich damit arbeiten; also generell zum Graden, nicht nur um eine LUT zu machen :)



Antwort von freezer:

Ich habe eine Pro-Lizenz für den 3D LUT Creator.



Antwort von Starshine Pictures:

Ach dieses Resolve ... ich habs schon paar Mal ausprobiert und werde einfach nicht warm damit. :( Aber anscheinend kommt man tatsächlich nicht drum herum.






Antwort von mash_gh4:

Ein direktes Plugin ist mir nicht bekannt (anders als FCPX, da gibts doch dieses Color Finale?) für nuke gibts eine bekannte color-sciemce.org basierende lösung, die sich sehr leicht auch nach natron übertragen lassen würde:

http://www.marcomeyer-vfx.de/?p=88

aber wie gesagt, mit argyll kaan man wesentlich genauerer profile rechnen, die sich notfalls auch mit hilfe von OpenColorIO in die verschiedensten LUT varianten umrechnen lassen.

noch besser ist natürlich dcamprof, das ohnehin pratisch alles in den schatten stellt, was hier tlw. über die unzulänglichkeiten verhältnismäßig günstiger lösungen schwadroniert wurde/wird.

ich hab aber ohnehin nichts zu verkaufen -- kann höchstens meine ganz praktischen erfahrungen weitergeben! ;)



Antwort von CameraRick:

Stimmt, ganz vergessen, da gabs ja dieses Gizmo. Hatte sogar mal mit Natron-Devs drüber gesprochen, die waren nicht so interessiert, aber wenn jemand Numpy etc einbinden würde sagen die auch nicht nein.

Die Frage ist halt aber, wie man Argyll dazu bekommt, den Colorchecker im Material auszulesen. Die Tools zielen doch eigentlich alle auf die Nutzung von externen Instrumenten ab, und haben keine Bildanalyse?
Ich stecke leider nicht so sehr in Argyll wie ich das gern würde, mir fehlt das Verständnis (bzw die Willenkraft) für die Programmierarbeit



Antwort von mash_gh4:

Stimmt, ganz vergessen, da gabs ja dieses Gizmo. Hatte sogar mal mit Natron-Devs drüber gesprochen, die waren nicht so interessiert, aber wenn jemand Numpy etc einbinden würde sagen die auch nicht nein. ich glaube, das wäre verhältnismäßig einfach umzusetzten. man braucht dafür gar keinen aufwendigen bilddatenzugriff via numpy od.ä. ImageStatistics nodes reichen völlig aus, um die einzelnen messfelder einzulesen. auch die color-sciemce.org python libraries stellen keine großen anforderungen, die natron nicht längst bereitstellen würde.
Die Frage ist halt aber, wie man Argyll dazu bekommt, den Colorchecker im Material auszulesen. Die Tools zielen doch eigentlich alle auf die Nutzung von externen Instrumenten ab, und haben keine Bildanalyse? dafür nutzt man traditionel das tool 'scanin' in der argyll werkzeugsammlung. es kann verschiedene charts, deren feldanordnung in einem speziellen konfigurationsformat festgelegt werden, auslesen und die messwerte in verschiedenen tabellenformen numerisch exportieren. normalerweise wird dabei auch das entzerren, rotieren etc. übernommen. in den werten werden auch ein paar statistische kriterien mitbeachtet, um bspw. reflexe auszuklammen und das rauschen zu kompensieren. mit den diversen -d (debug) optionen, kann man auch ein kontrollbild ausgeben, auf dem man sehen kann, ob das testmuster mit hilfe der automatischen bilderkennung richtig zugeordnet wurde bzw. die messfelder korrekt platziert wurden...
Ich stecke leider nicht so sehr in Argyll wie ich das gern würde, mir fehlt das Verständnis (bzw die Willenkraft) für die Programmierarbeit ja -- da gebe ich dir gern recht! -- das ist wirklich eine ziemlich wilde und anspruchsvolle region der bildverarbeitung. auch ich bin da regelmäßig wieder völlig überfordert. ;)

dcamprof ist diesbezüglich noch viel irrer als als argyll selbst. :) nützliche teile von letzterem werden zwar auch dort genutzt, um bspw. die messdaten einzulesen, aber die tatsächliche aufbereitung und verarbeitung ist noch wesentlich avancierter! das ist wirklich beeindruckend! es gibt sehr wenige programme, aus deren dokumentation und begleitenden entwicklungsgeschichte man so viel über diffizilste probleme der farbkorrektur lernen kann, wie an diesem beispiel.

dagegen nehmen sich so lösungen, wie man sie im resolve findet bzw. wie es die color-sciemce.org farbanpassungsroutine umsetzt, vergleichsweise trivial aus.



Antwort von CameraRick:

Hab die Daten von X-Rite mit meiner Auslesung abgeglichen, die einzigen Werte die da halbwegs richtig liegen sind die Grauwerte, sind sogar recht genau. Die Farben liegen alle, manchmal mehr manchmal weniger, daneben. Wobei das dunkle Grün (#4) ziemlich punkt genau liegt :)

Wie dem auch sei, was ich sagen will: auch die Referenzcharts von X-Rite liegen nicht so richtig drauf, was mich auch nicht so wundert. Wer eine richtige Referenz braucht muss sich also eher anders behelfen, und wer nur angleichen will kann auch in China kaufen.

@mash
So unaufwändig geht es ja aber auch nicht, da Du ja viele Operationen parallel ausführen musst. Ich habe mich immer mal gefragt ob man so ein Ding wohl manuell bauen kann, aber ich komme nicht drauf wie ich zB 24 Grade-Nodes parallel zum Laufen kriegen würde

Und Danke für die Info mit dem Scain. Wenn man das irgendwie sinnvoll zum Laufen bekäme (manuelle Platzierung auf Bild und LUT-Export), das wäre doch was :) aber ich schaffe ja nicht mal eine halbwegs funktionale GUI vom spotread zu bauen, haha :)



Antwort von mash_gh4:

So unaufwändig geht es ja aber auch nicht, da Du ja viele Operationen parallel ausführen musst. Ich habe mich immer mal gefragt ob man so ein Ding wohl manuell bauen kann, aber ich komme nicht drauf wie ich zB 24 Grade-Nodes parallel zum Laufen kriegen würde. du brauchst keine 24 grade nodes prallel, sondern nur 24 ImageStatistics nodes, um die messwerte einzulesen. diese übergibst du dann als liste gemeinsam mit den entsprechenden sollwerten an folgende funktion in colour-science.org:

https://colour.readthedocs.io/en/latest ... tting.html

als resultat erhältst du eine 3x3 matrix, deren werte du in einer einzigen ColorMatrix node für die korrekturen deiner farben benutzten kannst. ;)

wenn man es noch ein bisserl komplizierter und schöner haben will, gibt's auch noch die variante, verschiedene farbfelder bzw. gruppen von ihnen unterschiedlich zu gewichten, damit manche abweichungen, denen man weniger beachtung schenken will, weniger einfluss auf das gesamtergebnis haben...

wenn du diesbezüglich irgendwelche probleme oder wünsche hast, helf ich dir jederzeit gerne weiter, so gut ich es handwerklich vermag!
Und Danke für die Info mit dem Scain. Wenn man das irgendwie sinnvoll zum Laufen bekäme (manuelle Platzierung auf Bild und LUT-Export), das wäre doch was :) ja -- prinzipiell kann man dem scanin relativ einfach mit komandozeilenangaben die koordinaten der eckpunkte des testmusters an hand eines overlays übergeben. es gab dafür vor langer zeit sogar einmal eine schönes gui-tool, das auf diesem weg brauchbare kamera profile generieren konnte, ohne die nerven der benutzer zu sehr zu strapazieren. :) ist mir aber aber schon länger nicht mehr untergekommen.



Antwort von CameraRick:

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. Die eine Liste ist ja die Referenzliste, richtig?
Wobei ich es trotzdem spannend fände, parallel-arbeitende Grades zu haben, das wäre doch spannend (wenn auch Schwierig)

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

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.
Gibt wohl .icc aus, aber das kann man ja zur Not mit DisplayCal zu einer .cube wandeln



Antwort von freezer:

Hab die Daten von X-Rite mit meiner Auslesung abgeglichen, die einzigen Werte die da halbwegs richtig liegen sind die Grauwerte, sind sogar recht genau. Die Farben liegen alle, manchmal mehr manchmal weniger, daneben. Wobei das dunkle Grün (#4) ziemlich punkt genau liegt :) Ich glaube, dass das noch die Daten für die älteren Targets sind. Ist Dein Colorchecker jünger oder älter als November 2014? Ab da habe sich die Farbspezifikationen etwas geändert.



Antwort von freezer:

Beispiel:

Die 24 Felder der Fläche E2:E5 bis J2:J5 des Colorchecker SG entsprechen den Feldern des Colorchecker Passports.

Die neuen CIELAB Werte des CC SG sind:
http://xritephoto.com/documents/apps/pu ... _l_a_b.txt

Umrechnung von CIELAB auf RGB:
http://davengrace.com/cgi-bin/cspace.pl

Alte vs. neue RGB-Werte:
1. dark Skin ... 115/82/68 vs. 111/63/41
2. light skin ... 194/150/130 vs. 199/140/120
4. foliage ... 87/108/67 vs. 78/96/37
13. blue ... 56/61/150 vs. 0/42/135
14. green ... 70/148/73 vs. 55/141/52
15. red ... 175/54/60 vs. 179/0/27
16. yellow ... 231 / 199 / 31 vs. 245/194/0
17. magenta ... 187/46/149 vs. 188/68/142
18. cyan ... 8/133/161 vs. 0/130/164



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






Antwort von freezer:

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.



Antwort 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



Antwort von mash_gh4:

leider dürftest du mit den meisten einwänden und bedenken recht haben. :(
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?
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.
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.
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.
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. ;)

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



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



Antwort von mash_gh4:

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



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



Antwort von CameraRick:

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



Antwort von freezer:

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



Antwort 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%)?






Antwort von mash_gh4:

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:


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



Antwort von freezer:

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.



Antwort 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 :(



Antwort von mash_gh4:

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



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



Antwort 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



Antwort von mash_gh4:

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



Antwort von nachtaktiv:

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

https://www.ebay.de/itm/24Patch-Farben- ... OSwldRaPJJ~



Antwort von cantsin:

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






Antwort von nachtaktiv:

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

https://www.ebay.de/itm/X-Rite-Colorche ... 2ab4b16b99



Antwort von Sammy D:

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



Antwort 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?