My Atik 383L OSC/ SGPro-Mosaic / PixInsight Mystery

I am posting the same “mystery” on the Atik Forum, SGPro Forum and the PixInsight Forum hoping someone can solve what I think is an interesting problem. I am also adding links to my images via Dropbox.

First, some background. I’ve been using my Atik 383L OSC camera with Artemis capture software for more than two years. Both have performed beautifully. I have also been a PixInsight advocate and user for at least two years. I understand how to use flats, darks and bias images to calibrate my lights. I have done several mosaics with very few problem. (I have always used BGGR in PixInsight as my debayer matrix.

Two weeks ago, downloaded Sequence Generator Pro (SGPro) which I think is absolutely amazing piece of software. The integration of plate solving and image sequencing to a joy to behold. I also bought the “mosaic” add-on to SGPro which again is fantastic.

But after all this joy, I ran into a problem that has me completely stumped. I took my first series of images of the Heart Nebula with SGPro and moved them into PixInsight for processing. I debayered the images using BGGR as always, and to my surprise, I discovered a green Heart nebula. I changed the matrix to GRBG and I was back to the hydrogen we all know and love. This surprised me, but didn’t seem like a big problem.

Next, I tried out the mosaic add-on. It worked beautifully. Four, twenty minute subs of the Heart Nebula with nice even overlaps in both directions. I immediately fired up PixInsight to debayer, register and combine the four panels into one image. Again to debayer the images I had to use the GRBG matrix. When I started to combine the image using StarAlignment -> Register/Union - Mosaic. I got an matching intersection but the two halves of the combined image seemed to have a very different matrix/noise/brightness structure. I am attaching links to the images.

Why would images produced with the same camera but captured with different software (Artemis vs. SGPro) act so differently in PixInsight? I noticed in the .fits header of an old image captured by Artemis the fields BAYOFFX=1, BAYOFFY=1. Maybe that’s a clue.

Here are the four Heart Nebula images (.fits)

https://www.dropbox.com/s/afdcju4ui2e4u5q/Heart-1frame1.fit?dl=0
https://www.dropbox.com/s/0vkv5gpl7s7tm8g/Heart-2frame1.fit?dl=0
https://www.dropbox.com/s/3iz2wl3g8i4m2t9/Heart-3frame1.fit?dl=0
https://www.dropbox.com/s/wrmw6ru3vocya9d/Heart-4frame1.fit?dl=0

Here are Heart1 panel and Heart2 panel combined

https://www.dropbox.com/s/83c4vdk83pnah28/Heart1%262.jpg?dl=0

Here are Heart 3 panel and Heart4 panel combined

https://www.dropbox.com/s/h45qejs7cxt86hx/HEART_3%264.jpg?dl=0

Here is the full mosaic

https://www.dropbox.com/s/oat8h4aaesfzmja/Mosaic.jpg?dl=0

Here is a close up of one of the intersections

https://www.dropbox.com/s/sba4yb398ipgw4u/Intersection.jpg?dl=0

Hi Robert,

Not sure if this what you are looking for or asking but I image with the Atik 383L+ OSC. I use DeepSkyStacker 3.3.2 for stacking all of my images including Darks, Flats and Bias. I have the Bayer pattern set to GBRG and everything turns out with the correct color. I process my images in a program called StarTools.I’ve only every did two mosaic’s and both processed the same, I did not need to mess with the Bayer pattern. All were obtained using SGPro.

regards,
mahaffm

Hey Robert, Have you tried calibrating your images first before trying to register them for the mosaics?

There are normally 2 steps to the mosaics one is first a mosaic map then the next GradientMergeMosaic.

I did a few tests I was able to create the mosaic, just I had a few issues with most definitely the frames not being calibrated.

I tried to calibrate ther images with old flats, darks and bias masters from the Atik-Artemis setup. They wouldn’t calibrate. I’ll have to make some new masters using SGPro. Thanks for the help.

Bob

i am just following up on the PI forum. the crux of this is that the SGP-generated images have an odd number of rows. this is not normal for an OSC and it’s why flipping the image has no effect on the debayering method.

i don’t think this is necessarily a problem with SGP; i think it is something to do with how the Atik ASCOM driver has been set up.

I think you may have solved my problem. I forgot the Artemis uses the Atik camera natively whereas SGPro uses the Atik ASCOM Driver.

As I mentioned, the .fits header from the Atik image has BAYOFFX=1 and BAYOFFY=1. I just used the ASCOM Profile Explorer and look at the ASCOM driver for the Atik camera. It has BayerOffsetX=1 and BayerOffsetY=0.

If i change the value in the ASCOM Driver, will everything work? I’ll try it and see what happens.

Thanks for the tip.

Are you talking “rows” or “columns”?

i am not sure if changing it will fix things, but it’s certainly worth a try. i noticed you had mentioned those keywords @ PI forum but i didn’t know what they meant.

i’m talking about rows when you view the image as “landscape” which i think is the native orientation of the sensor. the number of columns in that same orientation was an even number.

oh - dunno if the ascom explorer changes would be the same as clicking “setup” next to the camera connect icon in SGP. that’s how i always access the ascom driver settings for my various equipment. so i guess that’s something to look out for if it doesn’t “take” when you use the explorer.

rob

Using the setup dialog is the preferred way to change things, the Profile Explorer is like the Windows Regedit tool, powerful but dangerous.

I’d always recommend collecting calibration data using the same acquisition application as the image data, there’s no guarantee that the fundamentals of the data, such as the number of rows and columns and the orientation of the image in the data will be the same.

Chris