JPEG XL در مقابل AVIF برای موارد استفاده وب

JPEG XL در حال حاضر در همه مرورگرهای اصلی قرار گرفته است، بنابراین من فکر کردم که در مقایسه با فرمت های دیگر به خوبی و بدی آن نگاه دقیق تری داشته باشم.

من به جزئیات کامل، با مثال ها و معیارها می پردازم، اما برای کسانی از شما که وقت ندارید، در اینجا سرفصل ها آمده است:

برای عکس‌های با اتلاف در وب، AVIF تقریبا همیشه فایل‌های کوچک‌تری نسبت به JPEG XL تولید می‌کند. در تنظیمات پیش فرض تلاش، بهترین نسخه JPEG XL معمولا 15 تا 25 درصد بزرگتر از AVIF معادل است. در تنظیمات حداکثر تلاش، شکاف کمی کاهش می یابد، به طور معمول به 6-20٪. موارد پرت وجود دارد، که در آن JPEG XL نزدیک به AVIF است، یا حتی از AVIF شکست می‌دهد، بنابراین اگر می‌خواهید بهترین نتیجه را برای یک تصویر خاص داشته باشید، ارزش امتحان کردن هر دو را دارد. تصویر F1 را برای یک مثال معمولی، و راسو را برای یک نمونه پرت ببینید.

رمزگذار JPEG XL اهمیت زیادی دارد. jixel، یک رمزگذار جدیدتر JPEG XL، معمولا فایل‌های کوچک‌تری نسبت به libjxl تولید می‌کند، مگر اینکه تصویر شفافیت دقیقی داشته باشد. تصویر مردم یک نمونه است.

برای اسکرین شات ها و تصاویر، AVIF بسیار بهتر از JPEG XL است. JPEG XL معادل 30 تا 90 درصد در تنظیمات تلاش پیش‌فرض بزرگ‌تر و 20 تا 70 درصد در تنظیمات حداکثر تلاش بزرگ‌تر است. Lossy AVIF این موارد را به خوبی مدیریت می کند - شما نیازی به استفاده از فرمت های بدون اتلاف ندارید مگر اینکه واقعا به نتایج کمی نیاز داشته باشید. اسکرین شات و نمونه های تصویر را ببینید.

برای تصاویر با شفافیت، AVIF بسیار بهتر از JPEG XL است. نسخه libjxl در تنظیمات تلاش پیش‌فرض 31 تا 44 درصد و در تنظیمات حداکثر تلاش 61 تا 70 درصد بزرگ‌تر است. jixel همیشه شفافیت را بدون اتلاف رمزگذاری می‌کند، که باعث می‌شود فایل‌های آن ۲ تا ۳ برابر اندازه AVIF باشد. داده ها را ببینید.

AVIF معمولا برای رمزگذاری سریع‌تر است و با توجه به اندازه فایل، از حافظه کمتری استفاده می‌کند. jixel سریعتر از AVIF است و از حافظه کمتری استفاده می کند، اما فایل های آن معمولا به طور قابل توجهی بزرگتر هستند، بنابراین AVIF در تعادل بهتر است. برای یک مثال تصویر F1 را ببینید.

رمزگشایی AVIF سریعتر است. رمزگشایی JPEG XL معمولا 2 تا 3 برابر طول می‌کشد تا با کیفیت متوسط ​​رمزگشایی شود، اما این شکاف در کیفیت‌های بسیار بالا کاهش می‌یابد، جایی که Chrome گاهی اوقات می‌تواند JPEG XL را سریع‌تر رمزگشایی کند. تصویر مردم یک نمونه است.

تنظیمات تلاش بالاتر برای AVIF و jixel ارزش آن را دارد، اما libjxl نه. تلاش های بالاتر libjxl بسیار کندتر است، از حافظه بسیار بیشتری استفاده می کند و به سختی نتیجه را بهبود می بخشد. گاهی اوقات آنها فایل های بزرگتر از تلاش پیش فرض تولید می کنند. اسکرین شات نمونه ای از این موارد است.

حالت 4:2:0 (رزولوشن نیمه رنگ) AVIF نباید پیش فرض شما باشد. به ندرت اندازه فایل را کاهش می دهد و دسترسی به کیفیت های بالاتر را سخت تر می کند. اگرچه، رمزگذاری و رمزگشایی سریعتر است. اگر وقت ندارید هر دو را بررسی کنید، از 4:4:4 استفاده کنید. تصویر F1 یک نمونه است و اسکرین شات یک استثنا است.

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

Progressive JPEG XL اساسا با تلاش زیاد رایگان است. جیکسل اخیرا از پیش‌نمایش‌های پیشروی اولیه پشتیبانی کرده است، و در پایین‌ترین حالت، هزینه کمی دارند یا اصلا هزینه ندارند، اما در تنظیمات پیش‌فرض، فایل‌ها 12 درصد بزرگ‌تر هستند. فایرفاکس و کروم از JPEG XL پیشرفته پشتیبانی می کنند. سافاری همچنان تصویر نهایی را ارائه می‌کند، اما پیش‌نمایش‌های پیش‌رونده را نشان نمی‌دهد. با این حال، آیا این نوع رندر پیش رونده تجربه کاربری خوبی است؟ نمونه ها و داده ها را ببینید.

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

برای HDR، JPEG XL فاقد نقشه های بهره است، که در مقایسه با AVIF محدودیت قابل توجهی است. فرمت JPEG XL از نقشه‌های افزایش پشتیبانی می‌کند، اما توسط رمزگشاهای مرورگر پشتیبانی نمی‌شوند، و داستان رمزگذاری آشفته/تجربی است. هنگام مقایسه محتوای HDR نقشه‌برداری شده بدون سود، دو معیار کیفیتی که من استفاده کردم بسیار مخالف هستند، اما آنها موافق هستند که JPEG XL در مقایسه با AVIF فایل‌های کوچک‌تری تولید می‌کند. نمونه ها را ببینید.

JPEG XL می‌تواند JPEG‌های موجود را 9 تا 20 درصد کوچک‌تر کند، بدون از دست دادن بیشتر. همچنین رمزگشایی سریعتر یا سریعتر است، به جز برای تصاویر کوچک. داده ها را ببینید.

برای بدون ضرر، JPEG XL برنده واضح است. Lossless WebP برای عکس‌ها 9 تا 17 درصد بزرگ‌تر است و AVIF بدون اتلاف 30 تا 120 درصد بزرگ‌تر است. اما تصاویر بدون اتلاف تقریبا هرگز آن چیزی نیستند که در وب می خواهید. اگر از آن‌ها در وب استفاده می‌کنید (مانند من در این صفحه)، مراقب تلاش‌های بالاتر jixel باشید - اغلب فایل‌هایی تولید می‌کند که برای رمزگشایی بسیار کند هستند. داده ها را ببینید.

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

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

هم AVIF و هم JPEG XL (از طریق jixel) اخیرا شاهد پیشرفت‌های عظیمی بوده‌اند، بنابراین ممکن است این توصیه در آینده تغییر کند. اطلاعات نادرست زیادی در مورد این موارد وجود دارد، و هوش مصنوعی شما با خوشحالی این اطلاعات نادرست را به شما ارائه می دهد. در عوض، چیزها را با تصاویر خود آزمایش کنید.

افراد AVIF پیشنهاد می کنند که JPEG XL در مقایسه با AVIF از نظر فنی محدود است. این ممکن است درست باشد، اما در این مقاله من روی نتایج پیاده سازی های امروزی تمرکز می کنم.

من یک اسکریپت بنچمارک ایجاد کردم که تصاویر را با استفاده از کدک های مختلف در تنظیمات مختلف رمزگذاری می کند و جزئیات مختلف را ثبت می کند.

من از آخرین نسخه های منتشر شده از کدک های تصویر استفاده می کنم که در زمان نوشتن عبارتند از:

من مجموعه ای از تصاویر را انتخاب کردم و بیشتر آنها را با عرض 1598 پیکسل رمزگذاری کردم - که 2 برابر حداکثر عرض تصاویر در این وبلاگ است. این بدان معنی است که آنها در نمایشگرهای با تراکم بالا، که اکثر کاربران دارند، واضح به نظر می رسند. در نتیجه، اگر این صفحه را روی یک صفحه نمایش کوچک یا کم تراکم مشاهده می کنید، تجربه کامل را دریافت نمی کنید.

من این بنچمارک ها را در مک بوک پرو 2024 خود (M4 Pro) اجرا کردم.

وقتی برای اولین بار در مورد AVIF نوشتم، از یک ماشین F1 به عنوان اولین تصویر استفاده کردم، بنابراین فکر کردم دوباره این کار را انجام خواهم داد!

من تصویر را با کیفیت‌های کدک مختلف کدگذاری کردم و نسخه‌هایی را انتخاب کردم که به امتیازات خاص SSIMULACRA2 نزدیک‌تر بودند - یک معیار کیفیت تصویر ادراکی توسط افرادی که پشت JPEG XL هستند. 50 با کیفیت متوسط، 70 بالا، 80 بسیار بالا و 90 از نظر بصری بدون تلفات در نظر گرفته می شود. اگرچه، مطمئن نیستم که آیا این رتبه‌بندی‌ها نمایشگرهای با چگالی بالا را در نظر می‌گیرند یا خیر.

در سراسر مقاله، مقایسه‌های بصری، مانند بالا، از حداکثر تلاش هر رمزگذار استفاده می‌کنند، مگر در مواردی که حداکثر تلاش منجر به فایل بزرگ‌تر می‌شود (بله، این اتفاق می‌افتد).

برای آرشیو، من به سمت کیفیت های تقریبا بدون ضرر گرایش دارم، اما اگر فقط یک تصویر گویا را در وبلاگم نمایش می دهم، عملکرد برای من مهم تر است. من شخصا از نتیجه 70 فوق راضی هستم. اگر بزرگ‌نمایی کنید، می‌توانید کاهش کیفیت را ببینید، اما اگر واقعا نگران زوم کردن بودم، از چیزی مانند VisualViewport API برای بارگذاری تصویر با وضوح بالاتر در زمان وقوع آن استفاده می‌کردم، نه اینکه دانلود را برای همه بزرگ‌تر کنم.

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

همچنین، من احساس می کنم که با کیفیت متوسط ​​(50)، AVIF و libjxl بهتر از نسخه jixel به نظر می رسند. نسخه jixel دارای نویزهای قابل مشاهده زیادی در اطراف لوگوی BWT است و متن مایکروسافت در بال جلو بسیار کمتر خوانا است. کمی در مورد متریک تعجب می کنم.

به هر حال، تفسیر من از نتایج این است:

در اینجا اطلاعات کامل وجود دارد، بنابراین می توانید تصمیم خود را بگیرید:

خوب، بیایید به اولین نمودار خود، نمرات SSIMULACRA2 برسیم:

تعداد زیادی از این نمودارها وجود خواهد داشت، بنابراین در اینجا چه اتفاقی می افتد:

در اینجا نتایج کیفیت با استفاده از معیار کیفیت متفاوت، ColorVideoVDP آمده است:

نتیجه تقریبا یکسان است با این تفاوت که این معیار فاصله بیشتری بین تصاویر AVIF و JPEG XL ایجاد می کند.

همچنین نشان می‌دهد که AVIF دارای مزیت‌هایی با زیرنمونه‌برداری کروما 4:2:0 در کیفیت‌های پایین‌تر است، اما جزئی است.

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

یکی دیگر از مواردی که ممکن است در صورت رمزگذاری تصاویر در سرور نگران کننده باشد، حداکثر استفاده از حافظه است:

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

رمزگشایی JPEG XL در تنظیمات با کیفیت بسیار بالا ناگهان سریع‌تر می‌شود (اما همچنان کندتر از AVIF). فکر می‌کنم این به دلیل فیلتر حفظ لبه است که در تنظیمات با کیفیت پایین‌تر کار بیشتری می‌کند.

من شنیده ام که مردم می گویند تمایل AVIF به صاف کردن جزئیات آن را برای چهره انسان بد می کند، بنابراین من این تصویر را از Unsplash انتخاب کردم.

در کیفیت‌های پایین‌تر، می‌توانید صاف کردن صورت را مشاهده کنید، اما برای AVIF و JPEG XL یکسان است.

جالب است که در کیفیت های پایین تر، جیکسل در سافاری بسیار کندتر رمزگشایی می کند.

این یکی را انداختم چون تصویر پیش‌فرض Squoosh است، اما حدس می‌زنم خطوط واضح موها آن را با تصاویر قبلی متفاوت می‌کند. در واقع، حتی با کیفیت متوسط، تفاوت با نسخه اصلی در مقایسه با سایر تصاویر برای من بسیار کمتر قابل درک است.

نتایج بسیار نزدیکتر از دو مورد قبلی است:

من با هر دو کدک زیاد بازی کرده ام، و برای عکس ها، چیزی که تا به حال نشان داده ام نشان دهنده است، جایی که AVIF JPEG XL را شکست می دهد. با این حال، هر از گاهی مواردی مانند این تصویر وجود دارد.

به نظر می رسد برخی از توسعه دهندگان، به خصوص آنهایی که تا زمانی که من در این زمینه حضور داشته اند، فکر می کنند چیزهایی مانند اسکرین شات ها باید در قالبی بدون ضرر ارائه شوند. اما من فکر می‌کنم این به این دلیل است که آنها به فرمت‌هایی مانند JPEG و WebP (و به ظاهر JPEG XL) عادت کرده‌اند که این نوع تصویر را به خوبی مدیریت می‌کنند، در حالی که AVIF با تلفات آن‌ها را به خوبی مدیریت می‌کند.

من نمودار ColorVideoVDP را درج نمی‌کنم زیرا معیار از کانال‌های آلفا پشتیبانی نمی‌کند.

زمان‌های بالای رمزگشایی JPEG XL در اینجا احتمالا یک عارضه جانبی از تولید فایل‌های بسیار بزرگتر برای کیفیت معین است.

در بسیاری از موارد، برای تصاویر تا حد زیادی با رنگ مسطح، از SVG استفاده می کنید. اما گاهی اوقات این امکان پذیر نیست (این یک اسکرین شات است)، یا نامطلوب، مانند این مورد. این تصویر، همچنین از Unsplash، هنوز 1.1 مگابایت به عنوان یک SVG فشرده و کوچک شده است. این به دلیل پیچیدگی مناطق سایه دار است. در نتیجه، فرمت شطرنجی بر حسب اندازه فایل و زمان رمزگشایی/قرعه کشی برنده می شود.

با کیفیت 50 در نسخه ی نمایشی بالا، جیکسل دارای بلوک های رنگی بسیار شدید است، به عنوان مثال. روی صورت گربه باز هم، این باعث می شود که متریک را کمی زیر سوال ببرم.

تا به حال، تمام تصاویر عمدتا مات بوده اند. در مورد یک تصویر با شفافیت چطور؟

چند چیز وجود دارد که این یکی را متفاوت می کند:

تصاویر تا کنون وضوح مشابهی داشته اند. آیا نتایج با تصاویر کوچکتر متفاوت است؟

نه واقعا. نتایج تقریبا مشابه تصویر F1 در اندازه کامل است:

اعدادی که سافاری می دهد گرد هستند، بنابراین داده ها واقعا پر سر و صدا هستند.

بیشتر داستان مشابه تصویر F1 معمولی است، اما با چند تفاوت:

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

برای تصاویری که تا به حال به آنها نگاه کردم، آنها را با avifenc -q 50، cjxl -q 70 و jixel با کیفیت 80 کدگذاری کردم و نمرات حاصل از SSIMULACRA2 را ثبت کردم:

رفتار کدک ها در اینجا واقعا مشابه به نظر می رسد. همه آنها طیفی از امتیازات SSIMULACRA2 را تولید می کنند و همه آنها برای تصاویر مشابه بالاتر یا پایین تر می شوند.

و من فکر می کنم این خوب است؟ به عنوان مثال، هر سه به دنبال کیفیت پایین‌تری برای تصویر Weasel هستند که بدون کاهش کیفیت سوژه تصویر، نویز را حذف می‌کند. با اسکرین شات همه به سراغ کیفیت بالاتری می روند که به نظر من قابل توجیه است.

بدیهی است که این حجم نمونه کوچکی است، اما من چیزی ندیده‌ام که نشان دهد استفاده از یک تنظیم کیفیت واحد برای هر یک از سه کدک خطرآفرین باشد.

همچنین بررسی عمیق تر Halide Compression را در این مورد ببینید.

هر دو AVIF و JPEG XL می‌توانند چیزی را به تدریج با بارگذاری تصویر نشان دهند. کروم و فایرفاکس از JPEG XL پیشرفته پشتیبانی می کنند، در حالی که فقط کروم از AVIF پیشرونده پشتیبانی می کند. بنابراین، و من این را از طریق دندان قروچه می گویم، این نسخه آزمایشی بعدی به بهترین وجه در کروم مشاهده می شود (من یک پچ فایرفاکس در حال پیشرفت دارم):

این دوباره تصویر 18 مگاپیکسلی است، بنابراین اگر در دستگاهی با صفحه نمایش کوچکتر آن را مشاهده می کنید، جلوه کامل را دریافت نمی کنید.

Progressive AVIF و JPEG XL بسیار متفاوت عمل می کنند. با JPEG XL، می‌توانید داده‌های ذخیره‌شده را طوری انتخاب کنید که رمزگشا بتواند نسخه‌های با وضوح پایین را قبل از اینکه کاشی‌های با وضوح بالاتر را وارد کند، ارائه دهد. جیکسل اخیرا (مانند دیروز در زمان نگارش) پشتیبانی از این را نیز اضافه کرده است. این "DC پیشرو" نامیده می شود و مهم ترین نوع رندر پیش رونده برای JPEG XL است.

با AVIF، پیشرفت‌ها بیشتر شبیه فریم‌های یک ویدیو هستند. شما حداکثر چهار فریم ارائه می دهید، بنابراین این سه مرحله قبل از تصویر نهایی است. دوباره، مانند یک ویدیو، هر فریم می تواند از داده های فریم قبلی به عنوان بهینه سازی استفاده کند. مزیت این کار این است که می توانید دقیقا نحوه ظاهر آن قاب ها را انتخاب کنید. در مثال بالا، من با یک فریم پیش‌نمایش تک پیش‌نمایش رفتم: یک نسخه با وضوح 1/8، با کمی تاری. اما، اگر واقعا بخواهید، فریم های پیش نمایش شما می توانند تصاویر کاملا متفاوتی باشند.

وقتی صحبت از تصاویر پیشرو و تجربه کاربری به میان می‌آید، کمبود داده وجود دارد، بنابراین اینها فقط تصورات من هستند:

اگر اتصال بدی دارید، داده‌ها به تدریج به دست نمی‌آیند، همانطور که برخی از ابزارهای throttling شما را باور می‌کنند. تمایل دارد به صورت انفجاری بیاید. بنابراین، رندر پیش رونده در تصاویر کوچکتر فایده کمی دارد و مطمئن نیستم که بسیاری از مراحل پیشرونده به ویژه مفید باشند.

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

قاب پیش نمایشی که برای AVIF انتخاب کردم به اندازه ای است که بگوییم یک ماشین مسابقه ای چرخ باز است. اگر فرمول یک را بشناسید، می دانید چه تیمی است. حتی ممکن است بدانید که عکس از کجا گرفته شده است. و آن را در 11.5 کیلوبایت ارائه می دهد.

JPEG XL یک پیش‌نمایش BlurHash مانند روی صفحه در 2 کیلوبایت دریافت می‌کند، اما تا 63 کیلوبایت طول می‌کشد تا با کیفیت پیش‌نمایش AVIF مطابقت داشته باشد. پس از آن، به تدریج بهبود می یابد و با رسیدن اطلاعات بیشتر، تصویری با جزئیات بیشتر و با کیفیت بالاتر ارائه می دهد.

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

در اینجا یک برش از JPEG XL، 80٪ بارگذاری شده است. منطقی به نظر می رسد که کسی به آن نگاه کند، و فقط فرض کند من عکس را بد گرفته ام و بخش هایی را خارج از فوکوس گذاشته ام. احتمالا می‌توانید من را متقاعد کنید که تار کردن لوگوی ApeCoin یک مزیت اجتماعی است، اما همچنان مانند یک تجربه کاربری غیربهینه به نظر می‌رسد.

سیستم AVIF به من کنترل بیشتری می‌دهد، اما همچنین پیچیده‌تر است.

من تصویر بزرگ F1 را با و بدون فعال کردن رندر پیش رونده کدگذاری کردم و تنظیمات کیفیت را طوری تنظیم کردم که امتیاز SSIMULACRA2 حدود 70 باشد:

بیایید به فشرده سازی با اتلاف برگردیم، اما این بار HDR! چند راه برای رمزگذاری تصاویر HDR وجود دارد و ما به دو مورد می‌پردازیم.

Quantization ادراکی (PQ) به هر پیکسل می گوید که چه چیزی باید باشد. هر مقدار به روشنایی مطلق، تا 10000 نیت، با منحنی شکل داده می‌شود تا داده‌ها در جایی مصرف شوند که چشم‌های ما حساس‌ترین هستند. اگر تصویر رنگ‌ها و روشنایی‌هایی را درخواست می‌کند که نمایشگر نمی‌تواند نشان دهد (هیچ صفحه‌نمایش مصرف‌کننده‌ای نمی‌تواند 10000 نیت داشته باشد)، مرورگر/سیستم‌عامل باید آن را به تصویر بکشد، و میزان خوب انجام آن بین پلتفرم‌ها متفاوت است.

نقشه های سود متفاوت هستند. تصویر اصلی یک تصویر SDR معمولی است (معمولا) و در کنار آن یک "نقشه افزایش" وجود دارد که برای دستیابی به نسخه HDR، روشنایی و تغییر رنگ را برای هر پیکسل اعمال می کند.

CSS و <picture> به ما اجازه می دهند یک تصویر SDR یا PQ را از طریق پرس و جو رسانه با دامنه پویا به کاربر ارائه دهیم، اما در مواردی که مرورگر سیگنال پشتیبانی از HDR را می دهد، اما دامنه کامل را پشتیبانی نمی کند، به نگاشت تن تکیه می کنید.

اگرچه فرمت JPEG XL از نقشه‌های دریافت پشتیبانی می‌کند، هیچ مرورگری آن‌ها را مدیریت نمی‌کند و داستان رمزگذاری نامرتب است.

AVIF از نقشه های دریافت پشتیبانی می کند و شما با ارائه دو تصویر، آنها را رمزگذاری می کنید: تصویر SDR و تصویر HDR. از آن ها برای محاسبه و رمزگذاری نقشه بهره استفاده می کند.

مرورگر/صفحه نمایش شما از HDR پشتیبانی نمی کند، بنابراین تصاویر PQ بد به نظر می رسند.

در روشنایی متوسط، در صفحه HDR، نقشه بهره و تصاویر PQ یکسان به نظر می رسند. در حداکثر روشنایی، در پیکسل 10 پرو و ​​مک بوک پرو 2024 من، تصاویر PQ کمی محو می شوند و تصویر نقشه افزایش بهتر به نظر می رسد. در روشنایی کم در پیکسل 10 پرو من، دوباره تصویر نقشه افزایش بهتر به نظر می رسد.

این به این دلیل است که در سطوح روشنایی بسیار زیاد، دستگاه فضای سر کامل HDR برای نمایش تصویر را ندارد و نقشه های Gain می توانند این موارد را بهتر مدیریت کنند. بنابراین، اگرچه به نظر می‌رسد نقشه‌های گین مقدار زیادی به حجم فایل اضافه می‌کنند، به نظر من ارزشش را دارد.

شاید آینده ای وجود داشته باشد که در آن نگاشت آهنگ بسیار بهتر شود و مزیت نقشه بهره کمتر قابل توجه شود.

SSIMULACRA2 معمولی فقط SDR را می‌فهمد، بنابراین برای این تصویر، امتیازات از حالت آزمایشی HDR در fast-ssim2 به دست می‌آیند. این بدان معناست که این نمرات را نمی توان با نمرات SSIMULACRA2 در جاهای دیگر این مقاله مقایسه کرد. ColorVideoVDP به صورت بومی HDR را مدیریت می کند و در اینجا یک مانیتور 1500 nit HDR را مدل سازی می کند.

این دو معیار با این تصویر بسیار مخالف هستند. و آنها در مزایای نقشه های بهره فاکتور نمی گیرند، بنابراین این نتایج را به عنوان مقایسه ای بین انواع PQ در نظر بگیرید:

جالب خواهد بود که ببینید JPEG XL چگونه نقشه ها را پس از پشتیبانی کامل از آنها کنترل می کند.

به هر حال، اینها نشانه هایی هستند که نشان می دهد گربه های من داخل هستند یا بیرون، و نمایشگر کوچک نشان می دهد که چقدر تا تغذیه خودکار بعدی آنها باقی مانده است.

JPEG XL به شما امکان می دهد یک JPEG موجود را بدون ضرر اضافی به JPEG XL تبدیل کنید. من این را با تصویر F1 در طیف وسیعی از اندازه ها و کیفیت های JPEG آزمایش کردم:

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

بسیار نادر است که به تصاویر بدون اتلاف در وب نیاز داشته باشید. همانطور که قبلا دیده‌ایم، حتی برای مواردی مانند اسکرین‌شات‌ها و تصاویر، AVIF با اتلاف آن‌ها را به خوبی مدیریت می‌کند. از قضا، این صفحه یکی از موارد پرت است، زیرا می‌خواستم نسخه‌های فشرده‌شده را در مقابل نسخه‌های بدون اتلاف آن‌ها نشان دهم. خوشبختانه، JPEG XL بدون ضرر عالی است!

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

من یک کلیپ کوتاه را رمزگذاری کردم و AVIF متحرک 725 کیلوبایت و JPEG XL 2.17 مگابایت برای همان امتیاز ColorVideoVDP (9.5) بود.

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

AVIF اساسا فرمت فریم کلیدی ویدیوی AV1 است، با مجموعه‌ای از بهینه‌سازی‌های خاص عکس ثابت. با این حال، AVIF متحرک، تقریبا فقط بسته‌بندی مجدد ویدیوی AV1 است. شما می توانید یک MP4 AV1 را به AVIF تبدیل کنید و بدون ضرر به آن برگردید - این فقط یک تغییر ظرف است. به همین دلیل عملکرد بسیار بهتری دارد، زیرا برای حرکت ساخته شده است.