3.61
#...
·
·
1
like
|
|---|
Just the five lights that you processed with default WBPP with LN: So clearly the accumulation of data from the 75 more light frames is shifting the gradient to white. |
5.76
#...
·
|
|---|
| Interesting. At least we are seeing the same stuff, I was worried. |
|
3.61
#...
·
·
1
like
|
|---|
| Well I feel better as well. Next time I'm out at the scope I'm going to reset the QHY driver to turn off overscan data. ASI turns it off by default and I don't think even gives the ability to enable it. I think I ended up here because in redoing some equipment I had gathered some dark and bias frames in a previous setting where overscan was off and then I did some imaging with overscan on and couldn't calibrate due to frame size mismatch. I just decided to turn on overscan vice redoing my bias and darks and have left it there since. |
0.00
#...
·
|
|---|
|
I would put my finger on the overscan which creates the white lines around (divide by zero with flat calibration) the image, and then local normalization picking that up. 99% of the time if there’s no data it’s black so I think many processes don’t deal nicely with that. Why it’s different between channels? I would assume drift in imaging so that the blue channel is offset from the other two enough that in the registered blue images the line is smaller. What you can do is to crop the images before integration (but do it for the calibration images as well). Open ImageContainer, add all of your images that go into the calibration and stacking, open a single frame and using that create a (dynamic) crop process that does the right crop, and then apply that to the image container. |
|
3.61
#...
·
|
|---|
| I like that plan Otto, thanks for the suggestion (was unaware of that process and didn't like the idea of the daunting task of manually cropping over 300 frames). |
|
3.61
#...
·
·
2
likes
|
|---|
| Just to update everyone. I ran the dynamic crop on an image container of all the images (bias, darks, and flats included) and reran WBPP with fully default settings and the end result masters are perfectly fine and should work well in creating the final image. I want to thank everyone for the suggestions and help particularly Linwood for all the investigative work and Otto for the ImageContainer fix method (yet another Pixinsight feature I was unaware of). |
|
0.00
#...
·
·
1
like
|
|---|
| Nice! I think the ImageContainer and ProcessContainer are very underappreciated gems in PI. Before WBPP script supported cfa drizzle properly without bugs, I used the ProcessContainer heavily to load six channels of drizzle tasks into one execution run so I could leave it to process everything at once unattended. |
|
3.61
#...
·
|
|---|
Yes, it was very helpful (after I figured out how to use it  ).
|
|
3.61
#...
·
|
|---|
| Just wanted to close this out. I turned overscan off on my camera's driver and my latest image made it through WBPP without issue. Thanks again for everyone's help! |
