[daip] AIPS frustration-related issue
Eric Greisen
egreisen at nrao.edu
Fri May 7 17:37:19 EDT 2010
Glen Langston wrote:
> The imaging program SDGRD makes images with very noisy
> edge pixels. The range in these output images using
> the sync and Bessel function (XTYPE = -16)
> is strangely large. Most of the other convolution
> functions produce more stable output ranges, so
> the map contains pixels with values only in
> the range between the max input and spectra.
> (Ie gridding the data with convolution function -12
> yields reasonable data)
>
> For XTYPE = -16, the data in the center of the map
> are fine, so to find the data range, use
> TVWIN and IMSTAT to find the min and max values
>
> A simple to work around this problem use
>
> pixra = -1, 20 (for orion)
> pixra = -20, 250 (for the moon)
>
> for these sources, then
>
> TVLOD
>
> Glen
>
>
>> Thanks.
>>
>> A few more random AIPS questions:
>>
>> I made an image and the full data range somewhere was quite large so
>> that I had to fiddle with the TV color table and the image looked good,
>> but it was all compressed into a tiny range. Setting aside the issue as
>> to what was different for me in getting to that image, how do I limit
>> the TV to just consider a smaller data range? I see that tvlod has a
>> pixrange parameter, but setting that never seemed to make any
>> differences in what was actually loaded. So, how would you handle that?
>>
>> Are you still doing the baseline subtraction in AIPS? Can you remind me
>> what that task name was?
>>
>> Finally, for that "continuum" image. How did you generate that in
>> AIPS? Are you using an AIPS task to average several channels together?
>> Presumably that's all done before any baseline subtraction? Or is that
>> just one of those channels from that image prior to any baseline
>> subtraction?
>>
>> Thanks.
>>
>> -Bob
>>
>> Glen Langston wrote:
>>> The image circulated was made with the sinc/bessel function
>>> convolving function, (XTYPE=-16).
>>>
>>> Using the exponential convolving function allows producing a smoother
>>> image, without occasional high spots (XTYPE=-12)
>>>
>>> Glad that last trick worked.
>>>
>>> Glen
>>>
>>> PS. Using different convolving functions can sacrifice angular
>>> resolution for smoothness.
>>>
>>> Here's an image with 40 arc-second convolving function size,
>>> and 16 arc-second convolving function FWHM.
>>> (XTYPE=-12, XPARM=40,16,2,0)
>>>
>>>
>>>
>>>> Changing groups didn't help. I verified that the group was actually
>>>> changed by making a local file where the group was seen to be set to
>>>> aipsuser. I still can't make any changed to the /home/aips/RUN
>>>> directory.
>>>>
>>>> However, the last trick worked. Thanks.
>>>>
>>>> You made at least 3 images as seen in aips message log. Which one is
>>>> the image that ultimately led to the continuum image that was included
>>>> in that e-mail?
>>>>
>>>> -Bob
>>>>
>>>> Glen Langston wrote:
>>>>
>>>>> Sometimes you have to change groups to make the links
>>>>>
>>>>> newgrp aipsuser
>>>>>
>>>>> or something similar
>>>>>
>>>>> Alternatively you can put the runfile in the
>>>>> directory you started aips in.
>>>>>
>>>>> If you have the file IDLTOSD.001, put it there,
>>>>> Then you type
>>>>>
>>>>> VERSION = 'PWD'
>>>>> input RUN
>>>>> RUN IDLTOSD
>>>>>
>>>>> This should load the code
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Hi Glen,
>>>>>>
>>>>>>
>>>>>> How do I load the IDLTOSD run file? Typing:
>>>>>>
>>>>>> > run idltosd
>>>>>>
>>>>>> results in "TEXT FOR IDLTOSD UNAVAILABLE". I can see the RUNFIL
>>>>>> environment variable is defined and points at /home/aips/RUN which
>>>>>> sure
>>>>>> seems to have an IDLTOSD.001 in it, so I don't understand why this is
>>>>>> failing for me.
>>>>>>
>>>>>> I also can't make a symbolic link for a version using my current AIPS
>>>>>> user number there because I apparently lack the necessary permission
>>>>>> to
>>>>>> do that even though I am a member of the aipsuser group. So, what am
>>>>>> I
>>>>>> doing wrong.
>>>>>>
>>>>>> -Bob
The REWEIGHT(2) parameter is very helpful here - values like 0.1 or 0.3
even might help in preventing excessive **extrapolation** of the data.
It is places where the convolving weight is ~0 that cause the bad
brightnesses at the edges of the data.
Eric Greisen
More information about the Daip
mailing list