Stacking Error in WBPP?

[AMcD]

PixInsight has just finished stacking 282 120s luminance integrations on the Iris Nebula from my QHY268M and has produced the master frame below.   I used local normalisation and x2 drizzle (which is why the stack took 17hours!!!).  The single subs and my master flat, master dark and master flat dark seem fine (also attached), with no apparent areas on the bottom of those frames that could have caused the issue seen on the master frame.  Does anyone have any idea what has caused this?

Edited December 19, 2022 by AMcD
Typo

[scotty38]

Did you blink or look at all 282 of your lights? Any chance there is any of them with this in them, maybe caught the edge of the Obs or something???

[AMcD]

25 minutes ago, scotty38 said:

Did you blink or look at all 282 of your lights? Any chance there is any of them with this in them, maybe caught the edge of the Obs or something???

I did, and there is nothing like that in them.  I had worried about the top of the observatory wall as the target gets quite low towards the end of the night but all of the frames look clean.  On closer inspection of the master light I think I can see a matrix at the border between the properly integrated data and the black strip.  I wonder if something went wrong with local normalisation or drizzle.  I am trying the stack in DSS now to see if I can reproduce the artefact.

[scotty38]

Ok will be interesting to see if there is any difference

[AMcD]

1 hour ago, scotty38 said:

Ok will be interesting to see if there is any difference

It looks like it was indeed a stacking error by the PixInsight WBPP script.  DSS stacked it without producing the artefact.  I am going to try and do a manual pre-processing of the data in PixInsight, as I think the good bits of the result that WBPP did manage to produce are better than that produced by DSS.  In particular, local normalisation appears to have done a better job of removing the gradient that runs bottom left to top right in the stack...

[scotty38]

I must admit I'm surprised but there you go. Did you just use the WBPP defaults as it were as I wouldn't expect there's anything wrong with WBPP as such but if there is it would be worth posting on the PI forum?

[AMcD]

1 hour ago, scotty38 said:

I must admit I'm surprised but there you go. Did you just use the WBPP defaults as it were as I wouldn't expect there's anything wrong with WBPP as such but if there is it would be worth posting on the PI forum?

Yes, I will post it on the forum.  As I say, it took 17 hours for the process to complete.  In the circumstances, I wonder whether there might have been a hardware issue at some point, in circumstances where my processor was working at max effort for nearly a day!  It will be interesting to see what happens now that I am breaking the processes down by pre-processing "manually" as it were.

[AMcD]

On 19/12/2022 at 13:13, scotty38 said:

ny chance there is any of them with this in them, maybe caught the edge of the Obs or something???

Well @scotty38, I think you were right after all.   I have spent the past couple of days noodling away at this and have traced the issue to the application of Local Normalisation to the light frames.   Even though the scope did not dip below the wall of the observatory, and therefore no edge shows when the frames are blinked, I think it did indeed get close enough to cause a subtle shadow over the objective lens, which is in turn confusing the Local Normalisation algorithm when that algorithm comes to be applied on the lower part of the frame.  Essentially, I think the algorithm thinks that 'normal' in that area of the frame is the shadow from the observatory wall rather than the sky.  Many thanks for your responses to this post.

[scotty38]

That's good news you sorted it, nice one!