從一個 .xmp 檔案 到你留下的那一張。
預設集只解析一次，變成一組參數；為觀景窗烘焙成一張三維查找表；按下快門時，再以完整的浮點精度在未壓縮的感光元件畫面上重新跑一遍。兩條路徑由同一份以 Rust 寫成的實作驅動——預覽與成品一致，原因就在這裡。
最後更新:
一張照片走過的路
解析檔案
.xmp 預設集本質上是 XML。其中每一項 Camera Raw 屬性都會被讀進同一組參數：白平衡與曝光、色調與曲線、HSL、顏色分級、細節、效果，以及可能存在的遮色片。引擎不認得的屬性會被忽略而不是當成錯誤，因此由更新版本的 Lightroom 匯出的預設集，仍能帶著它讀得懂的一切正常載入。
預設集變成一條流水線
這些參數會變成一串順序固定的運算：先白平衡與曝光，再色調與曲線，再顏色，最後是與空間有關的部分——清晰度、去朦朧、銳利化、遮色片、暈影與顆粒。順序是固定的，因為同樣的調整換個次序，得到的並不是同一張照片。
觀景窗拿到的是一張查找表
凡是只取決於像素本身顏色的部分——曲線、HSL、顏色分級、點顏色——都會在你切換預設集的那一刻一次性烘焙成三維查找表。此後 GPU 只要把這張表套到每一格畫面上，幾乎沒有額外開銷，這正是風格能跟上即時畫面的原因。
快門跑的是真的那一套
按下快門，同一條流水線會以浮點精度在整幅未壓縮的感光元件畫面上重新跑一遍，其中不含查找表的任何內插。光暈與顆粒在兩條路徑上使用完全相同的程式碼，所以你在觀景窗裡看到的質感，就是你最後得到的質感。
原始畫面會保留
預設會在成品旁儲存一份未經處理的副本；在 RAW 模式下，未加工的感光元件資料還會單獨寫成一個 ProRAW 的 DNG。套用風格這件事，刪掉一個檔案就能還原，不會不問一聲就烙進照片裡。
預覽與成品為什麼一致
大多數帶即時濾鏡的相機，預覽用一套程式碼、出圖用另一套，兩者會逐漸分道揚鑣——「先拍平、之後再調」這句老話就是這麼來的。
在這裡，兩條路徑用同樣的參數呼叫同一份 Rust 實作。預覽讓出的只有精度，換回速度：用在網格上取樣的查找表取代逐像素運算，僅此而已。哪一步運算、按什麼順序、用什麼數值，兩邊完全一致。
查找表裝不下的東西
查找表把一個顏色對應到另一個顏色，因此只能承載僅取決於單一像素的調整。凡是必須看鄰近像素的都屬於空間處理——清晰度、去朦朧、銳利化、消除雜訊、暈影、遮色片與顆粒——它們在兩條路徑上都各自單獨跑一遍。
這也是帶好幾個遮色片的預設集在觀景窗裡比較吃效能的原因：每個遮色片都代表每格畫面若干次全畫面 GPU 運算，而它的顏色部分早就免費摺進那張表裡了。
對著 Lightroom 擬合，而不是猜
HSL 的飽和度與明度運算子是對著 Lightroom 自身的輸出擬合出來的，而不是憑對公式的猜測重新實作——在 Lightroom 裡做好的預設集，會落在作者放它的位置上。
確實沒有實作的控制項，引擎會以中性值算圖並且可以據實說明，而不是拿個大致相似的東西頂上。預設集是有人刻意選定的一組數值；悄悄算成另一組，比什麼都不算更糟。
沒有任何東西離開裝置
這裡沒有伺服器。解析、算圖、拍攝與輸出全部在手機上完成，照片直接寫進你的照片圖庫。
如果你登入 Google Drive 或 OneDrive 來取預設集，權杖會存在 iOS 鑰匙圈中，而且只用於讀取 .xmp 檔案。