Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

3x3 binning loses a column in the center of the mosaiced image #38

Open
tepickering opened this issue Sep 19, 2019 · 7 comments
Open

3x3 binning loses a column in the center of the mosaiced image #38

tepickering opened this issue Sep 19, 2019 · 7 comments
Assignees
Labels

Comments

@tepickering
Copy link
Collaborator

The way the binning is currently implemented, 3x3 binning is causing a column at the center of the image to be dropped due to number of pixels not being even factor of 3. This is obvious if there's a star straddling the boundary of the readout regions. One workaround is to switch to 4x4 binning as the ARTN default. This would mean 0.6" pixels which is getting to be undersampled under the best of conditions, but the majority of the time has IQ > 1.2". Being able to switch between 2x2 and 4x4 would be another option...

@dsand
Copy link
Collaborator

dsand commented Nov 4, 2019

I am going to try using different binning for some test targets tonight. I will let you know how it goes.

@dsand
Copy link
Collaborator

dsand commented Sep 14, 2020

Is this still an issue, @lund0946 ?

@lund0946
Copy link

lund0946 commented Sep 15, 2020

It is definitely still a problem. I took a 3x3 image and ran each amplifier through astrometry.net separately and then loaded them in ds9 as separate color channels. You can see that there's a gap in the data and it's larger than I thought it would be. I've also circled stars from NOMAD as a basic astrometry check. We can check this in a more robust way if we want.

There's an AZTEC night coming up. I'll request 3 dithered short exposures of 3x3 and 4x4 binning for some bright part of the Galaxy.

image

@bjweiner
Copy link
Collaborator

My notes from looking at the way the IRAF merge4k.cl script worked (previous to writing the Python pipeline) suggest that: the binned 3x3 image data in each half was in columns 1:682 (682*3 = 2046), meaning the last two unbinned columns were dropped on readout. The merge script then stuck an extra blank binned column in the middle when it pasted the image halves together. This was a little wrong since it replaced the 4 unbinned columns with 3 unbinned, but less than pasting them together without that extra space.

The missing 4 unbinned columns should be 0.6", so there is some other problem if the gap is closer to 2"; perhaps another binned column is being dropped in the pipeline.

If you can, try taking some images and then dithering by say 10 or 15" in the direction across the gap, to move stars from one side of the gap to the other. We can then count how many pixels they moved.

@lund0946
Copy link

In this case, I took two dithered images, subtracted the overscan, removed the background, and saved the amps individually. This is 3x3 binning and I can see ~5 binned pixels in the gap so ~2.1".

image

image

@dsand
Copy link
Collaborator

dsand commented Sep 15, 2020

Can we actually put human eyes on the overscan region from a raw image and verify that the header keywords are correct? Something seems wrong.

@lund0946
Copy link

lund0946 commented Sep 15, 2020

These bars represent the overscan region. The trim sections are correct in that there is no science data here that we are missing. The overscan looks black due to the scaling (values are negatives after background subtraction).

image

image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants