iraf.net

Dear all,We are having trouble with the imarith command in the noao package of IRAF.In carefully analyzing our scaled images, the calculated pixel value does not exactly match the value we expected. It's close but not exact.So for instance we are doingimg1.imh - img2.imh = img3.imhAnd if some pixel in img1.imh is 3000 and a pixel in img2.imh is 2000 we DON'T get img3.imh as 1000. This is very strange.Both scale values and image types are real. What do you think the problem would be?Thank you all!

How close is "close"? Are the values really of order 3000 or is it much much larger/smaller? Is the error something you'd expect from floating point round-off?The task does have a 'pixtype' and 'calctype' parameter you can use to have the calculation done in double precision, if the numbers are very large/small this may be required along with a double-precision output image type. Otherwise, please post actual numbers, how you got them (e.g. from IMSTAT or by listing pixels) and what IRAF and machine type you're using. IMARITH has been around quite a while and is pretty reliable.BTW, are you actually getting a 'file truncated' error as suggested by the Subject? If so, how did you get the output image values?-Mike

When we subtracted 10 from an image, we found that it had actually subtracted anywhere between 9.75 to 10.25. We inspected the actual pixel values on both images.Then, when we subtracted this subtracted image from the original image. We found all pixels had a constant value of 9.9947. We did not see any of the pixel-to-pixel variations we were seeing initially.We got the same results whether we used double or real in the pixtype and calctype options.We are using IRAF 2.12.2 (on a Mac OSX) and the most recent Linux version downloaded onto a pc.We did get the error: pixel storage file truncated but we still get an image. It was that error that prompted us to look closely at the pixel values.Thank you!!!

Please post a URL to the image and the exact commands you used to both do the subtraction and to find the pixel values. If you can do this with the dev$pix test image (perhaps using CHPIXTYPE to make it a real image if that's what you have) all the better. I thought this might be a problem with FITS bscale/bzero but your original message mentioned .imh images, otherwise this is really strange.-Mike