الدليل الكامل لاستخدام WBPP: الواجهة وإطارات المعايرة الرئيسية ومسار التنفيذ

هذه المقالة مجمّعة من ملاحظات دُوّنت بين عامي 2021 و2024، وقد جرى تحديث بعض الأدوات أو الإجراءات منذ ذلك الحين، فيرجى الانتباه إلى ذلك أثناء القراءة؛ وما يرد في النص من واجهات وخيارات وسلوكيات خاصة بإصدارات بعينها (مثل الإصدارين 2.1.2 و2.5) إنما يعكس حال الأمور في حينه. أما الأخطاء والعلل المعروفة التي قد تصادف المستخدم أثناء التنفيذ، فلها مقالة منفصلة بعنوان «استكشاف أخطاء WBPP وإصلاحها».

WBPP (WeightedBatchPreprocessing) هو السكربت الذي ينفّذ داخل PixInsight سلسلة «المعايرة وتسجيل النجوم والتجميع» كاملةً وبصورة آلية، وهو مريح إلى حدّ مذهل. وقد تغيّرت إصداراته كثيرًا في السنوات الأخيرة، وكتبت عنه تباعًا ملاحظات متفرّقة كثيرة؛ وهذه المقالة تجمعها في شرح أكثر اكتمالًا، مقسّم على ثلاثة مستويات: المفاهيم الجوهرية التي لا تتغيّر كثيرًا بتغيّر الإصدارات، ومسار التنفيذ الحالي، وبعض التغييرات المهمة عبر الإصدارات المتعاقبة. وأيًّا كان الإصدار المستعمل، فمتى رسخت المفاهيم أولًا، لم يعد تغيّر الواجهة داعيًا لأي ارتباك.

المفهوم الجوهري الأول: ما يُخرجه WBPP من تجميع ليس إلا معاينة

هذه هي النقطة التي أودّ طرحها أولًا، وهي في الوقت نفسه النقطة التي يغفل عنها أكثر الناس.

وقد وقعت أنا نفسي في الفخ: فبعد إحدى المرات التي استعملت فيها Drizzle Integration، اكتشفت أن مراكز النجوم (المناطق المفرطة الإشباع) قد اسودّت. وبتتبّع الأمر، تبيّن أن الجاني هو إجراء التجميع عبر WBPP.

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

The integrated image generated by WBPP is just a convenience preview of the achievable image, but it should always be deleted/ignored, and the integration should always be done manually with the registered frames. This is the only way to obtain an optimal integrated image with full control over the normalization, pixel rejection and noise reduction tasks.

بل قالت الجهة الرسمية على سبيل المزاح نصف الجادّ إنها تودّ تكرار هذه العبارة «n+1 مرة، حيث n يقارب اللانهاية أصلًا»: فصورة Master Light التي ينتجها WBPP لا ينبغي استعمالها لغرض نهائي، فهي مجرد معاينة، وأفضل نتيجة لا تُنال إلا عبر Image Integration يدوي يحسّن رفض البكسلات ونسبة الإشارة إلى الضوضاء.

لذا صارت عادتي: لا أستعمل WBPP إلا إلى خطوة «تسجيل النجوم» على أبعد تقدير، أما التجميع الحقيقي فأعيده إلى Image Integration بالمعالجة اليدوية. والأسلوب النظامي القائم على فصل الإجراءات — المعايرة (تُترك إلى WBPP)، وتسجيل النجوم (Star Alignment)، والتجميع (Image Integration) — وإن زاد عدد الخطوات بضع خطوات، فإنه يسهّل كثيرًا، عند وقوع خلل، معرفة الحلقة التي انكسرت. وهذا ما استقرّ عليه رأيي لاحقًا. أما مقطعا الفيديو التعليميان المفصّلان جدًّا عن WBPP اللذان أعدّهما هواة يابانيون في وقت مبكّر فأوصي بهما كثيرًا، لكن لا بدّ من إضافة التنبيه نفسه إليهما: نتيجة التجميع تُؤخذ للاسترشاد لا أكثر.

المفهوم الجوهري الثاني: تمييز ما هو عمل نهائي داخل مجلد Master

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

• الصورة داخل الإطار الأحمر هي وحدها Master Light المكتمل بعد التجميع، وهي المطلوبة.
• الصورة داخل الإطار الأصفر هي الصورة المرجعية (Ref) الخاصة بعملية Local Normalization، وليست Master Light؛ فيرجى عدم الخلط بينهما.
• الصور بلا إطار هي إطارات المعايرة الرئيسية، وتشمل هنا Master Flat وMaster Bias وMaster Dark.

(غير أنه، بحسب ما ورد في القسم السابق، تبقى صورة «Master Light» هذه ذات طابع المعاينة في WBPP، ومن أراد الدقة فالأولى به أن يعيد التجميع بنفسه مرة أخرى.)

مسار التنفيذ الحالي: الحزمة الكاملة للكاميرا الملوّنة

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

1. Calibration File Integration: إنشاء إطارات المعايرة الرئيسية
2. Calibration: معايرة إطارات Light
3. Cosmetic Correction: إزالة البكسلات الساخنة أو الخطوط التالفة
4. Debayer: فكّ نمط باير (فصل RGB)
5. Measurements: قياس إطارات Light ومنحها أوزانًا
6. Reference frame selection: تحديد الصورة المرجعية للتسجيل
7. Plate solving reference frames: إجراء الحل الفلكي للصور المرجعية
8. Registration: تسجيل النجوم
9. LN reference generation: توليد الصورة المرجعية لعملية Local Normalization
10. Local Normalization: تنفيذ Local Normalization
11. Integration: تجميع إطارات Light
12. RGB Combination: إعادة دمج قنوات RGB الثلاث

وبصياغة أكثر إيجازًا، يمكن اختصار ذلك في ثماني خطوات: إنشاء ملفات صور المعايرة ← معايرة الصور ← Cosmetic Correction ← فكّ نمط باير (فصل قنوات RGB الثلاث) ← تسجيل النجوم ← Local Normalization ← تجميع الصور ← دمج قنوات RGB الثلاث.

وهناك خطوتان تستحقّان كلامًا إضافيًا: فصل RGB غايته تجاوز الزيغ اللوني (إذ تبدو حواف النجوم مختلفة اللون بين الجانبين)، وثمنه وقت تشغيل إضافي؛ أما Drizzle Integration فإن استُعمل، فليس الغرض منه هنا تكبير الصورة بل تجنّب الأثر الزائف، ولذلك لا معنى له إلا مع عدد كافٍ من الصور المأخوذة مع dither، وعمومًا إذا قلّ العدد عن 50 صورة فيمكن الاستغناء عنه. وعلى الهامش، ملاحظة عن الإحساس الفعلي بالوقت: استعملت مرةً 360 صورة بدقة تسعة ملايين بكسل، وسرت بها من المعايرة حتى Drizzle Integration 1x، فاستغرق الأمر أكثر من ساعة؛ ومع دقة أعلى لن يزيد الأمر إلا «إثارة».

إطارات المعايرة الرئيسية: موضع ذكاء WBPP

يخبّئ WBPP في تعامله مع إطارات المعايرة (Flat وDark وBias وغيرها) لمسات مدروسة كثيرة تستحقّ قسمًا خاصًّا بها.

من الأفضل إعادة إنشاء إطارات المعايرة داخل WBPP انطلاقًا من الملفات الأصلية. فكثيرون يكتشفون بعد المعايرة أن إطارات Light مصابة بخلل، والسبب الرئيسي غالبًا هو تطبيق «ملفات Master التي أنتجتها برامج أو إجراءات أخرى» (Master Flat / Bias / Dark). وأضمن أسلوب هو إلقاء الملفات الأصلية لملفات المعايرة داخل WBPP وتركه يعيد إنشاء ملفات Master.

فرق طفيف في زمن التعريض؟ الأمر متروك لخيار Exposure tolerance. سأل أحد الهواة مرةً في المجموعة: كان يلتقط إطارات Dark بالتحكّم بالإشارة عبر Eqmod، وبسبب التأخير قد يقع إطار Dark الذي مدته خمس ثوانٍ فعليًا بين 4.980 و5.02 ثانية، فأراد التحوّل إلى التصوير عبر NINA. والحقيقة أن WBPP سبق أن فكّر في ذلك: فإطارات المعايرة الواقعة ضمن فارق زمني معيّن يمكن تعيينها ضمن المجموعة نفسها، ويجري WBPP تلقائيًا على إطارات المعايرة في المجموعة الواحدة ما ينبغي إجراؤه، ويقرنها تلقائيًا بإطارات Light. وقيمة التسامح هذه هي Exposure tolerance.

الصور الملتقطة في أيام مختلفة تُحسم دفعةً واحدة عبر Grouping Keywords. فبعد التحديث اكتسب WBPP وظيفة التجميع في مجموعات، بحيث يمكن إلقاء الصور الملتقطة في تواريخ مختلفة دفعةً واحدة ومعالجتها معًا — بشرط تصنيفها في Grouping Keywords بكلمة مفتاحية (التاريخ مثلًا). فمجموعة ملفاتي تلك كان إطار Flat فيها مختلفًا كل يوم، ومع ذلك استطاع WBPP معايرتها تلقائيًا بحسب التاريخ كلًّا على حدة، دون حاجة إلى ضبط يدوي منفصل لكل تاريخ بين إطارات Light وإطارات Flat، وهو أمر مريح للغاية.

الرغبة في إنشاء إطارات المعايرة الرئيسية وحدها؟ يمكن ذلك دون إدراج إطارات Light. وهذا استعمال يجهله كثيرون: فمع غياب إطارات Light، يكفي إلقاء إطارات Dark وBias وFlat وFlat Dark في WBPP، فيتولّى بذكاء تحويل إطارات المعايرة هذه إلى إطارات معايرة رئيسية وفق الخطوات الصحيحة، ويُخرجها إلى المجلد المحدَّد، وهو ما يوفّر عناء صنعها يدويًا بإجراءات مختلفة متفرّقة.

خيارات صفحة Light وحيل تسريع التنفيذ

تضمّ صفحة Light في WBPP صفًّا من الخيارات يمكن للمستخدم تفعيلها بحسب الحاجة. وفي الوضع الافتراضي، جميعها غير مفعّلة عدا subframe weighting.

وما دام في الإمكان الأخذ ببعض هذه الخطوات وترك بعضها، فإن ذلك يقود إلى سؤال عملي: كم من الوقت يمكن توفيره بإيقاف المعالجات غير الضرورية؟ أجريت اختبارًا فعليًا على مجموعة بيانات متاحة للتنزيل من الخارج، مجموعها 372 صورة بدقة ستة عشر مليون بكسل، وبعد استبعاد المعالجات غير الضرورية صار التنفيذ أسرع بنحو 7 إلى 8 أضعاف (25 دقيقة و03 ثانية مقابل 03 دقائق و30 ثانية)، ولم تتراجع جودة الصورة إلا قليلًا — نحو 15% على جهازي، وبعد الضغط عبر الشبكة يكاد الفرق لا يُرى. وفي المواقف التي يُلاحَق فيها الوقت أو يُراد فيها إلقاء نظرة عامة أولًا، تكون هذه المقايضة مجزية جدًّا.

أما عن الخطوات التي تلتهم أكبر قدر من الوقت، وأيّها يكون إيقافه أشدّ فعالية، فسأعود إلى ذلك في مقالة «استكشاف أخطاء WBPP وإصلاحها».

تغيّرات الإصدارات: هذه أمور جاءت لاحقًا

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

بعض الأمور في الإصدار 2.1.2. ابتداءً من هذا الإصدار، تجدر ملاحظة ثلاث نقاط: أولاها أن ظهور خلل في إطارات Light بعد المعايرة يعود غالبًا إلى خلط ملفات Master المصنوعة خارجيًا (كما سبق)؛ وثانيتها أن Dark frame optimization يُستعمل أساسًا حين لا يتطابق طول تعريض إطار Light مع إطار Dark (مثل Light مدته 20 دقيقة مع Dark مدته 30 دقيقة)، وأفضل شروطه أن يكون التعريض طويلًا والصور متعددة، ولا يظهر الخيار إلا بالنقر على ملف إطار Light؛ وثالثتها أن مستعملي CCD تظهر لديهم مع الاستعمال عيوب (defect) تدريجيًا، ولا سيّما column defect، وقد كان لا بدّ سابقًا من صنع defect map لإزالتها وهو عمل مستهلك للوقت جدًّا، فقدّم WBPP أداة Linear Pattern Subtraction للمساعدة في معالجتها.

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

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

السكربت القابل للاستنساخ داخل مجلد log. بعد التشغيل، يحتفظ أحدث إصدار من WBPP بسجل log مفصّل وبسكربت التنفيذ داخل مجلد log. وبقراءة السكربت عبر Script Editor في PI وترجمته وتشغيله، تظهر نافذة Process Container تضمّ كل أيقونات (ICON) الإجراءات الموجودة في قائمة Pipeline الفرعية بنافذة WBPP الرئيسية، ويمكن فتح كل واحدة منها على حدة داخل PI. وهذا مفيد للغاية في تصحيح الأخطاء (Debug) — فمثلًا عند الرغبة في معرفة سبب عدم تنفيذ Cosmetic Correction تنفيذًا صحيحًا أو عدم ظهور أثره، يمكن فتح تلك الخطوة من هنا وفحص ما إذا كانت المسألة مسألة معاملات أم علّة برمجية. وثمة استعمال آخر: فمن ليست لديه دراية كافية بالمعالجة الأولية يستطيع بهذه الطريقة أن يقرأ كل إجراء ومعامل استعمله WBPP في كل خطوة، فيتّخذها نموذجًا مرجعيًا لتنفيذها بنفسه يدويًا.

الخطوة الأولى بعد فتح WBPP ليست في الحقيقة تحميل الملفات

وأخيرًا نعود إلى أبسط الأمور وأكثرها عرضةً للخطأ. فالخطوة الأولى بعد فتح WBPP ليست التسرّع إلى «تحميل ملفات Light وDark وFlat وBias».

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

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

الإعدادات البيئية التمهيدية لمستخدمي Windows

عند تشغيل WBPP على Windows، هناك إعدادان بيئيان من الأفضل ضبطهما منذ البداية، إذ يجنّبانك لاحقًا جملةً من الأخطاء الغامضة (وللاطلاع على رسائل الخطأ ذات الصلة وتشخيصها، يرجى مراجعة «استكشاف أخطاء WBPP وإصلاحها»):

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

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

---

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