Re-open Generalized Hyperbolic Stretch

[Desmis]

I accidentally merged the PR GHS #7210
I reverted with the PR 7250

I open this new PR... same code

[Desmis]

This PR as well as the one on Abstract profile highlights - beyond the technical aspects and understanding of the algorithms - the following difficulties (not exhaustive)

• the developer's language problem. Of course, we can dismiss this out of hand, saying that modern translators are excellent. This may be true (and I have doubts) for everyday language, much less so for technical language (in this case photography). I try to do my best, but, as proof, there are misunderstandings related to the subtleties of languages. I can quote the term "Retour d' Experience" in French, that I used in the challenge to test Cam16 in the spring. It is translated as "feedback" in English which does not take into account the same aspects, in particular human factors. This has been the subject of major misunderstandings. I think I can speak about it objectively, having been one of the REX specialists.
• The problem of creating a new concept like Abstract profile, or adapting an existing algorithm to a different situation for which it was designed (for example GHS). In these cases, the tools or additions are misunderstood or even despised...And it is not easy (adding language problems) to make yourself understood.
• The problem of standards and names when we talk about image processing:
  ** I take the example of CIECAM and CAM16 or Cam16. In this case, I have modified the CIECAM procedures so much, by additions which are absolutely not in the CIECAM literature, for example the notions of Black-Ev and White-Ev, the curves, HDR-PQ, etc. hence my proposal of Cam16 instead of CAM16 (which would be the full respect of the documentation). However I used CAM16
  ** The notions of Luma, luminance, lightness, brightness, chroma which are different depending on the authors and context....You just have to look at the work of researchers from CIECAM, Jzazbz and ACES to see the differences.

Jacques

[Lawrence37]

My intention is not to change all the usages of "luma" into "lightness". Doing so does not resolve any problems for me. My point in asking why it is luma instead of lightness is because I don't know which one the code is using. If the code is really using luma, then it should be kept as luma (and clarifications should be made on what L and ab refer to if it is not CIELAB). If the code is really using lightness, then I am fine with the change. As of now, I have not looked at the code, so I don't know which one is correct.

[Desmis]

@Lawrence37
In fact it is more complex than that and cannot be easily summed up in vocabulary.
Indeed, due to the fact that in almost all parts of Selective Editing we very often work with values ​​that are not in the interval [0 1], whether it is Jz, Cam16 (and not CAM16), GHS, etc.
In this sense the notions of lightness, luma are not always appropriate. The most appropriate would generally be brightness which takes into account Absolute luminance. But if we look at the literature on these data, researchers do not use the same notations for the same thing, for example J in CIECAM is taken as Lighness and J in JzCzHz is taken as brightness.

I had to "tinker" with Jz so that there was a Lightness value...

We have already had this debate, without any real solution for all cases. With you, the advantage is a "new" reader, therefore more representative.

So I opt for the choice of Lightness and not Luma.

thank you for this review.

I will be away 2 days, but maybe I would have an internet connection

Jacques