David Payne

Activity

• 
  BlockHead → David Payne

  Dave,

  
  

  A couple of things... of course... its long... everything I do is long.

  
  

  1. First please give me credit for allowing the announcement as a tacit form of "openness" to new ideas. That is what this forum is for..and you used it accordingly. Your message can be read by a fairly  large group of PI enthusiasts- your target audience.

  
  

  2. I watched your video tutorial and understand the usage of the script I think. I also read a good fraction of the more extensive manual. I really wasn't going to say *anything* more... but you asked for an endorsement (you didn't ask me to try it only to find fault with it, and you made the comment public to all of my customers). Then others wanted a response. I have not used it in my processing, but I think I understand what is going on. You can verify that below. My comment was my impression based on the information I had at hand (your video and the written information). I think I was being fair.

  
  

  3. This script, my first impression, generates a particular set of input/output transforms by manipulating sliders that control the shape of the curves (they are the parameters and coefficients of the functions). The curves, that is their shapes, are useful for stretching astronomical images.  

  
  

  4. The demonstration on particular images is something I would do after demonstrating (graphically) the more general behaviors of the curves visually. No particular astronomical image will have a complete range of values that shows behaviors. This is a "just so" way of demonstrating how something works and I just never find it complete. (Typically I would hear back from people that say "I see how it worked in the demonstration...but it doesn't work like that on my image(s)). This is where I was coming from regarding the greyscale tablet and more general discussion. 

  
  

  5. In the video (and written documentation) there is an emphasis on the "precision" (your words) of the stretch by using this script (or these functions). Based on my experience in image processing, the "precision" of having the transform yield particular output values at a *particular* well-defined input in 16-bit space is usually lost (or very subtle) in the 8-bit monitor output we actually discern. It seems to me that this script emphasizes that having the cutoff/bend..etc happen *precisely* at a particular spot gives more control over the final result. My experience is that for most processing- the adjustments made are really quite gross (larger in magnitude) than the level of precision demonstrated- so my impression is this is like focusing a star using an with a fine focus knob. The argument is that there is greater precision- which is true- but the difference between this result and the more crude focuser (the cruder tools of "spline interpolations...etc") is often subtle. This is easy to demonstrate if I am wrong. Just generate a curve that is desired in the script..and then create a crude one in Curves... even without the spline- just line segments. And blink the two images. This will show the degree or magnitude of the precision the script is offering compared to the mittened-hand approach.

  
  

  (Let me add, I do understand the idea of applying more/less contrast within a range of values that is relevant to an image...I get it- I am saying that importance is often (not always, but often) over-emphasized. Note that I do not have a video on using MLT/MMT with a gazillion fine bias adjustments between layer scales... so I am coming from a certain point of view on this kind of idea.) 

  
  

  6. The other concern I had, again from the demonstration and written material, is the point about how this level of precision helps with star bloat. So this concern is easy to address. Given two (or some) pixels with the same value- one in the PSF of a star and the other in glow of nebulosity- the transfer function does not distinguish between these values- it is agnostic- unless there is a PSF fitting that is happening. That is where I was coming from about claims that transfer functions help with star bloat. I guess you could make star masks.. but this is not the usage I think was being described. I understand there is an effect on stars by manipulating the function to adjust the contrast at a particular range of values... but as you say in the manual...it is doing this globally.  This might help stars at the expense of other elements in the image. I saw prescriptions in the written document..but I do not think this point is really made dispassionately.

  
  

  7. I still interpret Ann's comment as a "being easier" to either understand or use kind of perspective- which is what I mentioned in my initial response. It is from that point that I did not want to become an forced endorser. The announcement was made and I saw it. This kind of script strikes me as the kind of thing that is akin to the "citizen science" approach. My interest is piqued more by users (or demonstrators) showing the benefit- especially visual comparisons- that show more than ease of use (I get the same basic result in fewer steps... which *is* good if the difficulty in the process is high)- but also show some concrete showstoppers. Then I get excited.

  
  

  Lest you think I don't get it... let me tell you some positive things about the script from my impressions:

  
  

  1. It appears to be a good educational tool. The written manual is a TOME. Someone that sits down and reads and understands everything there will be very well informed on many things.

  2. The idea of saving the parameters for specific transforms is a nice one. 

  3. I am actually happy to try this out and explain, in my way, how it works. I was really just waiting to see how it is adopted by others (just as the initial announcement suggested). 

  
  

  -the Blockhead

  March 2022