Uploaded image for project: 'Data Management'
  1. Data Management
  2. DM-14799

Support Lupton (2004) algorithm for RGB composites

    XMLWordPrintable

    Details

    • Story Points:
      16
    • Sprint:
      SUIT Sprint 2018-07, SUIT Sprint 2018-08, SUIT Sprint 2018-09
    • Team:
      Science User Interface

      Description

      See 

      http://adsabs.harvard.edu/abs/2004PASP..116..133L

      for details and motivation.

      (According to Gregory Dubois-Felsmann, this is already on the radar at some level, but I didn't see a ticket, so I created one).

       

      Paper:

      https://arxiv.org/pdf/astro-ph/0312483.pdf

      Implementation in afw_display and astropy:

      https://github.com/lsst/afw/blob/master/python/lsst/afw/display/rgb/rgbContinued.py

      https://github.com/astropy/astropy/blob/master/astropy/visualization/lupton_rgb.py

       

        Attachments

          Issue Links

            Activity

            Hide
            tatianag Tatiana Goldina added a comment -

            We can always make no hue-preserving option a default behavior. It's not hard to disable it in IRSA, and we should certainly do it if it does not work for IR data sets.

            However, it would be interesting to understand, why the algorithm behaves the way it is for Spitzer images or any other cases we think it should work. Is there something we could do to to bring the images to the same scale and make it work? I tried to follow astropy implementation as close as possible. We can check if astropy produces the same result with Spitzer irac bands you mentioned.

            Show
            tatianag Tatiana Goldina added a comment - We can always make no hue-preserving option a default behavior. It's not hard to disable it in IRSA, and we should certainly do it if it does not work for IR data sets. However, it would be interesting to understand, why the algorithm behaves the way it is for Spitzer images or any other cases we think it should work. Is there something we could do to to bring the images to the same scale and make it work? I tried to follow astropy implementation as close as possible. We can check if astropy produces the same result with Spitzer irac bands you mentioned.
            Hide
            jbosch Jim Bosch added a comment -

            I would expect most of those images to contain header information about how to scale to a common zeropoint; it may be worthwhile considering how to use that in Firefly more generally even if over in LSST-land we expect the pixels to already have that property.  That said, if those images are also not background-subtracted, there's little that can be done to make any kind of color-image display work, I'd think.

            Show
            jbosch Jim Bosch added a comment - I would expect most of those images to contain header information about how to scale to a common zeropoint; it may be worthwhile considering how to use that in Firefly more generally even if over in LSST-land we expect the pixels to already have that property.  That said, if those images are also not background-subtracted, there's little that can be done to make any kind of color-image display work, I'd think.
            Hide
            rebull Luisa Rebull added a comment -

            there's little that can be done to make any kind of color-image display work, I'd think.

            The default (non-Lupton) stretches work fine. It's the hue preservation voodoo that's doing something strange. The images sure look ok, eg., don't seem to have an excessively high background level, but I'm not really familiar with this hue preservation stuff; this is the first time I've encountered it. The 2MASS and WISE images are in counts (with stuff in the header to convert to calibrated values). The Spitzer images are calibrated, so they should work ok. Should...

             

            Show
            rebull Luisa Rebull added a comment - there's little that can be done to make any kind of color-image display work, I'd think. The default (non-Lupton) stretches work fine. It's the hue preservation voodoo that's doing something strange. The images sure look ok, eg., don't seem to have an excessively high background level, but I'm not really familiar with this hue preservation stuff; this is the first time I've encountered it. The 2MASS and WISE images are in counts (with stuff in the header to convert to calibrated values). The Spitzer images are calibrated, so they should work ok. Should ...  
            Hide
            shupe David Shupe added a comment -

            I looked at a number of Luisa Rebull's cases as well as some others. For the hue-perserving stretch to look good, the image values have to have some interesting color variation in an absolute sense. M101 is all green because the 12 micron emission is so dominant compared to 22 microns and 4.5 microns.

            For a good-looking result, the images need to show the same population of sources. Any combination of the four WISE bands with extended dust emission will show stars as completely blue and will have very little blue contribution to the extended emission. I get much better results on images with extended emission with Herschel SPIRE 250, 350 and 500 micron images.

            2MASS images give poor results because the background levels vary so much across the images.

            As Jim noted, Bad background removal can't be helped much. The other strange-looking results could be helped by having a separate stretch / slope parameter for each of the three bands. It's possible to do this in the per-band mode by selecting "asinh" as the algorithm, with the only difference being that at high intensities you get "white" instead of the color of the object.

            Show
            shupe David Shupe added a comment - I looked at a number of Luisa Rebull 's cases as well as some others. For the hue-perserving stretch to look good, the image values have to have some interesting color variation in an absolute sense. M101 is all green because the 12 micron emission is so dominant compared to 22 microns and 4.5 microns. For a good-looking result, the images need to show the same population of sources. Any combination of the four WISE bands with extended dust emission will show stars as completely blue and will have very little blue contribution to the extended emission. I get much better results on images with extended emission with Herschel SPIRE 250, 350 and 500 micron images. 2MASS images give poor results because the background levels vary so much across the images. As Jim noted, Bad background removal can't be helped much. The other strange-looking results could be helped by having a separate stretch / slope parameter for each of the three bands. It's possible to do this in the per-band mode by selecting "asinh" as the algorithm, with the only difference being that at high intensities you get "white" instead of the color of the object.
            Hide
            rhl Robert Lupton added a comment -

            The whole point is not to do separate stretches in the different bands – it breaks the mapping from colour to astrophysics.

            You do have to choose the overall scaling sensibly for each band; if `M101` is green, scale back the 12 micron channel.

            Show
            rhl Robert Lupton added a comment - The whole point is not to do separate stretches in the different bands – it breaks the mapping from colour to astrophysics. You do have to choose the overall scaling sensibly for each band; if `M101` is green, scale back the 12 micron channel.

              People

              Assignee:
              tatianag Tatiana Goldina
              Reporter:
              jbosch Jim Bosch
              Reviewers:
              David Shupe, Trey Roby
              Watchers:
              David Shupe, Jim Bosch, Luisa Rebull, Robert Lupton, Tatiana Goldina, Trey Roby, Vandana Desai, Xiuqin Wu [X] (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              8 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:

                  Jenkins

                  No builds found.