Generalized Hyperbolic Stretch (GHS) Script for "Designer Transforms"

Comments

• Anne van Houwelingen

  January 2022

  A kick for this post. It is in many ways a much better masked stretch and does not blow up star cores like HT can do.

  However, it needs getting used to. Understanding the interplay between the 5 parameters is not trivial. I have used it many times now, but I still need to experiment every time. 

  So, a walkthrough by Adam of this nice addition to our toolbox would be nice.

  
  
• David Payne

  January 2022

  Hi Anne, 

  Thanks for the feedback.  I am working on an improved tutorial/guide based on my own use, but it likely won't be up to the caliber I see here...

  
  
• Reinhard Gloggengiesser

  February 2022

  Kicking this again. I've heard good things about this new tool and my first experiments have also been very promising. Being not on the level of the more experienced image editors here however, I would also be very interested in getting Adam's take on this and ideally a video tutorial on its use.

  
  

  Many thanks to David and Mike for putting this out. I personally really like the interface although indeed, it takes a while to get the hang of it. The documentation is fantastic - I wish there were more as good as this from other authors of scripts.
• Euripides

  March 2022

  I would love to see Adam’s approach too. Now the v2 is available to download.
  
  
• BlockHead

  March 2022

  OK.

  (I have been holding my breath on this because I am not yet convinced... and I guess I was waiting. But the below is what I wrote last month... I still agree with myself- but I am open to be wrong and persuaded otherwise. Perhaps some users can speak to my concerns.)

  *************
  

  So I have a couple of comments. If you want me to address this script- you have to speak my language. 

  In fact, I would argue that the combination of my tutorials on this topic (of various input vs output transform curves and how they work) can be found in  https://www.adamblockstudios.com/articles/Nonlinear_01 ; and 

  https://www.adamblockstudios.com/articles/ExponentialTranformation for example.
  

  
  

  I would have liked to have seen this is a starting point. Using a grayscale tablet to represent all possible brightness levels would demonstrate much better how the tool works- THEN you can show a tutorial on particular images which have their own unique tonal values. In other words, I would have liked to have seen my methodology for explanation used. 

  
  

  I see this tool as a slider-based version of curves. Since the transform is global, there is no particular strength in "at bringing out very faint nebulosity and exhibiting excellent control over stars." To me this is a throw-away comment at best. It isn't that the transform this script uses is somehow better or different than as implemented in curves (or other processes)- but instead that using the sliders instead of control points (Curves) or numbers/parameters (Exponential Transform) is easier in some way. The faint wings of PSFs of stars will "react" to the transform in precisely the same way as faint nebulosity. Unless there is a parameter in the script I am missing- the "bloat"  that stars exhibit will not be mitigated in any special way. 

  
  

  I have avoided diving into this because it has the whiff of the "Zone" system (Wodaski) which was a "craze" for some time. There is merit in understanding these concepts and their importance as perhaps first clearly expressed by Ansel Adams. But if the idea behind the script is that it "easier/safer"... that is a difficult thing for me. At the end of the day I couldn't not show two images and show differences due to algorithmic effects- instead I would demonstrating you can get from A to B in some purported less time or effort. There are instances where I do this as an evangelist (WBPP is a good example)... but at the moment I am not all in here.

  
  

  So these comments are not a critique- as much as my initial "take." I may be entirely wrong (As I have been notably on a number of things.). 

  
  

  -the Blockhead
• David Payne

  March 2022

  Thanks for engaging in the discussion, but I am a little disappointed in your reaction.

  
  

  Perhaps you are arriving at this discussion from an imagers point of view, while I am coming to it from a mathematics/science viewpoint, with much less background in image processing per se.   Perhaps this is why I don't speak your language so well.  However, please allow me to describe some observations I made that led me to first propose the equations that the GHS script uses.   I have indeed watched your videos, and it is understanding the math (or lack thereof in some cases) in the stretching methods that led me to first propose, what I believe is potentially a better way.

  
  

  As a newcomer to image processing, I found most software was provided with a few limited functions (or rather, relations) that I could understand, to stretch my images: 

  
  

  The histogram transform equation (which, in math terms is a linear stretch multiplied by a harmonic function).   This works ok, but just ok, for a lot of images.  The histogram transform is really the harmonic form of the hyperbolic equation (with a hyperbolic exponent of 1).  In Pixinsight, the origin of the function must correspond to the black point.

     

  The second was the "arcsinh" (stands for inverse "hyperbolic" sine) which is really a logarithmic stretch - again a form of a hyperbolic equation, only this time the integral form of the hyperbolic equation, with an exponent of 1 - that makes it logarithmic.  (Note that arcsinh does sound fancy, though).  Again, the origin of the function had to correspond to the black-point.  The arcsinh function isn't a particularly good one, but it is the colour saturation enhancement (which actually has nothing to do with arcsinh) that imagers like about this process.

  
  

  The third, an "exponential" stretch, as you mentioned is really a special case of the general hyperbolic equation, (with an hyperbolic exponent of 0 in this case).   It took me a while to figure out the actual implementation of this function was , but your video clear this up for me.   (What the heck is PIP?)

  
  

  Mathematically speaking - all the actual stretch transforms you discuss have "band-aids"  (sometimes in the form of masks, or otherwise, to only these three forms of the hyperbolic equations to try and make them work better - including the "power of the inverted pixel (whatever that is), and presumably the "Zone" system, whatever that is too) to make up for their limited degrees of freedom and yet is expected to apply to image stretching in general    Here's where the math kind of falls apart for me.  There is the recognition that another two or three degrees of freedom are required to actually make these stretch transforms work, but the band-aids are funky and awkward and may work in only a few circumstances and only for a few images.  That is why you are seeing fads, and multiple stretch processes.   THis is why so many of these techniques create artifacts.   Why is there more than 1 stretch transform process?  Should I use Histogram transform on Monday, and Arcsinh on Tuesday, etc.

  
  

  The other solution popular and admittably quite successful is the "Curves method".  THis is likely better than the existing transforms because the curves method does have more degrees of freedom and you can tailor your transform to the image at hand.  There were a couple of things that bugged me about Curves, however.  One was that they aren't reproduceable without either carrying around a table of values, or recreating a table for each image.   The second was that this table of points (you described as "control points") are just spline interpolated.  (Don't be fooled, however, these aren't "control points", they are just values you enter that are then spline interpolated to get all of the values in-between.   This is "bubble gum" math - the same math used for video games and don't represent true transforms.   (please don't use spline interpolation - EVER - to draw scientific or economic plots - they overshoot,  double back on themselves and describe unphysical things as any excel user will tell you - but that's a rant).   When used for stretching, you may get things (artifacts) that aren't really there.   Splines are good for sales, however.  (Note in contrast, the GHS equations are true functions, defined not just at the "control points"  but everywhere in between - an infinite number of control points all defined by a few "sliders").

  
  

  It didn't take me long to figure out what was important in these Curves I was drawing - where I wanted to apply the most contrast, where I was taking it from, how much I was brightening pixels and where.   -Because of my background in forecasting time series (I know these equations in my sleep), I found I was drawing, over and over again, essentially what I recognized as general hyperbolic functions.   The same hyperbolic functions used in nuclear physics, chemical engineering, economics (continuous and interval compounding), even in epidemiology (see Covid-19 forecast models) etc. etc -( just not in image processing for some reason - until now.)   

  
  

  So, I thought, rather than continually draw Curves (which are especially difficult to draw with any degree of accuracy for an initial large stretch), and rely on "cubic splines" or other fundamentally flawed interpolation methods, why not apply the hyperbolic functions directly?   So the GHS equations are just "cutting out the middle man of having to draw "control points" - instead of drawing n points, I need a max of 5 easy to understand parameters (yes, on sliders) to accomplish the same thing, only better.  

  
  

  I tested it out the GHS (the hard way, via Pixelmath with quite long expressions) and lo and behold it worked.
  

  
  

  A science and math person would recognize the slider inputs as: D=hyperbolic coefficient, b=hyperbolic exponent.   The parameter in the equation SP defines the origin of the hyperbolic equations.  The last two "slider inputs" , define the limits of the hyperbolic equation - and actually are used to change the stretch to linear beyond these points - at a slope (1st derivative) defined by the hyperbolic equation itself.   These are given different "names" in the script, such as stretch focus for b, of highlight protection for HP, to relate it better to non-math people and better describe what it actually does to the image transform.  But please have no doubt that if you do the research, you will see that the math is the same.  (The best description I have read to the math can be found at this site (totally unrelated to astrophotography, but a good summary nonetheless).  In essence the generalized hyperbolic equations and its integrals encompass the family of equations you may know as logarithmic, exponential, harmonic, hyperbolic, and even super-hyperbolic (b>1).

  
  

  Anyways, the GHS represent true analytically invertible functions (not so spline interpolations, PIP with lightness mask, or many of the methods you mention), retains all data and will maintain the rank pixel order across the image (again, not so for many of the methods you mention), does not require pixel/data clipping, are piecewise continuous, piecewise smooth, and described by analytically integrate-able and differentiable functions - not so the standard methods I have seen and certainly not spline approximations.  So I hope we have that "slider stuff/argument" taken care of.

  
  

  I wish I had invented these equations, but I did not (I think Euler did and I am pretty sure he would not agree that his equations are a "slider version of curves").  All I did was take something that I have used and seen used in many other scientific applications and brought it to image stretching.   Indeed I found that I could show dim nebulosity, be better at controlling stars (by increasing the hyperbolic exponent, b) and with a little practice to generate results that were better than, and take far less time than hand drawn curves,   In fact, the stars can, in some cases, be so gently stretched that Starnet does not recognize man of them as stars.(hasn't "learned" on GHS stretched images). 

  
  

  Star bloat is not the enemy of dim nebulosity, as your comment suggests.   (With GHS  it is noise that is the enemy of showing dim nebulosity.)   Showing dim nebulosity while avoiding "bigger, brighter, lower contrast stars (ie bloated)" is much easier with the GHS equations.  It is not "magic" and it does not have the super-power of inverted pixels, but it is math.  It can come up with the best compromise that there is.   There is indeed a "parameter" in the script you are missing - the hyperbolic exponent - that  DOES mitigate bloat.  I am surprised you are making such a statement without trying out the script at all.  What you seem to be saying is "it doesn't matter what "curve" I draw, the star bloat will be the same.  If you are correct, why is there a curve process at all, if it doesn't matter.

  
  

  In contrast to myself, you can talk the astrophotography lingo much better than I can, and you bring a wealth of skill and knowledge to the subject.   You also have a skill at explaining what is going on better than I can, and likely have much greater stature and street-credibility than I amongst the community.   To that end, I hope you give the stretch a try.   Even if you don't understand the math itself, quite a few other have tried it and are getting good success.   Think about it, what is the fad? - I'd put my money on "Power of the Inverted Pixel").  If you want control points, GHS will generate an infinite amount of them for you if you like, then you can paste them in the Curves transform, spline interpolate them, and then see what GHS can do.

  
  

   Mike has just released version 2 of the script (including a real time preview, and a similar colour saturation enhancement that exists in the Pixinsight arcsinh process. which works great too).  

  
  

  The author the script, and I are offering the script for free, and our only interest is sharing with the community.  I am hoping you don't dismiss this out-of-hand and keep an open mind.  You won't believe how often I come across those in specialties such as this, that believe their "niche" of practice, is somehow special and not subject to what has worked elsewhere.

  
  

  
  

  
  

  
  

  
  
• Anne van Houwelingen

  March 2022

  Adam,

  
  

  Ahhh, memories. Wodasky's zone system. :-)

  I still have the book and actually it is very good. Because it teaches to look at an image at different levels and forces you to think what to emphasize on that level. 

  
  

  As for GHS. Sliders are fairly irrelevant to the essence of the tool. They make it easier to use and easy without losing control is always better. Always. There is no merit in obscurity. There is also no merit in tools being clunky (Blink and Clonestamp come to mind immediately). In PI there is a range of very good tools of varying degrees of maturity. GHS in my humble opinion is a very useful addition and neither superfluous or clunky.

  GHS gives a lot of control in the transition from linear to non-linear. More than HT, more than curves and with less artefacts than masked stretch or ASH.

  Yes the working of the parameters could be demonstrated on a grayscale gradient. Please do. The mathematics and the visual representation of the curve in the script are very transparent in my eyes. Having said that, GHS does require hands-on experience to get the most of it. 

  
  

  Just my opinion based upon actually using the tool.

  
  

  David, I just watched your videos on V2 of the script (great improvement by Mike on his original). Very well done! Thank you both.

  
  

  Anne

  
  

  
  

  
  

  
  
• David Payne

  March 2022

  Thanks Anne, for your kind words on the script and videos and for the analysis of the script you have provided on other forums.   I have been admiring your images, with a huge dollop of envy, on astrobin. 

  
  

  I have been trying to think of the substance of Adam's comment regarding "speak my language".  I think what he would like me to do is great a grey scale "image", and then plot the resultant pixel values versus the input pixel values, similar to what he did for the "exponential" transform/stretch process - to show what the GHS script does.

  
  

  The reason I am not doing this is because of two reasons. 

  1) it is exactly what the GHS stretch shows on the histogram plot - the transform up front - so one knows exactly going in what the transform looks like, and there is no need to "recreate it" with a grey scale image. ...unless one doesn't actually believe that GHS does what it says it does.   There is no other reason to back-calculate it because you will get what is presented in the first place.

  2) it is why I subscribed and pay into to this website in the first place.   If I were to do, what I consider the job of this website, which is to test existing and new techniques and report back to the subscribers on them, then I would be essentially getting a dog and barking myself.  This is why I was disappointed in the response, which was essentially a poorly informed pronouncement on a script that clearly hadn't even been loaded and opened up (or he would have realized point 1).   Saying "I don't like it, here's why I am sloughing it off, but I could be wrong about it" left me unsatisfied.

  
  

  No matter what your opinion, I think we should all be open to learning from one another, realize no-one has captured the market on talent or brains here, and particularly avoid "not invented here syndrome".  I sincerely would like Adam, with his unquestionable talent, to take a look and provide us with even more value for our subscription dollar.

  
  

  Thanks again, Anne

  Dave