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

[Robert Q. Kimball]

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

[pfile]

i think as was suggested in the SGP forum, this is a question of the fits reader direction. unfortunately there's no standard for which corner of a fits file is represented by the first byte in the file. the old software probably is writing the fits file bottom-up and SGP is writing up-bottom (or vice versa, depending on how your PI fits reader is currently configured.)

you'll find that under the format explorer tab, if you double-click the FITS file handler you can change the reader direction globally. also i think you can give the format hints "up-bottom" or "bottom-up" to ImageCalibration, which will override the setting in the FITS file handler on a case-by-case basis.

if you used your old calibration masters with the new SGP lights, it's possible the calibration of the SGP lights is bad.

rob

edit: i had not seen in the other thread that you said these things did not fix the problem. i'm a little surprised at that - having to reverse the bayer matrix decoding is the hallmark of a fits reader direction problem.

[Robert Q. Kimball]

I had always noticed that in PixInsight my Atik images always seemed "upside-down".  I changed the setting in the Format explorer and it did flip the image, but not the debayer matrix.  I'll try it again, but I think I did it right the first time.  Thanks for the help.

[Robert Q. Kimball]

Rob,

I tried changing the read direction again and it does flit the image, but not the bayer pattern.

Bob

[pfile]

yeah i am looking at it, i see the same thing.

i think this boils down to the canon bayer matrix ordering getting flipped when the reader direction is reversed vs. the KAF-8300C ordering not being flipped. maybe. it's kind of a brain twister.

as a workaround, if you capture calibration frames with SGP they should at least be compatible with the lights captured with SGP. i think if you've used old masters to calibrate these images they have messed them up due to this issue.

rob

[pfile]

also with respect to the mosaic problem, it's hard to make mosaics from single frames as the SNR is so low. its even harder to make mosaics from unflattened images because of the vignetting gradient.

having said that, i used ABE on each of your frames to try to reduce the gradient/vignetting and then used the dnaLinearFit script to fit panes 2 and 3 to pane 1, then fit pane 4 to pane 3. i then used StarAlignment to make the mosaic, but kept "frame adaptation" unchecked, as the dnaLinearFit script will match the brightness of all the frames. the result is attached.

you can see that it's better than your try, but still pretty sketchy. to fix this the only cure is more integration time and good calibration and gradient removal.

rob

[pfile]

also on the bayer ordering problem it occurs to me that if the old software includes an odd number of overscan region lines, that would change the bayer ordering. do you happen to have one of those old files? is the X by Y geometry exactly the same as what SGP is writing out?

rob

[pfile]

well i looked at this a little bit more and the datasheet shows the following for a KAF-8300C sensor:

Total Number of Pixels
3448 (H) × 2574 (V) = approx. 8.9 Mp

Number of Effective Pixels

Color Device

3358 (H) × 2536 (V) = approx. 8.6 Mp

Monochrome Device

3366 (H) × 2544 (V) = approx. 8.6 Mp

now - it's certainly not unusual for a capture program / driver to give you slightly different number of rows and columns than what appears in the datasheet, because there are a number of "dummy" pixels around the edges of the device that are not exposed to light. depending on driver settings, you might have these 'overscan' regions turned on or turned off.

what's interesting is that the files out of SGP have an odd number of rows (your images are 3354x2529). this is why flipping the image over has no effect in debayering - the top and bottom rows, by necessity, have the same bayer pattern.

i don't think this is necessarily a problem with SGP, but more than likely how the ATIK ascom driver is configured (unless SGP has built-in support for ATIK?). the ATIK capture software probably does not use the ascom driver, so the default configuration for readout modes probably differs. just a guess, though.

rob

[Robert Q. Kimball]

Rob,

I can see why you're on the Jedi Council!   Thanks for all the time you've spent on my problem.  Unfortunately, (not really) I'm off to Madeira, Portugal and won't get to take my scope out for two weeks.  When I get back, I'll do a serious try at collecting data and doing the appropriate calibrations. I'll post my results here.  If you're ever in Las Cruces, New Mexico I'll buy you beer or two.

Bob

[pfile]

ha, well the jedi council tag just comes from having 20 billion posts in the forum! anyway glad it is sorted out.

eventually i will be in santa fe, but not sure when.

rob