Solução de problemas do WBPP: erros frequentes e bugs conhecidos
Este artigo foi compilado a partir de notas feitas entre 2022 e 2025; algumas ferramentas ou fluxos de trabalho já foram atualizados, então tenha isso em mente durante a leitura; as mensagens de erro e os comportamentos específicos de cada versão mencionados no texto foram todos registrados como estavam na época. Para a interface do WBPP, os masters de calibração e o fluxo de execução normal, consulte o outro artigo “Guia completo do WBPP”.
Rodar o WBPP do início ao fim com um único clique é sem dúvida uma delícia, mas, quando você realmente o usa, sempre acaba esbarrando em situações em que ele trava, dispara erros ou produz resultados que simplesmente não parecem certos. Este artigo organiza as categorias de problemas de WBPP que enfrentei ao longo destes anos — as que mais me perguntam — em um manual de solução de erros, desde a mentalidade de diagnóstico até alguns bugs conhecidos concretos.
Primeiro passo da solução de problemas: olhe primeiro o Process Console
Quando algo dá errado no processamento do PixInsight, a primeira coisa em que você deve sempre pensar é consultar o Process Console. Ele diz onde o erro ocorreu e de que tipo de erro se trata; é o ponto de partida de todo diagnóstico.
No entanto, o WBPP é um script e, enquanto o script não está em execução, o console fica recolhido e não pode ser selecionado. Portanto, para ver o console, muitas vezes é preciso fechar primeiro o WBPP. Isso parece um transtorno, mas, para muitos problemas, é a única fonte de pistas — a solução de vários dos bugs a seguir começou toda ela naquela linha de texto vermelho no console.
Falhas e bugs na fase de calibração
Calibração falhou (failed) — feche primeiro o PI e reabra. Se, ao executar o WBPP, a calibração inicial (que usa os masters de calibração) falhar logo de cara e o status exibir um failed em vermelho, você pode pausar todo o fluxo, fechar o PI, reabrir o WBPP e executá-lo mais uma vez; esse erro de calibração falhada em geral desaparece então. Ao processar imagens OSC, encontrei esse bug pelo menos quatro vezes, e todas as vezes o resolvi com esse truque.
Os flats falham a calibração o tempo todo — volte ao processamento manual, passo a passo. Algumas versões do WBPP têm um bug que faz a calibração dos flats falhar repetidamente. Nesses casos, saber processar você mesmo, passo a passo, torna-se importante. Já que estamos nisso, vamos revisar os passos do Pre-Process:
- Calibration:
light − dark / ((flat − flat dark) * med(flat)) - Cosmetic Correction
- Debayer: interpolar sobre a matriz de Bayer
- Star Alignment
- NSG
- Integration
Quando não se pode confiar na automação, decompor o fluxo e executá-lo à mão torna, na verdade, mais fácil localizar em qual passo está o problema.
Problemas de caminho: duas causas possíveis de um File I/O Error
Ao usar o WBPP no Windows, se a fase de calibração (calibration) disparar um File I/O Error, em geral é por uma destas duas causas:
- O caminho do arquivo mais o nome do arquivo é longo demais e ultrapassa o limite do sistema, precisando ser encurtado.
- A pasta de destino não pode ser gravada, por exemplo, se você definir a saída em uma pasta do sistema.
A primeira é a mais comum. Para curar de vez o “caminho longo demais”, você pode ativar no Windows o suporte a caminhos longos (definir LongPathsEnabled como 1 no Editor do Registro, regedit); além disso, é recomendável evitar caminhos com caracteres não ASCII (por exemplo, chineses). Os passos detalhados desses dois pré-requisitos de ambiente eu escrevi na seção de configuração do ambiente Windows de “Guia completo do WBPP”, por isso não os repito aqui.
O bug das coordenadas RA/DEC dos “60 segundos não transportados”
Este é o problema mais capcioso e também o que mais merece ser destacado à parte, porque seus sintomas são dos mais variados, mas a causa de fundo é sempre a mesma: no FITS Header, as coordenadas de ascensão reta / declinação têm um valor de segundos de “60” que nunca foi transportado para a casa seguinte.
Eu me deparei com isso duas vezes, cada uma com uma manifestação diferente.
A primeira vez: o WBPP não conseguia carregar o arquivo. Fechei o WBPP e fui olhar o Process Console, e descobri que certa linha de um script js reportava “invalid coordinates”. Na hora, achei que fosse um bug do WBPP; peguei a mensagem de erro e a pesquisei na internet, e só então encontrei no PixInsight Forum várias mensagens de erro idênticas — acontece que o problema de coordenadas estava impedindo a imagem de carregar no WBPP. Já com uma direção a seguir, ainda assim levei uma hora vasculhando centenas de lights até localizar a imagem problemática: sua coordenada OBJCTDEC estava errada. Abri no PI o processo FITSHeader, rolei até OBJCTDEC e alterei o valor que “deveria ter sido transportado, mas não foi” — no exemplo, mudando -69 26 60 para -69 27 0 — e essa imagem então carregou sem problemas, e os arquivos seguintes deixaram de ficar travados por causa dela.
A segunda vez: os arquivos não entravam e o console reportava too much recursion. Mais tarde, aconteceu de novo: ao adicionar arquivos ao WBPP, o software travou e, no fim, nenhum arquivo foi adicionado. Fechei o WBPP e, ao olhar o Console, havia um InternalError: too much recursion em vermelho. Depois de reabrir o WBPP, percebi que parte dos arquivos já estava carregada e parte não; ao verificar os que não haviam carregado, era de novo, como esperado, uma anomalia do FITS Header — desta vez o DEC exibia -46 01 60, em que os segundos “60” deveriam ter sido transportados para -46 02 00. Assim que o WBPP lê um valor anômalo desse tipo, ele trava, e ainda arrasta consigo todas as imagens seguintes, impedindo que elas também carreguem. Do mesmo modo, abri o FITS Header e transportei os segundos à mão; depois de corrigir, bastou adicionar os arquivos de novo. Quando todos os arquivos carregam com sucesso, o WBPP faz aparecer automaticamente uma mensagem de diagnóstico, por exemplo “60 of 60 light frames were added”.
Uma conclusão comum: esse problema de as coordenadas não serem transportadas automaticamente, pelo que vi até agora, ocorreu quase sempre quando o software de captura era o MDL (controle remoto), embora eu não possa descartar que outros softwares de captura tenham o mesmo defeito. Por isso, sempre que o WBPP travar e os arquivos não puderem ser adicionados, consulte primeiro o Process Console para confirmar o tipo de erro e, em seguida, verifique se o Header de RA/DEC apresenta o bug dos “60 segundos não transportados”; após uma correção manual, na maioria das vezes o problema se resolve.
Desempenho: por que o pacote completo demora tanto
Por fim, vamos falar de um problema que, a rigor, não é um “erro”, mas nem por isso deixa de ser um suplício — o pacote completo do WBPP é simplesmente lento demais. Certa vez deixei o pacote completo rodando quatro horas inteiras por causa de cinco imagens com que eu queria fazer um HDR (a máquina de então era um AMD R5-4650G, DDR4 3200 32GB, SSD Gen4, com imagens de 24 megapixels; uma espera dessas dá mesmo vontade de trocar de computador).
Há dois pontos que consomem especialmente tempo:
- Separated RGB: processar separadamente os canais RGB de uma foto colorida para eliminar a aberração cromática.
- Local Normalization: escolher as melhores imagens (algumas poucas) como referência e aplicar a Local Normalization às demais.
Se você desativar esses dois, o WBPP fica muito mais rápido. Se vale a pena sacrificá-los em nome da velocidade depende das suas exigências quanto ao resultado final — sobre as medições concretas de “quais passos desligar, quanto tempo se economiza e quanta qualidade se perde”, tenho em “Guia completo do WBPP” um conjunto de dados que mostra uma aceleração de 7 a 8 vezes ao qual você pode recorrer.
Resumindo a mentalidade deste manual de solução de problemas: quando algo der errado, olhe primeiro o Process Console; se a calibração der failed, feche o PI e reabra; se os flats falharem a calibração o tempo todo, volte ao processamento manual passo a passo; um File I/O Error é, na maioria das vezes, um caminho longo demais ou uma pasta em que não se pode gravar; e se as coisas não carregarem, travarem ou reportarem recursion, vá verificar se o RA/DEC no FITS Header tem um valor de segundos de 60 que não foi transportado. Domine bem esses poucos truques e você dará conta da maioria dos gênios difíceis do WBPP.