[Debian-astro-maintainers] Bug#988992: ds9 WCS

[Ole Streicher]

Hi Peter, William,

thank you for the detailed report, and for the sample file in the Debian 
bug report. The effect also happens with the (debianized) version 8.3b1 
which is in Debian Experimental. I don't think this directly connected 
to WCS: The output we see here is

     %1.8G

which looks much like outputting a format string instead itself instead 
of the formatted string (see attached image). When one changes the 
setting for "Precision --> Coordinates --> Linear" from 8 to 5, the 
output changes to "%1.5G", which shows that it is really the format 
string, built from the precision setting. However, I still was unable to 
find the place in the code where the format is used to print the output.

William, can I ask you to point me to that location in the source? I 
promise that I will do the rest of debugging myself :-)

Best

Ole


On 23.05.21 18:45, Peter Teuben wrote:
> Hi Bill
> 
> thanks for some useful info on what goes on behind the scenes in ds9
> 
>      I now use 8.3b1 actually, and as long as I have your binaries it 
> never bit me.  It was when I was using a virgin laptop with just 
> ubuntu/debian packages. And  I could not easily upgrade my ubuntu to use 
> 8.2 or 8.3, i have to do some fiddling with some apt setting, and given 
> that my laptop was effectively bricked after yesterdays disaster, I'm in 
> no mood to experiment on other machines.
> 
> But Ole has the file and debian debug report, and he could see if 8.3b 
> is also effected by this, i.e. if it's a WCS issue.  Or maybe I need to 
> learn to write a better WCS :-(
> 
> peter
> 
> PS:   my laptop bricking could also be a hardware error, I'm not blaming 
> the firmware update and/or the debian bug reporter that seems to have 
> de-installed some dell specific things. It's an SSD, but the health 
> reporter only claimed 3% of the spares were taken.
> 
> On 5/23/21 12:10 PM, William Joye wrote:
>> All
>>
>> The current official release is v8.2. It is based on Tcl/Tk 8.6.10. 
>> I’ve also released v8.3b1, which is based on Tcl/Tk 8.6.11.
>>
>> I can’t really say why the change in WCS behavior, other than we are 
>> talking about binaries over 2+ years old. The current version uses AST 
>> 8.7.1 for all WCS support. I no longer try to ‘fix’ screwed up WCS 
>> definitions. You get what the FITS file creator defined, screwed up or 
>> not.
>>
>> Also, lots of 2D data out there with 3D WCS defs, along with 3D data 
>> cubes with 2D WCS defs. DS9 will blindly display what AST calculates, 
>> as ‘David Berry’ knows best :-)
>>
>> Also, DS9 needs OPENSSL 1.0.x, while the default for most ports now is 
>> 1.1.x. I don’t know how Debian/Ubuntu is handling this. In my 
>> binaries, I compile 1.0.x and statically link.
>>
>> Peter, you should upgrade to at least 8.2 or 8.3b1, as it has so many 
>> bug fixes and new features, including Dark Mode and Prism.
>>
>> And Ole, thanks for maintaining the DS9 ports for Debian and Ubuntu.
>>
>> Bill
>>
>>> On May 22, 2021, at 10:02 AM, Peter Teuben <teuben at gmail.com> wrote:
>>>
>>> hi Bill
>>>
>>>       i usually grab the ds9 binaries from your site (now via 
>>> google), but ubuntu also offers a  package "saods9".  Sadly it has a 
>>> different approach, which is killing some of my WCS application. 
>>> Maybe Ole knows the provenance of this.
>>>
>>> It runs /usr/share/saods9/library/ds9.tcl directly via wish. Yours is 
>>> a true executable, at least as far as I can see.
>>>
>>> For most RA-DEC-FREQ stuff I use, this is not an issue, but for some 
>>> more non-standard slicing of cubes I wind up making my own CTYPE's:
>>>
>>>
>>> CTYPE1  = 'RADIUS  ' /
>>> CTYPE2  = 'VELO-LSR'
>>> CTYPE3  = 'Z       '           /
>>>
>>>
>>> and this works fine on yours , I can read off the WCS values. but for 
>>> the ds9 from ubuntu/debian (still at v8.1) I get to see the value
>>>
>>> %1.8G
>>>
>>> in the top left panel where the WCS is "named".
>>>
>>>
>>> And one more item about WCS I wondered about.
>>>
>>> Incidentally, the labeling of the axis, where I see "FK5" for our 
>>> cubes, I get to see "RADIUS-Z-SPEC..."  the last word is cut off 
>>> because there is not enough space. But it's SPECTRUM. And I wondered 
>>> why Z was mentioned before SPECTRUM.
>>>
>>> If I make the cube a 2D image, so take the "Z" axis away, the label 
>>> reads "RADIUS-SPECTRUM"
>>>
>>> But if I change VELO-LSR to PHI, it correctly reads R-PHI in my 
>>> case.  So i guess VELO-LSR is the SPECTRUM axis, but then why was Z 
>>> listed before SPECTRUM earlier when I had a 3D cube with the Z axis 
>>> only 1 in length....
>>>
>>> best,
>>>
>>>
>>> - peter
>>>
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ds9.png
Type: image/png
Size: 34144 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/debian-astro-maintainers/attachments/20210524/0a2efd87/attachment-0001.png>