Tue 03 Jan 2017 04:24:54 PM UTC, 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 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:
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?
|