破解 Mac 色彩管理迷思
為什麼取得精準可靠的顯示器校正如此困難？
每一台 Mac，無論是筆電螢幕還是透過顯示卡連接的專業顯示器，其色彩輸出都必須經過 Apple 的 ColorSync 處理——而且除了透過專用的視訊輸出裝置（例如：BMD 的 UltraStudio）之外，沒有任何方法可以將其關閉。
本文假設你已經閱讀過〈ICC 出了什麼問題？〉，該文涵蓋了基於 ICC 的顯示器校正（Display Calibration）之普遍限制。該頁面上的所有內容仍然適用於 Mac。本文將探討 macOS 在這之上所增加的影響——而這可能會讓情況變得更糟。
本文並不是在斷言 Mac 的色彩管理（Color Management）在其自身限制下絕對無法運作。我們的論點是：對於任何特定的應用程式或任何 macOS 版本而言，它是否能正常運作是無法可靠預知的——這對於專業用途來說，等於是同樣糟糕的結果。
同時，本文也定義了 Mac 色彩管理的極限，及這些限制為何同樣無法被專業色彩應用所接受。
為什麼要寫這篇文章？
要找到關於色彩管理在 Mac 上實際如何運作的直接、可驗證答案真的非常困難——對於這個在專業色彩工作中如此重要的主題來說，這難度實在太高了。Apple 從未發布過一份單一且完整的說明，來解釋 ColorSync、系統合成器（System Compositor）及指派給顯示器的 ICC 描述檔之間究竟是如何互動的。相反的，現有的資訊散佈在開發者論壇的回答、第三方校正工具的文件及多年的使用者報告中，而且其中很多內容是相互矛盾的。
這些矛盾有些是真實存在的。Apple 官方的開發者支援團隊曾公開表示，某些描述檔類型「從未被支援過」——但其他經驗豐富的開發者在同一個論壇討論串中直接且公開的反駁了這一說法，並指出這些描述檔明明已經正常運作了好幾年。雙方說的都是事實：他們只是在描述不同的事物，或是指向不同的時間點，卻沒有明說。要弄清楚真相真的很困難，且因為在任何地方都很少有清楚寫下來的紀錄，很容易——我們在研究這篇文章時也發現了這點——會得出比證據所能支持的還要廣泛的結論。
本文中若將某事陳述為事實，那是因為我們發現 Apple 曾經明確說明過、可以直接證明，或是獲得了多個可信來源的獨立證實。如果證據不夠充分，我們會直接明言而不會妄加猜測。我們自己的 SpaceMan 文件，及其背後更廣泛的測試，也是基於同樣的原則所建立的。
ColorSync 永遠處於作用中狀態——無法繞過
在 Windows 上，一個沒有進行色彩管理的應用程式，會直接將其像素傳送出去，除了顯示卡 VCGT 中的灰階（Grey Scale）校正之外，幾乎不會有任何修改。但在 macOS 上並非如此。每一個應用程式，無論它是否具備色彩管理功能，其輸出在到達螢幕之前都必須經過 ColorSync 的處理流程。沒有任何設定、沒有任何標記，也沒有任何應用程式層級的退出機制可以移除這個過程。
Light Illusion 多年來在我們所有的文件中都一再聲明：在每一台 Mac 上，ColorSync 始終處於全系統啟動的狀態。必須澄清的是，這不僅僅是我們自己的觀察。Blackmagic Design 自己的工程團隊在針對 DaVinci Resolve 的 Mac 顯示路徑時，也確認了完全相同的事情——Resolve 中的「使用 Mac 顯示器色彩描述檔」選項，僅僅只是改變 Resolve 自身是否要對 ColorSync 正在做的事情進行補償。Blackmagic 已經確認，無論該選項是開啟還是關閉，底層的 macOS 色彩轉換都會被套用。在你的應用程式中關閉色彩管理，並無法在 Mac 上為你帶來乾淨、未經校正的訊號。從來都沒有辦法。
在 Mac 上最接近「原生」讀取的方式根本不是一種繞過（Bypass）機制——它是一種恆等轉換（Identity Transform），在此過程中，顯示的內容會被刻意標記以符合當前指派的顯示器描述檔，因此 ColorSync 的轉換作用實際上等於什麼都沒做——或更準確的說，幾乎沒有作用（譯者註：當影像本身的色彩描述檔（來源），剛好與螢幕的色彩描述檔（目標）完全一模一樣時，macOS 的 ColorSync 色彩轉換系統在進行數學運算時，會發現數值根本不需要改變。因此，這個原本應該要進行色彩轉換的處理流程，最終的結果就是「影像原封不動地輸出」，這就等同於轉換機制形同虛設或被完全抵消了）。這在進行顯示器特徵化（Display Characterisation）時，是一種有用且正當的技術。然而在驗證過程中，也很容易不小心把它遺留在原處，這時它可能會讓校正結果看起來很好，或看起來像什麼都沒做，而無視於實際情況。任何在測量 Mac 顯示器的人，都需要知道自己實際處於這兩種狀態中的哪一種。
根據 Apple 自己目前的立場，macOS 顯示器描述檔只能對你的影像做兩件事：套用單一的 3x3 矩陣（Matrix）與色調曲線（Tone Curve）來處理色域（Gamut），及載入一個獨立的 1D 單色版表格——也就是 VCGT——來處理灰階和白點（White Point）。這兩者無論是單獨還是結合使用，都不是 3D LUT。
我們會這麼說，是因為 Apple 自己的開發者支援團隊在直接回覆一位專業使用者的查詢時證實，帶有 3D LUT 數據的 ICC 描述檔並非 macOS 顯示器描述檔所支援的機制——無論早期的 macOS 版本是否看似接受它們。
一個 3x3 矩陣無法修正體積色彩誤差（Volumetric Color Error）。而 VCGT 則完全無法觸及色域。這在架構上是無法改變的事實，而不是任何特定描述檔的品質問題。
同一台 Mac 上的兩種不同色彩架構
鮮少人了解到，目前的 Mac 根據所連接的顯示器不同，會執行兩種截然不同的色彩架構之一，而且這兩者的運作方式大相逕庭。
標準的 ColorSync 顯示器：任何透過顯示卡連接的第三方顯示器，及任何較舊或非 XDR 的內建螢幕——都使用上述的傳統模型：在指派的 ICC 描述檔中包含矩陣和色調曲線的描述，加上登入時載入至顯示卡的 VCGT。
Apple 的 XDR 等級顯示器：包含 Pro Display XDR、Studio Display XDR，及 2021 年及後續 MacBook Pro 機型內建的 Liquid Retina XDR 螢幕——則使用了另一種截然不同的方式，稱為參考模式（Reference Mode）。在這裡，校正數據被保留在顯示器或硬體層級，根本不再主要依賴 ICC 描述檔，因此系統設定也不再為這些螢幕提供手動選擇 ICC 的選項。
這兩種架構都無法進行真正的體積校正（Volumetric Correction）。標準處理架構受限於上述的矩陣與 VCGT 限制。而 Apple 自己的參考模式架構，雖然是貨真價實的硬體層級校正，但依然受限於單一的色調曲線與白點目標，完全無法提供體積校正功能——因此，無論顯示器是如何被驅動的，它仍然無法與真正的 3D LUT 校正相匹敵。
一般色彩轉換與顯示器指派是兩回事
在進一步探討之前，有一項區別非常重要，必須明確說明，因為這兩者很容易被混為一談，並從真實且正確的經驗中得出錯誤的結論。
自從 Mac 上有 ICC 描述檔以來，ColorSync 的色彩比對引擎一直都能夠完美的讀取並使用體積 LUT 數據（AToB/BToA 標籤）。這一點毫無疑問，也從來不是問題。幾乎所有的印表機與掃描器描述檔都是這樣運作的，且任何明確透過描述檔來轉換影像或影片素材的工具——像是畫面風格燒錄（Look Burn-in）、列印模擬或軟打樣（Soft Proof）——幾十年來也一直都是正確的這樣處理體積數據。Light Illusion 自己的 AlexICC 是一套幾年前的 Mac 工具，它利用 QuickTime 將 SpaceMan 產生的 ICC 描述檔直接燒錄至影片素材中，正是依賴於這一點，而它之所以能順利運作，完全是因為 ColorSync 的這一部分從未受到限制。
本文所討論的限制其實範圍更窄、更具體：當系統合成器或預覽程式（Preview）算圖輸出至該螢幕時，目前被指派為顯示器即時裝置描述檔中的體積數據是否會被使用。這是一項單一且具體的工作——針對指派的描述檔進行即時顯示算圖——而不是在質疑 ColorSync 處理基於 LUT 描述檔的一般能力，這一點從未受到質疑，並始終保持其原有的強大功能。
本文或 Light Illusion 的其他文件中，任何提到「Apple 自己的預設色彩處理不使用體積數據」的地方，該聲明都是專指這個即時顯示指派的案例，而非泛指 ColorSync 的整體表現。
在 Mac 上真的能使用體積 ICC 描述檔嗎？
像 Light Illusion 的 SpaceMan 這類的軟體，可以建立真正體積化的 ICC 描述檔，透過現代的 v4/iccMAX 描述檔格式嵌入真實的 3D LUT 數據，這些數據是由精確的 ColourSpace 特徵化所產生的。真正重要的問題是，在 Mac 上指派該描述檔，是否會讓 macOS 真正去使用這些體積數據。
Apple 自己的開發者支援團隊曾明確表示，基於 LUT 的顯示器 ICC 描述檔在 macOS 上並非受支援的機制——儘管這項規定是隨著時間逐漸變得嚴格，而非一開始就是固定且永久的規則。一位專業攝影師向 Apple 開發者支援提交的報告中描述，這類描述檔在 macOS Monterey 和 Ventura 上是可以安裝且使用的，但這項限制在較新的版本中變得更加嚴格；Apple 的回覆證實了這一點，將早期的接受行為描述為一個錯誤，並且已經「在近期的更新中被修復」。DisplayCAL 長期記錄了在 macOS 上使用這種類型描述檔時出現的暗部死黑（Black Crush）與色階斷層（Posterization）錯誤，這進一步證實了這個狀況，儘管這是作為出錯的紀錄，而不僅是運作不穩定而已。
這是專指 macOS 自己預設色彩處理的立場。擁有自己相容色彩引擎的第三方應用程式則是一個截然不同的情況，這不只是理論上的說法——Adobe 的應用程式就是最好的證明。專業使用者描述他們多年的實務經驗，刻意維護一個專供 Adobe 軟體使用的體積描述檔，同時為一般桌面使用準備另一個純矩陣描述檔，正是因為這兩者的表現不同。這是真實的、匯聚的第一手證據，而非臆測。不過這也不是無條件的保證：Adobe 自己的色彩引擎在當前的 macOS 和應用程式版本中，本身也出現了明顯的退步，在至少一個有紀錄的案例中，Apple 自己的引擎反而成了能正常運作的備用方案。哪一個引擎能真正正確的處理特定的描述檔，值得針對你特定的應用程式和版本進行驗證，而非憑空假設。
決定任何給定應用程式最終結果的，是三個獨立條件所組成的連鎖反應。特別是對於 Apple 自己的預設色彩處理而言，這其中的第二個條件已經被確認是否定的。對於擁有自己色彩引擎的第三方應用程式來說，這是一個真實且有證據支持的可能性，而不是一個固定的答案——請參見下文。
內容必須被標記，才能真正觸發轉換：只有當來源標籤與指派的顯示器描述檔不同時，ColorSync 才會轉換色彩。直接標記為符合顯示器描述檔的內容——與用於獲得乾淨原生讀取資料的恆等技巧相同——完全不會觸發任何轉換（無論是體積轉換還是其他轉換），並且會默默的看起來像什麼都沒做。
處理該轉換的 CMM 必須真正讀取體積標籤：當該轉換是特別針對指派的顯示器描述檔算圖輸出至螢幕上時，Apple 自己的預設色彩引擎——也就是預覽程式和一般系統合成器背後的引擎——已經被確認不會為了這個目的而去讀取體積標籤（ColorSync 在其他地方處理基於 LUT 的描述檔的能力，如影像轉換、列印或畫面風格燒錄，則不受影響，並且始終如此——見上文）。一個建立良好的 v4 描述檔會包含矩陣與色調曲線的備用方案（Fallback），正是因為這個原因，好讓描述檔能降級使用，而不是完全失效。這意味著描述檔可在沒有任何錯誤的情況下安裝，但在依賴 Mac 自己預設處理的任何情況下，仍然默默的只以其平坦化、非體積的形式被使用。擁有自己色彩引擎的獨立應用程式則是一個截然不同的情況——Adobe 的應用程式有社群多年來真實的證據，證明它們也能正確的在螢幕顯示上讀取體積標籤，以至於專業使用者會建立一整套工作流程，專門為了 Adobe 軟體而切換到體積描述檔。這並不保證適用於每一個應用程式，甚至對 Adobe 來說也不是永久的保證——這是有證據支持的目前最佳實務，但並非絕對。
該結果必須正確的與獨立的 VCGT 結合：體積轉換（如果真的發生的話）與 VCGT 在流程架構上是兩個獨立的機制，並在不同的節點上被套用。macOS 是否會以描述檔建立時所預期的方式將這兩者結合在一起，Apple 並沒有在任何地方留下文件紀錄，這也不是你可以從外部檢查出來的。
對於 Mac 自己的預設色彩處理來說，這實際上並不是三個環節都有可能出錯的連鎖反應——因為第二個環節已經被確認絕對會出錯了。真正有證據支持的可能性，完全取決於你使用了哪些第三方應用程式，及它們自己的色彩引擎是否尊重體積標籤——Adobe 的應用程式是最明確、證據最充分的案例——而不是取決於 Mac 自己的桌面或預設檢視器。
Apple 自己的預設色彩處理——預覽程式和一般的系統合成器——在針對指派的描述檔算圖輸出至即時顯示器時，並不會使用體積 ICC 數據。不是偶爾不會，而是絕對不會。這不是在評斷 ColorSync 處理基於 LUT 的描述檔的一般能力，那方面是不受影響的——請見上文。
擁有自己相容色彩引擎的第三方應用程式則是另一種情況，且有真實證據支持的——特別是 Adobe 的應用程式，其圍繞著正確讀取體積標籤所建立的專業實務已有多年紀錄。這是真確的證據，而非猜測。這同樣也不是永久的保證：Adobe 自己的色彩引擎在目前的 macOS 及應用程式版本中也出現了退步，Apple 的引擎反而成為了可行的備用方案。對於 Mac 自己的桌面、自己的預設檢視器，及任何依賴系統預設色彩處理、而非自備引擎的應用程式來說，體積數據絕對不是決定螢幕上顯示內容的因素。至於其他的應用，請針對你特定的應用程式和版本進行驗證——不要抱持任何先入為主的假設。
VCGT 無法可靠的保持載入狀態
即使完全把體積的問題擺在一邊，每個 Mac 色彩工作流程所依賴、用於校正灰階與白點的簡單 1D VCGT，也不能保證會一直保持作用。在許多 macOS 的發行版本中都有明確記錄，VCGT 可能會被日常的一般事件悄悄的重置——例如登入、從睡眠狀態喚醒，或重新連接外部顯示器。在 Apple 的 XDR 等級顯示器上，這種重置行為確實存在，但只是局部的：詳細的使用者測試發現，白平衡（White Balance）組件會被重置，但其他的校正數據卻能在相同的事件中留存下來，這比起乾淨徹底的完全重置，是一種更為怪異且更難以診斷的故障模式。
這並非已經被修復的歷史問題。兩個目前仍然開啟的獨立問題證實，在不同的版本之間，該處理架構依然不穩定。Apple 的開發者支援團隊已經承認存在一個錯誤，即同一個顯示器描述檔會被做出不同的解釋，進而產生實質上錯誤的色彩，這完全取決於是哪個近期的 macOS 版本在執行它。另外，在最新的 Apple Silicon 硬體上，負責將 VCGT 載入到顯示器的系統呼叫（System Call）已經被確認會默默的失敗——它會回報成功，讀取回來的結果也像是成功了，但實際上在螢幕上完全沒有產生任何改變。
一個完全沒有 VCGT 標籤的 ICC 描述檔，並不能告訴你先前載入的 VCGT 是否仍在作用中。這是兩個完全獨立的狀態，而 macOS 並沒有給你任何可靠的方法來直接檢查第二種狀態。
Apple 的「參考模式」硬體校正
Apple 的高階顯示器——Pro Display XDR、Studio Display XDR，及 2021 年和之後的 MacBook Pro 機型內建螢幕——是透過參考模式進行校正，而不是透過傳統指派的 ICC 描述檔。Apple 的 Pro Display Calibrator 可以在所有這些裝置上微調白點和亮度（Luminance），且可以在支援的機型上，使用一小部分受認可的光譜輻射計（Spectroradiometer），或是特定的受認可色度計（Colorimeter）來執行更完整的校正。
最新的 Studio Display XDR 還引進了 Apple 自己的色彩比對函數（Colour Matching Function），目的是在現代顯示器所使用的窄頻域背光上，提供比大多數測量工具仍假設使用的、有著百年歷史的 CIE 1931 舊標準更好的準確度。在適用此函數的情況下，標準的濾波器型色度計完全無法正確測量該顯示器——需要一台支援較新標準的分光光度計（Spectrophotometer），而目前只有少數的第三方校正工具支援。
這些都沒有改變根本的限制。參考模式是貨真價實的硬體層級校正，但它依然受限於單一色調曲線與白點目標，在整個環節中完全沒有提供體積校正。執行得很完美的參考模式校正，與執行得很糟糕的校正，有著相同的天花板限制——兩者都無法修正 3D LUT 被設計來解決的那種體積、色域層級的誤差。
親自測試看看
如果你想親眼看看 Apple 自己的色彩管理在特定 Mac 上的實際表現，而不需要一台專用的測試圖形產生器（Test Pattern Generator），你可以將一個已知的 ICC 描述檔嵌入為一般影像的來源標籤，並在預覽程式或快速預覽（Quick Look）中開啟它——這兩者都是直接使用 Apple 自己的預設色彩引擎，而非應用程式自帶的引擎。這是一種非常實用的診斷方法。但它並不等同於正確的測量工作流程，因為它沒有自動化，不能保證像素對像素（Pixel For Pixel）的呈現，也無法控制縮放。
若要在 Mac 上獲得真正受控、可重複的測試訊號，PatternSpace 正是為此而生，並且完全與 ColourSpace 相容。
唯一能確知的方法
本文提到的所有機制，都無法從外部進行確認。指派了哪個 ICC 描述檔，及它是否包含 VCGT 或體積數據，這些是可以檢查出來的。但這些數據是否真的被使用、被哪個應用程式使用，卻無從得知。
ColourSpace 的 Active LUT 功能迴避了這整個問題，而不是試圖去解答它。它直接在 ColourSpace 自己的色彩引擎（Color Engine）中套用 3D LUT 校正，強制將結果輸出，而不是依賴於某種由應用程式、CMM 及 macOS 版本組成的隱形組合，去碰運氣看它們是否能正確的尊重已安裝的 ICC 描述檔。這是 ColorSync 在任何 Mac、任何 macOS 版本上都無法提供的保證。
在 Mac 上最可靠的方法，仍然是我們在〈ICC 出了什麼問題？〉中所建議的那一套：使用真正的 3D LUT 準確的校正顯示器本身，並將 Mac 自己的 ICC 描述檔簡化為對該結果簡單、誠實的描述——一個只有矩陣和曲線的描述檔，不包含任何會默默失效的體積數據。如果你還是堅持要為 Mac 建立體積 ICC 描述檔，SpaceMan 會根據你的數據準確的建立一個——只是在這麼做之前，請確保你已清楚了解本文所述的一切。
一步步執行 Mac 校正
綜合上述所有內容，以下是使用 ColourSpace、PatternSpace 和 SpaceMan 來校正連接 Mac 的顯示器之真實、實用的選項。這裡假設你使用的是透過標準顯示卡連接的顯示器，或是 Mac 自己的內建螢幕，且裝置本身沒有自帶的硬體校正功能——這與本文其他部分所涵蓋的範圍相同。
以下的兩條路線都共有相同的第一階段：對顯示器實際表現進行準確、體積化的特徵化。它們的不同之處在於，接下來要求 SpaceMan 用這些數據來做什麼。
第一階段——顯示器特徵化
ColourSpace 本身目前無法在 Mac 上原生執行，因此由 PatternSpace 扮演圖形產生器的角色，而 ColourSpace 則如常執行並驅動測量過程。
將 PatternSpace 連接為圖形來源：目前這個連線及其設定是直接在 PatternSpace 內部進行規劃，而不是從 ColourSpace 遠端操作，這有待未來透過 PatternSpace 的 SDK 進行更完整的整合。
將 PatternSpace 設定為符合顯示器目前指派的色彩空間：這就是前面提到的恆等轉換技巧——它能為特徵化獲取乾淨、原生的讀取資料，前提是顯示器目前指派的描述檔中，沒有殘留上次校正留下的作用中 VCGT。
在 ColourSpace 中對顯示器進行特徵化：透過連接的色度計（Probe）執行完整的體積色塊集（Patch Set），就像對待任何其他顯示器一樣。這就是下面兩條路線所依據的測量數據。
產生校正用的 3D LUT 並用 Active LUT 進行確認：在完全沒碰到 ICC 之前，請先使用 ColourSpace 的色彩引擎產生校正用的 LUT，並直接透過 Active LUT 進行驗證。這確認了在此顯示器上，準確的校正實際看起來是什麼樣子，且完全獨立於 ColorSync 之外。
路線 A——將 3D LUT 嵌入 ICC 中
這條路線是在押寶特定目標應用程式自己的色彩引擎會讀取體積數據——而不是押在 macOS 本身上，因為前面已經提過，這確定是行不通。特別是對於 Adobe 應用程式來說，考量到前面提到的真實證據，這是一個合理的押注，儘管不能保證適用於任何應用程式或版本。
SpaceMan 預設的顯示器類別（Display Class）匯出檔案中，只包含 LUT 標籤，如果有建立的話，還會加上 VCGT。它不會自動加入獨立的矩陣和 TRC 標籤——這是下面刻意安排的額外步驟，請不要以為它已經自動完成了。
將校正 LUT 載入 SpaceMan 並建立顯示器類別描述檔：使用在第一階段產生且經 Active LUT 確認過的相同 3D LUT。這會產生一個只包含 LUT 標籤（如果有使用該選項，則還包含 VCGT）的描述檔——目前還沒有任何矩陣或 TRC 數據。
建立矩陣與 TRC 備用方案，並將其複製到相同的描述檔中：使用下方路線 B 中相同的測量原色（Primaries），建立第二個單獨僅包含矩陣與 TRC 標籤的描述檔。接著使用 SpaceMan 的標籤匯出與匯入工具，將這些標籤複製到步驟 1 的基於 LUT 描述檔中，這樣這一個檔案最終就會同時包含這兩種表示方式。如果沒有這個步驟，macOS 自己預設的色彩處理就會完全沒有備用方案可依賴——關於具體該如何操作，請參閱 SpaceMan 手冊。
將該描述檔指派為 Mac 的顯示器 ICC：透過系統設定進行；如果系統設定沒有為該顯示器提供選項，請透過 ColorSync 軟體（ColorSync Utility）進行指派。
使用正確標記的內容進行驗證，而非恆等轉換：針對新指派的描述檔，將測試內容標記為原始的目標空間（Target Space），這樣才能強制進行真正的轉換。透過預覽程式或快速預覽進行檢查時，確認到的是矩陣備用方案，而不是體積數據——這是預期中的結果，而非描述檔建置不良的跡象。真正重要的驗證，應該在你日常會使用的任何應用程式中進行。Adobe 應用程式擁有正確讀取體積標籤最充分的證據與機會，但還是請針對特定的應用程式與版本進行檢查，不要單憑本文的內容就妄加假設。
將任何特定應用程式的結果視為暫時性的：在任何 macOS 或應用程式更新後請重新檢查。隨著時間的推移，Apple 針對體積 ICC 描述檔的立場只會越來越強硬，而非固定不變，而且也沒有人能保證特定的應用程式之色彩引擎在每個版本中都能保持相同的運作方式。
路線 B——由顯示器真實原色建立的純矩陣 ICC
這條路線完全不對 ColorSync 處理體積數據的方式抱持任何假設，因此它是完全可靠的——代價是受到貫穿本文所述的相同矩陣與 VCGT 限制。它與典型製造商 ICC 的主要區別在於，它所使用的原色是顯示器本身實際的測量值，而不是像 sRGB 或 Rec709 這樣被預設的標準。
擷取顯示器真實測量的原色：可以從第一階段的特徵化中自動擷取（使用 ColourSpace 的 Library > Modify > Extract Space 選項），或是手動操作——在校正介面上測量 100% 的紅、綠、藍與白色，並自行記錄結果的 xy 值，就如同在〈ICC 出了什麼問題？〉的「將顯示器校正至其本身」章節中所描述的一樣。
將原色與白點直接輸入到 SpaceMan 的 ICC 標籤中：不需要嵌入任何體積數據，而是將測得的 xy 值、白點及目標 Gamma（Target Gamma）直接輸入到 SpaceMan 的矩陣/原色（Colorant）與 TRC 標籤欄位中。現在，這個描述檔描述的是顯示器真實的色彩特性，而非預設的目標。
從相同的特徵化數據建立 VCGT：灰階與白點的校正依然來自於第一階段的測量，這與路線 A 中 LUT 的作法完全一樣。
將此描述檔指派為 Mac 的顯示器 ICC：與路線 A 相同的指派步驟——但此時完全沒有體積標籤會讓 CMM 去解讀，無論是正確解讀、錯誤解讀，還是根本不解讀。
了解這個描述檔實際上在告訴 ColorSync 什麼：它不再宣稱顯示器達到了像 sRGB 或 Rec709 這樣的標準空間。它只是誠實的描述顯示器自己的原生色域。尊重這個描述檔的應用程式，將會獲得進入該真實色域的準確轉換。而不尊重的應用程式，至少也不會被根據錯誤的假設來進行校正。
當一切條件都剛好符合時，路線 A 可以提供比路線 B 更準確的色彩——但當它沒有發揮作用時，它也無法告訴你。路線 B 永遠無法比擬真正的體積校正，但它每一次都能分毫不差的執行它所承諾的事情。
對於大多數基於 Mac 的影視色彩工作來說，路線 B 是最可靠的基準線；只有那些了解並接受本文中所涵蓋的所有警告事項的人，才應該嘗試路線 A。無論是哪種方式，ColourSpace 中的 Active LUT 依然是在該顯示器上實際觀看並確認真正的 3D LUT 校正結果的唯一方法，因為它完全不依賴於 ColorSync。
想瞭解更多關於 ColourSpace 的功能及應用嗎？
堅達公司（GETOP）為 ColourSpace 授權經銷商，擁有專業校準實驗室，我們的 校準專家線上隨時為你提供應用實例及回答技術上的疑問：
👉 加入我們的 LINE 官方帳號洽詢：https://line.me/R/ti/p/@691ttrbp
https://getop.tv/15u16a
留言