كانت لدي قاعدة ضغط تبدو بسيطة ومريحة: ترميز AVIF بأقل جودة ما زالت تحقق هدف SSIMULACRA2 بقيمة 60. وفي مجموعات الصور الكبيرة كنت أسمح لعينة تمثيلية واحدة بالهبوط إلى 58، بينما يجب أن تبقى بقية العينات عند 60 أو أعلى.
مع PNG والصور المصدرية العادية كنت مرتاحًا لهذه القاعدة. ثم بدأت أتعامل مع ملفات WebP كانت قد ضُغطت بالفعل من أصول أعلى جودة قبل أن تصل إليّ.
أصل أعلى جودة: ~2 MB
↓
WebP مضغوط بفقد: ~100 KB
↓
AVIFهل ينبغي السماح للتحويل الثاني بالحصول على 60 مقابل ملف WebP؟ في البداية ظننت أن الإجابة نعم. فالدرجة 60 تظل 60. لكن المشكلة الحقيقية كانت أن الصورة المرجعية نفسها تغيرت.
المقياس لم يكن مخطئًا، بل المرجع هو الذي تغير
يقارن SSIMULACRA2 صورة مرجعية بصورة مشوهة ويقيّم الفرق الإدراكي بين هذين المدخلين تحديدًا. وقد صُمم ليتفاعل مع أضرار الضغط مثل التمويه والرنين والحواف المصطنعة، كما تشمل مواد التقييم المنشورة تشوهات ناتجة عن JPEG وWebP وAVIF وغيرها. تشرح وثائق](https://github.com/cloudinary/ssimulacra2/blob/main/README.md%22>وثائق) SSIMULACRA2 المقياس ومستويات الجودة التقريبية.
عندما أرمّز AVIF مباشرة من مصدر جيد، تكون المقارنة عمليًا source → AVIF. عندها تصف درجة 60 الضرر الذي أضافه هذا التحويل.
أما مع WebP مضغوط مسبقًا بفقد، فالتاريخ الحقيقي مختلف:
original
↓ first lossy encode
WebP
↓ second lossy encode
AVIFلكن SSIMULACRA2 يرى فقط WebP → AVIF. ولا يعرف شيئًا عن الأصل الذي كان موجودًا قبل WebP. أي عيوب موجودة أصلًا في WebP أصبحت جزءًا من المرجع.
لذلك يمكن لدرجة 60 أن تخبرني بأن AVIF لم يبتعد كثيرًا عن WebP، لكنها لا تخبرني بمدى ابتعاد AVIF النهائي عن الأصل المفقود.
التحويل بين صيغتين بفقد ينشئ ميزانية جودة ثانية
لنفترض أن الأصل يحتوي على تدرج لوني نظيف. يضيف المرمّز الأول قدرًا بسيطًا من التقطّع اللوني، لكن WebP ما يزال مقبولًا. بعد ذلك أرمّز WebP إلى AVIF. يستطيع SSIMULACRA2 معاقبة التدهور الإضافي الذي يضيفه ترميز AVIF، لكنه لا يستطيع معاقبة الضرر الموجود أصلًا في الصورة المرجعية.
لهذا لا يساوي الترميز من صورة مضغوطة مسبقًا بفقد الترميز المباشر من أفضل مصدر متاح. وتشير مناقشة في مشروع](https://github.com/AOMediaCodec/libavif/discussions/2640%22>مشروع) libavif إلى الفكرة العامة نفسها: يمكن أن تنتقل عيوب الضغط الموجودة أصلًا إلى AVIF الجديد عندما يكون الإدخال مضغوطًا مسبقًا.
هذا لا يعني أن AVIF يضخم تلقائيًا كل عيب في WebP، ولا يعني أن التحويل يجب منعه دائمًا. المعنى هو أن المرمّز الثاني يبدأ عمله بعد أن استُهلك جزء من ميزانية الجودة الأصلية.
السياسة التي انتهيت إلى استخدامها
- مصدر أساسي أو عالي الجودة: الهدف 60، والحد الأدنى لعينة واحدة 58.
- WebP بلا فقد: الهدف 60، والحد الأدنى 58.
- نسخة مشتقة معروفة بأنها مضغوطة بفقد: الهدف 65، والحد الأدنى 63.
الفارق المهم ليس JPEG مقابل WebP، بل مصدر أساسي مقابل نسخة مشتقة معروفة بأنها مضغوطة بفقد.
يمكن أن يكون WebP بلا فقد. وتصف مواصفة](https://developers.google.com/speed/webp/docs/webp_lossless_bitstream_specification%22>مواصفة) WebP بلا فقد وضعًا يعيد قيم البكسلات بدقة، وبالتالي لا يوجد جيل سابق من الفقد يحتاج إلى تعويض. وبالمقابل، فإن ملف JPEG أعرف أنه مر بعدة عمليات ضغط بفقد يستحق الحذر نفسه الذي أتعامل به مع WebP مضغوط مسبقًا.
لماذا 65؟
لا توجد قاعدة في SSIMULACRA2 تقول إن الجيل الثاني من الضغط بفقد يحتاج إلى خمس نقاط إضافية بالضبط. لم أجد مثل هذه القاعدة لأنها غير موجودة. الرقم 65 سياسة هندسية، وليس خاصية في المقياس.
مستويات الجودة المنشورة تعطي سياقًا مفيدًا: تقريبًا، 50 تعادل جودة متوسطة أو مقبولة، بينما 70 تعادل جودة عالية أو جيدة. وهذا يضع 60 في نطاق ضغط ويب هجومي نسبيًا، وليس في نطاق قريب من عدم وجود فقد بصري.
في التحويل المباشر من مصدر جيد، أقبل إنفاق هذا القدر من الجودة الإدراكية مقابل ملفات أصغر. أما في الجيل الثاني من الضغط بفقد، فأريد ميزانية أصغر للتشوه الإضافي.
فكرت في 70، لكنها ستدفع كل الصور المعاد ترميزها إلى منطقة جودة أكثر صرامة بوضوح. في الصفحات التي تحمل عددًا كبيرًا من الصور، وخصوصًا على اتصالات الهاتف المحمول، تصبح هذه البايتات الإضافية مهمة. لم يكن لدي دليل يبرر إجبار كل صورة مضغوطة مسبقًا على 70، لذلك اخترت 65 كحل وسط محافظ.
لماذا 65/63 بدلًا من 65/62؟
كانت سياستي الأصلية 60/58، أي السماح لعينة تمثيلية واحدة بالهبوط نقطتين تحت الهدف الرئيسي. وعندما رفعت الهدف إلى 65، فإن الحفاظ على السياسة نفسها يقود طبيعيًا إلى 65/63.
60 - 58 = 2
65 - 63 = 2استخدام 62 يصنع استثناءً من ثلاث نقاط. وهذا يجعل العينات العادية أكثر صرامة وفي الوقت نفسه يجعل أسوأ عينة أكثر تساهلًا. لم أجد سببًا تقنيًا لتوسيع هذا الاستثناء تحديدًا للمدخلات التي مرت أصلًا بضغط بفقد.
لا 63 ولا 65 رقم سحري. الفائدة هي أن تبقى السياسة متسقة داخليًا.
تحول ملف من 2 MB إلى 100 KB لا يخبرني بالجودة البصرية
أتجنب عمدًا اشتقاق حدود SSIMULACRA2 من نسبة الضغط. تقلص ملف من 2 MB إلى 100 KB يبدو كبيرًا، لكن حجم الملف وحده لا يقول الكثير عن مقدار التدهور الإدراكي.
الدقة، وتعقيد الصورة، والضجيج، والمساحات المسطحة، ورسوم الخطوط، وتقليل عينات اللون، والصيغة السابقة كلها تؤثر في كفاءة الضغط. وتقارن دراسة](https://developers.google.com/speed/webp/docs/webp_study%22>دراسة) Google لضغط WebP بين الصيغ عند مستويات جودة متقاربة بدل افتراض أن الأحجام المتساوية تعني جودة بصرية متساوية.
لذلك لا أستخدم قواعد مثل أصغر 20× → الهدف 65. ما يهمني هو ما إذا كان الملف الحالي نسخة مشتقة معروفة بأنها مضغوطة بفقد، لا مدى إثارة نسبة تقليص الحجم.
إذا كان الأصل ما يزال موجودًا، فلا أحول WebP
إذا كان الأصل عالي الجودة وWebP الصغير المضغوط بفقد موجودين معًا، فإنني أرمّز AVIF مباشرة من الأصل وأستخدم سياسة 60/58 العادية.
preferred:
original → AVIF
avoid when possible:
original → lossy WebP → AVIFرفع هدف الجيل الثاني لا يعيد المعلومات التي فُقدت أثناء الترميز الأول. 65 يجعل AVIF أقرب إلى WebP، و70 يجعله أقرب أكثر. لا واحد منهما يعيد الأصل المفقود.
خطأ التنفيذ كان أهم من النقاش حول 62 أو 63
أثناء مراجعة السياسة وجدت مشكلة أخطر في منطق المرمّز. كان الكود يحتوي بالفعل على أهداف منفصلة حسب الصيغة وعلى دالة تستطيع إرجاع هدف مختلف لـ WebP، لذلك بدا تغيير WebP من 60 إلى 65 بسيطًا.
لكنه لم يكن كذلك. قرار البحث التكيفي عن الجودة ظل يستخدم الهدف العام والحد الأدنى العام. وكان الهدف الخاص بالصيغة يُستخدم لاحقًا لوصف النتيجة بأنها ناجحة أو تحت الهدف، من دون أن يتحكم بالضرورة في القرار الذي يختار جودة AVIF النهائية.
هذا يخلق فشلًا خفيًا: قد توصف عينة WebP بشكل صحيح بأنها تحت هدفها 65، بينما يقبل البحث التكيفي الجودة نفسها لأن شرط النجاح العام ما يزال 60.
intended WebP target: 65
actual score: 61.2
format-aware label: below target
global search rule: pass if target is still 60أي حد جودة لا قيمة له إذا لم يشارك فعليًا في القرار الذي يختار الملف الناتج.
التصميم الأكثر أمانًا هو جعل الحدود جزءًا من سياسة كل عينة
أفضل الآن التعامل مع الحدود كخصائص للمصدر نفسه، لا كثوابت شكلية مرتبطة بالصيغة. بصيغة مبسطة:
if sample is a known lossy derivative:
target = 65
floor = 63
else:
target = 60
floor = 58
reject if any sample is below its floor
allow at most one sample below its targetالمهم أن الحدود نفسها التي تصف النتيجة هي التي تتحكم أيضًا في قبولها أو رفضها.
سياسة أخذ العينات مهمة أيضًا
لا أحتاج إلى اختبار كل صورة عند كل قيمة جودة مرشحة لـ AVIF. يختار خط المعالجة حتى عشر عينات تمثيلية من JPEG وPNG وWebP موزعة على نطاق البايتات لكل بكسل.
في المجموعات التي تحتوي على عشر صور أو أقل يجب أن تحقق كل عينة الهدف المعتاد. وفي المجموعات الأكبر يمكن لعينة واحدة استخدام الحد الأدنى المنخفض، بينما يجب أن تحقق بقية العينات الهدف الرئيسي.
أخذ العينات يجعل البحث عمليًا، لكنه يعني أيضًا أنني لا أريد جعل قاعدة الاستثناء متساهلة بلا داع. العينات المختارة تمثل المجموعة، لكنها لا تثبت أن كل صورة غير مختبرة تتصرف بالطريقة نفسها.
التجربة التي يمكن أن تحل محل هذه القاعدة التقريبية
أقوى إجابة تتطلب الاحتفاظ بالأصول الحقيقية لمجموعة تمثيلية واختبار السلاسل كاملة:
A: original → AVIF, target 60
B: original → lossy WebP → AVIF, target 60
C: original → lossy WebP → AVIF, target 63
D: original → lossy WebP → AVIF, target 65
E: original → lossy WebP → AVIF, target 70لكل حالة سأقيس الحجم النهائي، وSSIMULACRA2 مقابل الأصل الحقيقي، وSSIMULACRA2 مقابل WebP الوسيط، وجودة المرمّز المختارة، إضافة إلى الفحص البصري اليدوي للصور الصعبة.
لم أنفذ هذه التجربة المحكمة على مجموعة كبيرة وتمثيلية بما يكفي من الأصول المحفوظة، لذلك لا أستطيع الادعاء بأن 65 هو الأمثل عالميًا. وهذه حدود مهمة للاستنتاج.
AVIF لا يستحق تلقائيًا عملية ترميز إضافية
إذا كان المصدر الوحيد المتبقي WebP بحجم 100 KB وكان AVIF الذي ينجح عند 65/63 حجمه 96 KB، فسأشكك في جدوى التحويل. توفير 4 KB قد لا يبرر جيلًا إضافيًا من الضغط بفقد وتعقيدًا إضافيًا في المعالجة.
أما إذا تحول WebP نفسه من 100 KB إلى AVIF بحجم 65 KB مع استمرار نجاحه في سياسة الجودة، فتصبح الصفقة أكثر إقناعًا بكثير في الصفحات كثيفة الصور.
أي تحويل بين الصيغ يجب أن يجيب عن سؤالين منفصلين: هل التشوه الإضافي مقبول؟ وهل تقليص الحجم كبير بما يكفي ليكون مهمًا؟ النجاح في الأول لا يضمن الثاني.
القاعدة التي أستخدمها الآن
إذا كان لدي أفضل أصل متاح، أرمّز منه مباشرة وأستخدم 60/58 لهذا النوع من أعباء الويب. وإذا كان WebP بلا فقد أستخدم 60/58 أيضًا. وإذا كان الملف الوحيد المتبقي نسخة مشتقة معروفة بأنها مضغوطة بفقد، أستخدم ميزانية أكثر صرامة للجيل الثاني، وهي حاليًا 65/63. وإذا كان AVIF لا يقلص الحجم إلا قليلًا، فقد أحتفظ بـ WebP الموجود.
الدرس الأعمق ليس أن WebP يحتاج إلى رقم خاص في SSIMULACRA2. بل إن مقياس الجودة كامل المرجع يجيب فقط عن السؤال الذي تمثله صورته المرجعية.
إذا كان المرجع قد فقد معلومات بالفعل، فتعني الدرجة العالية «قريب من هذا المرجع»، لا «قريب من الصورة التي كانت موجودة قبله». عندما بدأت أتعامل مع أصل الصورة ومسارها السابق كجزء من سياسة الضغط، توقفت الحدود عن الظهور كأرقام اعتباطية للمرمّز، وأصبحت ميزانيات لأجيال مختلفة من الفقد.