Build for the pull request: https://irsawebdev9.ipac.caltech.edu/dm-14799/firefly/

Reviews completed by both reviewers on the pull request.

Notes on testing at this incarnation: https://irsawebdev9.ipac.caltech.edu/dm-14799/firefly/

launch tool. pick 3-color composite. enter target M101, default size, ask it for red as W4, green as W3, blue as W2. search. It gives you a 3-color image. Click on color stretch pulldown. pick color stretch so as to get the pop-up. Default has it as "per band" stretch. Click on "Hue preserving stretch." Click on "Use zscale for bounds".  Refresh. The image turns green, and all other colors vanish. It seems like it is only modifying the green plane. Nothing else I do (except for restarting the tool) makes the image anything other than green. Oh, wait, if I go back to a per-band stretch, it returns to that, but then going back to hue preserving makes it turn green. Is this what it is supposed to do?

More: loading another target (i picked M16) and trying to fuss with its stretch yields the same result, even more dramatically. The whole image goes green. AND it changes the stretch in the previously-loaded M101 too. Is that the desired behavior?  wait, i think i understand this - it had the images locked together. Still took me aback … 

The algorithm requires that the flux in different bands is on the same "scale": "We assume that these data have been background-subtracted, if necessary linearised, flatfielded, and scaled appropriately". (https://arxiv.org/pdf/astro-ph/0312483.pdf)

If you check band-by-band, in you M101 example I see that the flux range for W4 (Red) is 95-168, W3 (Green) is 333-1090, W4 (Blue) is 6-69. There are just a few spots on the image where the green intensity (flux-minFlux) is lower then the intensity for red and blue. (You can verify it by moving the mouse and checking the readout on top. I guess, the flux in different Wise bands is not on the same scale.

David Shupe is off today, he might have more insight. He've been testing the algorithm with SDSS images in https://caltech.app.box.com/v/hue-preserving-testims

Ah ok. Interesting.

It fails for 2MASS in a similar fashion, though not so dramatically – the background is a very weird color.

It fails for Spitzer SEIP in a similar fashion, using irac1,3,4 for b,g,r – now the image turns all red.

MSX is a crappy image of M101, but it too goes all red under hue preservation.

Akari goes mostly red under hue preservation.

So I guess what i'm saying is that it fails dramatically for all of the IR data sets I've tried from IRSA. If I were a regular user coming in to see if this works, I'd think it was broken. I'm not sure how to fix this, but it doesn't seem to work for the IR data sets, even though Spitzer images should be all calibrated absolutely (in units of MJy/sr, unlike WISE or 2MASS).

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.

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.

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...

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.

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.