فرمت تصویر نسل بعدی برای وب JPEG XL نیست؟

من دیر به مهمانی اینجا رسیده‌ام، اما به نظر می‌رسد گوگل رای خود را به آنچه می‌خواهند به عنوان فرمت تصویر بعدی که به طور گسترده برای وب مورد قبول قرار گرفته است، داده است. این است نه JPEG XL.

فرمت جنگ ها

اگر با جدیدترین فرمت های تصویر آشنا نیستید، 3.5 رقیب برای قلب و ذهن زندگی حساس در جهان وجود دارد:

AVIF و HEIC از video-land می آیند، آنها فرمت های مشتق شده از مشخصات ویدیویی هستند. JPEG XL به عنوان یک فرمت تصویر کامل ایجاد شد. WebP v2 نسخه جدیدی از WebP است، اما به نظر می رسد در حال حاضر کاملاً آزمایشی باشد.

در طول تاریخ، ممکن است فرد برنده باشد فرمت جنگ ها، لزوماً “بهترین” قالب برنده نیست. به نظر می رسد حداقل یک بار در دهه یک مسابقه فرمت رسانه ای وجود دارد:

• در دهه 1970، فرمت های نوار ویدئویی آنالوگ بود: JVC VHS در مقابل Sony Betamax در مقابل Philips Video 2000.
• در دهه 1990، این کاست‌های دیجیتال بودند: کاست فشرده دیجیتال فیلیپس (DCC) در مقابل MiniDisc سونی (MD).
• در دهه 2000، فرمت‌های دیسک نوری با کیفیت بالا بود: دیسک بلوری در مقابل دی‌وی‌دی HD.
• در سال 2010، این فرمت‌های ویدئویی دیجیتال بود: H.264 در مقابل H.265 (استانداردهای ثبت شده که نیاز به پرداخت حق امتیاز دارند) در مقابل جایگزین‌های بدون حق امتیاز مانند VP8، VP9، و Theora بود که تلاش کردند از نقض حق اختراع جلوگیری کنند.

این رقابت‌ها تماشای گیشه نیستند، اما اگر در داستان‌ها فرو بروید، درک نیروهایی که دنیای اطراف ما را شکل می‌دهند می‌تواند روشن‌کننده باشد.

با بازگشت به داستان گوگل، گوگل فرمت AVIF را بدون پرچم به کروم نسخه 85 در آگوست 2020 اضافه کرد. بعداً، JPEG XL به عنوان یک ویژگی آزمایشی در می 2021 به نسخه 91 کروم معرفی شد. عجیب است که AVIF مستقیماً به عنوان یک ویژگی وارد شد، اما JPEG XL آزمایشی بود!

در 30 اکتبر 2022، گوگل اعلام کرد که JPEG XL را به دلایل زیر از کروم حذف خواهد کرد:

از همه برای نظرات و بازخورد شما در مورد JPEG XL سپاسگزاریم. به دلایل زیر کد و پرچم JPEG XL را از Chromium حذف خواهیم کرد:

– پرچم ها و کدهای آزمایشی نباید به طور نامحدود باقی بمانند
– علاقه کافی از کل اکوسیستم برای ادامه آزمایش با JPEG XL وجود ندارد
– فرمت تصویر جدید مزایای افزایشی کافی را نسبت به فرمت‌های موجود به ارمغان نمی‌آورد تا فعال کردن آن به‌طور پیش‌فرض را تضمین کند.
– با حذف پرچم و کد موجود در M110، بار تعمیر و نگهداری را کاهش می دهد و به ما امکان می دهد روی بهبود فرمت های موجود در کروم تمرکز کنیم.

برخی از کلمات کوتاه با حروف صدادار گسترده با آب در گوشه‌های وب به حرکت درآمدند. سپس در ژانویه 2023، JPEG XL در نسخه 109 کروم حذف شد.

کلودیناری برخی از افکار خود را در مورد دلایل گوگل برای حذف پشتیبانی منتشر کرد:

اولین عبارت منطقی است، اما بسیاری از مردم انتظار داشتند که با فعال کردن ویژگی به طور پیش فرض حل شود، نه با حذف کامل ویژگی. این به هیچ وجه این تصمیم را توجیه نمی کند.

در مورد نکته دوم: سوال این است که آیا و چگونه منافع اکوسیستم سنجیده شده است؟ از آنجایی که این ویژگی پشت یک پرچم قفل شده است، بدیهی است که هرگونه استقرار واقعی مسدود شده است – ویژگی‌های غیرفعال شده به‌طور پیش‌فرض را می‌توان برای آزمایش استفاده کرد، اما نه برای استقرار واقعی، زیرا اکثر کاربران نهایی پرچم را فعال نخواهند کرد. بنابراین آمار استفاده معناداری برای بررسی وجود ندارد.

با این حال، اگر پشتیبانی مشتاقانه در ردیاب باگ کرومیوم از فیس‌بوک، ادوبی، اینتل و VESA، Krita، The Guardian، libvips، Cloudinary و Shopify نشانه‌ای باشد، به نظر می‌رسد گیج کننده است نتیجه گیری شود که علاقه اکوسیستم کافی وجود ندارد.

این ما را به سومین و شاید مهم ترین نکته می رساند: “مزایای افزایشی کافی نسبت به فرمت های موجود وجود ندارد.”

البته «عدم کفایت» یک معیار نسبتاً مبهم است، اگر مشخص نشده باشد که آستانه کافی تلقی شدن منفعت چقدر است. در این پست وبلاگ نگاهی دقیق‌تر به مزایای آن خواهیم داشت و سپس می‌توانید خودتان قضاوت کنید که آیا آنها “کافی” هستند یا خیر.

متوجه شدید، استدلال‌های مخالف زیادی وجود دارد. می توانید مقاله Cloudinary را بخوانید تا کیس آنها را برای JPEG XL ببینید.

Cloudinary با توجه به JPEG XL مغرضانه است زیرا فرمت تصویری است که ورودی قابل توجهی در آن داشته است. به اندازه کافی عجیب، گوگل در هر دو مشخصات AVIF و JPEG XL مشارکت داشت.

CNET موضوع را به صورت خلاصه بیان کرد:

گوگل یک قالب رقیب را دوست دارد که به توسعه آن کمک کرده است، AVIF. اما JPEG XL مزایایی دارد که عکاسان ممکن است از آنها استقبال کنند و این اختلاف می تواند به این معنی باشد که ما برای مدت طولانی تری با JPEG ساده قدیمی گیر کرده ایم.

اپل در گذشته نیز ترجیح داده بود. این اولین پذیرنده HEIC بود، HEIC از زمان macOS 10.13 High Sierra و iOS 11 به صورت بومی در دستگاه های اپل پشتیبانی می شود تا ظاهراً فضای ذخیره سازی دستگاه را حفظ کند. اما به سافاری اضافه نشد.

به نظر می رسد که فرمت های مشتق شده از ویدیو بر قالب های تصویری برای تصاویر در وب ترجیح داده می شوند. WebP همچنین از یک فرمت ویدئویی، VP8 پدید آمد. فرمت‌های تصویر بهبود یافته‌ای که در گذشته پیشنهاد شده‌اند به سختی به وب راه یافته‌اند: JPEG 2000 و JPEG XR. بزرگ‌ترین مانع در مورد JPEG 2000 این بود که تصور می‌شد حق ثبت اختراع در آن وجود دارد.

من تمام محاسن و معایب فرمت ها را نمی دانم و اگر بهترین قالب موفق شد و اکنون موفق شده است. به نظر من دوگانگی در استفاده وجود دارد – عکاسان تصاویر با کیفیت عالی و پردازش سریع را می خواهند، در حالی که وب به فشرده سازی بهینه و تصاویر متحرک می خواهد. مثل این است که آنها باندهای رقیب هستند که نمی خواهند از مسیرها عبور کنند. من یکی از اعضای بی میل هر دو باند هستم!

رویای یک قالب جهانی

فقط تعجب می کنم، در سال 2023، چرا نمی توانم با فرمتی که فشرده سازی خوبی دارد و توسط مرورگرهای وب پشتیبانی می شود، با دوربینم عکس بگیرم؟ من می توانم یک عکس را در اینترنت آپلود کنم و آن را در یک صفحه وب بدون رمزگذاری نشان دهم.

کاپیتان سیاره نمی‌تواند با این همه وات رمزگشایی در اینجا، آنجا و همه جا خوشحال باشد!

یا ذخیره بایت بهتر است؟ 😖

به نظر من WebP موفق شد زیرا ویژگی های فرمت های موجود مانند شفافیت و انیمیشن را همراه با فشرده سازی برتر ارائه داد. روایت در نهایت در مورد عملکرد بود – همان را به من بدهید، اما با فایل های کوچکتر.

به عنوان توسعه دهندگان وب، از نظر تئوری کار مهمی نبود. ما می توانیم یک فرمت تصویر جدید را به عنوان یک پیشرفت پیشرونده در نظر بگیریم. ما می توانیم استفاده کنیم picture عنصر، اضافه کردن یک source برای نسخه WebP تصویر، و الف source برای یک JPEG یا PNG از یک تصویر. اگر مرورگر از WebP پشتیبانی نکند، به فرمت دیگر باز می گردد. آسان. IPSO FACTO.

<picture>
  <source srcset="photo.avif" type="image/avif" />
  <source srcset="photo.webp" type="image/webp" />
  <img src="photo.jpg" alt="this is a photo that I just took....not" />
</picture>

البته برای این کار باید نسخه های مختلفی از یک تصویر تولید کنید. به هر حال شما یک فرآیند ساخت دارید، اینطور نیست؟ 😥

این تنها بخشی از داستان است، کار با تصاویر در طراحی وب ریسپانسیو کمی دردسرساز است. دلیلی وجود دارد که CDN های تصویری مانند Cloudinary افزایش یافته است!

من باید بیشتر در مورد آن تحقیق کنم، اما به نظر می رسد که مزایای AVIF نسبت به WebP این است:

• فشرده سازی برتر،

• پشتیبانی از HDR،

• عمق بیت رنگ بیشتر (WebP 8 بیتی است، در حالی که AVIF دارای عمق رنگ 8، 10 و 12 بیتی است).

جیک آرچیبالد در سال 2020 یک شیرجه عمیق در AVIF انجام داد. او پیشرفت های ارائه شده توسط AVIF را بر اساس موارد استفاده مختلف از JPEG، PNG و WebP نشان داد. بر روی کیفیت نسبی تصویر و اندازه فایل متمرکز شد. او چند دموی زنده برای نمایش تصاویر در کنار هم دارد.

دیدن مقایسه مشابه AVIF و HEIC و JPEG XL و WebP عالی خواهد بود. این نوع مقایسه را حتی می‌توان در مرورگر انجام داد، جیک از یک جزء Preact برای مدیریت بارگذاری و رمزگشایی تصویر برای دموهای خود استفاده کرد، به طوری که AVIF و WebP حتی بدون پشتیبانی مرورگر کار می‌کنند. شما می توانید این را تمدید کنید من حدس می زنم؟

جیک در مورد JPEG XL گفت:

JPEG-XL یک فرمت تصویری است، نه یک فرمت ویدئویی. این فشرده سازی بدون اتلاف و اتلاف و رندر چند گذری پیشرونده را پشتیبانی می کند. به نظر می رسد فشرده سازی بدون اتلاف بهتر از WebP باشد که عالی است. با این حال، فشرده سازی با اتلاف برای کیفیت بالا به جای «کیفیت قابل قبول» تنظیم شده است، بنابراین ممکن است برای اکثر تصاویر وب مناسب نباشد. اما، مزیت رندر چند پاسی ممکن است به این معنی باشد که در مورد اندازه فایل ارزش آن را دارد. حدس می زنم صبر کنیم و ببینیم!

آیا این فرصت از بین رفته است تا ببینیم JPEG XL چگونه است؟

تعجب می کنم – آیا هر یک از AVIF، HEIC، و JPEG XL می تواند به فرمت جهانی تبدیل شود؟

تنها موردی که این مورد را به عنوان یک احتمال ذکر می کند JPEG XL است. خیلی خوب خواهد بود که این اتفاق بیفتد.

آیا ما نیاز به ارزیابی مجدد تصاویر در وب داریم؟

با ظهور پرس و جوهای کانتینر، ممکن است نیاز به ارزیابی مجدد داشته باشیم. جیسون گریبسی اخیراً مقاله جالبی در این زمینه با عنوان در مورد پرس و جوهای کانتینر، تصاویر پاسخگو و JPEG-XL نوشته است، جیسون می گوید:

مدت‌ها قبل از اینکه به نحوی تصاویر واکنش‌گرا بپردازیم، بسیاری از بحث‌های ما ناگزیر به ایده قالب تصویر جادویی می‌شد که شامل تمام وضوح‌های مورد نیاز ما باشد. آنقدرها هم که به نظر می رسد دور از ذهن نیست. در آن زمان، JPEG-2000 این قابلیت را داشت که “تصاویر را با وضوح و اندازه های مختلف از یک فایل تصویر نمایش دهد.”

اما رویاهای یک قالب تصویر جام مقدس به جایی نرسید. شایعه شده بود که JPEG-2000 دارای حق ثبت اختراع است و ما هیچ قالب دیگری در افق نداشتیم که مزایای مشابهی را ارائه دهد.

می توان گفت، بزرگترین چالشی که در وهله اول منجر به استاندارد تصاویر واکنش گرا شد، دانلود گمانه زنی تصاویر توسط مرورگر بود. جیسون آن را چنین توصیف می کند:

هنگامی که مرورگر برای اولین بار یک سند HTML را دریافت می کند، قبل از اینکه DOM را بسازد، و مدت ها قبل از اینکه طرح بندی را محاسبه کند، ویژگی به نام پیش تجزیه کننده پیش بینی سند را اسکن می کند و به دنبال دارایی هایی است که می تواند دانلود را شروع کند. این رفتار دانلود گمانه‌زنی نامیده می‌شود زیرا مرورگر نمی‌تواند مطمئن باشد که دارایی‌هایی که دانلود می‌کند استفاده می‌شوند.

اما شروع اولیه برای دانلود دارایی ها، حتی اگر برخی از موارد به اشتباه دانلود شوند، تأثیر قابل توجهی در عملکرد صفحه وب دارد. اندی دیویس گزارش می دهد، “در طول اجرای آنها، موزیلا 19٪ بهبود در زمان بارگذاری گزارش داد و در آزمایشی در برابر 2000 سایت برتر الکسا، گوگل حدود 20٪ بهبود یافته است.” و در سال 2015، ایلیا گریگوریک دریافت که “حدود 43٪ از واکشی های تصویر توسط اسکنر HTML گمانه زنی آغاز می شود، که حدود 50٪ از بایت های منتقل شده را تشکیل می دهد.”

مشکلی که در آن زمان برای JPEG 2000 وجود داشت این بود که با دانلود کننده گمانه زنی درگیر شد. اگر از قبل اندازه تصویر موجود در صفحه را نمی دانید، مرورگر چگونه متوجه می شود که چه زمانی دانلود تصویر را متوقف کند؟

بنابراین، مسیری که طی شد، افزودن نحو پاسخگو به تصاویر بود srcset و sizes ویژگی های. صریح باشید، نیازی به جادو نیست. با تمام فرمت های تصویر کار می کند.

اکنون، ما کوئری های کانتینری داریم و با دانلود کننده گمانه زنی نیز همراه نیست. اگر استفاده می کنید picture عنصر در یک کوئری کانتینر، به viewport گره خورده است، نه ظرف! چه اندازه ای را از قبل دانلود کنیم؟

این یک فضای مشکل باز است. همچنین محدودیت و بارگذاری تنبلی برای در نظر گرفتن در این معادله وجود دارد.

من نمی دانم که آیا JPEG XL یک فرمت تصویر جادویی است که روز را نجات می دهد یا خیر، اما اگر برخی از امکانات را ارائه می دهد که فرمت های دیگر ندارند. Jon Sneyers، یکی از سازندگان فرمت تصویر، قدرت پاسخگویی آن را در زیر توضیح می دهد:

به خصوص برای تحویل وب، بهتر است از ذخیره و ارائه چندین گونه از یک تصویر با توجه به عرض دید بیننده اجتناب شود. به همان اندازه مطلوب، گزینه ای برای رمزگشایی تدریجی تصاویر است که یک مکان نگهدار تصویر با کیفیت پایین را زمانی که تنها چند صد بایت رسیده است نشان می دهد و جزئیات بیشتری را با نمایش بقیه داده ها اضافه می کند. JPEG XL به خوبی از هر دو نسخه خوب پشتیبانی می کند.

با توجه به درک اولیه من از مسائلی که با آن روبرو هستیم، به نظر می رسد عجولانه است که JPEG XL را به عنوان یک گزینه کنار بگذارم. باید یک قدم به عقب برگردیم و بپرسیم بهترین نتیجه چیست؟

بهترین نتیجه برای همه، نه فقط وب.

مطمئناً به عنوان یک عکاس، من دوست دارم JPEG XL را ببینم. من می خواهم ببینم که محیط در این نتایج در نظر گرفته می شود، اگر برای دریافت فایل کوچکتر پردازش بیشتری لازم است، آیا این هم چیز بدی نیست؟ خط تحقیق برای سلیقه من بیش از حد مبتنی بر عملکرد وب است.

وضعیت بازی

وضعیت بازی این است که AVIF در کروم است و تا حدی در سافاری و فایرفاکس پشتیبانی می شود.

HEIC و JPEG XL در گوشه‌ای غبارآلود دراز کشیده‌اند.

شاید جیگ برای JPEG XL و HEIC مناسب نباشد. WebP به مدت 5 سال در کروم بود قبل از اینکه بقیه تصمیم گرفتند همین روند را دنبال کنند. جنگ فرمت جنگ فرسایشی است!

باشد که قالب، پاک دل، پیروز شود و بر هفت پادشاهی حکومت کند!

یا شاید لازم نیست جنگ باشد، آیا می توان غنائم را تقسیم کرد و ما بتوانیم با هم هماهنگ حکومت کنیم؟ آیا می توانیم AVIF داشته باشیم؟ و JPEG XL؟

اعتبار تصویر کاپیتان سیاره: ویکی مدیا