mainGNU Astronomy Utilities - Support: sr #110541, astcrop -width not matching output

 
 

sr #110541: astcrop -width not matching output

Submitter:  Alejandro S Borlaff <borlaff>
Submitted:  Thu 16 Sep 2021 08:05:49 PM UTC
   
 
Category:  Crop Priority:  5 - Normal
Severity:  3 - Normal Item Group:  * Input/Output
Status:  Done Privacy:  Public
Assigned to:  makhlaghi Open/Closed:  Closed
Operating System:  GNU/Linux
* Mandatory Fields

Add a New Comment Rich Markup
   

Fri 17 Sep 2021 01:58:47 PM UTC, comment #2: 

After posting the previous comment, I thought one of its paragraphs can be taken into the manual to help describe the reason behind this feature, so I just did it in Commit 48466e17. Thanks again Alex ;-).

Mohammad Akhlaghi <makhlaghi>
Group administrator
Fri 17 Sep 2021 01:35:53 PM UTC, comment #1: 

Thanks for reporting this Alex.

When you specify a '--center' coordinate (with a certain '--width') the output will always be an odd-sided image, it is also explained in the manual (see the description of '--width'):

https://www.gnu.org/software/gnuastro/manual/html_node/Crop-options.html

The basic reason for this is that your given coordinate will ultimately fall within a discrete pixel in the image (defined by the FITS standard). When the crop has an odd number of pixels in each dimension, that pixel can be very well defined as the "central" pixel of the crop (hence the '--center'). However, for an even-sided crop, it will be very hard to identify the "center" (it can be on any edge of the four central pixels!).

The lower-level '--section' option can be used to crop an even-sided crop (because it doesn't assume a high-level center). There is an example in the description of '--width' (in the link above) on how to use '--section' in a second call, to make it even-sided.

I thought a lot about this back when I was implementing this feature and although it also causes such confusions, this was the least confusing solution I could find! The alternative (where people didn't know where their central coordinate is located) is generally more confusing.

But if you have any suggestions on how to fix this problem for an even-sided crop, feel free to share your thoughts, I am sure there may be a good solution ;-).

Hopefully this address the problem, so I am closing this ticket, but if you have any suggestions, feel free to continue sending them here.

Mohammad Akhlaghi <makhlaghi>
Group administrator
Thu 16 Sep 2021 08:05:49 PM UTC, original submission:  

Hi all,

I am having a problem with astcrop. Sometimes, depending on the image to be cropped, and the crop settings, astcrop returns an image as output with slightly different dimensions than the desired ones. Example:

$ astfits soft_thresh.fits

> Fits (GNU Astronomy Utilities) 0.15

Run on Thu Sep 16 12:53:18 2021
-----
HDU (extension) information: 'soft_thresh.fits'.
 Column 1: Index (counting from 0, usable with '--hdu').
 Column 2: Name ('EXTNAME' in FITS standard, usable with '--hdu').
           ('n/a' means that no name is specified for this HDU)
 Column 3: Image data type or 'table' format (ASCII or binary).
 Column 4: Size of data in HDU.
-----

  1.      n/a             int32           4108x3602



$ astcrop -h0 soft_thresh.fits --mode=img --center=1854.5,1430.5 --width=512

$ astfits soft_thresh_cropped.fits

> Fits (GNU Astronomy Utilities) 0.15

Run on Thu Sep 16 12:54:02 2021
-----
HDU (extension) information: 'soft_thresh_cropped.fits'.
 Column 1: Index (counting from 0, usable with '--hdu').
 Column 2: Name ('EXTNAME' in FITS standard, usable with '--hdu').
           ('n/a' means that no name is specified for this HDU)
 Column 3: Image data type or 'table' format (ASCII or binary).
 Column 4: Size of data in HDU.
-----

  1.      n/a             no-data         0      

1      n/a             int32           513x513


The output is 513x513 instead of 512x512. The same error occurs if the center coordinates are set to int instead of float decimals. Thank you so much!

I cant upload the soft_thresh.fits file at it is 50Mb large. It can be downloaded here. https://wetransfer.com/downloads/e603ba92c64b20f03d21660edcde5a3120210916200237/5c48e14ef1c52ebc7ef4f46e70b21eca20210916200257/09784d

Alex

Alejandro S Borlaff <borlaff>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by makhlaghi (Posted a comment)
  • -email is unavailable- added by borlaff
  • -email is unavailable- added by borlaff (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-09-17 makhlaghi StatusNone Done
        Assigned toNone makhlaghi
        Open/ClosedOpen Closed
    2021-09-16 borlaff Attached File- Added soft_thresh_cropped.fits, #51927
        Carbon-Copy- Added -email is unavailable-

    Back to the top

    Powered by Savane 3.13-4b48.
    Corresponding source code