JPEG XL 與 Rust 影像生態解析

對於熱愛攝影的朋友來說，硬碟空間與畫質妥協永遠是一場停不下來的拉鋸戰。

每次週末帶著相機出門拍照，回家把記憶卡插上電腦，動輒幾十 GB 的 RAW 檔就這樣倒進硬碟。一張 3,000 萬到 6,000 萬畫素的相機 RAW 原檔（像是 Sony 的 ARW、Nikon 的 NEF 或 Canon 的 CR3，即使開啟無損壓縮），單張體積依然落在 40MB 到 80MB 上下。為了長久保存，我們捨不得刪除 RAW 檔；但如果要把照片整理、出圖、分享到 Instagram 或是放上個人作品集網站，我們又往往得退回有三十多年歷史的老舊 JPEG 格式。

偏偏傳統 JPEG 的限制在現代螢幕上顯得格外刺眼：只有 8-bit 色深、缺乏原生 HDR 支援、在日落晨霧中頻頻出現的階調斷層（color banding），以及將暗部細節壓得七零八落的塊狀偽影（blocking artifacts）。雖然近年來 Google 推出了向後相容的 Ultra HDR 格式（這也是我先前用 Rust 開發圖片切割工具 TileSplit 的起因），但那畢竟是在老舊容器上打補丁的過渡方案。

難道在肥大的 RAW 原檔與打補丁的老 JPEG 之間，就沒有一個從底層重新設計、兼顧極致畫質、原生高動態範圍與合理壓縮率的現代解答嗎？

這正是 JPEG XL 格式（.jxl）當初被寄予厚望的核心使命。更有趣的是，JPEG XL 從 2022 年底一度被 Google Chromium 移除的低谷，一路走到 2026 年獲 Chrome 155 與 Firefox 158 正式採納並預設啟用的戲劇性復活，背後最關鍵的推手之一正是 Rust 語言。今天我們就從業餘攝影玩家與工具開發者的雙重視角出發，深入探討 JPEG XL 的技術特性，將它與 Ultra HDR、AVIF、HEIC、WebP 放在同一個天平上客觀比較，並看看 Rust 如何改變現代影像處理的生態。

攝影人的兩難：RAW 檔太沉重，傳統 JPEG 又太殘缺

只要玩過一陣子攝影，通常都會建立一套固定的照片歸檔流程：

1. 「拍攝與匯入」：相機設定 RAW（或 RAW + JPEG），保留感光元件記錄下的 14-bit 完整寬容度。
2. 「數位暗房修圖」：在 Lightroom、Capture One 或 darktable 中拉亮陰影、壓制高光、校正白平衡並調整色彩風格。
3. 「出圖與典藏」：匯出 JPEG 用於社群分享或相簿檢視，RAW 檔則封存進 NAS 或外接冷儲存硬碟。

問題往往出在第三步。當我們在配備 Liquid Retina XDR 或 OLED 廣色域螢幕的手機與筆電上看圖時，傳統 8-bit JPEG 的致命缺點完全無所遁形：

• 「8-bit 色深的階調斷層」：每個色彩通道只有 256 階。當拍攝大面積平滑漸層（如無雲藍天、夕陽暮光、棚拍單色背景）時，天空會碎裂成一圈一圈難看的等高線。
• 「高動態範圍缺席」：現在主流手機與筆電螢幕的峰值亮度動輒衝上 1000 到 2000 nits，但標準 JPEG 規格原生為傳統 SDR（標準動態範圍）設計。即便後製時透過色調映射（tone mapping）壓縮高光以保留階調，在缺乏高動態範圍呈現能力的傳統輸出下，陽光通透感與真實輝度依舊無法被完整還原。
• 「高頻自然紋理遭到扼殺」：傳統 JPEG 採用固定的 8x8 離散餘弦變換（DCT），對照片中的微細毛髮、鳥類羽毛、織物纖維或底片雜訊非常不友善，容易在邊緣產生蚊狀雜訊（mosquito noise）。
• 「歷史典藏的儲存重擔」：累積了十幾年的數萬張旅行與生活 JPEG 照片，動輒佔據數百 GB 甚至數 TB 的空間，卻無法在不破壞畫質的前提下重新壓縮。

過渡期的聰明折衷：Ultra HDR 與我開發 TileSplit 的踩坑體悟

在進入次世代格式之前，不得不提目前在 Android 生態與 Instagram 上相當流行的折衷方案，也就是 Ultra HDR 格式（其 gain map 核心技術與中繼資料後續已進一步由 ISO 21496-1 標準化）。

傳統的純 HDR 格式（像 10-bit HEIF 或 AVIF）在舊螢幕或不支援 HDR 的軟體上打開時，常常會因為色調映射（tone mapping）不一致而顯得顏色怪異或整張過暗。Google 在 Android 14 引入的 Ultra HDR 用了一個頗聰明的雙層結構來解決向後相容問題：

1. 「SDR 基礎主圖」：外層本質上就是一張完全合法的 8-bit 傳統 JPEG，任何老舊軟體都能正常打開顯示。
2. 「Gain Map 增益圖」：透過 JPEG 的 MPF（Multi-Picture Format，APP2 區段）在檔案尾端封裝第二張較小的 JPEG（通常是 1/4 解析度），搭配 XMP metadata 或 ISO 21496-1 metadata（記載 hdrgm 相關增益範圍與伽瑪參數），指示系統每個區域對應的亮度增益倍率。
3. 「動態合成」：在支援 HDR 的螢幕上，看圖軟體會把 SDR 主圖乘上 gain map 的指數增益，即時還原出耀眼的高光細節。

從 TileSplit 看雙層修補架構的先天包袱

老實說，Ultra HDR 在社群分享上真的頗好用。我平常很喜歡把 3:2 的橫幅風景照裁切並對半切成符合社群比例的直幅圖（例如切出兩張 3:4 或微幅裁切為 4:5），發到 Instagram 上做「無縫滑動（seamless carousel）」展示。但之前我發現，市面上幾乎所有切圖工具在裁切照片時，根本不知道 gain map 的存在，切完只留下 8-bit SDR 主圖，原本在螢幕上閃閃發光的 HDR 層次感瞬間消失。

為此，我動手用 Rust 寫了 tilesplit（以及可以直接在瀏覽器裡跑的 TileSplit WASM 版），專門在裁切圖片時同步剖析、切割並重新組裝 Ultra HDR 容器。但也正是因為親手寫過這套工具，我深刻體會到「在 30 年前的 JPEG 容器上硬塞 HDR」有多麼脆弱與繁瑣：

• 「雙層解析度不同步的幾何誤差」：因為 gain map 解析度通常只有主圖的 1/4，裁切時不能直接套用主圖座標，必須用無損整數除法與無條件進位（ceiling division）精確映射兩層座標，否則切出來的照片會發生高光位置偏移的靈異現象。
• 「二進位容器的偏移量陷阱」：MPF APP2 標頭裡的影像偏移量必須相對於內部的 TIFF header（mpf_marker_offset + 8），而不是檔案開頭。當時我使用的第三方 Rust 移植庫 jpegli-rs 的 .add_gainmap() 就把偏移量寫成絕對偏移，害我得自己手刻二進位容器組裝邏輯。
• 「XMP metadata 的分裂問題」：有些看圖軟體讀主圖的 XMP，有些（像 Android Google Photos 與 Chrome）則堅持從副圖 gain map 自己的 XMP 讀取，而且還挑剔屬性寫法與 rdf:Seq 標籤格式。
• 「指數放大的量化誤差」：在較大動態範圍增益下，gain map 像素值經過指數公式放大後，JPEG 的微小量化失真可能會在最終高光處被放大。雖然 Android 官方建議 gain map 品質可從 85–90 試起以兼顧容量，但在開發 TileSplit 時，為了確保跨裝置渲染不出現階調瑕疵，我採取了最保守的 Quality 100 高品質編碼策略。

Ultra HDR 確實漂亮地解決了當下社群平台的相容性痛點，但它終究是「用兩張 8-bit JPEG 拼湊出 HDR」的過渡橋樑——底層主圖依然受限於 8-bit 色深與傳統 DCT 架構，每次裁切重編碼也依然會有二次量化失真。

如果我們希望照片從一開始就擁有單一圖層的高色深、無須維護脆弱的 MPF 雙圖偏移量，甚至能無損收納舊有的 JPEG 檔案，那麼 JPEG XL 正是我們真正需要的次世代標準。

JPEG XL 的核心設計與攝影優勢

JPEG XL（ISO/IEC 18181）的前身融合了 Google 的 Pik 專案與 Cloudinary 的 FUIF 演算法（順帶一提，Google 後來發表的 jpegli 高品質 JPEG 編碼技術，正是從 JPEG XL 的心理視覺模型下放而來的副產品）。它從第一天起就不是某個視訊編解碼器的附屬品，而是徹頭徹尾為高階靜態攝影與專業視覺出版量身設計。

先看 codec 的整體資料流：主影像可依需求選擇 VarDCT 或 Modular；即使使用 VarDCT，低頻影像與量化權重等輔助資料仍會透過 Modular 子位元流編碼。既有 JPEG 則可直接沿用 DCT 係數，搭配額外的重建資料保存原始檔案的位元精確還原能力。

圖：JPEG XL codec 高階架構，部分細節省略。圖中容器為選用，也可直接儲存裸 codestream。改繪自 Jon Sneyers 的 JPEG XL codec architecture，採 CC BY-SA 4.0 授權；調整了繁體中文標示、版面與流程說明。技術細節可參考 libjxl 格式概覽。

100% 無失真重壓既有 JPEG：平白省下 20% 儲存空間

如果只能挑一個讓攝影玩家最心動的功能，那絕對是 JPEG XL 的無失真 JPEG 重新封裝（Lossless JPEG Recompression）。

前面在寫 tilesplit 時我就提過，傳統 JPEG 只要經過「解碼成像素 ➔ 重新編碼」，就一定會因為 DCT 量化而產生二次失真（generation loss）。但 JPEG XL 走了一條完全不同的路：

• 它的 VarDCT 模式可以直接讀取傳統 JPEG 檔案中的 DCT 係數。
• 它不需要將像素解碼重算，而是直接將原始 JPEG 的量化係數與中繼資料（包含 EXIF、XMP 與嵌入的二進位區段，包含未解析的 MPF gain map 資料）透過更高壓縮率的非對稱數值系統（ANS，Asymmetric Numeral Systems）熵編碼重新封裝成 .jxl 容器。需要注意的是，這類直接無損轉碼會完整封存原始檔案位元，但傳統以 MPF 封裝的 gain map 仍需支援該專屬結構的解碼器才能在 JXL 容器中作為 HDR 解析。
• 轉碼完成後，檔案體積典型縮小約 16% 至 22%（平均約兩成）。
• 最實用的是，這個過程具備 bit-exact 的完全可逆性！只要你需要，隨時能把 .jxl 還原回與原始檔案完全相同的 JPEG 位元資料（SHA-256 校驗碼完全一致）。

這意味著你可以將硬碟裡的歷史照片整批進行約兩成的無損空間精簡，不損失任何一個像素，同時保留原始檔案的完美復原能力。

VarDCT 與攝影顆粒保真：細緻保留高頻質感

許多攝影同好嘗試用 AVIF 壓縮靜態照片時，常注意到微細紋理在特定設定下容易被平滑化。這是因為 AV1 視訊編解碼器最初專為連續畫面設計，其內建的去區塊濾波器（deblocking filter）在特定 preset 或中低位元率下，傾向將高頻雜訊視為可精簡的失真而進行平滑。在動態影片中這能大幅提升主觀觀感，但在保留底片微粒（film grain）、精緻織物或羽毛紋理的靜態攝影中，若未細緻調校 encoder 參數，常需要更高的編碼位元率或特定參數才能保留自然顆粒。

JPEG XL 的 VarDCT（Variable-block size DCT）專門針對靜態影像特性設計：

• 支援從 4x8、8x4、8x8、16x16 到 32x32（規格甚至涵蓋至 256x256）以及 AFV 非對稱角頻率變換區塊。
• 導入了以人類視覺感知模型為基礎的 Butteraugli 距離度量，深度模擬人眼視網膜對高頻訊號與色彩敏感度的生理反應。
• 在高保真度（high fidelity）下，它能夠精準分配位元給高頻紋理，保留自然的攝影顆粒，而不依賴強制濾波平滑畫面。

原生單層 32-bit 浮點色深與 HDR 廣色域

不同於 Ultra HDR 必須靠「8-bit 主圖 + 8-bit 增益圖」雙層拼裝，JPEG XL 原生單一圖層就支援高達 32-bit 浮點色彩深度：

• 完整支援 Rec.2100、PQ（Perceptual Quantizer）與 HLG（Hybrid Log-Gamma）等 HDR 標準傳輸曲線，並原生涵蓋 Display P3、Adobe RGB 與 Rec.2020 廣色域。
• 裁切或縮放照片時，只需要單純操作單一高色深圖層，再也不必擔心主圖與 gain map 座標對不準或 MPF 指標算錯。
• 同時，如果攝影師希望兼顧 SDR 螢幕顯示並精確掌控色調，JPEG XL 容器標準亦定義了專屬的 jhgm box（包含 ISO 21496-1 gain map metadata、替代色彩資訊與獨立 JXL 編碼流），使單一檔案也能靈活支援雙層動態範圍增益機制。

Modular 模式與響應式漸進載入

除了專為相片打造的 VarDCT，JPEG XL 還內建了 Modular 模式，專門用於完全無失真（Lossless）壓縮、透明度（Alpha）、景深地圖（Depth Map）與局部遮罩。

此外，它的響應式漸進載入（Responsive Progressive Decoding）經過現代化設計：根據 Mozilla 的實測展示，檔案僅需載入約 15% 的資料量即可清楚辨識畫面主體與構圖，載入約 40% 至 50% 時就能呈現接近完整的視覺解析度，相較於常見預設未啟用分層漸進的 AVIF 檔案在一般網頁載入時的體驗，JPEG XL 的漸進解碼對大圖展示非常友善。

五大影像格式全方位比較

為了讓大家在整理與發布照片時有清晰的判斷依據，我們將 JPEG XL、Ultra HDR、AVIF、HEIF 與 WebP 這五大格式拉到業餘攝影的實戰天平上逐項檢視：

為什麼 AVIF 與 HEIC 在攝影工作流中各有取捨？

• 「AVIF 的特質與門檻」：在極低位元率的網頁縮圖上，AVIF 壓縮率相當亮眼。但對高傳真攝影來說，AVIF 在中高畫質設定下若未細緻調整參數，容易平滑微細紋理；此外其軟體編碼器（如 rav1e、libaom）在高畫質多執行緒編碼時相當耗費 CPU 資源，修完數百張照片批次匯出時需花費較長的運算時間。
• 「HEIC 的授權複雜度」：許多主流相機與智慧型手機雖然都支援拍攝 10-bit HEIC，但因為背後的 HEVC 專利池（MPEG LA、HEVC Advance 等）授權結構複雜，導致非特定生態系的瀏覽器與作業系統支援受限，在跨平台展示與開源工具鏈整合上門檻較高。

為什麼 Rust 是促成 JPEG XL 逆轉與現代工具鏈的關鍵

如果你在 2023 或 2024 年關注過 JPEG XL，一定記得當時令人扼腕的僵局：Google Chromium 團隊在 2022 年底的 M110 版本中，突然移除了實驗性的 JPEG XL 支援；而 Mozilla Firefox 雖然保留了實驗旗標，卻也遲遲不願預設開啟。

為什麼技術指標領先的 JPEG XL，當時在瀏覽器整合上遇到阻礙？2022 年底 Chromium 團隊在評估時，考量了生態系採用度、新增編解碼器的維護成本與既有格式的邊際效益而暫緩；而 Mozilla 則對引入龐大 C/C++ 程式碼至安全敏感的解碼管線抱持審慎態度。要在維持極致效能的同時大幅降低資安防護成本，關鍵鑰匙正是 Rust 語言。

影像解碼管線的資安考量與系統挑戰

從系統軟體工程的角度來看，瀏覽器裡的影像解碼器是極為關鍵的攻擊表面（attack surface）：

1. 「直接暴露於不可信輸入」：瀏覽器的渲染行程必須下載並解析完全不可信的外部二進位圖片位元流。
2. 「記憶體安全風險」：傳統參考解碼器 libjxl 是由約 10 萬行高度複雜的多執行緒 C++ 程式碼寫成。解析惡意構造的標頭時，若發生整數溢位或邊界檢查疏漏，即使渲染行程具備沙盒隔離，仍可能成為漏洞利用鏈的第一步。

最顯著的案例之一就是 2023 年的 CVE-2023-4863 漏洞（WebP 堆積緩衝區溢位），凸顯了在複雜二進位多媒體解碼中維持安全性的難度。

這一點我自己開發 tilesplit 時也深有體會：

• 在 CLI 版本中，我使用了封裝 Google C++ libultrahdr 的 ultrahdr-rs 以及 jpegli-rs。遇到某些格式異常的 JPEG 時，解碼過程可能會觸發 Rust 的 panic。為了防範工具中斷，我不得不使用 catch_unwind 來捕捉 unwinding panic（需要說明的是，catch_unwind 僅能捕捉 Rust 的 panic，無法攔截一般 C/C++ 的未定義行為或程式異常終止）。
• 更麻煩的是，當我準備開發 TileSplit WASM 版 把切圖工具搬進瀏覽器時，依賴 C/C++ FFI 的 ultrahdr-rs 在 wasm32-unknown-unknown 目標下遇到編譯瓶頸。最後我是換成純 Rust 實作的 image 與 ultrahdr-core crate，才順利做到零外部 C 依賴、安全編譯進瀏覽器直接執行。

主流瀏覽器團隊為此推行了嚴謹的安全邊界策略（例如 Chromium 的「Rule of Two」原則：在不可信任輸入、無沙盒環境與非記憶體安全語言三者中，最多只能同時存在兩者）。這使得以純記憶體安全語言重新實作新解碼器，成為進入主流瀏覽器的最高優先路徑。

Mozilla 的「Rust 挑戰」與 Google Research 的 jxl-rs

正如 Mozilla 在 Intent to Ship: JPEG XL 中所回顧的，當時 Mozilla 團隊直接向 Google Research 的 JPEG XL 團隊拋出了一道明確的戰帖：

“So, we laid down a challenge to the JPEG XL team at Google Research: Build a safe, performant, compact, and compatible JPEG XL decoder in Rust, and we’ll ship it.” （我們向 Google Research 的 JPEG XL 團隊下了一道戰帖：只要用 Rust 打造出一個安全、高效、精巧且相容的 JPEG XL 解碼器，我們就正式出貨。）

與此同時，Apple 在 2023 年 9 月透過 Safari 17（涵蓋 iOS 17 以及 macOS Sonoma、Ventura、Monterey）率先支援了 JPEG XL（儘管初期屬於部分實作，尚未包含漸進式渲染），加上 PDF 國際標準組織將 JPEG XL 列為 HDR PDF 的首選影像格式，開發者與攝影社群要求恢復支援的呼聲達到頂峰。

為了回應 Mozilla 的戰帖與瀏覽器資安團隊的要求，Google Research 的 JPEG XL 團隊親自出手，啟動了官方純 Rust 解碼器專案：jxl-rs。

• 「大幅降低記憶體安全漏洞風險」：jxl-rs 以 Rust 重新打造符合標準規範的 JPEG XL 解碼核心，從語言層級避免緩衝區溢位、野指標與資料競爭等常見漏洞，並透過強大的型別系統提高解碼器容錯能力。
• 「高度向量化效能」：針對現代瀏覽器環境高度最佳化，兼顧二進位體積與 SIMD 多核心解碼吞吐量。

三大主流瀏覽器引擎全數到位

隨著 jxl-rs 的成熟，瀏覽器版圖在 2025 年底至 2026 年迎來了戲劇性的翻盤：

1. 「Chromium 與 Chrome 155 回歸」：Chrome 團隊於 2025 年底正式接納以記憶體安全為前提的回歸提案，改為直接整合純 Rust 的 jxl-rs 解碼器，並在 2026 年 10 月釋出的 Chrome 155 中正式重返舞台。
2. 「Firefox 158 兌現承諾」：Mozilla 將 jxl-rs 整合進 Firefox 引擎中，並特別針對漸進式渲染深度調校，於 Firefox 158 正式預設啟用靜態圖片解碼（HDR 相關顯示管線項目亦在持續完善中）。
3. 「Safari 持續支援」：加上早已在 iOS、iPadOS 與 macOS 原生支援的 Apple 生態系，三大主流瀏覽器引擎已全數支援 JPEG XL 基本解碼！

這不僅是 JPEG XL 的勝利，更是系統程式設計史上的一座里程碑，證明 Rust 已經正式成為現代網路多媒體標準能否進入主流瀏覽器的安全守門人。

蓬勃發展的純 Rust 社群影像生態：jxl-oxide 與 zune-image

除了瀏覽器內建的官方 jxl-rs 之外，如果你也像我一樣喜歡用 Rust 寫點影像處理小工具，開源 Rust 社群也建立起相當豐富的純 Rust 原生工具鏈：

• jxl-oxide：由社群獨立開發的純 Rust JPEG XL 解碼器，完整支援 VarDCT、Modular 與色彩管理（可選用純 Rust 的 moxcms 或 C 依賴的 lcms2），並與 Rust 最核心的 image-rs 生態系深度整合，編譯成 WASM 放上網頁也十分順暢。
• zune-image：專注於極致速度的純 Rust 影像處理管線，旗下多個主流編解碼器善用 AVX2 與 ARM NEON 向量指令集，並包含輕量級的 zune-jpegxl 無損 Modular 編碼實作。

需要指出的是，雖然 jxl-rs 是由 JPEG XL 官方專案主導的 Rust 解碼器，但 ISO 標準的官方參考軟體（reference software）仍為 C++ 的 libjxl。不過在個人伺服器、相片管理平台或本地看圖工具等場景中，純 Rust 函式庫能有效防範記憶體損毀漏洞，在維持多核心高效能的同時帶來極佳的系統穩定性。

給業餘攝影玩家的實用工作流程建議

站在 2026 年的時間點，面對 RAW、JPEG XL 與 Ultra HDR，我們在日常拍照與分享時該怎麼搭配最聰明？以下是我目前自己的實戰配置：

原始底片：RAW 檔維持 3-2-1 備份

無論壓縮技術如何進步，千萬不要因為新格式的出現而刪除重要的 RAW 原檔。RAW 檔是感光元件未經烹調的完整紀錄，建議對精選後的 RAW 原檔維持嚴謹的 3-2-1 備份原則（本機工作碟、NAS 陣列、異地冷備份）。

歷史相簿瘦身：用 JPEG XL 無失真重壓精簡儲存空間

如果你硬碟或 NAS 裡躺著過去累積的傳統 JPEG 相片（早期數位相機照片、親友分享照片、或是過去匯出的 JPEG 成品）：

• 使用官方 cjxl 工具執行無失真重壓縮（對 JPEG 輸入而言，無損重壓本來就是 cjxl 的預設行為，加上 --lossless_jpeg=1 則是明確宣示意圖）：

  # 將傳統 JPEG 無損轉為 JXL，體積典型可節省約 16%–22%
  cjxl legacy-photo.jpg archived-photo.jxl --lossless_jpeg=1
  
  # 若未來需要原始檔案，可 100% 位元精確還原回原本的 JPEG
  djxl archived-photo.jxl restored-photo.jpg

• 建議在批次處理後，透過比對還原前後檔案的 SHA-256 校驗碼確認一致，並確認備份妥當後再行清理來源檔案。

社群平台分享（Instagram / Threads）：出圖選 Ultra HDR + TileSplit

如果你的目標是把修好的風景或街拍照發上 Instagram，享受動態牆上閃耀的 HDR 視覺衝擊力：

• 在 Lightroom 開啟 HDR 編輯模式，匯出時選擇 JPEG 並勾選「包含 HDR 增益圖」（Ultra HDR）。
• 如果你想把 3:2 橫幅大景切成無縫滑動的直幅多圖貼文，千萬別用一般不認識 Gain Map 的裁切軟體；可以直接使用我寫的 tilesplit CLI 或直接打開線上版 TileSplit WASM 網頁工具 拖拉切圖，把每一格切片的 Ultra HDR 亮度資訊完整保留下來。

個人作品集與長期成品典藏：採用 16-bit HDR JPEG XL

如果是要放進個人作品集網站、部落格藝廊，或是留作高畫質成品典藏：

• 在 Lightroom 或 darktable 匯出時選擇 JPEG XL 格式（.jxl），設定 16-bit 色深與 Display P3 / Rec.2020 廣色域（需搭配 HDR 輸出特性設定與支援螢幕以呈現高動態範圍）。
• 隨著 Safari、Chrome 155 與 Firefox 158（透過 jxl-rs）全數到位，網頁端可以透過 <picture> 標籤嘗試優先提供 .jxl，並以 Ultra HDR .jpg 作為向後相容的備案：

<picture>
  <!-- 支援 JPEG XL 的瀏覽器 (Safari / Chrome 155+ / Firefox 158+) -->
  <source srcset="landscape-hdr.jxl" type="image/jxl">
  
  <!-- 向後相容備案：支援 Ultra HDR 的環境顯示 gain map HDR，舊設備顯示 SDR -->
  <img src="landscape-ultrahdr.jpg" alt="合歡山日出雲海" loading="lazy">
</picture>

需要說明的是，<source type="image/jxl"> 僅會依瀏覽器是否具備 JXL 格式解碼能力來挑選，無法自動偵測螢幕與瀏覽器是否已完整支援該檔案的 HDR 顯示管線（例如部分環境可能先以 SDR 渲染 JXL，而不會跳過它去讀取 fallback 的 Ultra HDR）。在現階段實務應用中，若最看重廣泛設備上的 HDR 亮度衝擊力，Ultra HDR 仍是相容性最高的選擇；而 JPEG XL 則是畫質與典藏的理想基石。

結語

科技的演進，最終都是為了忠實傳遞創作者眼中的感動。

身為業餘攝影愛好者，我們頂著清晨的寒風在山上等待第一道曙光，或是走在異國街頭耐心捕捉光影交錯的瞬間，無非是希望將按下快門那一刻的色彩、空氣感與光線張力完整保存下來。從我們為了發 Instagram 而折騰 Ultra HDR 的雙層 Gain Map 容器，到見證 JPEG XL 憑藉原生高色深、自然顆粒保真與無損轉碼成為真正的次世代主力，這段演進過程實在相當迷人。

更令人欣慰的是，當 JPEG XL 一度因為傳統 C++ 解碼器的資安包袱而在瀏覽器戰場受挫時，是 Rust 語言與 jxl-rs 挺身而出，以記憶體安全為基石打破了僵局，讓攝影愛好者與系統開發者同時迎來了最好的時代。下次整理完記憶卡裡的照片，不妨親自試試這套結合 JPEG XL 與 Ultra HDR 的現代工作流吧 :-)