Odd behavior of display with large magnification factors
Nicola Caon wrote on Apr 01, 2008
Hi,
I've noticed something which does not look quite correct when displaying on DS9 an image with a positive, large magnification factor.
Some examples:
The pixels along the edges are much narrower that all other pixels, whose size is slightly larger than one.
I checked this with both iraf 2.12.2a under Linux, and iraf 2.14 under macosx, in both cases with DS9 v5.0. 've also checked whether this is related to working with an image section, but no, it shows up also when first copying the image section into a new image and displaying the latter:
Is this some sort of bug in the display code? (zooming from DS9 does not produce any distorsions.)
It's true that this effect goes likely undetected when working with images hundreds or thousands of pixels in size, but right know I'm working with 16x16 pixel maps built upon IFU data and so it caught my attention.
Thanks
Nicola Caon
I've noticed something which does not look quite correct when displaying on DS9 an image with a positive, large magnification factor.
Some examples:
displa dev$pix[1:16,1:16] 2 xmag=32 ymag=32 fill- order=0
displa dev$pix[1:16,1:16] 2 xmag=9 ymag=9 fill- order=0The pixels along the edges are much narrower that all other pixels, whose size is slightly larger than one.
I checked this with both iraf 2.12.2a under Linux, and iraf 2.14 under macosx, in both cases with DS9 v5.0. 've also checked whether this is related to working with an image section, but no, it shows up also when first copying the image section into a new image and displaying the latter:
imcopy dev$pix[1:16,1:16] a16
displa a16 2 xmag=9 ymag=9 fill- order=0Is this some sort of bug in the display code? (zooming from DS9 does not produce any distorsions.)
It's true that this effect goes likely undetected when working with images hundreds or thousands of pixels in size, but right know I'm working with 16x16 pixel maps built upon IFU data and so it caught my attention.
Thanks
Nicola Caon
Francisco Valdes wrote on Apr 01, 2008
Hello Nicola,
I see the effect your write about (thanks for the clear and explicit example). I did a few other things like your imcopy but also clearing the physical coordinate system with wcsreset and using ximtool. Neither of these change things so it is nothing to do with ds9 or coordinates. As you say, this is something to do with DISPLAY.
I suspect that the the magnification is going from the center of the first pixel to the center of the last pixel. This means the edges are half as wide as the other pixels. The magnification (and demagnification) code is complicated and there may be reasons why this was done this way, and interpretation of what a magnification of, say, 6.3452 means in matching some other image at a different scale, or it may be a bug. The thing that concerns me is that the coordinate read back is not right. I would expect to see integer values at the centers of the magnified pixels which is not the case.
So there is a non-intuitive or buggy behavior with the magnification option in DISPLAY. I don't think we will have time to do much about this. Since image display servers, both ds9 and ximtool, are designed with their own integer zoom capabilities this should be used for small rasters. The magnificaiton option is used for non-integer zooms and you can avoid using the DISPLAY magnification by using image interpolation tasks for magnification. Note that something like MAGNIFY may do something similar.
I'm sorry if this is not the kind of answer you want but it seems to be a case of "it is what it is".
Yours,
Frank Valdes</u>
I see the effect your write about (thanks for the clear and explicit example). I did a few other things like your imcopy but also clearing the physical coordinate system with wcsreset and using ximtool. Neither of these change things so it is nothing to do with ds9 or coordinates. As you say, this is something to do with DISPLAY.
I suspect that the the magnification is going from the center of the first pixel to the center of the last pixel. This means the edges are half as wide as the other pixels. The magnification (and demagnification) code is complicated and there may be reasons why this was done this way, and interpretation of what a magnification of, say, 6.3452 means in matching some other image at a different scale, or it may be a bug. The thing that concerns me is that the coordinate read back is not right. I would expect to see integer values at the centers of the magnified pixels which is not the case.
So there is a non-intuitive or buggy behavior with the magnification option in DISPLAY. I don't think we will have time to do much about this. Since image display servers, both ds9 and ximtool, are designed with their own integer zoom capabilities this should be used for small rasters. The magnificaiton option is used for non-integer zooms and you can avoid using the DISPLAY magnification by using image interpolation tasks for magnification. Note that something like MAGNIFY may do something similar.
I'm sorry if this is not the kind of answer you want but it seems to be a case of "it is what it is".
Yours,
Frank Valdes</u>
Nicola Caon wrote on Apr 01, 2008
OK,
thanks very much for the prompt answer.
The reason why I was using the magnification option in the display task is that I was displaying a 16x16 map of, for instance, Halpha fluxes, and overlaying the fiber id for each pixel using tvmark (I have a table listing x, y, and id of the fibers). This allows to quickly identify which fibers correspond to some specific features such as intensity peak, emission knots, etc.
However, since, as you say, the centers of the magnified pixels do not have integer values, the fiber labels come up all misaligned.
Since I have to do so for many maps, I try to minimize manual interactions with the DS9.
I wrote a very simple script which magnify the image by using blkrep, transform the fiber table accordingly, and then execute the display+tvmark tasks. It works well, so for me the problem is solved.
Cheers
Nicola
thanks very much for the prompt answer.
The reason why I was using the magnification option in the display task is that I was displaying a 16x16 map of, for instance, Halpha fluxes, and overlaying the fiber id for each pixel using tvmark (I have a table listing x, y, and id of the fibers). This allows to quickly identify which fibers correspond to some specific features such as intensity peak, emission knots, etc.
However, since, as you say, the centers of the magnified pixels do not have integer values, the fiber labels come up all misaligned.
Since I have to do so for many maps, I try to minimize manual interactions with the DS9.
I wrote a very simple script which magnify the image by using blkrep, transform the fiber table accordingly, and then execute the display+tvmark tasks. It works well, so for me the problem is solved.
Cheers
Nicola
Last post on Apr 01, 2008