لماذا حجم GIF كبير إلى هذا الحد؟ 256 لوناً وLZW وبنية الإطارات

صُمّمت صيغة GIF عام 1987 ولم تتغير تقريباً منذ ذلك الحين. وما زالت مستخدمة على نطاق واسع اليوم، لكنها عديمة الكفاءة بصورة صارخة إلى جانب البدائل الحديثة. نفحص في هذا المقال البنية الداخلية للصيغة ونشرح سبب إنتاجها ملفات بهذا الحجم، وأين تبقى منطقية.

نموذج اللون القائم على اللوحة

أبرز خصائص GIF هي طريقة تخزين اللون فيها.

ففي صيغ الصور الحديثة يحمل كل بكسل قيمة لونه الخاصة: 8 بت للأحمر، و8 للأخضر، و8 للأزرق — أي نحو 16.7 مليون لون ممكن.

أما GIF فيعمل بطريقة مختلفة. إذ يحتفظ بـجدول ألوان (لوحة)، ويسجّل كل بكسل فهرساً في هذا الجدول. ولا تسع اللوحة أكثر من 256 مدخلاً.

Palette:
  0 → #000000 (black)
  1 → #FF0000 (red)
  2 → #00FF00 (green)
  ...
  255 → #FFFFFF (white)

Pixel data: 0, 0, 1, 1, 2, 0, 255, ...

الميزة: يشغل كل بكسل 8 بت بدل 24 بت. وكان هذا مكسباً جاداً في ظروف الذاكرة عام 1987.

العيب: لا يمكن أن تحوي الصورة أكثر من 256 لوناً مختلفاً.

الثمن البصري لـ 256 لوناً

يحوي إطار الفيديو النمطي عشرات آلاف الألوان المختلفة. وخفض ذلك إلى 256 يستلزم تكميم اللون (color quantization) — إذ تحلّل الخوارزمية ألوان الصورة وتختار الألوان الـ 256 الأكثر تمثيلاً، ثم تُسند كل بكسل إلى أقرب مدخل في اللوحة.

والنتائج الظاهرة لذلك:

التشريط (banding). يتحول التدرج الناعم — السماء، أو انتقال الضوء، أو الظل — إلى أشرطة لونية مصمتة. فتضيع الاستمرارية وينشأ مظهر مدرّج.

تشوّه لون البشرة. تحوي وجوه البشر درجات متقاربة كثيرة تعجز اللوحة عن التمييز بينها. والنتيجة مظهر مبقّع عليل.

انزياح اللون. تُقرَّب الألوان التي لا يوجد مقابل دقيق لها في اللوحة إلى أقرب جار؛ فقد ينزاح الأزرق المؤسسي لعلامتك التجارية إلى أزرق مختلف قليلاً.

نتيجة متفاوتة بحسب نوع المحتوى:

| المحتوى | النتيجة عند 256 لوناً | |---|---| | تسجيل شاشة، واجهة | جيدة عموماً (الألوان قليلة أصلاً) | | رسوم متحركة، رسم توضيحي | جيدة | | نص ورسوم بيانية | جيدة جداً | | مشهد طبيعي | تشريط واضح | | وجه بشري، بشرة | مبقّع | | مشهد ليلي، تدرج | سيئة |

التذبيب: حيلة بصرية

يُستخدم التذبيب (dithering) لتخفيف التشريط. والفكرة كالتالي: نثر لونين من اللوحة في بكسلات متجاورة، بحيث يبدو من بُعد أنك ترى الدرجة الوسطى بينهما.

وهو المبدأ نفسه الذي تُشكَّل به درجات الرمادي بنقاط سوداء في صور الصحف.

ويحسّن التذبيب الجودة البصرية تحسيناً واضحاً — فتختفي الأشرطة وتنعم التدرجات. لكن له ثمناً ينعكس مباشرة على حجم الملف.

ضغط LZW وتناقض التذبيب

يستخدم GIF ضغطاً بلا فقد اسمه LZW‏ (Lempel-Ziv-Welch). ويعمل LZW بإيجاد الأنماط المتكررة في البيانات واستبدالها برموز قصيرة. فمثلاً تُرمَّز متتالية مثل "0,0,0,0,0,0" برمز قصير جداً.

وهذا يعمل جيداً جداً في الصور ذات مساحات اللون المصمت — الشعارات، والرسوم البيانية، ولقطات شاشة الواجهات.

والآن تأمّل أثر التذبيب: فهو يجعل المساحات المصمتة مشوّشة عن قصد. فبدل "0,0,0,0,0,0" ينشأ نمط مثل "0,1,0,1,1,0".

ولا يجد LZW تكراراً في هذه الضوضاء. فتنخفض كفاءة الضغط ويكبر الملف.

أي أن التذبيب يرفع الجودة البصرية لكنه يرفع حجم الملف أيضاً. وعليك أن تقيم توازناً بين الاثنين عند إنتاج GIF.

التحسين بين الإطارات: آلية محدودة

يخزّن GIF الحركة على شكل إطارات متعاقبة. ويمكن أن يكون لكل إطار مدته الخاصة (قيمة التأخير) ولوحته الخاصة.

وتقدم الصيغة قدراً من التحسين:

الإطار الجزئي. قد يحتوي الإطار على منطقة مستطيلة متغيرة فقط بدل الصورة كاملة. وهذا يحقق مكسباً جاداً في حركة ذات خلفية ثابتة.

البكسل الشفاف. يمكن تعليم البكسلات غير المتغيرة كشفافة ليظهر الإطار السابق من خلفها.

طريقة التخلص (disposal method). تحدد ما سيحل بالإطار الحالي قبل الإطار التالي: أن يبقى، أو يعود إلى الخلفية، أو يعود إلى الحالة السابقة.

وهذه أمور مفيدة، لكنها تبقى بدائية إلى جانب مرمّزات الفيديو الحديثة. والسبب: GIF لا يعرف مفهوم الحركة.

فمرمّز الفيديو يستطيع اكتشاف انزياح جسم 12 بكسلاً إلى اليمين وأن يقول «خذ هذه الكتلة من الإطار السابق وانقلها 12 بكسلاً يميناً» — أي بضعة بايتات. أما GIF فلا يستطيع إلا قول «هذه المنطقة المستطيلة تغيّرت، وهذه بكسلاتها الجديدة» — أي آلاف البايتات.

وحين توجد كاميرا متحركة أو انتقال بين المشاهد، يصبح تحسين الإطار الجزئي عديم الجدوى تماماً؛ إذ يتغير كل بكسل في كل إطار.

مقارنة بالأرقام

للمحتوى نفسه بمدة 5 ثوانٍ ودقة 480×270 بكسل و15 إطاراً/ث، تقريبياً:

| الصيغة | الحجم النمطي | اللون | |---|---|---| | GIF | 3–8 ميجابايت | 256 | | WEBP متحرك | 800 كيلوبايت – 2 ميجابايت | ألوان كاملة | | APNG | 2–5 ميجابايت | ألوان كاملة + ألفا | | MP4 (H.264) | 200–500 كيلوبايت | ألوان كاملة | | WEBM (VP9) | 150–400 كيلوبايت | ألوان كاملة |

فـ MP4 يحمل المحتوى نفسه بنحو عُشر حجم GIF وبجودة لونية أفضل بكثير. وهذا الفارق ليس تحسيناً صغيراً بل تفوّق فئوي.

ثلاثة عوامل تحدد حجم الملف

يكبر حجم GIF بـحاصل ضرب ثلاثة متغيرات:

المدة × معدل الإطارات = عدد الإطارات الكلي. 10 ثوانٍ × 20 إطاراً/ث = 200 إطار. و5 ثوانٍ × 12 إطاراً/ث = 60 إطاراً. أي الثلث.

الدقة = عدد البكسلات في الإطار. وخفض العرض إلى النصف يخفض مجموع البكسلات إلى الربع.

وحين تضرب هذه في بعضها:

• 10 ثوانٍ، 20 إطاراً/ث، 800×450: 200 إطار × 360000 بكسل = 72 مليون بكسل
• 5 ثوانٍ، 12 إطاراً/ث، 400×225: 60 إطاراً × 90000 بكسل = 5.4 مليون بكسل

أي فارق نحو 13 ضعفاً. ولذلك ينبغي عند خفض حجم GIF معالجة الإعدادات الثلاثة معاً لا إعداد واحد.

العامل الرابع: مقدار الحركة. فالمشهد الثابت يستفيد من تحسين الإطار الجزئي ويخرج صغيراً جداً. أما المشهد ذو الكاميرا المتحركة فيخرج أكبر بأضعاف بالإعدادات نفسها.

لماذا لا تنتشر البدائل الحديثة

WEBP المتحرك وAPNG متفوقان على GIF من كل الوجوه: ألوان كاملة، وشفافية ألفا، وضغط أفضل بكثير. وكل المتصفحات الحديثة تدعمهما.

وما يعوق انتشارهما ليس تقنياً بل عادة المنظومة:

• تتعامل تطبيقات المراسلة مع GIF كنوع خاص وتقدم مكتبات بحث له.
• تعرف برمجيات المنتديات وأنظمة الويكي وسوم GIF.
• تعرض عملاء البريد الإلكتروني حركة GIF (ولا تشغّل الفيديو).
• يقول الناس «أرسل GIF»؛ ولا يقولون «أرسل WEBP متحركاً».

وثمة مفارقة: كثير من المنصات يحوّل ملف GIF الذي ترفعه إلى MP4 في الخلفية ثم يقدّمه لك على أنه GIF. أي أنك حين تقول «أشارك GIF» تكون في الواقع تشارك فيديو.

النهج الصحيح على الويب

إذا أردت عرض حركة على موقعك الإلكتروني، فلا سبب لاستخدام GIF:

<video autoplay muted loop playsinline>
  <source src="animation.webm" type="video/webm">
  <source src="animation.mp4" type="video/mp4">
</video>

وهذا يعطي سلوكاً مطابقاً تماماً لسلوك GIF — بلا صوت، وتشغيل تلقائي، وتكرار لا نهائي — لكن بعُشر الحجم وبجودة ألوان كاملة.

والخاصية playsinline تمنع انتقال الفيديو إلى ملء الشاشة في متصفحات الجوال؛ وهي ضرورية للسلوك الشبيه بـ GIF.

والفارق من ناحية سرعة الصفحة صارخ: فاستبدال فيديو بحجم 400 كيلوبايت بملف GIF بحجم 5 ميجابايت يقصّر زمن التحميل تقصيراً واضحاً.

المواضع التي يبقى فيها GIF صحيحاً

• البيئات التي لا تدعم الفيديو: بعض برمجيات المنتديات، وأنظمة الويكي القديمة.
• البريد الإلكتروني: لا يشغّل معظم العملاء الفيديو لكنهم يعرضون GIF (وبعضهم يعرض الإطار الأول فقط).
• مكتبات GIF في تطبيقات المراسلة.
• الحركات البسيطة قليلة الألوان: مؤشرات التحميل، وحركات الأيقونات الصغيرة — فحدّ 256 لوناً ليس مشكلة هنا أصلاً، ويخرج GIF بحجم معقول.

الخلاصة

يعمل GIF بنموذج قائم على لوحة من 256 لوناً، وهذا يفضي إلى التشريط والتبقّع في المحتوى الفوتوغرافي؛ والتذبيب يخفف ذلك بصرياً لكنه يضخّم الملف بخفض كفاءة ضغط LZW. ولا تستفيد الصيغة من التكرار بين الإطارات إلا استفادة بدائية — فلا مفهوم للحركة لديها، وكل ما تستطيعه تخزين المناطق المستطيلة المتغيرة. والنتيجة أنها تشغل للمحتوى نفسه نحو عشرة أضعاف ما تشغله مرمّزات الفيديو الحديثة. ولأن حجم الملف يكبر بحاصل ضرب المدة ومعدل الإطارات والدقة، فينبغي أن يتناول جهد التصغير الثلاثة معاً. أما في استخدام الويب فلم يبقَ لـ GIF جانب يمكن الدفاع عنه تقنياً: فالفيديو بخصائص autoplay muted loop يؤدي المهمة نفسها بصورة أفضل بكثير.