[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