تعزيز بيانات صناديق الإحاطة (bounding box) في الكشف عن الأجسام: الصيغ والأخطاء وأفضل الممارسات

نشر موقع Habr مقالة مخصصة لسبب شائع وقليل الظهور وراء إخفاق تدريب نماذج الكشف عن الأجسام: فالمشكلة ليست في بنية الشبكة نفسها، بل فيما يحدث لصناديق الإحاطة (bounding box أو bbox)، أي الإطارات المستطيلة التي تحدد مواضع الأجسام في التوسيم، بعد تطبيق عمليات التعزيز.

أين ينكسر التوسيم في الغالب

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

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

• المكتبة قيد الدراسة: Albumentations
• صيغ bbox المدعومة: COCO وYOLO وpascal_voc
• المعاملات الرئيسية: A.BboxParams وmin_area وmin_visibility
• المشكلة النموذجية: RandomCrop كثيرًا ما لا يناسب مهام الكشف عن الأجسام
• المصدر: Habr

كيف نُعِدّ Albumentations بالشكل الصحيح؟

تتناول المقالة الجانب العملي من المسألة على مثال مكتبة Albumentations، وهي من أكثر أدوات تعزيز الصور انتشارًا في الرؤية الحاسوبية. وتستعرض صيغ bbox التي تدعمها المكتبة، والإعداد الصحيح للمعامل A.BboxParams، ودور المعاملين min_area وmin_visibility اللذين يحددان الحد الأدنى لحجم الجسم أو ظهوره بعد التحويل كي يبقى الصندوق صالحًا، بدلًا من أن يُستبعد أو يُشوَّه.

تنتشر Albumentations على نطاق واسع لأنها تحوِّل الصورة والتوسيم المرتبط بها بشكل متزامن؛ فعند تدوير الصورة أو عكسها أو تغيير مقياسها، تعيد المكتبة تلقائيًا حساب إحداثيات جميع صناديق bbox عليها، فتعفي المطور من كتابة هذا المنطق يدويًا. غير أن هذه الأتمتة نفسها تصبح مصدرًا للمشكلات إذا ضُبطت معاملات A.BboxParams بشكل خاطئ: فالمكتبة لا تُصدر خطأً، بل تعيد حساب الإحداثيات وفق الصيغة المحددة (وإن كانت خاطئة)، فيحصل المطور على خط تعزيز يعمل شكليًا بصورة سليمة لكنه فعليًا فاسد.

لماذا لا يكون RandomCrop خيارًا آمنًا دائمًا؟

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

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

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