imarith issues
Jason Quinn wrote on Oct 22, 2012
I am trying to merely subtract a bias from a long list of image (about 450) and I'm getting strange errors.
I've been able to reproduce them using dev$pix.
Create a bunch of test files (for example 510) using
The last imarith command results (for me) in
A shorter lists appear to run correctly. For these images, the 87 images or more (at least for my machine) produces the "wrong number of elements" error message.
But some numbers of images less than 87 (for example 86) give a different error message:
results in
The "tes" part is a truncated part of the file names.
The exactly boundaries where this happens (like 86 or 256 for the original files where I noticed it) changes depending on the size of the images involved, so this might be some sort of out of memory error although my machine has 3GB of memory and should certainly be able to load 85'ish half-meg files based on dev$pix even if a few temporary files are involved for each. If this is being causes by out-of-memory conditions, the errors reported are unintuitive and I would think the design of imarith would makes it memory efficient so that all the images don't have to be loaded simultaneously.
Can't figure this one out.
Cheers,
Jason
I've been able to reproduce them using dev$pix.
Create a bunch of test files (for example 510) using
!seq -f 'imcopy dev$pix test%02g.fits' 1 510 > script.cl
cl < script.cl
!seq -f 'test%02g.fits' 1 510 > tlist
!seq -f 'out%02g.fits' 1 510 > olist
imcopy dev$pix bias.fits
imarith @tlist - bias.fits @olistThe last imarith command results (for me) in
ERROR: Wrong number of elements in the operand listsA shorter lists appear to run correctly. For these images, the 87 images or more (at least for my machine) produces the "wrong number of elements" error message.
But some numbers of images less than 87 (for example 86) give a different error message:
!seq -f 'imcopy dev$pix test%02g.fits' 1 86 > script.cl
cl < script.cl
!seq -f 'test%02g.fits' 1 86 > tlist
!seq -f 'out%02g.fits' 1 86 > olist
imcopy dev$pix bias.fits
imarith @tlist - bias.fits @olistresults in
tes is not an image or a numberThe "tes" part is a truncated part of the file names.
The exactly boundaries where this happens (like 86 or 256 for the original files where I noticed it) changes depending on the size of the images involved, so this might be some sort of out of memory error although my machine has 3GB of memory and should certainly be able to load 85'ish half-meg files based on dev$pix even if a few temporary files are involved for each. If this is being causes by out-of-memory conditions, the errors reported are unintuitive and I would think the design of imarith would makes it memory efficient so that all the images don't have to be loaded simultaneously.
Can't figure this one out.
Cheers,
Jason
Mike Fitzpatrick wrote on Oct 22, 2012
This may be a know issue with the new image template code that should be fixed in the latest update. You can do
to install the update. Otherwise, try using
to disable the new code and use the original template lists. If you still have problems let me know.
% cd /iraf/iraf
% make latest
to install the update. Otherwise, try using
cl> reset use_new_imt = noto disable the new code and use the original template lists. If you still have problems let me know.
Jason Quinn wrote on Oct 22, 2012
The "make latest" appears to have solved the issue. I had also reverted to 2.14.1 and the problem didn't exist yet as you also hinted.
Thanks for the super fast reply.
Jason
Thanks for the super fast reply.
Jason
Last post on Oct 22, 2012