شرط‌بندی‌هایم پیش از فشرده‌سازی کارت‌ها

2026-09-01T00:00:00+00:00

فشرده‌سازی نباید هیچ چیزی را از دست بدهد، حتی اگر مجبور شویم اختراعش کنیم. این جمله را با همین قاطعیت در برنامه نوشتم، بعد از اولین build. دو خط بعد نوشته بودم که ویدیوی lossless با کارت‌هایی که بر اساس شباهت مرتب شده‌اند یک راه است، و بالاتر jpegtran را کنار گذاشته بودم چون «بدون اتلاف به حساب نمی‌آید». فقط وقتی نشستم شرط‌ها را بنویسم و مجبور شدم تعریف کنم چه چیزی را اندازه می‌گیرم متوجه شدم، و اندازه‌گیری یعنی باید بگویی نسبت به چه. بدون اتلاف نسبت به چه؟ جوابی نداشتم. یک کلمه را برای سه چیز به کار برده بودم و نفهمیده بودم.

چرا zstd زورش به JPEG نمی‌رسد

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

پس «بدون اتلاف» روی JPEG سه معنا دارد و فقط یکی‌شان شایستهٔ این اسم است. اولی بسته‌بندی دوبارهٔ JPEG است، طوری که عملیات معکوس فایل اصلی را بایت به بایت برگرداند. JPEG XL همین کار را می‌کند: ضرایبِ از قبل گردشده را برمی‌دارد و با رمزگذار آنتروپی بهتری بازنویسی می‌کند و آن‌قدر اطلاعات نگه می‌دارد که بشود برگرداندش. اتلاف JPEG سر جایش است، اما بسته‌بندی فشرده‌تر شده.

دومی ذخیرهٔ دوبارهٔ همان JPEG با jpegtran یا jpegoptim است. پیکسل‌ها یکسان می‌مانند و بایت‌ها عوض می‌شوند. بدون اتلاف برای کسی که نگاه می‌کند، نه برای کسی که هش را چک می‌کند. و اگر منبع از قبل بهینه شده باشد، مثل فایل‌های Scryfall، سودش به صفر میل می‌کند.

سومی همان چیزی است که من بی‌آنکه بدانم پیشنهاد می‌کردم: رمزگشایی پیکسل‌ها و فشرده‌سازی دوباره با یک کدک بدون اتلاف دیگر، PNG، WebP یا ویدیو با FFV1. به نظر خالص‌ترین معناست و بدترینش است. کدک جدید پیکسل‌هایی می‌گیرد که نویز گردکردن JPEG را مثل سیگنال با خود دارند و بیت خرج می‌کند تا آن نویز را با دقت بازنمایی کند. همه‌چیز نشان می‌دهد نتیجه بزرگ‌تر از JPEG اصلی می‌شود، نه کوچک‌تر. این را نوشتم و هنوز باورم نمی‌شد، برای همین شد شرط.

یک چیز چهارم هم هست که معنا نیست، یک حفره است. در ۲۰۱۶ گروهی از دانشگاه تیانجین و Microsoft Research Asia مقالهٔ "Lossless Compression of JPEG Coded Photo Collections" را منتشر کردند: مجموعه‌ای از عکس‌های JPEG را به شکل یک شبه‌ویدیو مرتب می‌کنند، تفاوت میان عکس‌های همسایه را جبران می‌کنند، افزونگیِ باقی‌مانده را در حوزهٔ فرکانس حذف می‌کنند، و با این همه هر JPEG اصلی را بدون از دست دادن حتی یک بیت برمی‌گردانند. میانگین صرفه‌جویی بیش از ۳۱٪. این دقیقاً همان چیزی است که ایدهٔ اختراعی من می‌خواست باشد، فقط درست انجام شده. اما پیاده‌سازی بازی پیدا نکردم و قرار هم نبود آن هفته کدک بنویسم. پس چیزی که می‌توانستم اندازه بگیرم سقف با ابزارهای موجود بود. سقف واقعی، اگر نتیجهٔ آن مقاله روی کارت‌های Magic تکرار شود، بالاتر است و می‌خواهم پیش از گفتن عددم این را بگویم.

روی چه شرط بستم و چرا

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

ویدیوی AV1 با اتلاف خیلی بهتر از JPEGهای جدا فشرده می‌کند؟ بله، اولین build همین را نشان داد و در درماتوسکوپی هم دیده بودم. هرچه کارت‌های همسایه شبیه‌تر، سود ویدیو بیشتر؟ بله، و با قدرت: پایگاه داده ۱۰۰ هزار چاپ برای ۵۲ هزار تصویرسازی دارد، تقریباً نیمی از کارت‌ها تصویری را تکرار می‌کنند که روی کارت دیگری هست، و همه یک قاب مشترک دارند. اگر سودی از ویدیو هست، همین‌جاست.

سریع کردن ویدیو بایت کم می‌کند؟ یکی از MP4ها را در CapCut انداخته بودم، شصت برابر سریعش کرده بودم و فایل نصف حجم بیرون آمده بود. شرط می‌بندم بله، و اگر درست باشد ارزان‌ترین چیز فهرست است. tar با zstd چیزی می‌برد؟ فکر می‌کنم نه، به همان دلیل بخش قبل. و مرتب‌سازی بر اساس شباهت برای کارت‌های یکتا هم کار می‌کند؟ فکر می‌کنم نه، قبلاً دیده‌ام مرتب‌سازی روی دیتاست دیگری هیچ کاری نکرد، اما قاب مشترک مرا مردد می‌کند.

و همانی که از همه بیشتر می‌خواستم: بدون اتلافی بهتر از JPEG وجود دارد، «حتی اگر اختراعش کنیم». بعد از نوشتن آن سه معنا وسط شرط نظرم عوض شد. نامزد شد JPEG XL، و ویدیوی بدون اتلافِ مرتب‌شده بر اساس شباهت، یعنی ایدهٔ اختراعی، می‌بازد. دو شرطی که بیشتر از همه دلم می‌خواست درست باشند، CapCut و بدون اتلاف، همان‌هایی بودند که کمتر از همه می‌توانستم از آن‌ها دفاع کنم. این معمولاً نشانه است.

آزمون بدون اتلاف همان شب اجرا شد، ده نسل روی همان ۲۰۴۸ کارت. tar با zstd دقیقاً یک به یک داد. ذخیرهٔ دوباره با jpegtran کمتر از یک درصد داد، JPEGهای Scryfall از قبل بهینه‌اند. سقف، بسته‌بندی دوباره با JPEG XL بود، حدود ۱۱٪ کوچک‌تر، با ۲۰۴۸ فایل اصلی که بازسازی و با هش تأیید شدند. بالا بردن تلاش انکودر تا حداکثر کمتر از یک درصد بیشتر می‌دهد در ازای شش برابر زمان، پس پیش‌فرض روی تلاش متوسط ماند.

و ایدهٔ اختراعی بد باخت. FFV1 و x264 بدون کوانتیزه‌سازی، با کارت‌های مرتب‌شده بر اساس شباهت، سه تا چهار برابر بزرگ‌تر از JPEG اصلی شدند. مرتب‌سازی در این رژیم حجم را تقریباً تکان نداد، کسری از یک مگابایت در فایلی چندصد مگابایتی. پیکسل رمزگشایی‌شدهٔ JPEG نویز دارد و هیچ کدکی نویز را پیش‌بینی نمی‌کند، همان‌طور که صبح نوشته بودم بی‌آنکه باور کنم.

این شد پروفایل آرشیو Nest: کسی که حاضر نیست هیچ چیز از دست بدهد JPEG XL بسته‌بندی‌شده را می‌گیرد، ۳٫۶ گیگابایت برای کل مجموعه، و هر JPEG هر وقت خواسته شود بیت به بیت برمی‌گردد. عددی نیست که می‌خواستم. عددی است که می‌شود با هش از آن دفاع کرد، و من این را ترجیح می‌دهم. شرط‌های دیگر، آن‌هایی که با اتلاف بودند، داشتند اجرا می‌شدند وقتی این را می‌نوشتم. از نگاه کردن به شرط CapCut از همان موقع می‌ترسیدم.

Brenner Cruvinel - codec

شرط‌بندی‌هایم پیش از فشرده‌سازی کارت‌ها

چرا zstd زورش به JPEG نمی‌رسد

روی چه شرط بستم و چرا