Wenn ich einen Film aus Premiere exportiere, sehen die Farben in Quicktime und auf YouTube anders aus wie in Premiere.
Der VLC Player stellt es eher so dar wie in Premiere.
Um es besser erklären zu können, habe ich in jedem Programm das gleiche Bild und dann ein Bildschirmfotos gemacht.
Was habe ich in Premiere falsch eingestellt, bzw. was muss ich einstellen, damit der Film am Schluß auf YouTube genau so aussieht, wie ich ihn in Premiere gemacht habe.
Danke
Roland
MacBook Pro M1 Max
MacOS 12.1.
Premiere Version 22.1.1
Gelb_Bildschirmfoto.jpg
Gelb_Teststreifen.jpg
Farbblaken.jpg
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Das liegt an einem Fehler/Fehlinterpretation in der Dynamic Range.
Ich kenne mich mit Mac nicht aus, aber vielleicht gibt es eine Möglichkeit, ohne Quicktime zu exportieren.
Also, dort, beim Export, würde ich verschiedenen Codecs testen.
dienstag_01 hat geschrieben: ↑Mi 15 Dez, 2021 21:32
Das liegt an einem Fehler/Fehlinterpretation in der Dynamic Range.
Ich kenne mich mit Mac nicht aus, aber vielleicht gibt es eine Möglichkeit, ohne Quicktime zu exportieren.
Also, dort, beim Export, würde ich verschiedenen Codecs testen.
Habe das gleiche Problem wenn ich als mp4 (h.264) exportiere.
mash_gh4 hat geschrieben: ↑Mi 15 Dez, 2021 21:34
kannst für die variante "youtube" evtl. auch berücksichtigen, welcher browser verwendet wird bzw. wie es in den verschiedenen browsern aussieht?
ich würde vermuten, dass safari sich ähnliche verhalten wird wie quicktime, während vermutlich chome und firefox andere farben zeigen werden. ;)
Das gleiche Problem mit Firefox.
cantsin hat geschrieben: ↑Do 16 Dez, 2021 00:40
Toll, dass es den Quicktime-Gamma-Shift immer noch gibt... Kann jemand mal Quicktime den schon lange verdienten Todesstoß versetzen?
Warum macht sich das Quicktime-Gamma-Shift auch auf YouTube bemerkbar?
Das Problem besteht darin, daß Apple (ColorSync) REC709 immer noch mit einem Gamma von 1.96 darstellt, statt korrekt mit 2.4.
Das gilt auch für QuickTime Player, QuickView, Preview, Safari, Chrome, etc. und ja - auch Firefox und VLC, weil es in diesem Fall nicht nur ein Tag Problem ist.
Dazu kommt noch die bizarre Kombination aus Apple’s selbstgebasteltem P3 mit einem Whitepoint von D65 und einer sRGB Gamma Transfer, statt 2.6 von DCI-P3. Aber das ist nochmal ein ganz anderes Rabbit-Hole.
Die Gute Nachricht: es betrifft nur Leute mit Apple, auf allen anderen Geräten sieht dein Material aus wie in Premiere.
Ich erinnere mich noch an Zeiten als wir mit 1.8 bzw. 2.2 arbeiten mußten - Apple hat bis 2009 gebraucht das zu ändern.
Erwarte also nicht, daß Apple das vor 2030 fixt.
In a nut shell: Dein File ist okay für die Mehrheit der User, dein Rechner stellt es nur falsch da.
Lösung: Für CC braucht man einen Closed Loop Vorschaumonitor, in den das Apple OS nicht reinpfuschen kann.
Frank Glencairn hat geschrieben: ↑Do 16 Dez, 2021 07:56
Das Problem besteht darin, daß Apple (ColorSync) REC709 immer noch mit einem Gamma von 1.96 darstellt, statt korrekt mit 2.4.
Das gilt auch für QuickTime Player, QuickView, Preview, Safari, Chrome, etc. und ja - auch Firefox und VLC, weil es in diesem Fall nicht nur ein Tag Problem ist.
Das betrifft nur Leute mit Apple Geräten, auf allen anderen sieht dein Material aus wie in Premiere.
Ich erinnere mich noch an Zeiten als wir mit 1.8 bzw. 2.2 arbeiten mußten - Apple hat bis 2009 gebraucht das zu ändern.
Erwarte also nicht, daß Apple das vor 2030 fixt.
In a nut shell: Dein File ist okay für die Mehrheit der User, dein Rechner stellt es nur falsch da.
Danke für die Aufklärung!
VLC zeigt es so an wie Premiere - also richtig?
Soll ich in Premiere unter "Voreinstellungen" > "Allgemein" das Häkchen bei "Anzeigeart-Managment" setzen oder nicht?
Wenn ein Häkchen gesetzt ist, wird es in Premiere ein bisschen blasser und sieht nicht mehr so aus wie in VLC.
Premiere_Voreinstelllung.jpg
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
es liegt daran, dass kaum jemand ausser apple the colorsync (eingeführt 2012) beherrscht. speziell adobe und avid machen da nicht mit. resolve kann 709-A, FCP sowieso. VLC ignoriert, so wie premiere, alle tags und zeigt immer das rohsignal, also unmgeht jegliches color management (was nicht passieren soll, denn dinge wie range oder gamma sollten je nach nutzen umschaltbar sein. du musst eben solche LUTs verwenden um die anpassung ins bild einzubacken, oder du fährst dein apple display im sRGB modus. seit 2012 gibt es durch den colorsync auch fest definierte profile, du kannst auch die neuen (besser denn je) displays umschalten auf rec709 legal range, rec2020, dci p3 oder eben auch sRGB. letzteres ist nur für computer und web (aber 'safe"). wenn du ein externes display hast, dann kalibrierst du das auf den gewünschen raum (in der regel rec709) oder nutzt das entsprechende preset am monitor. es ist ein langes thema, das immer wieder kommt und immer wieder falsch erklärt wird. es gibt rekonstruierbar KEINE probleme, wenn du das sRGB display profile fährst oder eben resolve/fcp nutzt, die mit apples farm management umgehen können. tipp: der einzige player,, der das kann ist SWITCH von telestream. sofern du deine pipeline aber richtig eingestellt hast macht es quicktime (den bug gab es nie, es war immer ein problem der metadaten von drittherstellern). vergiss VLC, PP und MC für vertraunswürdige farben – jeder browser, jedes system zeigt es eh anders, aber auf apple geräten gibt es eben den colorsync (und im professionellen leben auch – metadaten sind gang und gebe, muss eine software aber schreiben, daher nutzt man in PP oder MC den MXF container (gutes quicktime konntne die noch nie...den es wurden nie metadaten geschrieben), damit gehen die am besten um. was da frank so faselt kann man nicht ganz nachvollziehen – apple war immer auf print optimiert, damit ist es berühmt geworden. nur weil andere hersteller immer den colorsync ignoriert haben und trotzdem 'profisoftware' auf mac herausgebracht haben, heisst das noch lange nichts. auf mac ist die color pipeline im vergleich am konsistenten und einfachsten einzurichten...nur aber nicht mit MC oder PP. VLC ist kein professioneller player, SWITCH ist es...oder quicktime, aber man muss halt wissen was man tut.
cantsin hat geschrieben: ↑Do 16 Dez, 2021 00:40
Toll, dass es den Quicktime-Gamma-Shift immer noch gibt... Kann jemand mal Quicktime den schon lange verdienten Todesstoß versetzen?
falsch. kein bug...feature, wird aber seit 2012 von adobe ignoriert. gibt genug erklärungen im internet. für alle intel macs gibt es das alte HD 709-A display profile, das dein internes display (imac oder macbook) auf rec709 einfriert. seit m1 und den XDR disolays sind die presets anders verbaut, aber sRGB findet sich auch - ª∂ 709-A lässt sich immer noch verwenden über umwege und bringt konsistenten workflow für non-apple geräte. bei resolve oder FC sollte man es aber nicht verwenden...die sind clever und schreiben/lesen metadaten.
rfr hat geschrieben: ↑Mi 15 Dez, 2021 20:42
Hallo,
Wenn ich einen Film aus Premiere exportiere, sehen die Farben in Quicktime und auf YouTube anders aus wie in Premiere.
Der VLC Player stellt es eher so dar wie in Premiere.
Um es besser erklären zu können, habe ich in jedem Programm das gleiche Bild und dann ein Bildschirmfotos gemacht.
Was habe ich in Premiere falsch eingestellt, bzw. was muss ich einstellen, damit der Film am Schluß auf YouTube genau so aussieht, wie ich ihn in Premiere gemacht habe.
Danke
Roland
MacBook Pro M1 Max
MacOS 12.1.
Premiere Version 22.1.1
Gelb_Bildschirmfoto.jpg
Gelb_Teststreifen.jpg
Farbblaken.jpg
altes thema...gibt viele artikel dazu und dieses eine video, das es konkurrenzlos richtig erklärt
stichwort: web/computer nutzt sRGB (den kleinsten gemeinsamen teiler in full range g2.2 – PP arbeitet mit 709 legal range g2.4 aber schreibt keine metadaten, das es so ist)
dienstag_01 hat geschrieben: ↑Mi 15 Dez, 2021 21:32
Das liegt an einem Fehler/Fehlinterpretation in der Dynamic Range.
Ich kenne mich mit Mac nicht aus, aber vielleicht gibt es eine Möglichkeit, ohne Quicktime zu exportieren.
Also, dort, beim Export, würde ich verschiedenen Codecs testen.
richtig: MXF container und prores, dann mit quicktime nach h254/65
anders ist das adobe leider nicht beizubringen (resolve/FCP machen's richtig)
mp4 oder mov aus adobe können keine metadaten und der verwendete codec ist NICHT apple's h264 (das beinhaltet colormanagement)
richtig, da geht es um metadaten. man muss den colorsync füttern, den gibt es lang genug. wird nur ignoriert zumindest bei quicktime.
die sog. NCLC tags (flags) bei QT sind sehr alt und wurden einfach ignoriert. bei MXF ist es ein engerer standard
aus der praxis kann ich nur sagen: ein funktioniert gut, apple macht das richtig und es ist konsistent zwischen web, tv und kino (wenn man weiss wie)
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Deswegen ist das wohl eine der am meisten gestellten Fragen, und Adobe & BM müssen "Hacks" entwickeln, um das Problem zu umgehen, obwohl das alles so einfach und prima ist.
Da gibt es eigentlich nur eine Erklärung, die Programmierer der beiden Firmen sind genauso unfähig, wie der Großteil der Apple user - oder?
hexeric hat geschrieben: ↑Do 16 Dez, 2021 10:58
richtig, da geht es um metadaten. man muss den colorsync füttern, den gibt es lang genug. wird nur ignoriert zumindest bei quicktime.
die sog. NCLC tags (flags) bei QT sind sehr alt und wurden einfach ignoriert.
Ich kriege hier echte Deja-Vus mit Linux in den späten 90er Jahren, als man noch Sendmail brauchte, um E-Mail verschicken zu können, und dessen Konfiguration höhere Programmier-Esoterik war. Man kann doch nicht ernsthaft erwarten, dass irgendein normaler MacOS-Nutzer hier noch durchsteigt.
das problem ist ja nicht das colormanagement an sich. das ist vielmehr recht vorbildlich, aber vor allen dingen fast unvermeidbar, wenn man geräte verkaufen will, die deutlich größere farbräume darstellen bzw. nutzen als die meisten geräte zuvor.
was aber weniger gut gelöst ist, ist die abwärtskompatibilität bzw. das default-verhalten des apple farbmanagements im hinblick auf video dateien. schließlich gibt es auch ganz ohne diese proprietären nclc-tags in den files weit verbreitete konventionen, wie rec.709 video-daten korrekt dargestellt werden sollten.
so hätte auch apple einfach ein funktionierendes default verhalten vorsehen können, um derartige dateien, die ja ohnehin bereits an anderer stelle herstellerunabhängige angaben über den zielfarbraum enthalten, korrekt zu interpretieren und im sinne der systemweiten farbmanagement-einstellungen vernünftig für die darstellung aufzubereiten. genau das funktioniert aber leider nicht, weil das default-verhalten, wenn derartige tags fehlen, noch absurder ausfällt als im falle einer redundanten rec.709 kennzeichnung per nclc-tag, die dann halt von apple leider auch wieder recht eigenwillig [miss-]gedeutet wird... :(
so funktioniert das ganze auf geräten dieses herstellers bzw. systemspezifischen anwendungen fast nur im zusammenspiel mit software, die sich diesen idiotischen proprietären konventionen beugt, und sich damit um die betreffenden eigenheiten herumschwindelt, während der rest der welt diese absurden umständlichkeiten natürlich vernünftigerweise ignoriert und es viel einfacher zu handhaben pflegt, was in der praxis auch ganz gut funktioniert.
Zuletzt geändert von mash_gh4 am Do 16 Dez, 2021 11:40, insgesamt 2-mal geändert.
einfach das im o.g. video HD 709-A profil verwenden (geht auch bei einem externen LG ultrafine retina mit p3 – identisches panel der alten intels) und gut ist's
alternativ den display modus "sRGB web" verwenden
hexeric hat geschrieben: ↑Do 16 Dez, 2021 10:58
richtig, da geht es um metadaten. man muss den colorsync füttern, den gibt es lang genug. wird nur ignoriert zumindest bei quicktime.
die sog. NCLC tags (flags) bei QT sind sehr alt und wurden einfach ignoriert.
Ich kriege hier echte Deja-Vus mit Linux in den späten 90er Jahren, als man noch Sendmail brauchte, um E-Mail verschicken zu können, und dessen Konfiguration höhere Programmier-Esoterik war. Man kann doch nicht ernsthaft erwarten, dass irgendein normaler MacOS-Nutzer hier noch durchsteigt.
läuft ja alles automatisch, den user betrifft das nicht. das war immer das schöne an apple. leider spielen da einfach viele dritthersteller nicht mit. auf windows ist das farbmanagement übrigens gar nicht vorhanden und nur über externe geräte mit kalibraot zu bewerkstelligen.
Frank Glencairn hat geschrieben: ↑Do 16 Dez, 2021 11:02
Deswegen ist das wohl eine der am meisten gestellten Fragen, und Adobe & BM müssen "Hacks" entwickeln, um das Problem zu umgehen, obwohl das alles so einfach und prima ist.
Da gibt es eigentlich nur eine Erklärung, die Programmierer der beiden Firmen sind genauso unfähig, wie der Großteil der Apple user - oder?
ja, bei adobe würde ich das behaupten. das sind reine katastrophen, auf der welt verteilte teams, die alle an einem schräubchen drehen und am ende wird es zusammen geworfen. bei avid leider nicht anders und die neuen versionen sind sehr fraglich. resolve bekommt das ja auch hin. also, warum apple und bmd programmierer? den quicktime container haben die meisten nicht verstanden oder ignoriert. der ist auch alt und war mal der größte. zu schnell zu groß geworden. daher: MXF machts meistens in PP und MC gut
Ich glaube, Rec 709 und Gamma wurde hier schon oft diskutiert, Gamma steht da nicht drin.
(Nur mal am Rande, aber das ist ja überhaupt der Ausgangspunkt für alle Anzeigeprobleme dieser Art)
Computerbildschirme sind eigentlich nie auf 2.4 profiliert, weder bei Mac noch bei Windows (die meisten dürften sRGB haben).
Ohne Color Managment wird aber Videomaterial, Player, Betriebssystem und Display kein konsistentes Zusammenspiel liefern können.
Daher beruht das meist auf Annahmen. Dieser Umstand, unterschiedliche Annahmen von unterschiedlichen Anwendungen, führt dazu, dass unter Umständen die eine Anwendung ein anders Bild als die andere liefert, beides auf dem selben Rechner/Display.
(Die Fehlinterpretation der Luma Range jetzt mal außen vor gelassen)
dienstag_01 hat geschrieben: ↑Do 16 Dez, 2021 11:35
Ohne Color Managment wird aber Videomaterial, Player, Betriebssystem und Display kein konsistentes Zusammenspiel liefern können.
ja -- nur kann das halt in den anwendungen erfolgen, wie es unter windows und linux gebräuchlich ist, oder in zentraler weise auf systemebene, wie beim mac.
so lange es sauber gemacht wird, funktionieren natürlich beide varianten ohne probleme.
d.h. jedes bessere besere videobearbeitungsprogramm nimmt natürlich auch unter windows und linux eine übersetzung der transferkurven vor, um rec.709 zufriedenstellend auf sRGB schirmen darzustellen. meist wird von den anwendungen sogar mittels OCIO, littleCMS u.ä. deutlich mehr color-management-funktionalität angeboten.
Zuletzt geändert von mash_gh4 am Do 16 Dez, 2021 11:54, insgesamt 3-mal geändert.
hexeric hat geschrieben: ↑Do 16 Dez, 2021 11:28
einfach das im o.g. video HD 709-A profil verwenden (geht auch bei einem externen LG ultrafine retina mit p3 – identisches panel der alten intels) und gut ist's
alternativ den display modus "sRGB web" verwenden
Habe mir das Profil geladen und in den Systemeinstellungen unter Displays aktiviert, aber welches Profil stelle ich dann auf meinem Monitor (Asus PA329C) ein?
dienstag_01 hat geschrieben: ↑Do 16 Dez, 2021 11:35
Ohne Color Managment wird aber Videomaterial, Player, Betriebssystem und Display kein konsistentes Zusammenspiel liefern können.
ja -- nur kann das halt in den anwendungen erfolgen, wie es unter windows und linux gebräuchlich ist, oder in zentraler weise auf systemebene, wie beim mac.
so lange es sauber gemacht wird, funktionieren natürlich beide varianten ohne probleme.
d.h. jedes bessere besere videobearbeitungsprogramm nimmt natürlich auch unter windows und linux eine übersetzung der transferkurven vor, um rec.709 zufriedenstellend auf sRGB schirmen darzustellen. meist wird von den anwendungen sogar mittels OCIO, littleCMS u.ä. deutlich mehr color-management-funktionalität angeboten.
Innerhalb der Anwendung heißt eben auch, dass es nur eine Annahme zum verwendeten Display Profil gibt. Muss ja nicht sRGB sein.
dienstag_01 hat geschrieben: ↑Do 16 Dez, 2021 11:57
Innerhalb der Anwendung heißt eben auch, dass es nur eine Annahme zum verwendeten Display Profil gibt. Muss ja nicht sRGB sein.
ja -- im gegensatz zu zentralen variante muss es in den anwendungen leider überall ein wenig anders eingestellt werden od. auf ein ICC-profil verwiesen werden.
allerdings ist es in der praxis nicht ganz so schlimm, da ohnehin überall sehr ähnliche mechanismen genutzt werden, und deshalb große überschneidungen da sind, aber natürlich auch im falle von windows und linux zumindest rudimentäre CMS fetures auf system-, anzeige od. desktopumgebungsebene existieren, die hier ein klein wenig unterstützung bieten.
in wahrheit ist es aber viel wichtiger, dass die einstellungen tatsächlich zu den verwendeten schirmen bzw. den dortigem settings und ihrem realen verhalten passen, und nicht nur wie weit diese funktionalität ins system integriert ist bzw. softwareseitig unterstützt wird.
auch am mac hat man ja von diesen fähigkeiten nicht sehr viel, wenn sie von den benutzern nicht richtig genutzt werden od. man oft sogar dagegen anzukämpfen genötigt ist.
Das eine kann recht einfach durch einen closed loop Vorschaumonitor gelöst werden.
Damit wird schon mal sichergestellt, daß man während der Farbkorrektur unverfälschte Farben sieht, völlig unabhängig von irgendwelchen OS Mätzchen und Eigenheiten.
Das zweite ist die Darstellung beim Enduser. Da muß man halt mit entsprechendem Tagging sicher stellen, daß alles für die jeweilige Plattform passt.
Was der Enduser dann auf seinem jeweiligen Gerät einstellt, entzieht sich jeder Kontrolle, daher ist das dann auch müßig darüber zu diskutieren - zumal es den meisten Usern sowieso ziemlich egal ist, weil sie keinen Bock haben, sich damit zu beschäftigen.
Frank Glencairn hat geschrieben: ↑Do 16 Dez, 2021 13:33
Das zweite ist die Darstellung beim Enduser. Da muß man halt mit entsprechendem Tagging sicher stellen, daß alles für die jeweilige Plattform passt.
eben nicht!
es recht im grunde völlig, wenn klar ist, dass es sich um rec.709 handelt und nicht irgendeine HDR variante.
damit ist im grund alles nötige gesagt, und es verbleibt die aufgabe der software auf seiten der endbenutzers, diese vorgabe auch tatsächlich befriedigend auf den schirm zu bringen -- was eben tatsächlich mit colormanagement und entsprechenen farbtransformtionen verbunden sein kann, wenn die farben des verwendeten anzeigegeräts vom übertragungsstandard abweichen, ganz egal ob rec.709, sRGB, P3 od. was auch immer.
so einfach funktionierts doch im ganze normalen fernsehen auch schon lange -- warum sollte man es unbedingt komplizierter machen bzw. zusätzlich irgendwelche properitären tags einführen, die nur auf den endgeräten einzelener hersteller sinn ergeben bzw. jede form der kompatibilität torpedieren?
Zuletzt geändert von mash_gh4 am Do 16 Dez, 2021 14:12, insgesamt 1-mal geändert.
Frank Glencairn hat geschrieben: ↑Do 16 Dez, 2021 13:46
Na ja, "proprietär" würde ich die Tags jetzt nicht wirklich nennen, das ist ein internationaler Standard den es schon ewig gibt.
standard ja -- aber eben so, dass der eintrag 1-1-1, also das, was die meisten programme eintragen, einfach für bt.709 steht und keine zusätzlichen apple-spezifischen verrenkungen (=um dabei auch die allergebräuchlichsten gammawerte zu übergeben) benötigen sollte -- siehe: https://poynton.ca/notes/misc/sde-nclc-vui-nclx.html
hexeric hat geschrieben: ↑Do 16 Dez, 2021 11:28
einfach das im o.g. video HD 709-A profil verwenden (geht auch bei einem externen LG ultrafine retina mit p3 – identisches panel der alten intels) und gut ist's
alternativ den display modus "sRGB web" verwenden
Habe mir das Profil geladen und in den Systemeinstellungen unter Displays aktiviert, aber welches Profil stelle ich dann auf meinem Monitor (Asus PA329C) ein?
das profil ist nur für apple monitore bzw. mac-kompatible (LG ultrafine), die sind alle DCI P3 und werden damit auf 709 g2.4 eingefroren. bei deinem asus entweder auch das preset für p3 wählen oder sRGB und dann dem mac auch sRGB einstellen. sonst kalibrieren den aus, das erstellt dann eh ein eigenes profil – der colorsync funktioniert eh nicht auf externen non-apple geräten! also musst du eigentlich 'nur' den asus kalibrieren oder, sofern verfügbar, die fabrikssettings für sRGB, rec709 oder p3 fahren. hat er das nicht, ist es kein video-profigerät und du musst dich manuell viel spielen.
Frank Glencairn hat geschrieben: ↑Do 16 Dez, 2021 16:09
Der sagt im Prinzip auch nix anderes, wie ich ganz am Anfang schon sagte - wollte ja keiner hören.
naja -- seine erklärungen zu den hintergründen finde ich ganz gut und verständlicher als bei einigen anderen, aber bzgl. der workarounds gibt's vermutlich bessere lösungen...
bzgl. der erklärung der ganzen problematik und möglichst sauberen lösungsstrategien finde ich übrigens auch dieses video recht gut:
alles was 'quicktime (gamma) bug' oder (shift) verwendet ist nicht wirklich vertraunswürdig. appleverse hat seine eigenen abläufe und quicktime spezielle tags, wie andere container auch. der 'bugÄ entsteht wenn beide enden an einander vorbeireden, aber wozu gibt es denn SDKs und documentationen? warum geht es mit einer freeware handbrake oder shutter encoder, aber nicht mit adobe's teurer 'profi' software? ein profi player wie SWITCH macht das was quicktime macht und kann auch viele tags auslesen, verändern (!) und umwandeln (wenn man was zahlt) – warum kann das ein PP oder MC nicht? nochmal: MXF klappt meistens und der levels/gamma shift hürdenlauf ist keineswegs auf mac beschränkt, sondern gang und gebe dann, wenn man das eigene system verlässt. bei apple sieht halt alles gleich aus, egal ob of iphone, ipad, macbook oder imac (oder apple displays). das thema gamma und elvels ist aber so alt wie digitale foto/layout bearbeitung und print. mac wurde berühmt mit dem darstellen des druckergebnisses (CMYK und gamma 1.8) – what you see was what you get. und jetzt lässt sich so ziemlich jeder farbraum auf dem p3 simulieren. presets für rec2020 und rec709 nach allen standards und auf den neuen auch HDR. das klappt alles gut...mit resolve und fcp.
Rechtliche Notiz: Wir übernehmen keine Verantwortung für den Inhalt der Beiträge
und behalten uns das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
