modulus operator for imarith
Mike McFadden wrote on Mar 18, 2003
Good day folks.
This is my first post to the listserv, so be easy on me :)
Short Form of question:
I need to perform a modulus operation on an image - and the imarith task doesn't seem
to support it - any ideas (other than doing a 'manual' modulus by hand using '/')?
Long Form: (for the more patient)
Here, at our observatory, we run PMIS as our image acquisition software, a windows application
that will probably be in use for the rest of the lifetime of the telescope.
Just recently, I moved from PMIS 3.5 to PMIS 4.0 due to some problems occurring in the
older version, and this allowed us to use 16-bit unsigned ints for our data format - increasing our
dynamic range. This is a good thing.
Unfortunately, it seems that PMIS writes FITS images with one's complement
binary or some other strange way of integer representation. This causes the FITS images, when
read into an image analysis program, to have bias levels just above ~32000 and gives some very
strange displays. Granted, after bias subtraction, this should all even out - but I would
like to correct the problem as suggested by Greg Remington of PMIS and Michael Newberry
of MIRA.
Other astronomers here use MIRA for their image reduction, and Mike Newberry wrote
a quick "PMIS unwrapper" for windows - which is run on the FITS images just before
they are opened in MIRA. The guts of this are basically just:
add 32768 & mod 65536
I'd like to write this 'unwrapper' for use with IRAF, simply by implementing it
with a call to imarith - but I hit a stump when I found that imarith doesn't support
the modulus operator.
In my investigations, I found that I can get a modulus operator from:
stsdas.toolbox.ttoolls.tcalc
But I wanted to bounce the question off the gurus before I go ahead and install
this entire package for just one simple mathematical operation.... I don't plan
on reducing any space telescope images here in the near future :)
any ideas?
-Mike
--
Michael T. McFadden
Research Technician - NASA Nearby Stars (Nstars) Project
Dept. of Physics and Astronomy
Appalachian State University
(828)262-STAR (7827)
Phil Hodge wrote on Mar 18, 2003
Mike, > add 32768 & mod 65536 I don't see why you would need to use the modulus function; just adding 32768 should be sufficient. > In my investigations, I found that I can get a modulus operator from: > stsdas.toolbox.ttoolls.tcalc You could use stsdas.toolbox.imgtools.imcalc. tcalc is in tables.ttools, and it's for tables, not images. Phil
Steve Allen wrote on Mar 18, 2003
On Tue 2003-03-18T12:02:51 -0700, Phil Hodge hath writ: > Mike, > > > add 32768 & mod 65536 > > I don't see why you would need to use the modulus function; just > adding 32768 should be sufficient. It seems extremely likely that the problem with the original images is that the contain 16-bit unsigned integer data. In that case they violate the FITS standard which only admits signed 16-bit integers. But if so, the fix is very easy, just add two header cards: BZERO = 32768 / offset data range to that of unsigned short BSCALE = 1 / default scaling factor -- Steve Allen UCO/Lick Observatory Santa Cruz, CA 95064 sla@ucolick.org Voice: +1 831 459 3046 http://www.ucolick.org/~sla PGP: 1024/E46978C5 F6 78 D1 10 62 94 8F 2E 49 89 0E FE 26 B4 14 93
Mike Fitzpatrick wrote on Mar 18, 2003
Steve is probably right that this is an unsigned short integer
problem. In addition to the bzero/bscale keywords the traditional "IRAF
approach" is to do something like
im> imexpr "(a < 0 ? a+65536 : a)" outimg a=inimg
where 'outimg' is the output file name and 'inimg' the input image name.
The IMEXPR task also include a mod() function if you really need a
modulus operation.
-Mike
Mike McFadden wrote on Mar 18, 2003
Thanks for the replies folks.... with the info I received, plus a little more hacking, I think I got it. First off, all the folks over here keep tossing around "16-bit unsigned int", but these images are sure behaving like they have more than 16 data bits... 24 maybe? 32? Anyway, I still needed to do a modulus because of this - adding 32768 to the images brought counts over 65536 - I'd like to see how that trick is done using only 16 bits! Steve: Oddly enough, I already had those fits cards you mentioned in my headers - so, unfortunately, it wasn't as easy as that. My final solution is to utilize Mike Fitzpatrick's suggestion with imexpr() and use the mod() operation. cl> imexpr "(mod(a+32768,65536))" out-image a="in-image" I'm still baffled by this PMIS image format, but hey - if I got a fix, then I'm not complaining. I'd be more than happy to supply one of these odd fits files to anyone interested - maybe I'm still missing something.... I'm still learning here, and appreciate the help. At least the learning curve isn't quite as steep as it was 2 years ago. Thanks again guys! -Mike PS - is there an RFC I should know about regarding the FITS format? -- Michael T. McFadden Research Technician - NASA Nearby Stars (Nstars) Project Dept. of Physics and Astronomy Appalachian State University (828)262-STAR (7827)
Steve Allen wrote on Mar 18, 2003
On Tue 2003-03-18T15:05:56 -0700, Mike McFadden hath writ: > PS - is there an RFC I should know about regarding the FITS format? There will be, but right now it's just an internet draft full of references to the standards documents... http://www.ucolick.org/~sla/fits/mime/ -- Steve Allen UCO/Lick Observatory Santa Cruz, CA 95064 sla@ucolick.org Voice: +1 831 459 3046 http://www.ucolick.org/~sla PGP: 1024/E46978C5 F6 78 D1 10 62 94 8F 2E 49 89 0E FE 26 B4 14 93
Last post on Mar 18, 2003