تغيير حجم GIF

يتضمن تغيير حجم صورة ثابتة بتنسيق JPEG أو PNG مجرد أخذ شبكة نقطية واحدة وتطبيق نواة استيفاء رياضي عليها. أما في ملف GIF المتحرك، فيحتوي الملف على عشرات أو مئات الإطارات الفردية المرتبطة بخط زمني متعاقب. ويمتلك كل إطار إزاحات إحداثيات مستقلة، وفهارس شفافية، وتعليمات خاصة للتخلص من الإطار (disposal instructions).

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

عند تغيير حجم صورة رقمية باستخدام خوارزميات الاستيفاء الحديثة (مثل التصفية ثنائية الخطية Bilinear أو التكعيبية Bicubic)، يقوم مرشح إعادة الاعتيان بدمج البكسلات المتجاورة معاً. فعلى سبيل المثال، يؤدي قياس بكسل أسود حاد مجاور لبكسل أبيض نقي إلى توليد عدة درجات وسيطة من اللون الرمادي لإنتاج انتقالات ناعمة خالية من التسنن (anti-aliasing).

في تنسيقات الألوان الحقيقية TrueColor ذات 24 بت (مثل PNG أو JPEG)، يكون هذا التنعيم غير ضار إطلاقاً لأن التنسيق يدعم 16.7 مليون لون. أما في معيار GIF89a، فإن كل إطار مقيد بصرامة بلوحة ألوان مفهرسة لا تتجاوز 256 لوناً كحد أقصى. وإن إعادة اعتيان 100 إطار بالتصفية التكعيبية يمكن أن يولد آلاف الظلال الجديدة المنعمة، مما يفكك ويدمر لوحة الألوان الأصلية المكونة من 256 لوناً بالكامل. وإذا لم يتم التعامل مع الأمر باحترافية، تعاني الرسوم المتحركة من تقطع وتدرج لوني حاد (banding)، أو ضوضاء نقطية مشوهة، أو تضخم هائل في جداول الألوان. يطبق محركنا تكميماً لونياً بطريقة Median-Cut مع إمكانية تطبيق نثر الأخطاء (dithering) بخوارزمية Floyd-Steinberg، مما يضمن دقة حواف واضحة مع الالتزام الصارم بسقف لوحة الألوان البالغ 8 بت.

يعد الحفاظ على النسب الهندسية أمراً بالغ الأهمية عند تغيير حجم العروض التوضيحية المرئية. فواجهات البرامج الممتدة بشكل مشوه، والخطوط المشوهة، والشعارات المائلة تفقد المحتوى مظهره المهني. توفر أداتنا قفلاً تلقائياً لنسبة الأبعاد يحسب الأبعاد المتناسبة في الوقت الفعلي:

• حساب العرض المستهدف: عند تعديل الارتفاع، $العرض_{الجديد} = \text{تقريب}\left(الارتفاع_{الجديد} \times \frac{العرض_{الأصلي}}{الارتفاع_{الأصلي}}\right)$ • حساب الارتفاع المستهدف: عند تعديل العرض، $الارتفاع_{الجديد} = \text{تقريب}\left(العرض_{الجديد} \times \frac{الارتفاع_{الأصلي}}{العرض_{الأصلي}}\right)$ • القياس بالنسبة المئوية: يمكنك تقليص الحجم بسهولة بنسبة 25% أو 50% أو 75% للحصول على تصغير فوري ومدروس للأبعاد. علاوة على ذلك، عند إعداد ملف GIF متحرك لتحويله لاحقاً إلى فيديو عبر أداة <a href="/ar/tools/image/gif-to-mp4/">تحويل GIF إلى MP4</a>، يتيح لك مغير الحجم فرض أبعاد بكسل زوجية (العرض والارتفاع يقبلان القسمة على 2)، تلبية لمتطلبات ترميز كتل الماكرو في معيار H.264.

يحاول العديد من منشئي المحتوى تقليل أحجام ملفات GIF المتضخمة عن طريق إسقاط الإطارات (تقليل 30 إطاراً في الثانية إلى 15 إطاراً مثلاً). ومع أن إسقاط الإطارات يقلل حجم البيانات خطياً ($O(N)$ حيث $N$ هو عدد الإطارات)، فإنه يتسبب في تقطع حركي واضح ورسوم متحركة متشنجة.

وفي المقابل، يقلل تغيير الحجم المكاني عبء البايتات بمعدل تربيعي ($O(W \times H)$). فإذا قمت بتصغير تسجيل شاشة سطح مكتب بأبعاد 1200x800 بنسبة 50% ليصبح 600x400، فإن إجمالي مساحة البكسلات ينخفض من 960,000 بكسل لكل إطار إلى 240,000 بكسل فقط—أي انخفاض هائل بنسبة 75% في حجم البكسلات عبر كل إطار منفرد! وتحتفظ الرسوم المتحركة بنسبة 100% من معدل إطاراتها الأصلي وحركتها فائقة السلاسة بينما ينكمش حجم الملف من 20 ميجابايت إلى أقل من 5 ميجابايت.

من الأخطاء البرمجية الشائعة في أدوات GIF الرديئة عبر الإنترنت حدوث خلل في التزامن الزمني أثناء تغيير الحجم. وتخضع مدة كل إطار في ملف GIF لحقل مكون من 2 بايت داخل كتلة ملحق التحكم في الرسومات (GCE)، وتُقاس بأجزاء من المائة من الثانية (1/100 ثانية).

يحلل محرك تغيير الحجم لدينا ويعكس قيم التأخير الدقيقة بالمللي ثانية لكل إطار أصلي. وسواء كانت الرسوم المتحركة الخاصة بك تستخدم فترات إطارات منتظمة (10 إطارات في الثانية = 10cs تأخير لكل إطار) أو توقيتاً متغيراً للإطارات (مثل التوقف على شريحة معلومات ثابتة لمدة ثانيتين كاملتين أي 200cs مع تشغيل الانتقالات السريعة عند 4cs)، فإن أداتنا تحافظ على التنسيق الزمني الدقيق. وتعمل الرسوم المتحركة الناتجة بالسرعة الفيزيائية التي قصدها المؤلف تماماً.

في بنية الويب المتجاوبة، يؤدي تقديم رسوم متحركة مخصصة لسطح المكتب بدقة عالية إلى الأجهزة المحمولة إلى إهدار جسيم في بيانات الاتصال واستنزاف بطارية الهاتف. ولا تستفيد شاشة الهاتف الذكي ذات منفذ عرض CSS يبلغ 390 بكسل على الإطلاق من تحميل ملف GIF بعرض 1800 بكسل، ومع ذلك يجب على معالج الهاتف استهلاك طاقة المعالجة لفك تشفير ملايين البكسلات الزائدة في الذاكرة.

ومن خلال إنشاء متغيرات مصغرة ومناسبة (مثل 480 بكسل لمنافذ عرض الهواتف، و800 بكسل للأجهزة اللوحية، و1200 بكسل لسطح المكتب)، يمكن لمطوري الويب تقديم أصول مخصصة باستخدام عناصر HTML القياسية المتجاوبة `<picture>`. وبالاقتران مع أداة <a href="/ar/tools/image/compress-gif/">ضاغط GIF</a> الخاصة بنا، تحقق صفحات الويب الخاصة بك نتائج فائقة السرعة في مؤشر أكبر رسم للمحتوى (LCP) وترتيباً متقدماً في مؤشرات أداء الويب الأساسية.

تسجل فرق التطوير المؤسسية ومصممو واجهات المستخدم والمستشارون القانونيون بانتظام رسوماً متحركة تعرض أدوات برمجية داخلية، ونماذج أولية للمنتجات، وتدفقات حسابات العملاء، ثم يغيرون أحجامها. ويؤدي نقل ملفات الوسائط هذه إلى خوادم تابعة لجهات خارجية إلى مخاطر امتثال فورية بموجب أطر عمل GDPR وCCPA وSOC 2.

تعمل أداتنا بالكامل داخل متصفحك باستخدام WebAssembly وWeb Workers. وتتم قراءة البيانات الثنائية الخام مباشرة من نظام ملفاتك المحلي إلى ذاكرة المتصفح، ومعالجتها عبر خيوط المعالجة متعددة الأنوية، وتنزيلها محلياً. ولا يتم إرسال بكسل واحد أو بايت واحد عبر اتصال شبكة خارجي على الإطلاق.