View on GitHub

IRAF Community Distribution

IRAF maintained by the community

Home | Installation | Packages | X11IRAF | PyRAF | Forum

image not displaying well with mscdispl

Ann wrote on Mar 24, 2009

I have a set of images from a mosaic ccd; I pre-processed them using a set of parameters recommended for the instrument (the VATT4k) and ended up with merged FITS files, not MEFs with extensions. I finished my processing in the noao imred package, and everything worked fine.

But now I'm trying to hop back to the mscred package to make finding charts, using mscgetcat, msctvmark, msccmatch, and some other tasks there. The problem is that the FITS appears to display just fine with display, but if I use mscdisplay, which I need for these tasks, the image pixels are off and my science image is essentially sitting in a black "frame."

Using mscdispl, the entire range of the "black box" is from pixels -527,-4 in the lower left corner and 1549, 2040 in the upper right. But the image itself is only in (9, 512) to (1017, 1520) or so. If I look at it using display, it's fine. I tried just zooming in so that I could see the science image, and proceeding with the rest of the processing, but I'm going to have problems since down the pipeline I'll be trying to "centroid" catalog stars on top of those black pixels.

But if I do an imhead, it looks ok:

agc8638R[2011,2011][real]:
No bad pixels, min=0., max=0. (old)
Line storage mode, physdim [2011,2011], length of user area 4131 s.u.
Created Sun 13:43:15 22-Mar-2009, Last modified Mon 13:54:53 23-Mar-2009
Pixel file "agc8638R.fits" [ok]
EXTEND = F / File may contain extensions
ORIGIN = 'NOAO-IRAF FITS Image Kernel July 2003' / FITS file originator
DATE = '2009-03-22T17:43:15' / Date FITS file was generated
IRAF-TLM= '13:54:53 (23/03/2009)' / Time of last modification
OBJECT = ' ' / Name of the object observed
NCCDS = 1 / Number of CCDs
NAMPS = 2 / Number of amplifiers
DETSIZE = '[1:2032,1:2032]' / Detector size
CCDSUM = '2 2 ' / CCD pixel summing
TIMESYS = 'UTC ' / Time system
DATE-OBS= '2009-03-19' / Date of observation
DARKTIME= 600.153 / Total elapsed time
ELEVAT = 70.4 / elevation
TIMEZONE= 7 / Local time zone
HA = '-01:22:21' / hour angle
DEC = '+24:43:26.0' / declination
EQUINOX = 2009.2 / equinox of RA and DEC
IMAGETYP= 'object ' / Image type
MOTION = 0 / telescope motion flag
INSTRUME= 'Vatt4k ' / Instrument name
RA = '13:39:47.26' / right ascension
DEWTEMP = -187.4 / Dewar temperature in C
LST-OBS = '12:17:25' / local siderial time
OBSERVER= 'ChangeMe' / Observers
JULIAN = 2454909.8 / julian date
OBSERVAT= 'Vatican Observatory, Mt.Graham' / Observatory
EPOCH = 2009.2 / equinox of RA and DEC
CAMTEMP = -112.1 / Camera temperature in C
AZIMUTH = 108.1 / azimuth
AIRMASS = 1.06 / airmass
UT = '07:49:10.021' / UT at start of exposure
TIME-OBS= '07:49:10.021' / UT at start of exposure
ST = '12:17:25' / local siderial time
FILTER = 'TOP 3 BOT 1' / Instrument filter
EXPTIME = 600. / Actual integration time
TIMFILE = 'tim2.lod' / Timing board DSP code filename
DETGAIN = 2 / Video gain setting
UTILFILE= 'util2.lod' / Utility board DSP code filename
SPEED = 2 / Video speed setting
IMAGEID = 1 / Image ID
CCDNAME = 'ccd1 ' / CCD name
CCDSIZE = '[1:2032,1:2032]' / CCD size
AMPSEC = '[1:1016,1:2032]' / Amplifier section
DETSEC = '[9:1016,9:2024]' / Detector section
CCDSEC = '[9:2024,9:2024]' / CCD section
WCSDIM = 2 /2
LTM1_1 = 1.
LTM2_2 = -1.
WAT0_001= 'system=image'
WAT1_001= 'wtype=tan axtype=ra'
WAT2_001= 'wtype=tan axtype=dec'
OVSNMEAN= 1791.027
LTV1 = -10.
LTV2 = 2023.
TRIM = 'Mar 20 15:36 Trim is [9:1016,9:2024]'
OVERSCAN= 'Mar 20 15:36 Overscan is [1020:1035,9:2024], mean 1791.027'
CCDPROC = 'Mar 20 17:05 CCD processing done'
IMCMB001= 'tmp2920n[1]'
IMCMB002= 'tmp2920n[2][-*,*]'
AMPMERGE= 'Mar 20 15:36 Merged 2 amps'
ZEROCOR = 'Mar 20 17:05 Zero level correction image is zero'
FLATCOR = 'Mar 20 17:05 Flat field image is rflat with scale=34146.98'
CRCOR = 'Threshold=450.0, fluxratio= 4.00, removed=1012'
FWHMPSF = 3.023
CTYPE1 = 'RA---TAN'
CTYPE2 = 'DEC--TAN'
CD2_1 = 0.
CD1_2 = 0.
CD2_2 = 2.2000000000000E-4
CD1_1 = -2.2000000000000E-4
CRPIX1 = 610
CRPIX2 = 1081
CRVAL2 = 24.77578
CRVAL1 = 204.8332

Any thoughts or helps would be much appreciated!

-- Ann

jstottsj wrote on Mar 24, 2009

amartin


agc8638R[2011,2011][real]:
DETSIZE = '[1:2032,1:2032]' / Detector size
CCDSUM = '2 2 ' / CCD pixel summing
...
CCDSIZE = '[1:2032,1:2032]' / CCD size
AMPSEC = '[1:1016,1:2032]' / Amplifier section
DETSEC = '[9:1016,9:2024]' / Detector section
CCDSEC = '[9:2024,9:2024]' / CCD section
TRIM = 'Mar 20 15:36 Trim is [9:1016,9:2024]'
OVERSCAN= 'Mar 20 15:36 Overscan is [1020:1035,9:2024], mean 1791.027'


I don't know if this is actually the cause of your problem, but these headers are inconsistent. If I remember right, VATT4k is a single CCD with multiple amplifiers, so DETSEC and CCDSEC should be the same. Also, you have CCDSUM set to '2 2', but everything else assumes that 1 pixel in the file is one pixel on the detector (binned pixels == unbinned pixels). I've never really figured out if CCDSUM is important or not to MSCRED, but to be safe I would try deleting the CCDSUM entirely and changing CCDSEC so it matches DETSEC (or vice versa) and see if that is enough to make the problem go away.

Jonathan

Francisco Valdes wrote on Mar 24, 2009

Hello,

I created an image with the same header and displayed it with mscdisplay. I think you are mislead by the different behavior or display/mscdisplay with filling the frame buffer (as set by stdimage). Display with show the center of the image if the frame buffer is smaller than the image, display in center of the frame buffer (with black around the edges), or zoom to fill the frame buffer (with the fill parameter). Mscdisplay will block average to put the whole image in a small frame buffer (i.e. it never just shows the center of the data), display in the center of the frame buffer (with black around the edges), or block replicate to the largest integer factor to fill the display with the fill option.

I used stdimage=imt4400 and mscdisplay put your 2011x2011 area in the center with black around the edges. I used the coordinate readout to see that the corners of the data did lie between 1 and 2011. So your description sounds like the expected behavior.

Yours,
Frank Valdes

Last post on Mar 24, 2009