Mit anderer Software funktioniert ja das Farbmanagment unter Windows auch. An den GPUs kanns daher nicht liegen.carstenkurz hat geschrieben: ↑Di 26 Jan, 2021 16:58 Naja, aber, ehrlich gesagt macht es die Verwirrung im Resultat nur noch größer...
Das Problem ist einfach, dass es in der Praxis zu viele Einflüsse gibt und es auch fast unmöglich ist, für jeden dieser Einflüsse eine saubere Dokumentation zu pflegen. Auch weil die Softwareschnittstellen sich ständig ändern, in wenigen IT Bereichen gibt es so eine schnelle Entwicklung wie bei den GPUs.
Man kann bestenfalls exemplarisch Referenzsysteme nach bestimmten Schwerpunkten definieren.
ich geb dir ja recht, dass die ganze sache fürchterlich nervt!carstenkurz hat geschrieben: ↑Di 26 Jan, 2021 16:58 Das Problem ist einfach, dass es in der Praxis zu viele Einflüsse gibt und es auch fast unmöglich ist, für jeden dieser Einflüsse eine saubere Dokumentation zu pflegen. Auch weil die Softwareschnittstellen sich ständig ändern, in wenigen IT Bereichen gibt es so eine schnelle Entwicklung wie bei den GPUs.
Historisch ist es natürlich genau umgekehrt, die Anbieter von Schnitt- und Color Correction Systemen MUSSTEN eigene Hardware anbieten. Da ging es um Performance aber auch, dass z.B. FBAS aus einer Consumergrafikkarte nun mal nicht das Referenzsignal für Farbkorrektur ist.mash_gh4 hat geschrieben: ↑Di 26 Jan, 2021 17:40ich geb dir ja recht, dass die ganze sache fürchterlich nervt!carstenkurz hat geschrieben: ↑Di 26 Jan, 2021 16:58 Das Problem ist einfach, dass es in der Praxis zu viele Einflüsse gibt und es auch fast unmöglich ist, für jeden dieser Einflüsse eine saubere Dokumentation zu pflegen. Auch weil die Softwareschnittstellen sich ständig ändern, in wenigen IT Bereichen gibt es so eine schnelle Entwicklung wie bei den GPUs.
trotzdem -- man kann sich in dieser frage einfach nicht damit begnügen, irgendwelche zusatzhardware, die in der praxis fast unvermeidlich nor noch neue weitere treiberprobleme und inkompatibilitäten mit sich bringen, als lösung anzupreisen.
das wäre fast so, als würde sich darauf hinausreden, das eben manche datenträger -- disketten, DVDs oder USB-speicher-sticks --, wenn es sich darauf wertvolles befindet, auch nur mit hardware eines ganz bestimmten prestigeträchtigen herstellers gelesen/kopiert/übertragen werden sollte, damit der inhalt der gespeicherten dokumente unverändert bleibt.
das ist jetzt nicht ganz so weit hergeholt, da in heutigen digitalen videoverbindungsprotokollem -- völlig egal, ob es um DVI-anschluss, HDI, SDI od. Display-Port handelt -- auch nur mehr derartige klar festgelegte zahlenwerte übergeben werden, von denen man ganz ähnliches wie bei einem übertragenen od. abgespeicherten textfile erwartet -- also: unveränderte buchstaben. für irgendwelchen aberglauben oder auswüchse, wie man sie etwa von analog-HiFi-esoterikern her kennt, bleibt da [zum glück!] denkbar wenig platz zwischen den tatsächlich benutzten bits und bytes über.
ja -- historisch und von den ganz spezifischen anforderungen im studio-umfeld her versteh ich's ohnehin. ich würde ja auch sicher niemandem raten, für längere kabelstrecken auf HDMI, DP od. USB-C aus dem consumerumfeld zu setzen. trotzdem muss man halt genauso klar sehen, wo manchens zeug, das nur mehr den charme einfachster computergrafikkarten aus den 90er jahren weiter am leben erhält, absolut keinen sinn macht bzw. besser durch vernünftig funktionierende software ersetzt wird.dienstag_01 hat geschrieben: ↑Di 26 Jan, 2021 17:47 Historisch ist es natürlich genau umgekehrt, die Anbieter von Schnitt- und Color Correction Systemen MUSSTEN eigene Hardware anbieten. Da ging es um Performance aber auch, dass z.B. FBAS aus einer Consumergrafikkarte nun mal nicht das Referenzsignal für Farbkorrektur ist.
Nicht, wenn man wie pillepalle alles, was Du oben beschreibst, im P3- statt im sRGB-/Rec709-Farbraum machen will.rdcl hat geschrieben: ↑Di 26 Jan, 2021 20:10 Irgendwie stehe ich auf dem Schlauch. Ich verstehe das Problem nicht.
- Wer einen externen Preview-Monitor hat, der LUTs intern speichern kann, kalibriert und profiliert und speichert direkt im Monitor.
- Wer einen externen Preview-Monitor hat, der keine LUTs intern speichern kann, kalibriert und profiliert und wendet das Calibration-Lut in Resolve auf den Preview-Monitor an.
- Wer keinen externen Preview-Monitor hat kalibriert und profiliert und wendet das Calibration-Lut in Resolve auf den GUI-Viewer an.
- Wer es ganz genau haben will kalibriert und profiliert sowohl GUI-Monitor als auch Preview-Monitor und wendet beide LUTs entsprechend in Resolve an.
Damit sollten doch alle Möglichkeiten offen stehen, egal ob über Grafikkarte oder I/O-Karte.
Preview Lut funktioniert nicht im Clean Video Feed. Wahrscheinlich ist mit Preview der über eine Monitoring Card angebundene Monitor gemeint. Oder?rdcl hat geschrieben: ↑Di 26 Jan, 2021 20:10 Irgendwie stehe ich auf dem Schlauch. Ich verstehe das Problem nicht.
- Wer einen externen Preview-Monitor hat, der LUTs intern speichern kann, kalibriert und profiliert und speichert direkt im Monitor.
- Wer einen externen Preview-Monitor hat, der keine LUTs intern speichern kann, kalibriert und profiliert und wendet das Calibration-Lut in Resolve auf den Preview-Monitor an.
- Wer keinen externen Preview-Monitor hat kalibriert und profiliert und wendet das Calibration-Lut in Resolve auf den GUI-Viewer an.
- Wer es ganz genau haben will kalibriert und profiliert sowohl GUI-Monitor als auch Preview-Monitor und wendet beide LUTs entsprechend in Resolve an.
Damit sollten doch alle Möglichkeiten offen stehen, egal ob über Grafikkarte oder I/O-Karte.
Wie machen die Leute, die damit Probleme haben, das denn dann bei z.B. Premiere oder AE, wo man gar keine Displayluts anwenden kann?
Ah, verstehe. Ok, das ist ein Problem wenn man keine I/O-Karte nutzt. Aber funktioniert da dann nicht das GUI-Viewer LUT?dienstag_01 hat geschrieben: ↑Di 26 Jan, 2021 20:43Preview Lut funktioniert nicht im Clean Video Feed. Wahrscheinlich ist mit Preview der über eine Monitoring Card angebundene Monitor gemeint. Oder?rdcl hat geschrieben: ↑Di 26 Jan, 2021 20:10 Irgendwie stehe ich auf dem Schlauch. Ich verstehe das Problem nicht.
- Wer einen externen Preview-Monitor hat, der LUTs intern speichern kann, kalibriert und profiliert und speichert direkt im Monitor.
- Wer einen externen Preview-Monitor hat, der keine LUTs intern speichern kann, kalibriert und profiliert und wendet das Calibration-Lut in Resolve auf den Preview-Monitor an.
- Wer keinen externen Preview-Monitor hat kalibriert und profiliert und wendet das Calibration-Lut in Resolve auf den GUI-Viewer an.
- Wer es ganz genau haben will kalibriert und profiliert sowohl GUI-Monitor als auch Preview-Monitor und wendet beide LUTs entsprechend in Resolve an.
Damit sollten doch alle Möglichkeiten offen stehen, egal ob über Grafikkarte oder I/O-Karte.
Wie machen die Leute, die damit Probleme haben, das denn dann bei z.B. Premiere oder AE, wo man gar keine Displayluts anwenden kann?
genau! -- für das hier diskutierte sind eigentlich nur die vier felder unten bzw. eher nur zwei davon relevant. unguter weise geht das im resolve wirklich nur mit LUTs, während es in den meisten programmen eher auch mit den fixen umrechnugsvorgaben für die div. gebräuchlichen standards und evtl. zusätzlicher korrektur-LUTs abgewickelt wird, was das ganze deutlich flexibler und auch genauer macht.
Genau. Die Preview Lut funktioniert nicht, die für den Viewer schon. Der Clean Video Feed scheint also nochmal was ganz anderes zu sein, was gar keine Konfigurationsmöglichkeiten hat.rdcl hat geschrieben: ↑Di 26 Jan, 2021 20:52Ah, verstehe. Ok, das ist ein Problem wenn man keine I/O-Karte nutzt. Aber funktioniert da dann nicht das GUI-Viewer LUT?dienstag_01 hat geschrieben: ↑Di 26 Jan, 2021 20:43
Preview Lut funktioniert nicht im Clean Video Feed. Wahrscheinlich ist mit Preview der über eine Monitoring Card angebundene Monitor gemeint. Oder?
Hier ist ein Bild dazu:
https://www.richardlackey.com/wp-conten ... -image.jpg
Für den externen Monitor via Decklink wäre es das "Video Monitor LUT", und für den GUI-Viewer über die Grafikkarte das "Color Viewer LUT". Zumindest in der Theorie.
Aber mit fixen Umrechnungsvorgaben würde doch die Profilierung des Monitors nicht mit berücksichtigt werden. Welche meisten Programme machen das denn besser? Premiere, AE oder Avid bieten z.B. überhaupt keine Display-Luts an.mash_gh4 hat geschrieben: ↑Di 26 Jan, 2021 21:03genau! -- für das hier diskutierte sind eigentlich nur die vier felder unten bzw. eher nur zwei davon relevant. unguter weise geht das im resolve wirklich nur mit LUTs, während es in den meisten programmen eher auch mit den fixen umrechnugsvorgaben für die div. gebräuchlichen standards und evtl. zusätzlicher korrektur-LUTs abgewickelt wird, was das ganze deutlich flexibler und auch genauer macht.
Das stimmt so nicht, Avid schon. Bei Fullscreen Playback kann ich wählen, ob sRGB oder 709 und ich weiß nicht, welche noch.rdcl hat geschrieben: ↑Di 26 Jan, 2021 21:07Aber mit fixen Umrechnungsvorgaben würde doch die Profilierung des Monitors nicht mit berücksichtigt werden. Welche meisten Programme machen das denn besser? Premiere, AE oder Avid bieten z.B. überhaupt keine Display-Luts an.mash_gh4 hat geschrieben: ↑Di 26 Jan, 2021 21:03
genau! -- für das hier diskutierte sind eigentlich nur die vier felder unten bzw. eher nur zwei davon relevant. unguter weise geht das im resolve wirklich nur mit LUTs, während es in den meisten programmen eher auch mit den fixen umrechnugsvorgaben für die div. gebräuchlichen standards und evtl. zusätzlicher korrektur-LUTs abgewickelt wird, was das ganze deutlich flexibler und auch genauer macht.
schau dir einmal die seite 1379f im resolve 16 handbuch an.
Aber das hat nichts mit einer akkuraten Ausgabe zu tun. Das ist eine Farbraum-Simulation, wo der Monitor selbst auch garnicht berücksichtigt wird.dienstag_01 hat geschrieben: ↑Di 26 Jan, 2021 21:28Das stimmt so nicht, Avid schon. Bei Fullscreen Playback kann ich wählen, ob sRGB oder 709 und ich weiß nicht, welche noch.
Kann sein, aber wie gesagt, in Resolve geht das genausowenig für die Vollbildvorschau.rdcl hat geschrieben: ↑Di 26 Jan, 2021 21:38Aber das hat nichts mit einer akkuraten Ausgabe zu tun. Das ist eine Farbraum-Simulation, wo der Monitor selbst auch garnicht berücksichtigt wird.dienstag_01 hat geschrieben: ↑Di 26 Jan, 2021 21:28
Das stimmt so nicht, Avid schon. Bei Fullscreen Playback kann ich wählen, ob sRGB oder 709 und ich weiß nicht, welche noch.
naja -- vielleicht kann man ja tatsächlich Color Management bis zu einem gewissen grad auch als Farbraum-Simulation od. eben "...-Transformation" verstehen. ;)
es gibt workarounds dafür:dienstag_01 hat geschrieben: ↑Di 26 Jan, 2021 21:04 Genau. Die Preview Lut funktioniert nicht, die für den Viewer schon. Der Clean Video Feed scheint also nochmal was ganz anderes zu sein, was gar keine Konfigurationsmöglichkeiten hat.
Ja, aber YT erwartet 709 (wenn wir HDR jetzt mal außen vor lassen - das ist noch ne ganz andere Diskussion), um das dann wahlweise auf einem sRGB(Computer), TV oder Oled(Handy) Panel abzuspielen, bei letzerem dreht der Helligkeitssensor, und irgendwelche Blaufilter an der Farbe, bei TVs irgendwelche Verschlimmbesserungsprofile, und was der durchschnittliche Homeoffice Computer ausspuckt möchte ich gar nicht wissen. Verschiedene Player (managed und unmanaged), Betriebssysteme, und Browser/Apps tun ein Übriges, um das Bild jedesmal anders aussehen zu lassen.
Im Gegenteil - halbwegs genau ist es nur, wenn du den Bildschirm vorher kalibriert hast, und die dabei entstandene LUT drauf anwendest.mash_gh4 hat geschrieben: ↑Di 26 Jan, 2021 21:03
für das hier diskutierte sind eigentlich nur die vier felder unten bzw. eher nur zwei davon relevant. unguter weise geht das im resolve wirklich nur mit LUTs, während es in den meisten programmen eher auch mit den fixen umrechnugsvorgaben für die div. gebräuchlichen standards und evtl. zusätzlicher korrektur-LUTs abgewickelt wird, was das ganze deutlich flexibler und auch genauer macht.
Meine Rede. Ich weiß auch noch immer nicht welche "meisten" Programme dass jetzt großartig besser machen.Frank Glencairn hat geschrieben: ↑Mi 27 Jan, 2021 05:53Im Gegenteil - halbwegs genau ist es nur, wenn du den Bildschirm vorher kalibriert hast, und die dabei entstandene LUT drauf anwendest.mash_gh4 hat geschrieben: ↑Di 26 Jan, 2021 21:03
für das hier diskutierte sind eigentlich nur die vier felder unten bzw. eher nur zwei davon relevant. unguter weise geht das im resolve wirklich nur mit LUTs, während es in den meisten programmen eher auch mit den fixen umrechnugsvorgaben für die div. gebräuchlichen standards und evtl. zusätzlicher korrektur-LUTs abgewickelt wird, was das ganze deutlich flexibler und auch genauer macht.
Irgendeine generische Umrechnug, starr auf einen nicht referenzierten Monitor anzuwenden ist das Gegenteil von flexibel.
Die einzige Frage ist eher, hab ich die LUT im Monitor (wenn er das überhaupt kann), und wie gut ist da die Umsetzung, sprich wir da aus dem Cube vielleicht nur ne 2D LUT draus, ist die Interpolation da Tetrahedal oder Trilinear etc. oder lass ich das lieber mein CC Programm machen, oder vielleicht sogar ne externe LUT Box?
Wer Zeit zum lesen hat, dem kann ich das hier empfehlen, ich denke da werden viele Fragen beantwortet:
https://nick-shaw.github.io/cinematicco ... enges.html
Und ich weiß garnicht worüber hier eigentlich geredet wird!rdcl hat geschrieben: ↑Mi 27 Jan, 2021 07:25Meine Rede. Ich weiß auch noch immer nicht welche "meisten" Programme dass jetzt großartig besser machen.Frank Glencairn hat geschrieben: ↑Mi 27 Jan, 2021 05:53
Im Gegenteil - halbwegs genau ist es nur, wenn du den Bildschirm vorher kalibriert hast, und die dabei entstandene LUT drauf anwendest.
Irgendeine generische Umrechnug, starr auf einen nicht referenzierten Monitor anzuwenden ist das Gegenteil von flexibel.
Die einzige Frage ist eher, hab ich die LUT im Monitor (wenn er das überhaupt kann), und wie gut ist da die Umsetzung, sprich wir da aus dem Cube vielleicht nur ne 2D LUT draus, ist die Interpolation da Tetrahedal oder Trilinear etc. oder lass ich das lieber mein CC Programm machen, oder vielleicht sogar ne externe LUT Box?
Wer Zeit zum lesen hat, dem kann ich das hier empfehlen, ich denke da werden viele Fragen beantwortet:
https://nick-shaw.github.io/cinematicco ... enges.html
Interessant.mash_gh4 hat geschrieben: ↑Mi 27 Jan, 2021 03:20es gibt workarounds dafür:dienstag_01 hat geschrieben: ↑Di 26 Jan, 2021 21:04 Genau. Die Preview Lut funktioniert nicht, die für den Viewer schon. Der Clean Video Feed scheint also nochmal was ganz anderes zu sein, was gar keine Konfigurationsmöglichkeiten hat.
https://www.steakunderwater.com/wesuckl ... php?t=3689
...allerdings sind die fast genauso krank wie eine firmenpolitik, die solch idiotischen umwege erzwingt. :(
benutzer der freien version sind aber ohnehin davon verschont, weil die ja bekanntlich noch immer keine vernünftige vollbildausgabe ohne zusätzliche BMD-hardware nutzen dürfen.
hab ich irgendwo behauptet, dass eine solche kalibrierung der schirme nicht nötig wäre?!Frank Glencairn hat geschrieben: ↑Mi 27 Jan, 2021 05:53Im Gegenteil - halbwegs genau ist es nur, wenn du den Bildschirm vorher kalibriert hast, und die dabei entstandene LUT drauf anwendest.mash... hat geschrieben: für das hier diskutierte sind eigentlich nur die vier felder unten bzw. eher nur zwei davon relevant. unguter weise geht das im resolve wirklich nur mit LUTs, während es in den meisten programmen eher auch mit den fixen umrechnugsvorgaben für die div. gebräuchlichen standards und evtl. zusätzlicher korrektur-LUTs abgewickelt wird, was das ganze deutlich flexibler und auch genauer macht.
im wörtlichen sinne ist es es natürlich "flexibler", wenn man ganz ohne solche standards und orientierungen auskommt, "praktikabel" ist es dagegen weit weniger.Frank Glencairn hat geschrieben: ↑Mi 27 Jan, 2021 05:53 Irgendeine generische Umrechnug, starr auf einen nicht referenzierten Monitor anzuwenden ist das Gegenteil von flexibel.
ja -- das problem mit unzureichendem rechenvermögen älterer bildschirme oder erschwinglicheren angeboten, die zwar von den technischen spezifikation her hw-kalibrierung anbieten, sie aber so fragwürdig umsetzten, dass man davon besser keinen gebrauch macht, ist leider hinlänglich bekannt. umgekehrt gibt's natürlich auch computerseitig jede menge lösungsansäte, die völlig indiskutabel sind bzw. im umfeld ernsthafterer anforderungen besser vermieden werden.Frank Glencairn hat geschrieben: ↑Mi 27 Jan, 2021 05:53 Die einzige Frage ist eher, hab ich die LUT im Monitor (wenn er das überhaupt kann), und wie gut ist da die Umsetzung, sprich wir da aus dem Cube vielleicht nur ne 2D LUT draus, ist die Interpolation da Tetrahedal oder Trilinear etc. oder lass ich das lieber mein CC Programm machen, oder vielleicht sogar ne externe LUT Box?
ich muss zugeben, dass ich ohne weitere angaben nicht klar erkennen kann, was ich diesem link nun genau entnehmen soll? -- vielleicht kannst mir da noch einen hinweis geben? -- ich schätze aber natürlich den konkreten autor und seine fachkenntnis auch ungemein!Frank Glencairn hat geschrieben: ↑Mi 27 Jan, 2021 05:53 Wer Zeit zum lesen hat, dem kann ich das hier empfehlen, ich denke da werden viele Fragen beantwortet:
https://nick-shaw.github.io/cinematicco ... enges.html
Das kommt ganz darauf an, ob sie auf die gleichen Farbräume kalibriert wurden. oder nicht. Wenn Du alle drei mit gleichem Gamma, Weißpunkt und gleicher Helligkeit kalibriert hast, dann schon. Ansonsten eben nicht.klusterdegenerierung hat geschrieben: ↑Mi 27 Jan, 2021 09:00 In diesem Zusammenhang stelle ich mal eine banal klingende aber ernst zunehmende Frage, dessen Inhalt und Kosequenz diese ganze Diskussion eigentlich schon obsolet macht, solange man nicht wie ein Profi Farben via Pipette und RGB Parade interpretiert.
Wenn meine Monitore per Messwerkzeug kalibriert werden, zeigen dann meine 3 unterschiedlichen Monitore alle das gleiche Grau?
ja! -- sollten sieklusterdegenerierung hat geschrieben: ↑Mi 27 Jan, 2021 09:00 Wenn meine Monitore per Messwerkzeug kalibriert werden, zeigen dann meine 3 unterschiedlichen Monitore alle das gleiche Grau?
Mit einer Kalibrierung eher nicht. Mit einer Kalibrierung & Profilierung schon eher. Hängt aber davon ab, ob sich die korrekte Profilierung, je nach Software, auf alle Monitore korrekt anwenden lässt. Darum dreht sich die ganze Diskussion doch.klusterdegenerierung hat geschrieben: ↑Mi 27 Jan, 2021 09:00 In diesem Zusammenhang stelle ich mal eine banal klingende aber ernst zunehmende Frage, dessen Inhalt und Kosequenz diese ganze Diskussion eigentlich schon obsolet macht, solange man nicht wie ein Profi Farben via Pipette und RGB Parade interpretiert.
Wenn meine Monitore per Messwerkzeug kalibriert werden, zeigen dann meine 3 unterschiedlichen Monitore alle das gleiche Grau?
Aber ein spezifisches Profil für den Monitor per Software ist um längen besser als ein generisches Farbraum-Profil.pillepalle hat geschrieben: ↑Mi 27 Jan, 2021 11:38 Man kann auch unterschiedlich erstellte Profile verschiedenen Monitoren zuweisen. Das Profil dient dazu eigene Settings zu speichern und nicht die vom Betriebssystem. Das weist man dem Monitor in der Regel selber zu. Die Kalibrierung ist bei Hardwarekalibrierbaren Monitoren dann im Monitor selber gespeichert. Bei einer Software-Kalibrierung wird die Kalibrierung im Profil gespeichert und die Grafikkarte muss die Werte quasi dahin verbiegen. Deshalb ist das Ergebnis einer Software Kalibrierung meist auch nicht so gut.
VG
Was meinst du mit generischem Farbraumprofil?rdcl hat geschrieben: ↑Mi 27 Jan, 2021 12:07Aber ein spezifisches Profil für den Monitor per Software ist um längen besser als ein generisches Farbraum-Profil.pillepalle hat geschrieben: ↑Mi 27 Jan, 2021 11:38 Man kann auch unterschiedlich erstellte Profile verschiedenen Monitoren zuweisen. Das Profil dient dazu eigene Settings zu speichern und nicht die vom Betriebssystem. Das weist man dem Monitor in der Regel selber zu. Die Kalibrierung ist bei Hardwarekalibrierbaren Monitoren dann im Monitor selber gespeichert. Bei einer Software-Kalibrierung wird die Kalibrierung im Profil gespeichert und die Grafikkarte muss die Werte quasi dahin verbiegen. Deshalb ist das Ergebnis einer Software Kalibrierung meist auch nicht so gut.
VG
Ich hatte bei meinem Monitor bei allen Werten ein Delta < 1. Müsste also zum größten Teil passen könnte man meinen. Aber gerade die kritische Rot- und Cyanwerte sind mit dem Profilierungs-Lut in Resolve nochmal unterschiedlich. Nicht extrem, aber gerade bei Hauttönen eben schon wichtig. Würde ich ohne die Profilierung für den Monitor graden, würden alle Hauttöne anders rauskommen als ich es eigentlich möchte, weil ich keine akkurate Vorschau hätte. Eine Kalibrierung ohne Profilierung reicht da einfach nicht, und ein Farbraumprofil ohne spezifische Korrekturen für den verwendeten Monitor auch nicht.
Wenn ich statt dem LUT für den Monitor, dass durch die Profilierung erstellt wurde, einfach nur ein "Standard-Rec709" oder einen anderen Farbraum als Output Color Space angeben würde. Dann würde die Korrektur für den Monitor fehlen.dienstag_01 hat geschrieben: ↑Mi 27 Jan, 2021 12:11Was meinst du mit generischem Farbraumprofil?rdcl hat geschrieben: ↑Mi 27 Jan, 2021 12:07
Aber ein spezifisches Profil für den Monitor per Software ist um längen besser als ein generisches Farbraum-Profil.
Ich hatte bei meinem Monitor bei allen Werten ein Delta < 1. Müsste also zum größten Teil passen könnte man meinen. Aber gerade die kritische Rot- und Cyanwerte sind mit dem Profilierungs-Lut in Resolve nochmal unterschiedlich. Nicht extrem, aber gerade bei Hauttönen eben schon wichtig. Würde ich ohne die Profilierung für den Monitor graden, würden alle Hauttöne anders rauskommen als ich es eigentlich möchte, weil ich keine akkurate Vorschau hätte. Eine Kalibrierung ohne Profilierung reicht da einfach nicht, und ein Farbraumprofil ohne spezifische Korrekturen für den verwendeten Monitor auch nicht.