ongoing analysis / duplicate WBPP - No light frames found

Tailspin45

Active member
After interrupting a WBPP run, it fails, saying there are no light frames.

Reset to factory, delete cache, delete WBPP-produced folders, and it still won't run.

Do all that and restart Pixinsight, then it's fine.

Repeatable.

PixInsight 1.8.9-2 build 1605
Mac OS 14.4.1
 

Attachments

  • 20240410000002.log.zip
    4.5 KB · Views: 21
Last edited:
After interrupting a WBPP run, it fails, saying there are no light frames.

Reset to factory, delete cache, delete WBPP-produced folders, and it still won't run.

Do all that and restart the program, then it's fine.

Repeatable.

PixInsight 1.8.9-2 build 1605
Mac OS 14.4.1
Since the calibration is failing, no light frames are being written, which is why you see that error message. You need to figure out what's wrong at the calibration stage. Start by checking the FITS headers of a raw light, dark, and flat to make sure that all the important terms match (for instance, when people collect flats with different software than lights they can end up with different filter names, which will stop calibration). You should also check this for your master dark and flat.
 
Remember, I interrupted the process. That's why no light frames were written.

Seems like a more graceful exit after an interrupt should be possible (ie it shouldn't be looking for light frames)
 
Remember, I interrupted the process. That's why no light frames were written.

Seems like a more graceful exit after an interrupt should be possible (ie it shouldn't be looking for light frames)
No. No light frames were written because the calibration failed, so none were generated. See line 434 of the log. Nothing to do with your interruption.
 
I can confirm the same bug, with exact the same steps. Interrupt WBPP and you can't it run anymore.
Only after deleting (or renaming) WeightedBatchPreprocessing-001-pxi.cache it works again.
 

Attachments

  • WeightedBatchPreprocessing-001-pxi12123124.zip
    813 bytes · Views: 22
Only after deleting (or renaming) WeightedBatchPreprocessing-001-pxi.cache it works again.

Are you sure about that?
Did you try to exit WBPP completely and restart it? For me it is enough, no need to delete the cache file.
 
Are you sure about that?
Did you try to exit WBPP completely and restart it? For me it is enough, no need to delete the cache file.
In my case - yes, I'm sure. In any case, I shouldn't care about exiting wbpp or deleting a file. It worked before that major update
 
In any case, I shouldn't care about exiting wbpp or deleting a file. It worked before that major update

I'm not trying to reduce the importance of this bug in any way! As you can see above I have reported it back in January.

It is interesting that quitting WBPP resolve the issue for me and not for you. Maybe these are two completely different problems?
 
I don't think so. It was reported earlier last year after a major update when pix switched to Qt6(and other changes). The symptoms were the same so we are not alone here
 
I can confirm the same bug, with exact the same steps. Interrupt WBPP and you can't it run anymore.
Only after deleting (or renaming) WeightedBatchPreprocessing-001-pxi.cache it works again.
The problem here is that the calibration stage is failing. Whether that's a bug or a problem with the files is not clear at this point. Based on the original description, I don't see that interrupting the operation is part of the issue at all (it's not clear it ever ran properly, even before the interruption).

If this is a bug, the important diagnostic information is that calibration is failing, which would suggest some kind of issue with a damaged cache which is somehow still being used even if it's supposedly cleared. Deleting the cache file entirely is a good test.
 
The problem here is that the calibration stage is failing. Whether that's a bug or a problem with the files is not clear at this point. Based on the original description, I don't see that interrupting the operation is part of the issue at all (it's not clear it ever ran properly, even before the interruption).

If this is a bug, the important diagnostic information is that calibration is failing, which would suggest some kind of issue with a damaged cache which is somehow still being used even if it's supposedly cleared. Deleting the cache file entirely is a good test.

Can you try it yourself because I can reproduce the problem at 100% with any set of data and I got the exact same result as the OP?
 
Last edited:
Just try it yourself. I can reproduce the problem at 100% with any set of data and I got the exact same result as the OP
Yeah. Not sure why that matters. My point is the problem is occurring during calibration, no matter what precipitates the problem, so that's the place to look.
 
Well because it would confirm the problem...



Not really. I believe it fails at the step you previously canceled.
Maybe. I have only the one log to work with. But it doesn't confirm the problem. It confirms that there is a problem. A little different. ;)
 
This is another benchmark of sorts. It's the same problem as I and others have described.

This time, I didn't try to fix anything; I just quit PixInsight and restarted.

WBPP worked fine, but ignored all previously created CC, debayer, and registration files.
 
Last edited:
Back
Top