Delays with ‘mscdisplay’
pakzad wrote on May 22, 2007
When displaying mosaic images in ximtool using 'mscdisplay', I have noticed it takes a long time for it to calculate z1 and z2 (~5 seconds). It also seems to take awhile to display the entire mosaic (~10 seconds). When I attempt to overlay a bad pixel mask using the parameters bpmask and bpdisplay(=overlay) in 'mscdisplay', nothing happens after giving it a few minutes. I have no problems when I use 'display' to do these tasks on a single CCD image.
With all the images I'll be working on, I'm afraid these times will add up, creating major delays. Are these 'mscred' tasks taking so long because I'm dealing with mosaic images? Or is there a way to speed up the processes 'mscdisplay' uses to display mosaic images?
Thanks,
Sabrina
With all the images I'll be working on, I'm afraid these times will add up, creating major delays. Are these 'mscred' tasks taking so long because I'm dealing with mosaic images? Or is there a way to speed up the processes 'mscdisplay' uses to display mosaic images?
Thanks,
Sabrina
Mike Fitzpatrick wrote on May 22, 2007
Hi Sabrina,
I apologize for the slow reply, Frank may also have some comments.
I agree 15-sec or so is a little long to display the image but it may be reasonable depending on whether you're using a local disk and local image display, or using a cross-mounted disk and/or a remote display. The z-scaling basically involves sampling each subraster on a grid to find the best values and so requires scanning the entire image, then doing it again when reading the image for display. Naturally this will be slower when accessing a disk on an NFS-mounted disk than if the disk were on a local disk (or even accessed w/ IRAF networking instead). AFAIK, there is no way to put pre-computed z-values in the header to be used instead. The missing mask overlay could simply mean the path to the mask is incorrect or invalid (e.g. the 'mscdb' isn't set).
A 'remote display' could refer to one where the XImtool and IRAF are running on a remote machine but you've used X to put the window on a local screen. In this case the bottleneck is the X traffic over the network. For better interactive use, an XImtool on your machine can be displayed to from a remote IRAF session using either an IMTDEV environment variable or by iraf networking and setting the 'node' CL
variable.
Lastly, if the FITS file has bscale/bzero values the FITS kernel will need to apply these each time it reads the image and adds to the processing time. If a MSCSTAT command shows similar access times then this may be the problem.
Hope this helps.
Cheers,
-Mike
I apologize for the slow reply, Frank may also have some comments.
I agree 15-sec or so is a little long to display the image but it may be reasonable depending on whether you're using a local disk and local image display, or using a cross-mounted disk and/or a remote display. The z-scaling basically involves sampling each subraster on a grid to find the best values and so requires scanning the entire image, then doing it again when reading the image for display. Naturally this will be slower when accessing a disk on an NFS-mounted disk than if the disk were on a local disk (or even accessed w/ IRAF networking instead). AFAIK, there is no way to put pre-computed z-values in the header to be used instead. The missing mask overlay could simply mean the path to the mask is incorrect or invalid (e.g. the 'mscdb' isn't set).
A 'remote display' could refer to one where the XImtool and IRAF are running on a remote machine but you've used X to put the window on a local screen. In this case the bottleneck is the X traffic over the network. For better interactive use, an XImtool on your machine can be displayed to from a remote IRAF session using either an IMTDEV environment variable or by iraf networking and setting the 'node' CL
variable.
Lastly, if the FITS file has bscale/bzero values the FITS kernel will need to apply these each time it reads the image and adds to the processing time. If a MSCSTAT command shows similar access times then this may be the problem.
Hope this helps.
Cheers,
-Mike
Last post on May 22, 2007