Повний посібник із WBPP: інтерфейс, калібрувальні майстер-кадри та конвеєр виконання
Ця стаття зібрана з нотаток за 2021–2024 роки; деякі інструменти чи процеси відтоді оновилися, тож майте це на увазі під час читання. Частина інтерфейсу, опцій і поведінки версій, згаданих у тексті (наприклад, версії 2.1.2 і 2.5), відображає стан на той момент. А щодо помилок і відомих багів, з якими можна зіткнутися під час виконання, дивіться окрему статтю «WBPP Troubleshooting».
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, не варто використовувати як остаточний результат — це лише попередній перегляд, а найкращий результат можна отримати, лише оптимізувавши відбракування пікселів (pixel rejection) та відношення сигнал/шум (SNR) вручну через 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) повний порядок виконання такий:
- Calibration File Integration: створення калібрувальних майстер-кадрів
- Calibration: калібрування кадрів light
- Cosmetic Correction: видалення «гарячих пікселів» або бракованих ліній
- Debayer: дебаєризація (розділення на RGB)
- Measurements: вимірювання кадрів light і присвоєння їм ваги
- Reference frame selection: вибір референсного зображення для вирівнювання
- Plate solving reference frames: plate solving (автоматичне розпізнавання зоряного поля, астрометрія) референсних зображень
- Registration: вирівнювання зір
- LN reference generation: створення референсного зображення для Local Normalization
- Local Normalization: виконання Local Normalization
- Integration: інтеграція кадрів light
- RGB Combination: повторне об’єднання трьох каналів RGB
Якщо сказати коротше, це можна стиснути до восьми кроків: створення калібрувальних кадрів → калібрування зображень → Cosmetic Correction → дебаєризація (розділення на три канали RGB) → вирівнювання зір → Local Normalization → інтеграція зображень → об’єднання трьох каналів RGB.
Тут варто сказати кілька слів про два кроки: розділення RGB потрібне, щоб подолати хроматичну дисперсію (краї зір виглядають так, ніби мають різний колір з двох боків), а платою за це є довший час виконання; якщо використовується Drizzle Integration, то його мета тут не в збільшенні зображення, а в тому, щоб уникнути артефактів, тож він має сенс лише за достатньої кількості кадрів з dither — зазвичай менш ніж за 50 кадрів його справді можна пропустити. До речі, про реальне відчуття часу: одного разу я провів 360 кадрів по дев’ять мегапікселів від калібрування аж до Drizzle Integration 1x, і це зайняло понад годину; що більше пікселів, то сильнішими будуть «гострі відчуття».
Калібрувальні майстер-кадри: у чому кмітливість WBPP
У обробці калібрувальних кадрів (flat, dark, bias тощо) WBPP приховує чимало продуманих рішень, і про це варто поговорити окремо.
Калібрувальні кадри найкраще перестворювати в самому WBPP з вихідних файлів. Чимало людей після калібрування помічають проблеми з кадрами light, і головна причина здебільшого в тому, що вони застосували «файли Master, створені іншим програмним забезпеченням чи процесом» (master flat / bias / dark). Найнадійніший спосіб — закинути вихідні файли калібрування у WBPP і дати йому самому перестворити ці майстер-кадри.
У часу експозиції є невелика похибка? Довірте це Exposure tolerance. Одного разу хтось із спільноти запитав у групі: він знімав кадри dark, керуючи сигналом через Eqmod, і через затримку фактична тривалість 5-секундного кадру dark могла опинитися в діапазоні 4,980–5,02 с, тож хотів перейти на зйомку через NINA. Насправді WBPP уже про це подбав: калібрувальні кадри в межах певної різниці часу можна визначити як одну групу, і WBPP автоматично виконає потрібну обробку для кадрів цієї групи та автоматично зіставить їх із кадрами light. Саме це значення допуску і є Exposure tolerance.
Зображення, зняті в різні дні? Усе вирішується одразу через Grouping Keywords. Після оновлення у WBPP з’явилася функція групування, тож навіть зображення, зняті в різні дати, можна закинути й обробити одразу разом — досить лише класифікувати їх за ключовим словом (наприклад, датою) у Grouping Keywords. Наприклад, у моєму наборі файлів кадр flat щодня був інший, і WBPP все одно міг автоматично калібрувати окремо за датою, тож не було потреби вручну налаштовувати кадри light і flat для кожної дати окремо — дуже зручно.
Хочете отримати лише калібрувальні майстер-кадри? Можна й без кадрів light. Це спосіб використання, про який мало хто знає: без кадрів light закиньте у WBPP кадри dark, bias, flat і flat dark, і він розумно, за правильними кроками, перетворить ці калібрувальні кадри на майстер-кадри та виведе їх у вказану папку — це рятує від мороки створювати їх вручну різними процесами.
Опції сторінки Light і прийоми прискорення
На сторінці Light у WBPP є ряд опцій, які користувач може вмикати за потреби. За замовчуванням не позначено нічого, крім subframe weighting.
Оскільки цими кроками можна жертвувати, виникає практичне питання: скільки часу можна заощадити, вимкнувши непотрібну обробку? Я перевірив це на реальному наборі даних, вільно доступному для завантаження з-за кордону — загалом 372 кадри по 16 мегапікселів. Після виключення непотрібної обробки виконання прискорилося приблизно у 7–8 разів (25 хв 03 с проти 03 хв 30 с), а якість зображення знизилася лише трохи — на моєму комп’ютері приблизно на 15%, і після стиснення для передавання мережею це майже непомітно. Для ситуацій, коли поспішаєте або просто хочете отримати загальне уявлення, такий компроміс дуже вигідний.
А про те, які кроки забирають найбільше часу і вимкнення яких дає найбільший ефект, я ще розповім у статті «WBPP Troubleshooting».
Зміни у версіях: те, що з’явилося пізніше
За ці роки у WBPP додали чимало нового; впорядкую кілька важливих віх, щоб було зручно звірити з версією, яка є у вас:
Кілька моментів версії 2.1.2. Починаючи з цієї версії варто звернути увагу на три речі: по-перше, проблеми з кадрами light після калібрування часто виникають через змішування зовнішніх файлів Master (див. вище); по-друге, Dark frame optimization застосовується переважно тоді, коли тривалість кадрів light і dark не збігається (наприклад, 20-хвилинний кадр light разом із 30-хвилинним кадром dark), найкраща умова — довга витримка й багато кадрів, а сама опція стає видимою лише після натискання на файл light; по-третє, у користувачів CCD з часом поступово з’являються дефекти, особливо 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, який містить усі значки процесів з підменю Pipeline головного вікна WBPP, і кожен із них можна відкрити в PI окремо. Це надзвичайно зручно для налагодження — наприклад, якщо ви хочете з’ясувати, чому Cosmetic Correction виконався неправильно або не дав ефекту, можна відкрити саме цей крок звідси й перевірити, чи проблема в параметрах, чи в багу програми. Інше застосування: той, хто не знайомий із попередньою обробкою, може цим способом переглянути кожен процес і параметр WBPP і взяти це за зразок для власного ручного виконання.
Перший крок після відкриття WBPP насправді не завантаження файлів
Наостанок повернуся до найпростішого, але водночас того, де найлегше помилитися. Перший крок після відкриття WBPP — це не поспішати «завантажувати файли light, dark, flat, bias».
WBPP — один із небагатьох скриптів, що зберігає вміст з минулого разу. Якщо ви користувалися ним раніше, усі налаштування досі на місці. Тож перший крок має бути очищення списку файлів; а чи очищати разом з ним інші параметри — залежить від потреби.
А другий крок дуже легко пропустити, про нього не згадують і багато навчальних відео — натисніть Purge Cache. Раніше я казав про перевагу кешу (з версії 2.5): коли змінюєте лише частину параметрів, WBPP виконує тільки змінене, а решту бере з кешу. Але навпаки, коли ви вже виконали набір і більше не потребуєте цього вмісту кешу, його весь треба очистити, інакше під час виконання нових файлів через дублювання вмісту кешу можуть виникнути непередбачувані помилки.
Попереднє налаштування середовища для користувачів Windows
Якщо ви запускаєте WBPP у Windows, є два налаштування середовища, які краще одразу привести до ладу — це позбавить купи незрозумілих помилок пізніше (докладні повідомлення про помилки та діагностику дивіться в «WBPP Troubleshooting»):
Увімкніть підтримку довгих шляхів. Після одного з оновлень WBPP у Windows часто видавав попередження про довгий шлях, кажучи, що не може створити шлях довший за 256 символів. Я сам через задовгий шлях отримував пошкоджені файли від WBPP (бо файл не міг зберегтися). Рішення — знайти через пошук на панелі завдань regedit, відкрити Редактор реєстру, знайти потрібне місце й змінити значення LongPathsEnabled на 1; після перезапуску PixInsight це попередження більше не з’являється.
Уникайте шляхів із символами поза ASCII (наприклад, китайськими). Це й причина, чому я не рекомендую використовувати китайські символи в шляху до файлу. У Windows, якщо програмою за замовчуванням для відкриття є PI, подвійний клік на файлі зі шляхом, що містить китайські символи, викличе повідомлення про помилку, де ті нечитабельні символи і є китайським текстом. Обхідний шлях: не змінюючи шлях, просто перетягніть файл у PI мишею — і він відкриється.
Якщо скласти все це разом, загальна картина WBPP стає доволі зрозумілою: це потужний автоматизований механізм попередньої обробки, але треба пам’ятати, що результат його інтеграції — лише попередній перегляд, треба вміти групувати калібрування, вміло користуватися кешем, а також знати, що очистити й яке середовище налаштувати перед початком роботи. Коли поняття правильні, решта — лише питання майстерності.