قاعدهٔ سرانگشتی، و جایی که میشکند
فشردهسازی بااتلاف اطلاعات را دور میریزد، پس باید همیشه فایلی کوچکتر از بیاتلاف تولید کند. این برای عکسها درست است و آنقدر زیاد نادرست است که ارزش فهمیدن داشته باشد.
آنچه تعیینکننده است پیشبینیپذیری تصویر است.
کدگذارهای بیاتلاف با یافتن تکرار و ساختار کار میکنند — رشتهای از پیکسلهای یکسان، سطری که شبیه سطر بالایش است، پالتی از شانزده رنگ که در کل تصویر به کار رفته. یک اسکرینشات به یکی از آنها بدهید و نظم عظیمی پیدا میکند و تقریباً مجانی کدگذاریاش میکند.
کدگذارهای بااتلاف با دور ریختن جزئیاتی کار میکنند که چشم در دیدنشان ضعیف است، بیشتر در رنگ و بافت پرفرکانس. یک عکس به یکی از آنها بدهید و چیزهای زیادی برای دور ریختن هست. لوگویی روی پسزمینهٔ تخت به آن بدهید و تقریباً هیچ چیزی نیست — اما همچنان تمام هزینهٔ تبدیلش را میپردازد، و بدتر، دور لبههای تیزی که هرگز برایشان طراحی نشده بود رینگینگ (هالههای نوسانی) قابل مشاهده میسازد.
پیش از ادامهٔ مطلب
یک عکس را دو بار ذخیره میکنید: یک بار بیاتلاف، یک بار بااتلاف با کیفیت بالا. کدام فایل کوچکتر است؟
به تصویر بستگی دارد. عکس پر از نویز و گرادیان است که فشردهسازی بااتلاف ارزان دورشان میریزد، پس بااتلاف با فاصله برنده میشود. گرافیک تختی با نواحی بزرگ رنگ یکسان به شکلی عالی بیاتلاف فشرده میشود، و کدگذاری بااتلاف آن میتواند هم بزرگترش کند و هم آشکارا بدترش. محتوا تصمیم میگیرد، نه قالب.
چه چیزی برنده میشود، و کی
| محتوا | معمولاً کوچکتر | چرا |
|---|---|---|
| عکسها | بااتلاف، با اختلاف زیاد | پرنویز و پرجزئیات؛ چیزهای زیادی برای دور ریختن هست |
| اسکرینشات، رابط کاربری | بیاتلاف | نواحی تخت بزرگ، سطرهای تکراری، رنگهای متمایز اندک |
| لوگو، آیکون، طراحی خطی | بیاتلاف | لبههای تیز دقیقاً همان چیزی است که بااتلاف بدتر از همه از پسش برمیآید |
| نمودارها و دیاگرامها | بیاتلاف | پرشدگی تخت بهعلاوهٔ متن؛ رینگینگ متن بسیار قابل مشاهده است |
| هر چیزی که متن دارد | بیاتلاف | رینگینگ دور حروف محسوسترین آرتیفکت ممکن است |
| تصاویر بسیار کوچک | هر کدام — اغلب هیچکدام | زیر چند صد بایت، سربار سرآیند غالب است |
سطر آخر همانی است که مردم را غافلگیر میکند. زیر تقریباً یک کیلوبایت، کانتینر بیش از محتوا هزینه دارد، و یک تبدیل واقعاً میتواند فایل را بزرگتر کند. این باگ مبدل نیست.
یک مثال حلشده
یک تصویر آزمایشی ۳۲×۳۲ با یک گرادیان نرم، یک مربع قرمز با لبهٔ تند و رنگهای اصلی اشباع — عمداً دردسرساز، و تقریباً شبیه یک عنصر کوچک رابط کاربری:
source PNG 1,805 bytes
lossless WebP 146 bytes pixel-for-pixel identical
lossy WebP q80 264 bytes mean error 5.5 per channel
فایل بیاتلاف ۸۰٪ کوچکتر از فایل بااتلاف است، و در ضمن دقیق هم هست. هر دو واقعیت یک علت دارند: تصویر بیشتر رنگ تخت و لبهٔ تند است، که بهترین حالت برای کدگذار بیاتلاف و نزدیک به بدترین حالت برای کدگذار بااتلاف است.
آن ارقام از مجموعهٔ آزمون خود همین مخزن آمدهاند، که در هر commit آن تصویر را کدگذاری میکند و با کتابخانهای دیگر دوباره رمزگشاییاش میکند تا بررسی کند پیکسلها سالم ماندهاند.
چگونه بدون حدس زدن تصمیم بگیریم
هر دو را امتحان کنید و مقایسه کنید. یک ثانیه طول میکشد، هیچ هزینهای ندارد، و از هر قاعدهٔ سرانگشتیای قابل اتکاتر است — از جمله قاعدهٔ همین صفحه.
اگر نشد، یک پرسش بپرسید: آیا این تصویر نواحی بزرگی با رنگ دقیقاً یکسان دارد، یا لبههای تیز میان رنگها؟ اگر بله، با بیاتلاف شروع کنید. اگر عکس است، با بااتلاف حدود کیفیت ۸۰ شروع کنید و فقط اگر در اندازهٔ کامل تفاوتی میبینید بالاتر بروید.
آنچه هیچیک از اینها تغییر نمیدهد
انتخاب فشردهسازی روی ابعاد تصویر اثری ندارد، و تغییر اندازه تقریباً همیشه صرفهجویی بزرگتری است. عکسی به عرض ۴۰۰۰ پیکسل که در ستونی ۶۰۰ پیکسلی نمایش داده میشود بسیار بیش از آنچه هر تنظیم کدگذاری بازیابی کند بایت هدر میدهد — اول مقیاسش را کم کنید، بعد قالب انتخاب کنید.
فراداده لایهٔ سوم و جداگانهای است. حذفکنندهٔ فرادادهٔ تصویر میتواند چانکهای توصیفی PNG یا سگمنتهای کاربردی JPEG را بدون تغییر ابعاد یا محتوای کدگذاریشدهٔ تصویر حذف کند. این برای حریم خصوصی و پاکیزگی منشأ مفید است، اما به عنوان راهی برای کاهش حجم، بهندرت میتواند با تغییر اندازه یا فشردهسازی عکس رقابت کند.
پرسشهای رایج
پس همیشه از بیاتلاف استفاده کنم؟
نه. برای عکسها بااتلاف بهطرز چشمگیری کوچکتر است — اغلب پنج تا ده برابر — و در تنظیمات کیفیت معقول، اتلاف واقعاً بهسختی دیده میشود. قاعده دربارهٔ محتواست: عکسها بااتلاف خوب فشرده میشوند چون پرنویز و پرجزئیاتاند، و اسکرینشاتها بیاتلاف خوب فشرده میشوند چون تخت و تکراریاند.
چرا تصویر ریز من وقتی تبدیلش کردم بزرگتر شد؟
چون هر قالبی هزینهٔ سرآیند ثابتی دارد، و زیر چند صد بایت آن سربار بر هر چیزی که فشردهساز صرفهجویی میکند غالب است. یک PNG تکپیکسلی که به WebP تبدیل شود میتواند بزرگتر دربیاید، صرفاً چون کانتینر RIFF بیش از دادهٔ پیکسل هزینه دارد. این عادی است، و به همین دلیل مبدل باید جهتی را که واقعاً اندازه گرفته گزارش کند، نه اینکه صرفهجویی را فرض بگیرد.
آیا بیاتلاف یعنی فایل یکسان است؟
یعنی *پیکسلها* یکساناند، نه بایتها. WebP بیاتلافی که از یک PNG ساخته شده فایلی کاملاً متفاوت است که دقیقاً به همان تصویر رمزگشایی میشود — هر کانال هر پیکسل با اصل مطابق. این ویژگیای قابل آزمون است، و همان است که آزمودنش میارزد.