GNU Astronomy Utilities - Bugs: bug #58360, Disabling default blank values in...
You are not allowed to post comments on this tracker with your current authentication level.
bug #58360: Disabling default blank values in integer datasets
Submitter: | Mohammad Akhlaghi <makhlaghi> | ||
Submitted: | Tue 12 May 2020 08:58:13 PM UTC | ||
Category: | All Gnuastro | Severity: | 3 - Normal |
Item Group: | Output not reasonable | Status: | Postponed |
Privacy: | Public | Assigned to: | None |
Open/Closed: | Open |
Tue 12 May 2020 09:48:40 PM UTC, comment #1: |
Rafael Morales <rmorales> |
Tue 12 May 2020 08:58:13 PM UTC, original submission:
Unlike the NaN values in floating point format, integers don't have any predefined defined blank value. So as explained in the blank pixels section of the Gnuastro book, we have adopted the following convention for integers: for signed integers, the blank value is the smallest (most negative) and for unsigned integers, its the maximum value.
For unsigned integers (which is usually for type for raw exposures), this is natural because the maximum value is a saturated pixel.
But in some scenarios, this is not the desired behavior and the minimum (for signed) or maximum (for unsigned) values actually have a meaning. We should define a framework to disable associating blank values to integers if the user asks. Maybe as a common option to all programs. |
Mohammad Akhlaghi <makhlaghi>![]() |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
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.
Follows 1 latest change.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2020-05-12 | makhlaghi | Carbon-Copy | - | ![]() |
Added -email is unavailable- |
In my opinion, the idea of filtering some pixels when calculating statistics is a kind of "robust" statistical calculation, but not in the standard (classic) way.
My proposal is to clarify which statistic is being used in aststatistics the "robust" or "classic" one and add a new flag to allow switching between them.