gnuastro-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[gnuastro-devel] [bug #48978] Bad coordinates in polygon mode do not abo


From: Mohammad Akhlaghi
Subject: [gnuastro-devel] [bug #48978] Bad coordinates in polygon mode do not abort
Date: Tue, 3 Jan 2017 16:24:54 +0000 (UTC)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0

Update of bug #48978 (project gnuastro):

                  Status:             In Progress => Fixed                  
             Assigned to:                    None => vvm                    
             Open/Closed:                    Open => Closed                 

    _______________________________________________________

Follow-up Comment #3:

Thanks a lot Vladimir, I also checked with a few other bad numbers, and it
works. Thanks also for the very complete and thorough commit message. It has
been pushed to
<http://git.savannah.gnu.org/cgit/gnuastro.git/commit/?id=e59ab1137b> the main
repo.

I just added some comments above your correction in the code, so the reader
can get an idea of the purpose of this check without having to look up the
history or mentally building scenarios. I also added some blank lines in the
commit message for fitting better with the other commits. 

The issue you raised about the negative number was interesting. Its not a bug,
ImageCrop was working! Let me explain: In the FITS standard, we define the
pixel resolution (in units of degree/pixel) using the `PC1_1' and `PC2_2'
header keywords (when the image is aligned with the celestial grid). You can
see them with Gnuastro's Header program:


$ astheader tests/mkprofcat1.fits 
...
PC1_1   = -1.66666666245874E-06 / Coordinate transformation matrix element    
 
PC2_2   =  1.66666666245874E-06 / Coordinate transformation matrix element   

...


This says that each pixel is -1.66666666245874E-06, or that each degree is
600000 pixels (this is roughly the Hubble Space Telescope resolution). So by
changing the polygon vertice from `1.0013217' to `-1.0013217', you have
practically asked for the vertice to be 2 degrees below what it was meant to
be and the image would be more than one million pixels along one dimension.

To confirm this, I done this change (and added the `--keepblankcenter' option,
since the center will be blank and ImageCrop will delete it by default) and
waited a little. On my system after about 30 seconds, the final image was
made. It was 4.6GB and had a size of 960 x 1202018 pixels!

So fortunately this wasn't a bug, but you did raise an important point: A
sanity check can be defined when we are in WCS mode (`p->wcsmode==1'), just
before adding the coordinate to the list (with `gal_linkedlist_add_to_tdll').
In general, the right ascension (or first coordinate) should be between
`0<=RA<360' and the declination should be between `-90<Dec<90'. Since you
raised this limits issue could you implement this small check and post it as a
task?

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?48978>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]