فهرست

جست‌وجوی ابزارهاگزارش تغییرات

برای جابه‌جایی برای باز کردنمسئله را توضیح دهید، نه نام ابزار را

مبدل تصویر به WebP

یک PNG یا یک JPEG را در همین برگهٔ مرورگر به WebP تبدیل می‌کند و دقیقاً گزارش می‌دهد که چند بایت صرفه‌جویی کرده است — یا اینکه صرفه‌جویی نکرده است، که برای تصاویر کوچک و یکدست پاسخ صادقانه همین است. رمزگشایی و رمزگذاری هر دو روی دستگاه خود شما اجرا می‌شوند.

اندازهٔ WebP
صرفه‌جویی

چگونگی کار

این ابزار چه چیزی را محاسبه می‌کند

اینکه همان تصویر به‌صورت WebP چقدر کوچک‌تر می‌شود و آیا این مبادله ارزشش را دارد یا نه. پاسخ دو عدد است — اندازهٔ فایلی که تولید کرده، و تفاوتش با فایلی که به آن داده‌اید — و تفاوت در هر جهتی که واقعاً رفته باشد گزارش می‌شود.

روش

فایل به‌جای نامش از روی بایت‌های اول خودش شناسایی می‌شود، سپس به پیکسل‌های خام رمزگشایی و بعد دوباره رمزگذاری می‌شود. سه کدک جداگانه درگیرند و هر سه در همین برگه اجرا می‌شوند: libpng یا mozjpeg برای بیرون کشیدن پیکسل‌ها، و libwebp برای برگرداندن‌شان به فایل.

کیفیت بدون تغییر به libwebp داده می‌شود. بی‌اتلاف به‌جای یک پرچم به‌صورت یک سطح فرستاده می‌شود، که همان چیزی است که libwebp انتظار دارد — اگر مقدار چک‌باکس مستقیم به آن داده می‌شد، هر بار بی‌سروصدا به معنای «با اتلاف» می‌بود.

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

مبدل PNG به JPEG در همین سایت هر دو کدکش را از روی مشخصات فنی پیاده‌سازی کرده و صفحه‌اش دلیلش را به‌تفصیل توضیح می‌دهد. دو مورد از آن سه دلیل اینجا هم به همان اندازه صدق می‌کنند: quality خود مرورگر به‌عنوان یک پیشنهاد مستند شده نه یک تعهد، پس یک تنظیم در هر موتوری فایل متفاوتی می‌دهد، و ابزاری که کل خروجی‌اش یک اندازهٔ فایل است نمی‌تواند اجازه دهد آن اندازه به این بستگی داشته باشد که کدام مرورگر را باز کرده‌اید.

تفاوت در رمزگذار است. نوشتن یک رمزگذار JPEG یک آخر هفته کار دقیق بر اساس یک جدول منتشرشده است. WebP همان VP8 درون‌فریمی است — یک تبدیل، یک کوانتایزر و یک رمزگذار آنتروپی با حساب بولی — و نسخهٔ دست‌نویس آن کندتر و بدتر از libwebp می‌شد، بی‌آنکه کسی بتواند فایده‌ای برایش نام ببرد.

بنابراین این صفحه libwebp، libpng و mozjpeg را کامپایل‌شده به WebAssembly عرضه می‌کند. مجوزشان Apache-2.0 است، روی دستگاه شما اجرا می‌شوند، و فقط وقتی بارگذاری می‌شوند که چیزی را تبدیل کنید، نه وقتی وارد صفحه می‌شوید: حدود ۳۴۰ کیلوبایت که تا استفاده نشود هیچ هزینه‌ای ندارد. آنچه بدون تغییر باقی می‌ماند همان بخشی است که اهمیت داشت — تبدیل دقیقاً تکرارپذیر است، در هر مرورگری یکسان است و اصلاً به شبکه نیاز ندارد.

پیش از ادامهٔ مطلب

یک PNG ۶۹ بایتی که فقط یک پیکسل در خود دارد به WebP تبدیل می‌شود. چه چیزی بیرون می‌آید؟

  • روی یک عکس، بله. اما در یک پیکسل چیزی وجود ندارد که فرمت بهتر بتواند در آن بهتر باشد.

  • بله. هر دو فایل تقریباً به‌تمامی سرآیند هستند.

  • در اصل به حقیقت نزدیک است، ولی این جفت خاص اتفاقاً یک بایت به آن سو می‌افتد.

۶۸ بایت: یک بایت کوچک‌تر، یعنی عملاً هیچ صرفه‌جویی‌ای. هر دو فایل تقریباً به‌تمامی کانتینر هستند و در یک پیکسل چیزی برای فشرده کردن باقی نمانده است. این یک مورد ساختگی نیست — کوچک‌ترین فایل واقعیِ در دسترس است و در فایل آزمون این ابزار تضمین شده، پس این صفحه و کد نمی‌توانند دربارهٔ آنچه در کوچک‌ترین اندازه‌ها رخ می‌دهد از هم فاصله بگیرند. به فایل‌های بزرگ‌تر بروید و ماجرا کاملاً برعکس می‌شود: یک عکس با کیفیت ۸۰ معمولاً بیست‌وپنج تا سی‌وپنج درصد کوچک‌تر از JPEG معادلش است.

یک مثال حل‌شده

یک PNG ۶۹ بایتی از یک پیکسل به یک WebP ۶۸ بایتی تبدیل می‌شود: یک بایت کوچک‌تر، یعنی عملاً هیچ صرفه‌جویی‌ای. این یک مورد ساختگی نیست — کوچک‌ترین فایل واقعیِ در دسترس است و در فایل آزمون این ابزار تضمین شده، پس این صفحه و کد نمی‌توانند دربارهٔ آنچه روی فایلی رخ می‌دهد که برای فشرده شدن بیش از حد کوچک است از هم فاصله بگیرند.

به فایل‌های بزرگ‌تر بروید و ماجرا کاملاً عوض می‌شود. یک عکس با کیفیت ۸۰ معمولاً بیست‌وپنج تا سی‌وپنج درصد کوچک‌تر از JPEG معادلش است، و اسکرین‌شاتی با رنگ‌های یکدست که بی‌اتلاف ذخیره شود معمولاً از PNG کوچک‌تر است. قاعدهٔ سرانگشتی این است که WebP در همه‌چیز برنده می‌شود، به‌جز فایل‌هایی که از اول آن‌قدر کوچک بوده‌اند که چیزی برای فشرده کردن نداشته‌اند.

اعداد به چه معنا هستند

اندازهٔ WebP اندازهٔ فایلی است که پایین صفحه ارائه می‌شود، بر حسب واحدهای ۱٬۰۲۴ بایتی.

صرفه‌جویی آن را با فایلی که انتخاب کرده‌اید مقایسه می‌کند. صرفه‌جویی منفی به همان صراحتِ صرفه‌جویی مثبت بیان می‌شود، زیرا فایل‌هایی که WebP در آن‌ها می‌بازد دقیقاً همان فایل‌هایی‌اند که خواننده بیش از همه لازم است درباره‌شان بداند.

مراحل انجام کار

  1. بایت‌های اول فایل خوانده می‌شود و مشخص می‌شود که فایل واقعاً چیست. یک PNG با امضای 0x89504E47 شروع می‌شود؛ یک JPEG با 0xFFD8FF. نام فایل هرگز ملاک قرار نمی‌گیرد، زیرا نام فقط یک ادعاست.
  2. فایل به پیکسل‌های خام RGBA رمزگشایی می‌شود — libpng برای PNG و mozjpeg برای JPEG، هر دو کامپایل‌شده به WebAssembly و هر دو در همین‌جا اجرا می‌شوند، نه روی سرور.
  3. آن پیکسل‌ها با libwebp و در کیفیت انتخاب‌شده به WebP رمزگذاری می‌شوند. وقتی بی‌اتلاف روشن باشد، کیفیت به‌کلی نادیده گرفته می‌شود، زیرا libwebp رمزگذار دیگری را به کار می‌گیرد که هر پیکسل را دقیقاً بازتولید می‌کند.
  4. اندازهٔ دو فایل مقایسه می‌شود و تفاوت، در هر جهتی که رفته باشد، گزارش می‌شود.

فرض‌ها

  • کیفیت بر مقیاس خود libwebp است، نه مقیاس مرورگر. یک عدد یکسان در هر مرورگری همان فایل را تولید می‌کند، زیرا رمزگذار همراه ابزار عرضه می‌شود و از موتور مرورگر قرض گرفته نمی‌شود.
  • بی‌اتلاف تنظیم کیفیت را به‌کلی نادیده می‌گیرد. این رفتار خود libwebp است، نه ساده‌سازی‌ای که اینجا انجام شده باشد.
  • پروفایل‌های رنگ منتقل نمی‌شوند. پروفایل ICC موجود در فایل منبع حذف می‌شود و WebP به‌صورت sRGB ساده نوشته می‌شود، بنابراین عکسی با گسترهٔ رنگی وسیع (wide-gamut) کم‌رنگ‌تر از اصل خود درمی‌آید.
  • GIF متحرک، AVIF، HEIC، TIFF و SVG خوانده نمی‌شوند. این ابزار یک PNG یا یک JPEG می‌پذیرد، هر بار یک فایل، حداکثر تا ۳۲ مگابایت.
  • جهت‌گیری EXIF اعمال نمی‌شود، بنابراین عکسی که گوشی آن را «چرخیده» برچسب زده است، در همان جهتی درمی‌آید که پیکسل‌هایش واقعاً ذخیره شده‌اند.

پرسش‌های رایج

آیا تصویری که تبدیل می‌کنم جایی آپلود می‌شود؟

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

چرا WebP من از فایل اصلی بزرگ‌تر شد؟

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

بی‌اتلاف را انتخاب کنم یا با اتلاف؟

با اتلاف برای عکس‌ها؛ بی‌اتلاف برای هر چیزی با رنگ‌های یکدست، لبه‌های تیز یا متن — لوگوها، نمودارها، اسکرین‌شات‌ها. WebP بی‌اتلاف معمولاً دقیقاً روی همین نوع تصاویر بیست تا سی درصد از PNG کوچک‌تر است، و WebP با اتلاف در کیفیت برابر از JPEG بهتر عمل می‌کند. وقتی بی‌اتلاف روشن باشد، کیفیت نادیده گرفته می‌شود.

برای عکس چه کیفیتی انتخاب کنم؟

حدود ۸۰، که مستندات خود libwebp بخش مفید منحنی را همان‌جا می‌داند. زیر حدود ۶۰ آرتیفکت‌های فشرده‌سازی روی پوست و آسمان دیده می‌شوند؛ بالای حدود ۹۰ فایل به‌سرعت بزرگ می‌شود، برای تفاوتی که بیشتر افراد روی صفحهٔ نمایش نمی‌بینند.

آیا حالا می‌شود WebP را همه‌جا با خیال راحت به کار برد؟

در مرورگرها بله — Chrome، Firefox، Safari و Edge همگی سال‌هاست از آن پشتیبانی می‌کنند. ریسک باقی‌مانده نرم‌افزارهای دیگر است: برخی ویرایشگرهای دسکتاپ، کلاینت‌های ایمیل و سیستم‌های مدیریت محتوا هنوز آن را باز نمی‌کنند، پس اگر فایل باید به جایی برود که صفحهٔ وب نیست، نسخهٔ اصلی را نگه دارید.

منابع