Odd Images--integration failure

alanrock

Well-known member
Mar 16, 2018
104
5
I'm not even sure where to really start with this question, but here goes. I shot 150 subs of 60 seconds each and I am trying to integrate them using WBPP. I am using an OSC camera, my calibration frames are current, although I took my bias frames @-10 Deg below the ambient temp indoors, which would have put the sensor temp at room temp, and my subs were shot with the sensor at about -5Deg below ambient temp, and it was about 38DegC outside last night (Yes, Arizona in the summer). Anyway WBPP fails at image integration, with an error of:
[2020-07-04 19:58:08] * Waiting for running tasks to terminate...
[2020-07-04 19:58:18] *** Error:
[2020-07-04 19:58:18] *** Error: /Volumes/ASTR WIN/Pictures/Astronomy/Lights/+++_2020_+++/OSC_Cocoon Nebula/2ndRunNoMasterBiasorDark/registered/NoFilter/Cocoon Nebula_LIGHT_2020-07-04_-5.00_60.00s_0072_c_d_r.xisf: Zero or insignificant signal detected (empty image?)
[2020-07-04 19:58:18] <* failed *>
[2020-07-04 19:58:18]
[2020-07-04 19:58:18] ************************************************************
[2020-07-04 19:58:18] * End integration of Light frames
[2020-07-04 19:58:18] ************************************************************
[2020-07-04 19:58:18] ** Warning: Error integrating light frames.

And when I look at the sub in question, it is noisy as hell and the failure is understandable. When I look at the Debayerd and Registered images, they seem to look different from within the same run, meaning image 10 looks very different from image 100. I have attached a screen shot showing the debayerd images and the debayered+registered images, along with one of the raw subs. Can anyone point me in the right direction here?
All the dark and bias frames were made under the same conditions, as far as I know (they were made the same evening, with no settings changes)
Is there something obvious I am missing here?
Thanks in advance
 

Attachments

Last edited:

pfile

PTeam Member
Nov 23, 2009
5,710
117
the moire pattern in the upper left really looks like it came from a dark mismatch. is there a chance your cooler cut out when either making darks or lights? that could account for the progressive degradation you see.

do your fits headers contain the cooler temperature? although a PITA you can look thru some of them and see if the CCD temperature was really what you thought it was.
 

alanrock

Well-known member
Mar 16, 2018
104
5
Yes sir. Also, I used these same calibration frames a few nights ago without incident.
 

alanrock

Well-known member
Mar 16, 2018
104
5
One thing I just thought of. Since I’ve changed the drivers that I’m using FROM the ASCOM drivers TO the ZWO drivers, I retook my bias frames and my darks, but I did NOT redo flats, because I thought that wouldn’t matter. Any chance that’s what’s causing my problem?
 

pfile

PTeam Member
Nov 23, 2009
5,710
117
absolutely - that is almost certainly the problem. changing capture software or drivers can change how the camera data is recorded. try making new flats and thus using only frames from the new driver and see how it goes.
 

alanrock

Well-known member
Mar 16, 2018
104
5
Well, I took new flats and am getting the same thing, so that didn't help. Here's the latest error message showing up in my logs before WBPP conks out:
[2020-07-08 04:44:23] MRS noise evaluation:
[2020-07-08 04:44:23] ** Warning: No convergence in MRS noise evaluation routine - using K-sigma noise estimate.
[2020-07-08 04:44:23] ** Warning: No convergence in MRS noise evaluation routine - using K-sigma noise estimate.
[2020-07-08 04:44:23] ** Warning: No convergence in MRS noise evaluation routine - using K-sigma noise estimate.
[2020-07-08 04:44:23] done

In this case I was only using 15 lights, if that matters--just to speed things up. Does this help?
 

pfile

PTeam Member
Nov 23, 2009
5,710
117
are any of the lights from the old driver though?

i think you're going to have to post some of these subframes - lights and calibration frames, there's no other way to debug it.

rob
 

alanrock

Well-known member
Mar 16, 2018
104
5
Thank you for responding (yet again!) They are all definitely from the new driver. What's the best way to share those files?
 

pfile

PTeam Member
Nov 23, 2009
5,710
117
google drive, onedrive, dropbox or similar, but you have to mark the files as shareable with anyone who has the link.
 

bulrichl

PTeam Member
Nov 2, 2016
859
65
La Palma, Canary Islands
This is an easy one. Flat and dark frames are captured at gain 111, offset 10. Probably also the bias frame (judging from the histogram), but the FITS keyword 'OFFSET' is missing in the FITS header of the bias frame.

However, the light frame is captured at gain 111, offset 0. That's the problem. An offset of 0 is probably a setting that will produce unusble frames. I doubt that you can save the light frames by capturing calibration frames with the same setting, but of course you can try.

Bernd
 

alanrock

Well-known member
Mar 16, 2018
104
5
I wonder why the capture software would choose something different (gain and offset) for the different frame types if I haven't changed anything--that seems odd. I have actually tried it without bias frames at all, so maybe I don't need to worry about that for now-especially since it's a CMOS camera and I "shouldn't" be using bias frames anyway.
The light frames individually look just fine even with that offset of 0, but idk if that proves anything.
Thoughts?
Thanks!
Alan
 

bulrichl

PTeam Member
Nov 2, 2016
859
65
La Palma, Canary Islands
I don't recommend an offset of 0. The offset setting is not critical, but there must not be any clipping at all in the low intensity range.

We don't need to speulate in this case, it is easy to find out: capture some bias frames with setting gain 111 and offset 0. Take a look at the histogram (horizontal zoom set to 100) and the statistics (look out for 'count(%)' with option 'Unclipped' unchecked).

If the bias frame is clipped, discard the frames and begin with a reasonable offset (10 seems fine to me).

Bernd
 

alanrock

Well-known member
Mar 16, 2018
104
5
But we think that because the light frames had an offset of zero and the dark frames had an offset of 10, that caused the problem? I have actually tried running WBPP without bias frames at all and gotten the same weird results, so we may even be able to take the bias frames out of the equation.
 

bulrichl

PTeam Member
Nov 2, 2016
859
65
La Palma, Canary Islands
No, I did not say that your current bias frame caused the problem. Please read what I wrote:

However, the light frame is captured at gain 111, offset 0. That's the problem.
Then I (basically) wrote that you can check whether you can apply calibration frames that are captured with gain 111, offset 0 as well to your current light frames: take a bias frame with these settings and examine if the new bias frame is clipped. If it is clipped you'll have to capture new light frames (with gain 111, offset 10).

Bernd
 

alanrock

Well-known member
Mar 16, 2018
104
5
Exactly. That doesn't answer my question, but it confirms what I said. Thank you!
 

alanrock

Well-known member
Mar 16, 2018
104
5
Well, I just created some darks with an Offset of zero, and ran WBPP again. It worked perfectly. Thanks!
 
  • Like
Reactions: pfile