WBPP will not register all images

[Stephen Andrew Kennedy]

Please help me correct the user error that has resulted in the issue described below. I collected about 100 light frames of M33 during one evening, and culled out about 38 light frames due to clouds, etc. Of the 62 remaining images, blink shows them to be of good quality. I added the 62 light frames into WBPP with corresponding bias, flats, and darks. After running the script I get an error saying that only 13 light frames can be registered. According to the process logger, it looks like the software is excluding all the images captured after the meridian flip. For your convenience, attached is the process logger, a screen grab of the reference image, a screen grab of an image that was successfully included in registration, and a screen grab of one image rejected per the process logger. What user error have I committed and how do I resolve this?

UPDATE: I tried using the star alignment process based on the calibrated frames. 24 succeeded, 38 failed. I copied the info from the process console on the errors in case this helps and have included that in a txt file.

Equipment:
WO 102 with flattener, ZWO 2600MC Pro, guided on the EQ6R Pro with WO scope and camera, I am using the ASI Air Pro to collect the images, perform the meridian flip, etc.

 

[ngc1535]

Looks like a pretty big change in focus with respect to the rejected image.
-adam

 

[Stephen Andrew Kennedy]

Looks like a pretty big change in focus with respect to the rejected image.
-adam

Thank you for looking into this. Here is some additional information. I tried to stack about 45 images of the Flame nebula just now and received an error message that only about half of the images could be registered. I do not see a focus issue but when I get a moment I will prepare some screen shots for further consideration and comment.

 

[ngc1535]

Stephen,

If I may suggest- the best thing to do is prepare screenshots that show or prove what *cannot* be the problem. This issue can't be this because here is "X" screenshot. And it isn't this... because of "Y" screenshot.

So. Are the failures in registration due to hot pixels? (I have nice video on this.). Is this a PSF issue where you need to turn off PSF modeling. What about distortion?

At a minimum, your initial statement asserts that only rotated images failed to solve. Was this 100% true the first time and again true for the Flame data? If you use FastRotation (with an image container) on your flipped data, and then align does the problem remain?

-adam

 

[Stephen Andrew Kennedy]

Stephen,

If I may suggest- the best thing to do is prepare screenshots that show or prove what *cannot* be the problem. This issue can't be this because here is "X" screenshot. And it isn't this... because of "Y" screenshot.

So. Are the failures in registration due to hot pixels? (I have nice video on this.). Is this a PSF issue where you need to turn off PSF modeling. What about distortion?

At a minimum, your initial statement asserts that only rotated images failed to solve. Was this 100% true the first time and again true for the Flame data? If you use FastRotation (with an image container) on your flipped data, and then align does the problem remain?

-adam

Thank you, again, for looking at this issue. Your assistance is appreciated. I took the exact same frames for M33 that caused the original problem and transferred them from my Astro-only PC to my business laptop which has the same version of Pixinsight (the version before the most recent update). I rarely use the business laptop for astro because, well, it's for business. I ran the same lights/flats/darkflats on the business computer with PI and, voila, WBPP worked perfectly as expected, and all of the frames were processed. I have attached the process logger for informational purposes. This tells me that I must have a setting that is incorrect on the astro-only computer, probably in the settings menu for WBPP. But which setting is the question. I do not recall changing any WBPP settings. I use the default. Easy way out concept: since PI was recently updated to a new version, if I uninstall PI on the astro-only computer, and reinstall the newest version, may one assume that the new PI version will install with default settings? This is the path of least resistance but I concede that this process teaches me nothing and I could possibly repeat the error if I do not figure out what I did wrong in the first instance. To preserve the evidence, I will take screen shots of the WBPP settings before doing the clean install which hopefully will self-correct the problem and I can still do a forensic analysis of the settings on a cloudy night. I suppose I will also have to set up StarXterminator again which is a minor annoyance. I will try to post those screen grabs here so that you have something other than dead-reckoning theories on the incorrect WBPP parameters but if you want to take a guess, because you have nothing better to do, I would appreciate at your thoughts and let you know what i find. Thank you again.

UPDATE: I took some screen shots of the astro-only computer settings in WBPP compared to the same settings on the business computer. The files are numbered using this nomenclature: Capture 1 is the astro computer setting and should be compared to Capture 1.1 which (should be) the same screen as it appears on the business computer of the same screen in WBPP. This numbering scenario continues up to setting 8 (astro) versus 8.1 (from business computer). Because I am hopelessly dyslexic (no exaggeration) there all kinds of things I may have done incorrectly. I see that I did in fact make one setting change when the problem arose in screen 1 you will notice that the "force measurement" box is checked on the astro-only computer and it is not on the business computer. I did this after the problem arose in an effort to solve the problem which did not work. I hope these screen grabs will allow one to compare the screens on each computer so that you can draw some conclusions. I have to actually practice law today to fund this hobby so I will try examining these settings myself later this evening, but if anyone has time during the day and loves a challenge, appreciates a good puzzle, etc., well here you go, I would greatly appreciate your guidance, and you will gain a dyslexic friend fornever.

 

[ngc1535]

There aren't any screenshots attached- but I am not hopeful the answer will be there.
A couple of thoughts:

1. There are not default settings. This is an illusion and does not exist. The best way to approach the problem is to look carefully at the configuration of WBPP and the output. Probably best to simply work from the problematic machine (Astro-machine).
2. You have two PCs in the mix. You didn't mention this- but this means you have two sets of data- You may tell me they are identical, but so many issues like this are because data has been manipulated in some way the user forgot about or did not realize while they assumed the data was identical.
3. You can make 5 files that do and do not align from your astro-PC. Then someone can try to reproduce your results.

So I suspect go with the latest version of PI and WBPP and make certain you are using absolutely raw data (no masters).
By the way, the summary log isn't helpful. Better is the logfile found in the "Logs" directory that is created when you run WBPP.

 

[Stephen Andrew Kennedy]

There aren't any screenshots attached- but I am not hopeful the answer will be there.
A couple of thoughts:

1. There are not default settings. This is an illusion and does not exist. The best way to approach the problem is to look carefully at the configuration of WBPP and the output. Probably best to simply work from the problematic machine (Astro-machine).
2. You have two PCs in the mix. You didn't mention this- but this means you have two sets of data- You may tell me they are identical, but so many issues like this are because data has been manipulated in some way the user forgot about or did not realize while they assumed the data was identical.
3. You can make 5 files that do and do not align from your astro-PC. Then someone can try to reproduce your results.

So I suspect go with the latest version of PI and WBPP and make certain you are using absolutely raw data (no masters).
By the way, the summary log isn't helpful. Better is the logfile found in the "Logs" directory that is created when you run WBPP.

Thank you for the response. I had to correct a numbering issue in the screen shots which is why they were delayed in the upload.

I have attached the log file that you describe for the fail stack from the astro PC and also attached the log file that was a success on the business PC. My computers save the files as .txt files but when I try uploading they are recognized as .log files. Workaround: I saved them as text files with the ANSI format. But the ANSI format for the astro-pc file is "too large" to upload as a single document, so I split the information it into two separate volumes as another workaround. Thus, three new files attached.

As a point of further information and context, I initially encountered this problem with M33 on the astro-computer, and the software would not register the vast majority of the light images. I tried this several times. My immediate thought was that this was an issue unique to the data captured for M33. So I tried stacking data from a different target, the Flame nebula, to see if I would get a different result. The same problem arose, with a large number of the light frames being rejected. My conclusion, perhaps flawed, was that there is a setting in WBPP that is causing files to be rejected and not registered. To test that conclusion I copied the data files from M33 (which failed on astro-only PC) and tried to stack the same frames using PI on the business PC. The result was that all images registered. None failed.

You raise an interesting point regarding the image files. Yes, I took the frames from the astro-pc, copied them onto a disk drive, then ran the same files on the business laptop using WBPP which successfully processed them.

I collected new data yesterday evening on a different target. If it will prove helpful, I can copy that raw data onto separate thumb drives. Then I can process the same raw data using the astro-only PC versus the business PC and report the results. I will do this before updating to the newest version of PI.

 

[ngc1535]

If you upload a small set of calibrated and debayered files that (c_d) that failand some that succeed, it will be helpful.
You will need to upload them to a cloud drive somewhere and make publicly availble.
According to the log, I think it is failing due to hot pixels (my guess). Again, I have a YT video on this (have you seen it?).
Your log indicates you did not use Cosmetic Correction... with OSC data this seems to be a poor choice (based on my experience).

 

[Stephen Andrew Kennedy]

If you upload a small set of calibrated and debayered files that (c_d) that failand some that succeed, it will be helpful.
You will need to upload them to a cloud drive somewhere and make publicly availble.
According to the log, I think it is failing due to hot pixels (my guess). Again, I have a YT video on this (have you seen it?).
Your log indicates you did not use Cosmetic Correction... with OSC data this seems to be a poor choice (based on my experience).

Thank you Adam. Your attention to this question is very much appreciated. Just to clarify, am I correct that you recommend that all OSC users should select Cosmetic Correction? And does that opinion stand for all OSCs? I ask because I have two cameras, including the ZWO ASI2600MC (which is the camera associated with the subject of this thread) and a Canon EOS Ra (which is not the camera I used for M33). If I need to use Cosmetic Correction for both, I will certainly do that, and I thank you, sincerely, for the advice. Regarding YouTube videos ... I am hearing impaired so my first choice is to read but, if I need to watch a video, I can. It just means I have to put in those pesky hearing aids, and turn the volume up.

 

[ngc1535]

It is likely you will enjoy this. You can use the closed captions. I do not think there are too many technical words...so the automated captions should be OK.

 

[Stephen Andrew Kennedy]

It is likely you will enjoy this. You can use the closed captions. I do not think there are too many technical words...so the automated captions should be OK.

Very informative, and thank you for linking that. I was able to hear it just fine with the hearing aid. I probably would have overlooked checking the CFA box as part of cosmetic correction.