Tekst ten powstał z potrzeby ustrukturyzowania wiedzy, którą nabyłem podczas całkiem już długiej praktyki pracy jako kolorysta.
Kieruje mną chęć
podzielenia się swoimi spostrzeżeniami z osobami ewentualnie
zainteresowanymi.
Zagadnienie postaram się opisać od praktycznej strony,
popartej jednak nieodzowną dawką teorii.
Śmiało można stwierdzić, że system macOS jest ulubionym narządziem branży kreatywnej związanej z produkcją oraz postprodukcją materiału filmowego. Kultowy MacBook Pro zazwyczaj wyposażony jest w ekran dość blisko odwzorowujący standardy kolorystyczne, którymi na codzień posługujemy się podczas sesji gradingu.
Względem konkurencyjnych systemów operacyjnych macOS jest dosyć unikatowy. Został on wyposażony w system zarządzania barwą - ColorSync, który ma odpowiadać za poprawną reprodukcję wartości RGB pikseli względem profilu ICC ekranu.
Przestrzenią barwną Macbooka produkowanego od roku 2015 jest Display P3. Cechuje ją szersza paleta barw (Wide Gammut) niż starsze standardy Rec.709 czy też sRGB. EOTF (Electro optical transfer function) opisujący tonalność ekranu to sRGB. Sam ekran jednak, najprawdopodobniej posługuje się gammą 2.2. W przypadku video SDR - Standard dynamic range, EOTF utożsamiany jest z krzywą gamma.
https://developer.apple.com/documentation/coregraphics/cgcolorspace/1408916-displayp3
Skupię się tu na wciąż najbardziej popularnym standardzie konsumowania treści video - Rec.709.
W macOs dedykowaną aplikacją służącą do odtwarzania filmów jest QuickTime. Dzięki systemowi zarządzania barwą ColorSync powinien on gwarantować poprawną pod względem kolorystycznym prezentację pliku video. ColorSync zarządza również innymi aplikacjami służącymi do prezentowana treści wizualnych - Finder, Podgląd (Apple Preview), Safari, Chrome, Firefox.
W dalszej części tekstu, odnosząc się do charakteru odwzorowania materiału filmowego w systemie macOS, będę odwoływał się do obrazka podlegającego prawom ColorSync.
QuickTime uzgadnia z ColorSync sposób reprodukcji obrazka za pomocą tzw. tagów NCLC - metadanych, które opisują właściwości klipu video.
Dla danego klipu można je podejrzeć w Inspektorze QuickTime (Cmd+I), jak również w Informacjach o pliku Finder (również Cmd+I). Najbardziej typowy zestaw tagów (1-1-1) oznaczać będzie ITU-R BT.709 czyli profil Rec.709.
Żeby nie zanudzić czytelnika technikaliami przytoczę teraz z życia wzięte anegdoty, które dobrze ilustrują rzeczony problem.
Częstą praktyką podczas sesji koloru, jest przesyłanie nieobecnemu na miejscu klientowi tzw. stilek (klatek z filmu, zazwyczaj w formacie jpg). Pozwalają one w szybki sposób komentować propozycję gradingu. Zazwyczaj świadomie unikam tej metody prezentacji. Popełniłem ten błąd, podczas sesji z klientem z Ameryki. Stilki zostały przez niego zaakceptowane. Po skończonej pracy klient otrzymał gotowy plik video i zgłosił pretensje, ponieważ film różnił się jasnością oraz kontrastem od zaakceptowanych wcześniej statycznych obrazków. Film oczywiście oglądany był na MacBooku. Cała sytuacja nie była dla mnie zaskoczeniem, a wynikła z niedopatrzenia w ferworze prac. Wytłumaczyłem sytuację mojemu zleceniodawcy, zwalając winę na ColorSync. Dla potwierdzenia swojej teorii poprosiłem klienta aby porównał dostarczone mu materiały na iPhonie, ewentualnie iPadzie. Byłem pewien, że będą wyglądały identycznie. Tak też było, jako że iOS w przypadku pliku SDR ignoruje parametr transfer function - gamma, a co za tym idzie zdekodowane wartości pikseli wyświetla na ekranie w ich niezmienionej formie.
Gdyby dokonać podobnego porównania na urządzeniu pod kontrolą systemu Windows lub Android rzeczony problem również nie miałby miejsca.
|
|
Zamieszczone obrazki - zrzuty ekranu polecam otworzyć w widoku
Fullscreen - lewy KLIK na obrazku. |
W macOS, o ile nie zostaną podjęte dodatkowe kroki, klatka z filmu będzie wyglądać inaczej niż film.
Inna sytuacja.
Po skończonej sesji w pewnym studio zaistniała potrzeba
wysłania klientowi pliku podglądowego tzw. prevki w celu zdalnej akceptacji. Jakież było moje zdziwienie, kiedy okazało się, że aby tego dokonać,
studio musi najpierw policzyć sekwencję klatek a następnie z tychże klatek
wyrenderować wymagany plik mp4 za pomocą programu AfterEffects.
Wytłumaczeniem tej karkołomnej operacji był fakt że Resolve, po updacie do
najnowszej wersji, podczas liczenia mp4 przyciemnia obrazek. A i owszem tak
właśnie było, widziałem to na własne oczy.
Output color space projektu Resolve ustawiony był na Rec.709 Gamma 2.4 - zupełnie prawidłowo, gdyż tym standardem posługiwał się monitor referencyjny, na którym pracowaliśmy. Z wyborem Output color space powiązane są ustawienia renderu w zakładce Advanced Settings - Color Space Tag oraz Gamma Tag. Parametry te służą zapisowi metadanych pliku opisujących jego właściwość w odniesieniu do koloru. Nie ingerują one w wartości RGB pikseli, a jedynie tłumaczą sposób ich interpretacji. Pozwalają też w toku dalszego procesu postprodukcji lub dystrybucji zorientować się w jakim standardzie materiał był masterowany (w jakim trybie pracował monitor referencyjny).
W przypadku braku ingerencji w wartości Color Space oraz
Gamma Tag stosowane są te zdefiniowane w Output color space projektu. W
MacOS metadane te to właśnie tagi NCLC.
Tagi NCLC pliku wyjściowego z
projektu Rec.709 Gamma 2.4 wyglądają następująco: (1-2-1). Interesuje
nas drugi parametr - transfer function (EOTF), albo jak kto woli, gamma. „2”
oznacza „Unspecified”. Atrybut ten pozwala jednak na przemycenie informacji o
użytym EOTF, w omawianym przypadku 2.4.
Aby uzyskać poprawny obrazek -
tożsamy z tym policzonym z AfterEffects wystarczyło zmienić ustawienie
Gamma Tag na Rec.709. Programy pakietu Adobe eksportują video
jako Rec.709 (1-1-1). Podobnie jest w przypadku FCPX, AVID etc.
EDIT: Kolejna anegdotka! Autodesk Flame, potężny sprzymierzeniec na froncie vfx, który świeżo zawitał w studiu, gdzie miałem ostatnio przyjemność kolorować pewien teledysk. Po skończeniu efektów, za pomocą Wetransfer, otrzymaliśmy wraz z ReżOpem prevki jakości ProRes 422 HQ oraz lżejsze mp4. I co się okazało? A no to, że odtwarzane w QuickTime są dosyć różne.
ProRes policzony został z domyślnie zaznaczoną opcją ColorSync Compatibility, czyli z NCLC (1-2-1). Mp4 powstało natomiast poprzez transcode ProResa w którymś z programów typu Media Encoder. Opatrzone było oczywiście tagami (1-1-1).
Wyjaśniłem chłopakom, co zaszło oraz zaprezentowałem artykuł, który właśnie czytacie. Aby przeciąć spekulacje, rezolutny postproducent opiekujący się projektem zarządził, żeby ProResa zawiesić na YouTube. Film na YouTube wyglądał dokładnie tak jak plik mp4, był zdecydowanie jaśniejszy niż źródło ProRes. I w tym momencie już nikt, zdaje się, nie miał wątpliwości. ReżOp na szczęście, będąc poza sztywnym łączem, oglądał mp4.
https://www.liftgammagain.com/forum/index.php?threads/colorsync-compatibility-flame-2021.16005/
Tak wygląda różnica pomiędzy klipami z tagowaniem Gamma 2.4 (1-2-1) oraz Rec.709 (1-1-1):
Prezentowanie pliku tagowanego jako Gamma 2.4 (1-2-1) na ekranie MacBooka uważam za pomysł mocno kontrowersyjny.
Z mojego doświadczania wynika, że wciąż jest to sytuacja wysoce prawdopodobna. Ma ona miejsce, gdy plik podglądowy renderowany jest bezpośrednio z Resolve ze standardowego projektu Rec.709 Gamma 2.4, bez korekty parametru Gamma Tag w zaawansowanych opcjach renderu.
Metadane NCLC to zjawisko endemiczne typowe dla systemu macOS. Wszędzie indziej obrazek (1-2-1) będzie wyglądał jak przytoczona wcześniej klatka (stilka) z filmu. Zaskakujący jest fakt, że dzieje się tak również w iOS, czy też iPadOS.
Wyobraźcie sobie, proszę, sytuację, gdy grono osób zaangażowanych będzie oglądać materiał przy użyciu urządzeń pod kontrolą różnych systemów operacyjnych.
Czy aby jednak obrazek Rec.709 (1-1-1) prezentowany na MacBooku, rzeczywiście wyświetlany jest poprawnie, zgodnie z zamiarem twórców pracujących zwykle na monitorze referencyjnym skalibrowanym do standardu Rec.709 BT.1886 (norma ITU-R BT.1886 określa EOTF dla telewizji SDR jako ekwiwalent gammy 2.4)? Otóż, nie.
Często spotykana obiegowa opinia, jakoby QuickTime rozjaśniał obrazek, jest tego przykładem. QuickTime Gamma Shift czy jak kto woli Bug to temat rzeka od lat wylewający się z zakamarków internetowych forów przeznaczonych dla profesjonalistów z branży. Obfituje w mnogość sugerowanych rozwiązań, zazwyczaj niespecjalnie skutecznych. Poczesne miejsce zajmuje tu Rec.709-A, nowa przestrzeń kolorów zaimplementowana w Resolve 16.2.2, która w magiczny sposób, pozwala w końcu ujrzeć użytkownikowi jednakowy obrazek w QuickTime, YouTube, Vimeo oraz w okienku Viewer programu Davinci Resolve. Tyle, że jest to sztuczka, swego rodzaju obejście problemu polegające na rozjaśnieniu podglądu Resolve do gammy 1.961.
Taki workflow skutkuje wprost brutalnym faktem, że cały świat poza macOS, włączając w to użytkowników iOS będzie oglądał film ciemniejszy względem intencji twórcy. Nie jest to moim zdaniem dobre rozwiązanie.
Gamma 1.961 to atrybut przyjęty podczas kodowania sygnału video w kamerach cyfrowych, posługujących się standardem Rec.709. Apple zaimplementował go w ColorSync do dekodowania wartości pikseli plików Rec.709 (1-1-1) oraz tłumaczenia ich na profil ICC odpowiadający za poprawne wyświetlanie video na ekranie.
Apple przyjął tu założenie, że taka rozjaśniona gamma ma kompensować różnice w natężeniu światła w otoczeniu ekranu, pomiędzy wyciemnionym grading roomem a jasną przestrzenią biurowo-domową. Zgodnie z tzw. efektem kontrastu (simultaneous contrast effect) nasza percepcja kontrastu oraz koloru różni się w zależności od warunków oświetleniowych.
https://en.wikipedia.org/wiki/Contrast_effect
Rzeczona kompensacja zachodzi jednak niejako automatycznie i wynika z faktu różnicy w gammie użytej podczas procesu korekcji barwnej a EOTF - ekranu komputerowego (sRGB / Gamma 2.2), na którym film jest oglądany. Aktualnie, zazwyczaj nie przygotowuje się osobnych wersji kolorystycznych dla dystrybucji internetowej. Wykorzystuje się w tym celu pliki masterowane w środowisku Rec.709 Bt.1886 / Gamma 2.4 bez dodatkowej obróbki kolorystycznej.
I tutaj wkracza do gry stary, poczciwy standard, pamiętający jeszcze początki internetu - sRGB. Od Rec.709 BT.1886 / Gamma 2.4 różni go jedynie inna charakterystyka użytej krzywej gamma.
The colorist guide to DaVinci Resolve 18 - strona 148
„If you’re using a
Mac display, you’ll need to choose an Output color space based on your ICC
display profile. To find your display profile in your macOS, go to System
Preferences > Displays > Color tab. On newer displays, the profile will
usually be Display P3. To set the correct “Output color space” for Display P3
in the Project Settings, disable “Automatic color management,” select “Use
separate color space and gamma” above the Output color space field, and set
the left field as P3-D65 and the right field as sRGB.”
Powyższa rada ma sens jedynie w przypadku, kiedy podgląd Resolve współpracuje z ColorSync. Aby tak się stało, należy posłużyć się opcją - Use Mac display color profiles for viewers, którą można znaleść w preferencjach programu. Ważne aby ekran pracował w natywnym profilu ICC - Display P3.
Z przyczyn, o których nie będę się tu teraz rozpisywał, zmodyfikowałem zalecane ustawienia projektu, stosując ustawienie przestrzeni koloru, która nie zakłada zarządzania barwą względem użytych klipów video - DaVinci YRGB. W polu Output color space zamiast zwyczajowej Gamma 2.4 wybrałem sRGB - zgodnie z EOTF ekranu MacBooka.
Tak przygotowany projekt skutkuje jednakowym obrazkiem w Resolve, QuickTime, oraz Podglądzie (Apple Preview). Klatka z filmu w formacie jpg, png, itp., również wyglądać będzie tak samo. Tagi NCLC renderowanego pliku mp4, czy też mov będą wyglądać następująco: (1-13-1). „13” oznacza IEC 61966-2-1. transfer function czyli sRGB.
W opisanej sytuacji, w odniesieniu do parametru transfer function, ColorSync nie podejmie działań, których rezultat widoczny byłby gołym okiem. Zdekodowane wartości pikseli zostaną wyświetlone w niezmienionej formie, podobnie jak dzieje się to w Windows, Android czy też również w iOS.
W przypadku pracy w referencyjnym środowisku Rec.709 BT.1886 / Gamma 2.4 możemy posłużyć się zaawansowanymi ustawieniami exportu pliku. W polu Gamma Tag wystarczy wybrać sRGB. W wyniku tego, nasz plik zostanie wyposażony w porządane metadane (1-13-1).
W przypadku pliku z tagowaniem sRGB zalecam jednak daleko idącą ostrożność. Nie jest to standard video per se, a jedynie sposób na zbajpasowanie przypadłości ColorSync. Dlatego też należy go używać jedynie w gronie osób zaufanych oraz odpowiednio poinformowanych o konsekwencjach jego użycia. I w żadnym wypadku nie należy go stosować jako tzw. deliveries. Jakie jest ryzyko? A no takie, że jakiekolwiek transkodowanie takiego pliku np. przez platformy typu YouTube, Vimeo spowoduje zresetowanie metadanych do Rec.709 (1-1-1) i nasz obrazek stanie się jaśniejszy.
YouTube, Vimeo, Frame nie są idealnymi platformami, przy pomocy których moglibyśmy kreatywnie komentować kolor klipu video. Obarczone są bowiem grzechem pierworodnym ColorSync.
Potwierdzeniem moich dociekań jest film z kanału FilmLight, producenta konkurencyjnego dla Resolve systemu Baselight.
Zachęcam, w miarę możliwości, przeprowadzić test porównawczy obrazka prezentowanego na ekranie MacBooka w QuickTime względem monitora referencyjnego. Potrzebujemy 3 plików z interesującymi nas wartościami Gamma Tag: Rec.709 (1-1-1), Gamma 2.4 (1-2-1) oraz sRGB (1-13-1). Zamiast liczyć 3 oddzielne pliki można skorzystać ze zmyślnego narzędzia do zmiany metadanych pliku (działa tylko dla mov oraz mxf)
https://mogurenko.com/2021/01/29/amcdx-video-patcher-v0-6-7/
W celu dostosowania jasności ekranu w okolice 100 nitów (wartość referencyjna w trybie Rec.709 BT.1886 / Gamma 2.4), wyświetlcie na obu ekranach białą planszę.
Obstawiam, że, o ile display Waszego MacBooka nie będzie ze swojej natury zbyt mocno rozjechany, plikiem który będzie najbardziej odpowiadał tonalności obrazka widzianego na monitorze referencyjnym będzie ten z tagiem sRGB(1-13-1).
Miałem okazję porównać tak otagowany plik z produkcją Netflix, przy której dane mi było pracować. Użyłem polecenia Print Screen i zestawiłem ze sobą dwie jednakowe klatki filmu. Zdziwiłem się nieco, bo pod względem tonalności wyglądały identycznie! Spodziewałem się raczej obrazka, który na zagranicznych forach w alarmującym tonie określany jest jako „washed out”, sprany.
Chrome, którego użyłem w celu wygenerowanie zrzutu ekranu, jest jedną z aplikacji, które podlegają prawom ColorSync. W serwisach typu YouTube, Vimeo, jedynym respektowanym zestawem tagów plików SDR jest (1-1-1) czyli standardowy profil Rec.709. Skutkuje to tym, że video dekodowane jest przy użyciu gammy 1.961, co z kolei objawia się rozjaśnionym obrazkiem.
Okazuje się jednak, że ColorSync wykazuje się czasem nieprzewidzianym zachowaniem ignorując parametr transfer function i wyświetlając video poprawnie, a nie jak można by się było tego spodziewać, na modłę macOSa. W Chrome oraz Firefox zdarzają się tego typu sytuacje i w zależności od tego, której przeglądarki użyjemy, zobaczymy obrazek z inną gammą. Safari wydaje się być zdecydowane na systemową 1.961 - Rec.709-A. Chrome oraz Firefox, już nie koniecznie. Większość klipów na YouTube, które testowałem renderowane było jako Rec.709-A, natomiast zdarzały się sytuację, kiedy to tonalność obrazka odpowiadała sRGB.
Poniżej zamieszczam przykładowe zrzuty ekranu z Safari oraz Chrome. Polecam otworzyć je w widoku Fullscreen - lewy KLIK na obrazku.
|
| YouTube, Safari - Rec.709-A |
|
| YouTube, Chrome - sRGB |
Obrazek w standardowym, jedynym słusznym profilu Rec.709 (1-1-1) jest niekompatybilny z sobą samym nawet w bratnich systemach iOS oraz iPadOS.
Interesująca sytuacja ma miejsce na Frame, który również bazuje na profilu Rec.709, jednak jeżeli w ustawieniach jakości - rozdzielczości video, wybierzemy opcję Orginal, pliki zobaczymy z ich pierwotnym, zamierzonym tagowaniem. Warunkiem tej funkcjonalności jest przyzwolenie na możliwość pobrania pliku przez osobę udostępniającą oraz skorzystanie z Safari pod kontrolą macOS w wersji Sonoma lub wyższej.
W przypadku odtwarzania pobranego, oryginalnego pliku w QuickTime, video również zostanie zdekodowane poprawnie. W tym przypadku wersja macOS, czy też przeglądarka internetowa, nie ma już znaczenia. W skrajnej, lecz jak najbardziej prawdopodobnej sytuacji, możemy zderzyć się z podglądem Rec.709 (1-1-1) vs. Gamma 2.4 (1-2-1) i mocno zachodzić w głowę, co autor miał na myśli.
Aby zobrazować to o czym mówię, udostępniłem na Frame.io katalog Video. Znajdują się tam 3 pliki, różniące się jedynie metadanymi jakimi zostały opatrzone. Podczas domyślnego sposobu podglądu, zostaną nam one zaprezentowane w jednej ze zdefiniowanych rozdzielczości, 1080p, 720p, itp. Będą wyglądać identycznie, gdyż podczas procesu transkodowania, ich prawidłowe tagi zostały nadpisane do profilu Rec.709 (1-1-1). Prawdziwą ich naturę ujawni dopiero wybór wersji oryginalnej w polu ustawień Quality, bądź też pobranie pliku na dysk i odtworzenie go w QuickTime.
Udostępniam również 3 dodatkowe katalogi ze zrzutami ekranu Frame
(Original,
Fullscreen) pod kontrolą 3 różnych systemów operacyjnych, Windows,
iOS oraz macOS Sonoma. Porównując obrazki zauważymy, że te z katalogów iOS
oraz Windows są ze sobą tożsame. Są one również zgodne z plikiem z
folderu macOS opatrzonym tagami (1-13-1). Za wyjątkiem systemu
macOS, cała reszta dekoduje wartości pikseli i wyświetla je w ich
rzeczywistej, niezmienionej formie.
Podobnie zresztą na macOS działa
VLC. Jeżeli skonfrontujemy ze sobą ten sam obrazek (1-13-1) w QuickTime
oraz VLC, okaże się, że ich tonalność jest taka sama. Jedyną wyraźną
różnicą będzie nadmierna jaskrawość-saturacja, odwzorowania VLC. Jako
aplikacja, która nie podlega zasadom zarządzania barwą, nie uwzględnia ona
również różnicy pomiędzy przestrzenią barw Rec.709 pliku a Display P3
ekranu.
VLC to zło w przejaskrawionej postaci!
|
Alternatywnym rozwiązaniem dla video z metadanymi sRGB(1-13-1) w QuickTime jest opensource’owy odtwarzacz INNA. Możemy w nim użyć pliku z którymkolwiek z omawianych zestawów tagów. Muszę jednak ostrzec. Spotkałem się już parokrotnie z bezużyteczną wersją, która zachowywała się jak VLC - kolory były mocno przejaskrawione. Długi czas używałem wersji 1.2.0, gdyż 1.3.0 była już trefna. Obecna wersja 1.3.5 działa prawidłowo. Przestrzeń koloru Rec.709 jest poprawnie tłumaczona na profil Display P3 ekranu, podczas gdy gamma pozostaje niezmieniona.
Gdzieś w okolicy 2021 z nastaniem ery ekranów Liquid Retina XDR pojawiło się światełko w tunelu.
MacBook Pro 14 oraz MacBook Pro 16 zostały wyposażone w tzw. tryby referencyjne.
https://support.apple.com/en-euro/108321
Aby uzyskać poprawny podgląd pliku SDR należy zastosować tryb
HDTV Video (BT.709-BT.1886). W tym przypadku video koniecznie musi
zostać opatrzone standardowym profilem Rec.709 (1-1-1). W trybie
referencyjnym posługując się parametrem Gamma boost - 1.22, macOS
zmienia natywny EOTF ekranu przyjmując referencyjną wartość 2.4.
1.961
(gamma pliku Rec.709) x 1.22 (gamma boost) = 2.39242 (~referencyjny
EOTF). Tryb ten zaleca się stosować w środowisku kontrolowanego
natężenia światła, zbliżonym do studyjnego. Jeżeli w trybie referencyjnym
chcielibyśmy skorzystać z Resolve, należy użyć krytykowanego przeze mnie
wcześniej Output color space: Rec.709-A.
https://forum.blackmagicdesign.com/viewtopic.php?t=175467&p=924223
Tryb referencyjny, jak wspaniały by nie był (tu bez ukrytej ironii), posiada jednak jedną dość istotną wadę. Blokuje jasność ekranu na referencyjnym poziomie 100 nitów. Zgodnie z efektem kontrastu obrazek taki będzie zbyt ciemny w codziennej przestrzeni biurowo - domowej. Trudno wymagać np. od osób z agencji reklamowej, podczas godzin urzędowania, aby wyciemniali otoczenie swojego ekranu do poziomu zbliżonego temu w grading roomie.
Dodam jeszcze, że z moich obserwacji tryby referencyjne, nawet u profesjonalnych użytkowników MacBooków Pro są wciąż traktowane po macOSzemu. Zakładam, że 80-90% nie wie o ich istnieniu. Zachęcam zatem serdecznie. Nadmienię również, że iPad Pro 5 generacji wzwyż, również jest wyposażony w podobne rozwiązanie.
Taka ciekawostka. Tryb referencyjny iPada to stosunkowo świeża funkcjonalność, wprowadzona wraz z iPadOS 16.1 pod koniec 2022 roku. Wcześniej, zwłaszcza w czasie pandemii, iPad Pro był szeroko wykorzystywany przez studia postprodukcji w celu zdalnego komentowania pracy kolorysty. Funkcjonował wtedy w trybie sRGB. Ekrany iPad Pro oraz MacBook Pro, równoległych generacji, to bardzo zbliżone panele, wykorzystujące tą samą technologię oraz posługujące się tą samą przestrzenią barw - Display P3. Dlatego uważam, że świadomie użyty „tryb sRGB” na MacBooku, pozwala nam być bliżej prawdy ekranu :P
Więc, co zatem polecam do oglądania, gdy nie możemy skorzystać z trybu referencyjnego HDTV Video (BT.709-BT.1886)… Bardziej poddaję pod rozwagę - Frame, oczywiście. Ładujemy plik z profilem sRGB (1-13-1). Frame nam go transkoduje do wersji 1080p, resetując tagi do (1-1-1). Mamy zatem tylko jeden upload i dwa pliki o różnej charakterystyce gamma, które możemy pokazać klientowi. Trzeba jednak spełnić dwa warunki, przypominam - Safari oraz macOS Sonoma lub wyższy. Ewentualnie, w starszej wersji systemu, plik pobrać na dysk i otworzyć w QuickTime. Jedynie taki hack, gwarantuje nam, że użytkownik macOS, zobaczy to samo co ten na iOS, iPadOS, Windows czy też Android. Pomijając oczywiście kwestię tego, jak bardzo konkretny ekran jest nieskalibrowany.
I to chyba tyle. Mam nadzieję, że rzuciłem trochę światła, rozjaśniając mroki zawiłości ColorSync. Wybaczcie proszę clickbaitowy tytuł artykułu, ale zaobserwowana przeze mnie niedostateczna świadomość problemu rodzi często niepotrzebne perturbacje, a bycie sygnalistą w dzisiejszych czasach nie jest sprawą prostą :P.
Zapraszam oczywiście do dyskusji.
Michał Majki Kowalski
Bibliografia:
https://www.cined.com/quicktime-gamma-shift-bug-what-is-it-and-how-to-combat-it/
https://forum.blackmagicdesign.com/viewtopic.php?f=21&t=101253
Komentarze