Splotchy background after Batch Preprocessing and DBE or ABE

[alanrock]

I've got an image which seems to resist all my attempts with DBE to get an even background. I am pretty new to PI and am wondering if I could get some help with this. The image was taken with a ZWI OSC camera and I have applied flats, darks, and bias frames. The lights are 600 seconds ea and there were 14 of them. It's an RGGB camera, and the image has an obvious green color cast to it, but that's rather easy to remove, however, after running it through DBE or ABE, the resulting image is very splotchy and I cannot seem to flatten out the background. Any tips would be appreciated.

[pfile]

you'll have to upload the xisf to google drive or similar and post a link here, the only way to give advice is to work the image...

rob

[alanrock]

Is there someplace where I can upload the image, or do I need to share it some other way?

https://drive.google.com/file/d/1ds08Rk-6CszPcTOVoKNjBAWf-9gWm0k3/view?usp=sharing

[pfile]

part of the problem here is that you seem to have skipped the debayering step - you need to check "CFA images" in the BPP interface.

rob

[alanrock]

I have not skipped that step—it’s been debayered.

[alanrock]

Here's what the image looks like after a dynamic crop to clean up the edges and one pass of ABE.

[pfile]

someone else has to check me then - there's something wrong here; the image has a screen-door look which is characteristic of some kind of debayering problem.

rob

[msmythers]

rob

I've got the same thing as you. It looks like a debayer problem. I zoomed in 3:1 on the original and channel separated images and they all show the same thing which was expected. I also opened 2 of my own integrations with no other processing and the same zoom level. No screen-door. I tried a number of different debayering parameters on my own raw images and could not replicate the screen-door effect.

Could this be a split cfa type issue or drizzle cfa maybe? Another thought was all calibration and integration done in PI? Just throwing question out there.


Mike

[sharkmelley]

It's definitely using the wrong debayer mask for the files you have, that's why you seeing that blocky effect.  What format are your original files?  For instance with FITS there is always the confusion about whether or not the acquisition software saves them as "bottom-up" or not.  The "Up-bottom FITS" flag in the BatchPreprocessingScript can take care of that.  If you are not using BatchPreprocessing then try different combinations of debayer mask - I suggest GBRG first of all (the up-bottomed version of RGGB), then maybe GRBG, then perhaps BGGR.

Mark

[alanrock]

Well, the camera reports it’s RGGB, so that should be correct. I’m not seeing the screen door effect that you folks are seeing. Do you see the splotchy effect I’m talking about? Some areas in the image have a red/pink tint to them.

[sharkmelley]

Well, the camera reports it’s RGGB, so that should be correct. I’m not seeing the screen door effect that you folks are seeing. Do you see the splotchy effect I’m talking about? Some areas in the image have a red/pink tint to them.

Yes the camera might report it is RGGB but this only works if the acquisition software has not flipped the raw data before saving it into the file.  FITS, for instance, is notorious for being flipped by some software.

What acquisition software are you using and what file format does it use?

To see the screen door effect perform a ChannelExtraction then do a ScreenTransferFunction on each channel - view them at a scale of 2:1 or more to make it more visually obvious.

Until you debayer correctly then the colours will be incorrect.  This is the problem that needs to be fixed before anything else.

Mark

[srecaldin]

The debayer pattern for zwo cameras, I think is GRBG.

[alanrock]

I'm using Sequence Generator Pro and it's producing FITS files.

[bulrichl]

According to the pixel resolution (w=5496 h=3672) the camera seems to be a ASI183MC. The bayer pattern for this camera model is RGGB ( https://astronomy-imaging-camera.com/product/asi183mc-pro-color , Tab 'Specification').

I guess Mark is perfectly right: if the image is flipped vertically for some reason, the bayer pattern changes from RGGB to GBRG:

Code: [Select]

R G        G B
      ->
G B        R G
SGP was used for image acquisition(FITS files). So the correct setting in PixInsight would be 'Coordinate origin': 'Upper left corner (up-bottom)'. This has to be set in FITS format preferences (Format Explorer/FITS) and in BatchPreprocessing, if used.

Bernd

[alanrock]

I’ve used the up-bottom choice in Batchpreprocessing (I already was, that is). When I turned it off and left the debayering at RGGB, I got a very BLUE image, and the darks didn’t do their thing, so that wasn’t a good choice. I also switched it to GRGB and got the same as my original result. No luck here.