دعم المتصفحات والأداء لإزالة الخلفية على الجهاز

ما يجب أن يوفره المتصفح

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

تشغّل WebAssembly النموذج داخل بيئة المتصفح المعزولة، ما يُبقي لقطات الأداة التي تعمل على الجهاز على جهازك؛ أما bgremover.ai فترفعها إلى خوادم GPU لدينا، كما يشرح دليل كيف تعمل إزالة الخلفية. والاستدلال في معظمه ضرب مصفوفات، لذا يحتاج إلى GPU: تتيحه WebGL عبر واجهة رسومات، وWebGPU عبر واجهة حوسبة.

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

ثلاثة مسارات للتنفيذ

WebGL حل التفافي وليس تصميمًا مقصودًا: فالواجهة صُممت لرسم المثلثات، ونقل البيانات عبر الخامات يستهلك الوقت. لكنها تبقى الخيار الافتراضي العملي. وتتنافس WASM على الخيط الرئيسي ما لم يُنقل العمل إلى Worker، ويحتاج BEN2 إلى FP16 WebGPU، أي إلى معالجات رسومات حديثة على الحاسوب فقط.

التوفر هو ما يحسم الأمر، لا التفضيل: الأداة التي لا تدعم إلا WebGPU سريعة حيث تعمل، وغائبة في كل مكان آخر.

لماذا يكون التشغيل الأول أبطأ

1. 1 يُنزَّل النموذج مرة واحدة

   قبل معالجة أي إطار.

2. 2 يُهيَّأ ويُحمَّى

   ثم يمر الإطار الأول.

3. 3 المقاطع اللاحقة تتخطى الخطوتين

   يُقدَّم من الذاكرة المؤقتة، فلا يبقى إلا التهيئة.

لذا يجب أن تحمّل الأداة التي تعمل على الجهاز النموذج عند تفاعل المستخدم، لا عند تحميل الصفحة: فوصول ميغابايتات من WebAssembly لحظة فتح الصفحة سيجعلها تبدو معطلة لكل من جاء ليقرأ.

حسابات الإطارات المفككة

إطار الفيديو المفكك بكسلات غير مضغوطة، لذا تهيمن الدقة على استهلاك الذاكرة.

هذه الأرقام حسابات وليست قياسات، وحجم الملف المضغوط دليل ضعيف. لا شيء يحتاج إلى فك ترميز كل الإطارات دفعة واحدة، لكن خط المعالجة يحتفظ بمجموعة عمل: الإطار قيد فك الترميز، والإطار قيد الفصل، وقناعه، والصورة المدمجة، ومخزن المرمّز المؤقت.

اضرب بضعة إطارات في 33 MB بدقة 4K وستبدأ ميزانية الصفحة في الأهمية، خاصة على الهاتف. وإذا فشل مقطع طويل عالي الدقة أو أُعيد تحميل الصفحة، فقلّل الدقة لا المدة: تنصيف كل بُعد يقلل الذاكرة إلى الربع.

ما الذي يحدد وقت المعالجة

هذه علاقات وليست أرقامًا: الوقت المقيس على حاسوب محمول لا يخبرك شيئًا عن الهاتف.

• عدد الإطاراتالمدة مضروبة في معدل الإطارات؛ 60 إطارًا في الثانية ضعف 30.
• الدقةتؤثر في فك الترميز والدمج والترميز؛ ويبقى الاستدلال ثابتًا.
• مسار التنفيذWebGPU وWebGL وWASM-SIMD تختلف على الجهاز نفسه.
• فئة الجهازمعالجات الرسومات في الحاسوب المكتبي والمحمول والهاتف ثلاث آلات مختلفة.
• اختيار النموذجنماذج Matting أكثر تكلفة لكل إطار من MediaPipe.
• الحالة الحراريةالعمل المتواصل على GPU في هاتف دافئ يُخفَّض أداؤه.

مصفوفة دعم المتصفحات

يجب التحقق من كل متصفح هنا قبل أن يدّعي الموقع دعمًا شاملًا. أما ما يمكننا قوله دون اختبار فهو معماري: الأداة التي تعمل على الجهاز تحتاج إلى WebAssembly ومسار GPU، لا إلى WebGPU. وتحتاج bgremover.ai إلى WebCodecs، التي تستخدمها لتجهيز الرفع وإنشاء الملف النهائي.

الصورة الحقيقية على الهاتف

بالنسبة للأداة التي تعمل على الجهاز، فإن الحجم الصغير لـ MediaPipe selfie segmentation هو ما يجعل متصفحات الهاتف ممكنة أصلًا. فبضعة ميغابايتات مع متطلبات ذاكرة متواضعة تناسب ميزانية صفحة الهاتف؛ أما نموذج مصمم لمعالجات رسومات الحاسوب فلا يناسبها. وتتجاوز bgremover.ai هذه المشكلة بتشغيل نموذجها على خوادم GPU؛ ويبقى الهاتف هو من يفك ترميز المقطع ويرمّزه.

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

الأسئلة الشائعة