چرا JPEG XL جای وب نیست
فرانتاند
گوگلخلاصهٔ کاملتر
جانی روساتو که روی فشردهسازی تصویر کار میکنه و قبلاً از JPEG XL برای Interop 2024 حمایت کرده بود، تو یادداشت تازهش موضعش رو عوض کرده. بهانهٔ نوشتن این بوده که یه دیکدر JPEG XL نوشتهشده با Rust داره وارد فایرفاکس و کروم میشه و خیلیها این رو نشونهٔ برگشتن مرورگرها از تصمیم ۲۰۲۳ کروم میدونن. نویسنده میگه امنتر شدن دیکدر بهتنهایی دلیل کافی برای آوردن یه فرمت به وب نیست.
به گفتهٔ نویسنده، وب عملاً با فشردهسازی lossy یعنی فشردهسازی با افت کیفیت سر میکنه و کاربر معمولی سراغ lossless نمیره. برتری lossless این فرمت هم تو عمل حدود ۱۱.۹ درصد نسبت به WebP ـه، اون هم روی دیتاستی که با محتوای واقعی وب جور درنمیاد. پس ۱۲ درصد صرفهجویی روی حجم کمی از تصویرها، ارزش اضافه کردن یه کدک جدید به همهٔ مرورگرها رو نداره.
سر lossy هم نویسنده میگه انکدرهای AVIF مثل libaom و SVT-AV1 حالا تیونینگ ادراکی دارن و متریکهای قویای مثل SSIMULACRA2 و CVVDP تصویر خوبی از libjxl نشون نمیدن. دلیل فنیش رو هم میشمره: JPEG XL حالتهای پیشبینی جهتدار نداره، یعنی نمیتونه پیکسلهای یه بلوک رو از روی بلوکهای کناری حدس بزنه و فقط تفاضل رو کد کنه، که همین برای حفظ لبهها مهمه.
بقیهٔ ایرادهای فنی هم به گفتهٔ نویسنده کم نیستن. این فرمت فیلتر deblocking تو حلقه نداره و gaborish و EPF جایگزین کاملش نیستن، فضای رنگ ادراکی XYB ـش تو libjxl کانال B رو زیادی کوانتیزه میکنه و رنگها آسیب میبینن، و برای تصویرهای غیرعکاسی راهحلش یعنی patches خیلی گرونتر از IntraBC توی AV1 درمیاد چون باید هدر فریم و اطلاعات blend و دیکشنری پچ رو هم بفرستی.
بخش سنگین بحث دربارهٔ زمان دیکده. تو تست نویسنده با تصویرهای همحجم، WebP با اینکه بیشتر از ۹۰ کیلوبایت بزرگتر بود، بیشتر از ۱۰ برابر سریعتر از jxl-rs دیکد شد. رندر تدریجی هم که یه زمانی برگ برندهٔ JXL بود، حالا AVIF زودتر و با فقط ۲ تا ۳ درصد حجم فایل یه تصویر قابلاستفاده نشون میده. بازفشردهسازی JPEG هم حدود ۲۰ درصد حجم کم میکنه ولی دیکد رو حدود ۳۳ درصد کند میکنه.
نویسنده یه ریسک امنیتی هم مطرح میکنه: چون فرمت خیلی بیانگره، میشه فایلهای ریزی ساخت که دیکدشون ثانیهها طول بکشه. نمونهای که آورده فقط ۱۹۱۸ بایته و روی M5 Pro حدود ۱۷.۴ ثانیه وقت CPU میگیره. جمعبندی نویسنده اینه که کدکهای وب باید محدود و هدفمند باشن، و JPEG XL که قراره همهکاره باشه بیرون از مرورگر، جاهایی مثل ابزارهای حرفهای و دوربینها، آیندهٔ بهتری داره.
نکات کلیدی:
- برتری lossless این فرمت نسبت به WebP حدود ۱۱.۹ درصده، اون هم روی دیتاستی که نمایندهٔ محتوای وب نیست
- JPEG XL نه پیشبینی جهتدار داره نه فیلتر deblocking؛ gaborish و EPF جایگزین کاملش نیستن
- تو تست همحجم، WebP بیشتر از ۱۰ برابر سریعتر از دیکدر jxl-rs دیکد شد
- بازفشردهسازی JPEG حدود ۲۰ درصد حجم کم میکنه ولی دیکد رو حدود ۳۳ درصد کند میکنه
- یه فایل JXL فقط ۱۹۱۸ بایتی میتونه حدود ۱۷.۴ ثانیه وقت CPU برای دیکد بگیره
- هم JPEG XL و هم AVIF بدون حق امتیاز هستن و JPEG XL هم اصلش از Cloudinary و گوگل اومده
