[daip] Re: forwarded message from Eric Greisen

Eric Greisen egreisen at aoc.nrao.edu
Thu Jul 10 15:22:22 EDT 2003


Lincoln Greenhill writes:

I have made changes to PCNTR and kNTR coming in tomorrow's MNJ.

 > We have been wrestling with the question of how to display spectral-line
 > polarization information.  Glad you asked.  We have formulated to 
 > strategies to address our line polz cubes of maser sources in AG575.
 > 
 > 1 - this is what you suggest, contours w/ colored polarization vectors
 > where color indicates frequency channel number (as coded in the wedge).
 > The question is what contours to use?  If you use color coded contours
 > and vectors then for more than a few channels it is all too confusing
 > to read.  This is nonetheless a good capability for some applications and
 > I encourage you to implement something like this.  One might also permit
 > a ch0 map to be contoured while the vectors are color coded as suggested.

      PCNTR is hard to drive.  I have added the choice of overlapped
contours in color=channel, or no contours and polarization vectors
color=channel.  But that requires just the input you gave me - 3 cubes
with the I image used to limit where the P is plotted.  One also has
the choice of color = polarization angle since the angles of short
vectors are hard to see.  That may be especially useful in KNTR.

 > 2 - side by side B&W contour plots of consecutive frequency channels with
 > the B&W polarization vectors from all channel superposed on each plot. In
 > each plot window, the vectors for the channel that corresponds to the plot
 > window are black and thickened.  The other vectors are gray or
 > transluscent.  This permits one to see the frequency dependent structure
 > of the source (the contours) and to see the spread in polarization at each
 > pixel, which is an important quantity otherwise hard to estimate w/o 
 > turning a lot of pages.
 > 
     This is probably not all that useful for the present data - each
spot has its own polarization and they are rather different.

 > > KNTR may be a better task for diaplaying these data.
 > 
 > We are trying that now.  We may have another bug report related to it.

KNTR trashes FACTOR after the first plane.  That will be fixed in the
morning.

Send more thoughts - although I will have to write a new task if the
inputs get any worse....

ERic



More information about the Daip mailing list