عیبیابی WBPP: خطاهای رایج و باگهای شناختهشده
این نوشته از یادداشتهای سالهای 2022–2025 گردآوری شدهاست؛ برخی ابزارها یا روندها از آن زمان بهروزرسانی شدهاند، پس هنگام خواندن به این نکته توجه کنید. پیامهای خطا و رفتار نسخهها که در متن آمده، همگی همانگونهاند که در آن زمان ثبت شدهاند. برای آشنایی با رابط کاربری WBPP، فریمهای master کالیبراسیون و روند اجرای عادی، به نوشتهٔ همراه «The Complete Guide to WBPP» مراجعه کنید.
اجرای WBPP از ابتدا تا انتها تنها با یک کلیک بیگمان لذتبخش است، اما وقتی واقعاً از آن استفاده میکنید، همیشه به موقعیتهایی برمیخورید که برنامه گیر میکند، خطا میدهد، یا نتیجهای میدهد که درست به نظر نمیرسد. در این نوشته، دستههایی از مشکلات WBPP را که در این چند سال با آنها روبهرو شدهام — و بیش از همه دربارهٔ آنها پرسیده شدهاست — در قالب یک دفترچهٔ عیبیابی گرد آوردهام، از منطق تشخیص گرفته تا چند باگ شناختهشدهٔ مشخص.
نخستین گام عیبیابی: ابتدا Process Console را ببینید
وقتی در پردازش PixInsight مشکلی پیش میآید، نخستین چیزی که همیشه باید به یادتان بیاید بررسی Process Console است. این پنجره به شما میگوید خطا کجا رخ دادهاست و از چه نوعی است؛ نقطهٔ آغاز هر تشخیصی همین است.
اما WBPP یک اسکریپت است و تا زمانی که اسکریپت در حال اجرا نباشد، console جمع میشود و نمیتوان آن را انتخاب کرد. بنابراین برای دیدن console غالباً باید ابتدا WBPP را ببندید. این کار دردسر به نظر میرسد، اما در بسیاری از مشکلات تنها سرنخ موجود است — راهحل چند باگی که در ادامه میآید، همگی از همان یک خط قرمز درون console آغاز شد.
خطاها و باگهای مرحلهٔ کالیبراسیون
شکست کالیبراسیون (failed) — ابتدا PI را ببندید و دوباره باز کنید. اگر هنگام اجرای WBPP همان کالیبراسیون نخست (که از فریمهای master کالیبراسیون استفاده میکند) بیدرنگ شکست بخورد و status واژهٔ failed را با رنگ قرمز نشان دهد، میتوانید کل روند را موقتاً متوقف کنید، PI را ببندید، WBPP را دوباره باز کنید و یک بار دیگر اجرا کنید؛ آنگاه این خطای شکست کالیبراسیون معمولاً ناپدید میشود. هنگام پردازش تصاویر OSC دستکم چهار بار با این باگ روبهرو شدهام و هر بار با همین ترفند حلش کردهام.
فریمهای flat مدام در کالیبراسیون خطا میدهند — به پردازش دستی گامبهگام بازگردید. برخی نسخههای WBPP باگی دارند که پیوسته باعث خطای کالیبراسیون فریمهای flat میشود. در چنین مواقعی، اینکه بتوانید خودتان گام به گام و بهصورت دستی پردازش کنید اهمیت پیدا میکند. به همین مناسبت، مراحل Pre-Process را هم مرور کنیم:
- Calibration:
light − dark / ((flat − flat dark) * med(flat)) - Cosmetic Correction
- Debayer: درونیابی روی ماتریس Bayer
- Star Alignment
- NSG
- Integration
وقتی نمیتوان به خودکارسازی اعتماد کرد، تفکیک روند و اجرای دستی آن در عمل آسانتر میکند که بفهمید مشکل از کدام مرحله است.
مشکلات مسیر: دو علت احتمالی برای File I/O Error
هنگام استفاده از WBPP در Windows، اگر در مرحلهٔ کالیبراسیون (calibration) پیام File I/O Error ظاهر شود، معمولاً یکی از این دو علت در کار است:
- مسیر فایل بههمراه نام فایل بیش از حد طولانی است و از محدودیت سیستم فراتر میرود، پس باید کوتاه شود.
- در پوشهٔ مقصد نمیتوان نوشت، برای نمونه وقتی خروجی را روی یکی از پوشههای سیستمی تنظیم کرده باشید.
علت نخست از همه رایجتر است. برای درمان ریشهای «مسیر بیش از حد طولانی» میتوانید در Windows پشتیبانی از مسیرهای بلند را فعال کنید (در regedit مقدار LongPathsEnabled را روی 1 بگذارید)؛ همچنین توصیه میشود از مسیرهایی که کاراکترهای غیر ASCII (مانند حروف چینی) دارند پرهیز کنید. جزئیات این دو پیشنیاز محیطی را در بخش تنظیم محیط Windows در نوشتهٔ «The Complete Guide to WBPP» نوشتهام و اینجا تکرارشان نمیکنم.
باگ «سرریز نشدن 60 ثانیه» در مختصات RA/DEC
این دشوارترین مشکل است و بیش از همه ارزش دارد که جداگانه دربارهٔ آن سخن بگوییم، چون نشانههایش بینهایت گوناگوناند اما ریشهشان یکی است: در FITS Header، در مختصات بُعد (RA) و میل (Dec) مقدار ثانیه برابر «60» ظاهر شده اما به دقیقه منتقل نشدهاست.
دو بار با آن روبهرو شدهام و هر بار خود را به شکلی متفاوت نشان داد.
بار نخست: WBPP نتوانست فایل را بارگذاری کند. WBPP را بستم و به Process Console نگاه کردم و دیدم که خطی از یکی از اسکریپتهای js پیام «مختصات نامعتبر» میدهد. آن موقع گمان کردم باگی در WBPP است؛ پیام خطا را در اینترنت جستوجو کردم و تازه آنگاه در PixInsight Forum چند گزارش دقیقاً مشابه پیدا کردم — معلوم شد همان مشکل مختصات مانع بارگذاری تصویر در WBPP شدهاست. با اینکه جهت کار روشن شده بود، باز هم یک ساعت میان چند صد فریم light گشتم تا آن تصویر مشکلدار را بیابم: مختصات OBJCTDEC آن نادرست بود. در PI process FITSHeader را باز کردم، تا 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 مگاپیکسل؛ چنین انتظاری واقعاً آدم را به فکر عوض کردن رایانه میاندازد).
در این میان دو بخش بهویژه وقت زیادی میبرند:
- Separated RGB: پردازش جداگانهٔ کانالهای RGB عکس رنگی برای حذف ابیراهی رنگی.
- Local Normalization: انتخاب چند تصویر از بهترینها بهعنوان مرجع و اعمال Local Normalization روی بقیهٔ تصاویر.
اگر این دو مورد را غیرفعال کنید، WBPP بسیار سریعتر میشود. اینکه آیا ارزش دارد این دو را فدای سرعت کنید یا نه، به توقع شما از نتیجهٔ نهایی بستگی دارد — دربارهٔ اندازهگیری عملی این پرسش که «کدام مراحل را خاموش کنیم، چقدر در وقت صرفهجویی میشود و چقدر کیفیت از دست میرود»، در «The Complete Guide to WBPP» مجموعهای از دادهها دارم که شتابی 7 تا 8 برابری را نشان میدهد و میتوانید به آن مراجعه کنید.
منطق این دفترچهٔ عیبیابی را جمعبندی کنیم: هر وقت مشکلی پیش آمد، نخست Process Console را ببینید؛ اگر کالیبراسیون failed شد، PI را ببندید و دوباره باز کنید؛ اگر فریمهای flat مدام در کالیبراسیون خطا دادند، به پردازش دستی گامبهگام بازگردید؛ File I/O Error بیشتر بهخاطر مسیر بیش از حد طولانی است یا پوشهای که نمیتوان در آن نوشت؛ و اگر چیزی بارگذاری نشد، برنامه قفل کرد یا پیام recursion داد، بروید و بررسی کنید که آیا در RA/DEC داخل FITS Header ثانیهای برابر 60 بدون انتقال ماندهاست یا نه. این چند ترفند را خوب به خاطر بسپارید، آنگاه از پس بیشتر بدقلقیهای WBPP برمیآیید.