[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