errors in make_lupton_rgb

Dear Folks,

I’ve been using make_lupton_rgb, and noticed some odd behavior and some documentation issues. I think the odd behavior is due to at least one error in the code, which means it is not doing what Lupton et al. says.

A documentation issue is that “stretch” is not defined. It appears to be intended to be 1/alpha from the Lupton paper. Clarifying that in the documentation would be great.

Another documentation and implementation issue is the use of `“minimum”. It is unclear in the docs when this is a scalar how this is applied. In Lupton et al. it is defined as a single value applied to the intensity (per footnote 7). But in the code it is applied to each individual band, which will behave differently.

There is also an error (I think) in the code on or about line 253. The formula in the docstring correctly divides by Q. The formula in the code divides by asinh(frac * Q).

The code is a bit roundabout in the implementation, so it is entirely possible I have misunderstood its behavior and would happily be corrected if so!

Many thanks Mike

[blanton144]

The astropy version is 5.0.4. The numpy version is not relevant, though I think it is 1.22.x

I can’t exactly send a piece of code that reproduces the error—the code runs and produces something, but when you read the code it is clear that the astropy code is incorrect. The effect will be that color images don’t look like you would expect them to as you vary Q, which is a bit of a subtle thing to put into a bug report.

The piece of code in astropy is here in the AsinhMapping class init method:

        frac = 0.1                  # gradient estimated using frac*stretch is _slope
        self._slope = frac*self._uint8Max/np.arcsinh(frac*Q)

        self._soften = Q/float(stretch)

And then this gets used by a method in the class:

    def map_intensity_to_uint8(self, I):
        with np.errstate(invalid='ignore', divide='ignore'):  # n.b. np.where can't and doesn't short-circuit
            return np.where(I <= 0, 0, np.arcsinh(I*self._soften)*self._slope/I)

whereas the docstring of that class says:

x = asinh(Q (I - minimum)/stretch)/Q

If you compare the math the code is doing to the docstring you will find disagreement. The docstring is correct with respect to Lupton et al and is also the sensible thing to do. I think basically you want _slope to be just self._uint8Max/Q (without any arcsinh or the frac).

[parejkoj]

Just saw this now, while searching for the other RGB-related issues. Thanks for catching this, @blanton144 ! The error came from the original code (from Robert!) that I copied out of LSST’s afw package. The correct code had been blocked out with if False: I don’t know the rationale behind that change.

https://github.com/lsst/afw/blob/main/python/lsst/afw/display/rgb/_rgbContinued.py#L306

As to the unclear documentation, I did my best to document the parameters of the afw code, but it was mostly a “best guess”: if you have a better wording for those, I’d love to fix them!