gnuastro-commits
[Top][All Lists]
Advanced

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

[gnuastro-commits] master e353932 109/125: NaN magnitude will only blank


From: Mohammad Akhlaghi
Subject: [gnuastro-commits] master e353932 109/125: NaN magnitude will only blank the profile's area
Date: Sun, 23 Apr 2017 22:36:49 -0400 (EDT)

branch: master
commit e353932a68a62b0a12ae2edb4122e29c37a7cac1
Author: Mohammad Akhlaghi <address@hidden>
Commit: Mohammad Akhlaghi <address@hidden>

    NaN magnitude will only blank the profile's area
    
    In MakeProfiles, to have a constant blank region, it was necessary to call
    the `flat' or `circumference' profiles along with the `--mforflatpix'
    option. In any other case, if the given magnitude of the profile was NaN
    (blank), it would be divided by all the pixels covereing the profile's box
    and so so the whole box would become blank.
    
    NaN (blank) is a very unique value and is often necessary (when you want to
    mask some region of the image). But the user can easily forget to call the
    `--mforflatpix' option. When it is not intended (the NaN was a mistake),
    there is going to be a blank region in the image any way and the user will
    notice it, it doesn't matter if it is an ellipse or a box/rectangle. So a
    simple check was added at the last step of finalizing the profile's
    box/tile (in `oneprofile_make'). When the brightness of the profile is NaN,
    then only the non-zero pixels in the profiles will be set to NaN and the
    zero-valued pixels will just remain what they were (0.0).
    
    Note that with this change, `--mforflatpix' is still necessary for non-NaN
    constant values. This commit only simplifies the job for NaN magnitudes
    which is a unique value.
    
    This change was motivated because of my own desire to make a blank region
    in an image (to implement interpolation), but forgetting to use the
    `--mforflatpix' option. The blank box in the image was un-expected for me
    (as a user), so I thought this correction would be helpful in the spirit of
    the Principle of least astonishment.
---
 bin/mkprof/oneprofile.c | 24 ++++++++++++++++--------
 1 file changed, 16 insertions(+), 8 deletions(-)

diff --git a/bin/mkprof/oneprofile.c b/bin/mkprof/oneprofile.c
index 9824412..c0409ed 100644
--- a/bin/mkprof/oneprofile.c
+++ b/bin/mkprof/oneprofile.c
@@ -613,16 +613,24 @@ oneprofile_make(struct mkonthread *mkp)
          accurately (not using the pixel center). */
       mkp->ibq->accufrac /= sum;
 
-      /* Correct all the profile pixels. */
-      if(p->magatpeak)
-        {
-          ff=(f=mkp->ibq->img)+size;
-          do *f++ *= mkp->brightness/mkp->peakflux; while(f<ff);
-        }
+      /* Correct all the profile pixels. Note that ideally, if a user wants
+         a NaN valued profile, they should use the `flat' profile with
+         `--mforflatpix', which won't need this correction. However, it
+         might happen that they forget the later, or the catalog might be
+         generated by a script that gives a NaN value for the magnitude
+         with any kind of profile. In such cases if we don't check the NaN
+         value, then the whole profile's box is going to be NaN values,
+         which is inconvenient and with the simple check here we can avoid
+         it (only have the profile's pixels set to NaN. */
+      ff=(f=mkp->ibq->img)+size;
+      if(isnan(mkp->brightness))
+        do *f = *f ? NAN : *f ; while(++f<ff);
       else
         {
-          ff=(f=mkp->ibq->img)+size;
-          do *f++ *= mkp->brightness/sum; while(f<ff);
+          if(p->magatpeak)
+            do *f++ *= mkp->brightness/mkp->peakflux; while(f<ff);
+          else
+            do *f++ *= mkp->brightness/sum; while(f<ff);
         }
     }
 }



reply via email to

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