View on GitHub

IRAF Community Distribution

IRAF maintained by the community

Home | Installation | Packages | X11IRAF | PyRAF | Forum

CTIO Y4K CCD reduction question

santiago wrote on Aug 20, 2008

Hello, I'm Santiago Roland and im going to the Yale 1.0m telescope in CTIO in a couple of days.. to do some TNO Photometry.... I read the Y4K cam reduction intructions by Massey and i was wondering if all this reduction can be done in the binned 2x2 mode. The image of the Y4K cam is separated by overscan regions in the middle of the detector (not physically), because of the 4 amps of the large 4k x 4k CCD array. So the calibration of this images in not trivial... i'm not genius using IRAF but i found Massey scripts that calibrates de images in order to do photometry with them... but it says "only for binning 1x1".... how much difficulty can be in changing the scripts for binning 2x2? can this be done? i have to bin 2x2 because sheduled TNOs have low SNR.

Thanks,

Santiago.-

Francisco Valdes wrote on Aug 20, 2008

I am not familiar with Y4K format but I suspect what you want to do is use the quadred.ccdproc task. Read the help "quadformat" to check. Historically there was an earlier set of scripts for reducing this "quad" format and some older CTIO documents describe using them. The ccdproc version of quad format is a better approach because it was designed for this type of data and is not based on scripts which can have some configuration problems.

I am more familiar with quadred.ccdproc, though the quadproc scripts are based on the single image version of ccdproc. The point is that I believe that there is no problem with processing binned data and it will be effectively transparent to you. It does depend on the Y4K headers to correctly define keywords for binned data which is sometimes problematic.

Yours,
Frank Valdes

santiago wrote on Aug 20, 2008

Here is the link to the CCD data processing discussion.

http://www.lowell.edu/users/massey/obins/y4kcamred.html

I just wanted to knoe if there may or might be difficulties on applying this script to binned 2x2 images... it might be a matter of simple number or may be not...

may be use this like a guide and make an other script from scratch.

I was hoping to get to CTIO ready for processing but, it may take a while...

Thanks for any suggestion,

Francisco Valdes wrote on Aug 20, 2008

Hi Santiago,

Thanks for the link. This is useful to understand where you and others are coming from. I see that it is very explicit that this is for unbinned data. Of course I know nothing about these scripts so I can't say why this restriction. I expect it is only because it expects certain file sizes. So it may be a matter or finding where file sizes, and keywords based on these like CCDSEC and DATASEC, are set and appropriately modifying them. If you get to that level of detail you will probably need to look at


cl> phelp ccdgeometry


I'm wondering if you a simple workaround might be to simply expand the images as if they were unbinned. You could use the task blkrep to block replicate the images, process them as if they were unbinnned, and then block average (with blkavg) or extract every other pixel with


cl> imcopy big[*:2,*:2] binned


The only problem in this scheme would probably be that the overscan would be twice as wide and the scripts might not understand this.

Good luck,
Frank

santiago wrote on Aug 20, 2008

Hello, i started the image reduction of the binned images and i tried to modify the script and i got some errors in the xgterm. i looked in the y4ktrim.cl and the y4kbreak.cl and noticed that the pixel sizes of the images to trim and stuff lies in them... so i calculated and verified the corresponding image sizes of the binned images and changed them, hoping that is the only thing to modify in order to make it work. i also check other .cl files in the script and found no reference to the image size... should y change the image header in the binning keyword? because it says 2, and may be the script is trained to find 1

thanks for any suggestion...

*** glibc detected *** /iraf/iraf/bin.linux/ecl.e: free(): invalid pointer: 0x8000030e ***
========= Backtrace =========
/lib32/libc.so.6[0x5564a615]
/lib32/libc.so.6(cfree+0x90)[0x5564e080]
/iraf/iraf/bin.linux/ecl.e[0x8156fc9]
.
.
large list of errors but can't copy&paste in the xgterm...
.
.
etc
ERROR: abort

Last post on Aug 20, 2008