We still do not have asinh quite right, the following should be done:
- Determine what is wrong, maybe why it is wrapping?
- Understand why have a beta parameter exposed to the user and not a Q parameter. You might want to talk to Lijun about this since she did the original work but no longer works for LSST.
- From the UI- determine if we we need a slider entry instead of a number text box entry. Note- when asinh was originally done we had not yet brought in a slider component. It makes more sense now.
- Work with David Shupe to validate the implementation plan
- FitsRead.java has most of the stretch code as static methods. Move these out of FitsRead.java into a Stretch.java
- David Shupe thinks we have the same problem with Power law Gamma. If that is a simple fix after the above work then fix it, otherwise we will make a second ticket.
This ticket will deal with changing asinh algorithm to be consistent with asinh stretch implemented in https://github.com/lsst/afw/blob/master/python/lsst/afw/display/rgb.py and https://github.com/astropy/astropy/blob/master/astropy/visualization/lupton_rgb.py
The parametrization using Q is explained in the footnote on page 3 of https://arxiv.org/pdf/astro-ph/0312483.pdf
The algorithm will accept Q parameter from 0.1 to 10, which should be controlled by a slider.
The mapping from flux to color value is 255 * 0.1 * asinh(Q*(x-xMin)/(xMax-xMin)) / asinh(0.1*Q)
Below xMin, the color will be 0; above xMax, the equation has to be applied and then clipped to 244 (because we use 255 for blank pixel).
Per David Shupe
Zscale + linear is often used with CCD images to show faint features. I am thinking of Lupton’s asinh as keeping zscale + linear at low values, and bending the stretch function over at intermediate and large intensities. It uses only a fraction of the color range for the max value from zscale; but it will show brighter features above zscale.
Lupton’s formulation assumes that xMax is far below the bright features in the image. He wants to see the features above xMax as computed by zscale. This is different from how I have traditionally thought about these stretches.
The first and last items in the original description above were fixed by
Stretch code will stay in FitsRead.java to avoid conflicts with Lijun's IRSA-1498 ticket, which takes care of code refactoring.
Per David Shupe, it would also be helpful to display boundaries, calculated by z-stretch algorithm rather than the original data boundaries. I will see if I can add the calculated values to z-stretch dialog.