استكشاف أخطاء WBPP وإصلاحها: الأخطاء الشائعة والعلل المعروفة

هذه المقالة مجمّعة من ملاحظات دُوّنت بين عامَي 2022 و2025، وقد جرى تحديث بعض الأدوات أو مسارات العمل منذ ذلك الحين، لذا يرجى الانتباه إلى ذلك أثناء القراءة؛ ورسائل الخطأ وسلوك الإصدارات الواردة في النص كلها مسجّلة كما كانت آنذاك. أما واجهة WBPP وإطارات المعايرة الرئيسية ومسار التنفيذ الطبيعي، فيرجى الرجوع إلى المقالة الشقيقة «الدليل الكامل لاستخدام WBPP».

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

الخطوة الأولى في استكشاف الأخطاء: الاطّلاع على Process Console أولًا

عند حدوث مشكلة أثناء المعالجة في PixInsight، فإن أول ما ينبغي التفكير فيه دائمًا هو الاطّلاع على Process Console. فهي تبيّن أين وقع الخطأ وما نوعه، وهي نقطة الانطلاق لكل تشخيص.

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

الإخفاقات والعلل في مرحلة المعايرة

فشل المعايرة (failed) — يرجى إغلاق PI ثم إعادة فتحه أولًا. إذا أخفقت المعايرة الأولى (التي تستخدم إطارات المعايرة الرئيسية) فور تشغيل WBPP، وأظهرت الحالة status كلمة failed بالأحمر، فيمكن إيقاف مسار العمل بأكمله مؤقتًا، ثم إغلاق PI وإعادة فتح WBPP وتشغيله مرة أخرى؛ وعندها يختفي خطأ فشل المعايرة هذا في العادة. صادفت هذه العلة أربع مرات على الأقل أثناء معالجة صور OSC، وفي كل مرة حللتها بهذه الحيلة.

إطارات Flat تخفق في المعايرة باستمرار — يرجى العودة إلى المعالجة اليدوية خطوة بخطوة. في بعض إصدارات WBPP علّة تؤدي إلى إخفاق معايرة إطارات Flat مرارًا. في مثل هذه الحالة تصبح معرفة كيفية تنفيذ المعالجة يدويًا خطوة بخطوة أمرًا مهمًا. وبالمناسبة، لنراجع خطوات Pre-Process:

1. Calibration: light − dark / ((flat − flat dark) * med(flat))
2. Cosmetic Correction
3. Debayer: إجراء استيفاء على مصفوفة Bayer
4. Star Alignment
5. NSG
6. Integration

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

مشكلات المسار: احتمالان لظهور File I/O Error

عند استخدام WBPP على Windows، إذا ظهر File I/O Error في مرحلة المعايرة (calibration)، فالسبب عادةً أحد هذين:

1. مسار الملف مع اسم الملف طويل أكثر من اللازم، فيتجاوز حدّ النظام ويلزم اختصاره.
2. تعذّر الكتابة في المجلد الهدف، كأن يُضبط الإخراج على مجلد من مجلدات النظام.

السبب الأول هو الأكثر شيوعًا. ولعلاج «المسار الطويل أكثر من اللازم» علاجًا جذريًا، يمكن تفعيل دعم المسارات الطويلة في Windows (بضبط LongPathsEnabled على 1 في regedit)؛ كما يُنصح بتجنّب المسارات التي تحتوي على أحرف غير ASCII (مثل الصينية). أما التفاصيل الدقيقة لهذين الإعدادين التمهيديين للبيئة فقد كتبتها في قسم إعداد بيئة Windows من «الدليل الكامل لاستخدام WBPP»، ولن أكررها هنا.

علّة إحداثيات RA/DEC «60 ثانية دون ترحيل»

هذه أعقد مشكلة وأجدرها بالإفراد بالحديث، لأن أعراضها شديدة التنوع بينما سببها الجذري واحد: إحداثيات المطلع المستقيم/الميل في FITS Header تحمل قيمة ثوانٍ مقدارها «60» دون أن تُرحَّل إلى الخانة التالية.

صادفتها مرتين، وفي كل مرة ظهرت بشكل مختلف.

المرة الأولى: WBPP يعجز عن تحميل الملف. أغلقت WBPP واطّلعت على Process Console، فوجدت أن سطرًا ما في أحد سكربتات js يبلّغ عن «إحداثيات غير صالحة». ظننت حينها أنها علّة في WBPP، فبحثت عن رسالة الخطأ على الإنترنت، وعندها فقط عثرت في PixInsight Forum على عدة بلاغات بالخطأ نفسه — تبيّن أن مشكلة الإحداثيات هي التي تمنع تحميل الصورة في WBPP. ومع أن الاتجاه صار واضحًا، فقد أمضيت ساعة كاملة أنقّب بين مئات إطارات Light حتى عثرت على الصورة المسبِّبة للمشكلة: إحداثي OBJCTDEC فيها كان خاطئًا. فتحت عملية FITSHeader في PI، ونزلت حتى OBJCTDEC، وعدّلت القيمة التي «كان ينبغي ترحيلها ولم تُرحَّل» — وفي هذا المثال غيّرت -69 26 60 إلى -69 27 0 — عندها حُمِّل هذا الإطار بسلاسة، ولم تعد الملفات التالية تتعطّل بسببه.

المرة الثانية: تعذّر إضافة الملفات، وظهر في Console بلاغ too much recursion. ثم صادفت الأمر مرة أخرى: عند إضافة الملفات إلى WBPP تجمّد البرنامج، وفي النهاية لم يُضَف أي ملف على الإطلاق. أغلقت WBPP واطّلعت على Console، فإذا بها تُظهر InternalError: too much recursion بالأحمر. وبعد إعادة فتح WBPP وجدت أن بعض الملفات قد حُمِّل وبعضها لا؛ وبفحص الملفات التي لم تُحمَّل، تبيّن كما هو متوقَّع أنه خلل آخر في FITS Header — هذه المرة كان DEC يظهر بقيمة -46 01 60، والثواني «60» كان ينبغي ترحيلها لتصبح -46 02 00. فما إن يقرأ WBPP قيمة شاذة كهذه حتى يتجمّد، بل ويجرّ معه الصور التالية فلا تُحمَّل هي الأخرى. والحل هو نفسه: فتح FITS Header وترحيل الثواني يدويًا، ثم إعادة إضافة الملفات بعد التعديل. وحين تُحمَّل جميع الملفات بنجاح، يُظهر WBPP رسالة تشخيصية تلقائيًا، مثل «60 of 60 light frames were added».

خلاصة مشتركة: مشكلة عدم ترحيل الإحداثيات تلقائيًا هذه، في كل ما رأيته حتى الآن تقريبًا، تقع حين يكون MDL (التحكم عن بُعد) هو برنامج التصوير، وإن كنت لا أستبعد أن تعاني برامج تصوير أخرى من العيب نفسه. لذا، متى تجمّد WBPP وتعذّرت إضافة الملفات، يرجى الرجوع أولًا إلى Process Console للتأكد من نوع الخطأ، ثم فحص Header الإحداثيات RA/DEC بحثًا عن علّة «60 ثانية دون ترحيل»؛ وبعد التصحيح اليدوي تُحلّ المشكلة في الغالب.

الأداء: لماذا تستغرق الحزمة الكاملة كل هذا الوقت

وأخيرًا، حديث عن مشكلة لا تُعدّ «خطأ» بالمعنى الدقيق، لكنها مُعذِّبة حقًا — الحزمة الكاملة من WBPP بطيئة أكثر من اللازم ببساطة. تركت الحزمة الكاملة تعمل أربع ساعات كاملة من أجل خمس صور أردت تحويلها إلى HDR (كان الجهاز آنذاك AMD R5-4650G مع DDR4 3200 32GB وقرص Gen4 SSD، والصور بدقة 24 مليون بكسل؛ انتظار كهذا يجعل المرء يرغب فعلًا في تبديل حاسوبه).

وهناك موضعان يلتهمان الوقت بوجه خاص:

1. Separated RGB: معالجة قنوات RGB في الصورة الملونة كلًا على حدة لإزالة الزيغ اللوني.
2. Local Normalization: اختيار أفضل بضع صور مرجعًا وتطبيق Local Normalization على باقي الصور.

بإلغاء هذين البندين يصبح WBPP أسرع بكثير. أما التضحية بهما من أجل السرعة فأمر يتوقف على مستوى الطموح في النتيجة النهائية — وبخصوص القياس العملي لمسألة «أي الخطوات تُطفأ، وكم من الوقت يُوفَّر، وكم من الجودة يُفقد»، لديّ في «الدليل الكامل لاستخدام WBPP» مجموعة بيانات تُظهر تسارعًا يتراوح بين 7 و8 أضعاف يمكن الرجوع إليها.

---

نلخّص منهج هذا الدليل لاستكشاف الأخطاء: عند وقوع أي مشكلة، يرجى الاطّلاع على Process Console أولًا؛ وإذا أخفقت المعايرة وظهرت failed، فيرجى إغلاق PI وإعادة فتحه؛ وإذا ظلّت إطارات Flat تخفق في المعايرة، فيرجى العودة إلى المعالجة اليدوية خطوة بخطوة؛ أما File I/O Error فسببه في الغالب مسار طويل أكثر من اللازم أو مجلد لا يمكن الكتابة فيه؛ وإذا تعذّر التحميل أو تجمّد البرنامج أو ظهر بلاغ recursion، فيرجى فحص إحداثيات RA/DEC في FITS Header للتأكد من عدم وجود ثوانٍ بقيمة 60 دون ترحيل. بإتقان هذه الحيل القليلة يمكن التعامل مع معظم نزوات WBPP.