Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - monkeybird747

Pages: [1] 2
I appreciate the detailed response. I'm trying to follow along, but I may not be fully equipped to appreciate what you are saying. What I got from your reply is this is an inherent trait of the software, and not some setting I've bungled or poor choice in monitor. The stretch from the STF is being accurately transferred to the HT tool, but because of differences between how those two processes handle the data, the on-screen visualizations are different at certain zoom levels. Is that a reasonable layman's interpretation?

I've tried disabling the setting you referenced, but I did not see a change in the way the full screen (zoomed out) image was presented in the STF or HT version. I can duplicate your results at certain zoom levels, but when I try to view the entire frame on the monitor I get the difference in display. I did double check on another machine with different monitor just in case. The zoomed out view difference is not subtle in my case. Here is an example on a different machine with the "Use fast screen renditions" unchecked. The image on the left looks as if I've hit it with some star erosion.

I'm probably out to lunch on this, but I could swear this didn't behave the same way on the version of PI I was using sometime last year. It really jumps out at you, and I feel like I would have picked up on this a lot sooner. Making clone masks of linear data in this fashion has been a staple of my workflow for some time. Would I be able to roll back to a previous version of PI for testing and satisfy my curiosity so I may sleep peacefully again?  :-\

Nothing has changed in these tools recently. Both HT and STF use exactly the same image stretching algorithm, so this is very strange. To know why this happens, I need the image. Can you upload it?

Hi Juan, curious if you were able to look at the data and if you have any thoughts on this behavior?

As I mentioned in my test, up above, there is a *very* small difference at zoomed out levels I detect with my data (a master bias in this case). It is not as dramatic as your example though. So, effectively I haven't encountered your issue- but I have reproduced the behaviour.

Still, your observation is correct for your data and I do not know the details of how things are rendered. A permanent stretch does modify the total number of observable brightness levels (since you are typically compressing the dynamic range (scaling the image) and possibly clipping white/black points)- and I suspect this has something to do with the (calculated) rendered result of the smaller (zoomed out) image. In the original unstretched image I imagine that you have a range of values that are averaged to render an outputted zoomed out image accurately. In the new permanently stretched image... you have possibly more clipped/quantized/similar values from the (non-linear) scaling of brightnesses... so maybe the result of the zoomed out looks a little different- but zooming in would not show this effect. This is a total guess.  Juan just needs to chime in and tell me I am terribly off the mark! (which  would be just fine!)


Thanks for the input Adam!



Remember how I experimented ZOOMED IN and to compare the results?
When I zoom into your image...I can detect no change in the pixels at all when comparing the STF on the linear and the permanently stretched image. Please verify you see the same behavior. There is something about how PI handles the interpolation of the zoomed out image. At least this is my uninformed guess... but the values do appear to be correct and blinking at a intrinsic relation (1:1) or greater shows no issue.
I do see the same thing you described with you data being zoomed out. I do not know why, and it appears to be a screen rendering thing?


I see what you mean. I tested at several different zooms and there does seem to be a point at which they become synchronous. This raises further questions, as it seems possible that when working with data that has been stretched using the STF transfer one might not be seeing their image data truly represented on the screen. My instinct was to take the frame that had the permanently applied stretch and stretch it further to match what I was seeing with the linear STF in order to use it as a mask.

So now I'm really curious about what is going on. If my data is not being accurately displayed on the screen during at a certain zoom then that makes it very hard to process accurately. Did you test some of your own data, or does it just do it with mine?

I'm open to suggestions.

Just in case it matters, here is the same file calibrated and cosmetically corrected. It didn't change things for me.

Thanks for the help,


Dropbox link to the file I used in the original post. Just checked it again and same behavior. I tried changing to 16bit in HT, but anything else I try will just be me hitting buttons in the dark. Let me know what other info I can provide to get this mystery solved.

Wait..wait. This is all weird!
1. Are you absolutely certain the images in your first screenshot are the same data? The image on the left doesn't actually look like Ha data...but the image on the right does.
2. I note the image on the left is a clone... could it be an inadvertent copy of something?
3. The zoomed out comparison does show differences...but it doesn't make sense. The nebula doesn't appear dimmer..but the stars do. Even a non-linear adjustment will not do this since the faint stars appear similar in brightness to nebula. The STF is global and agnostic to structure. Perhaps a zoomed in comparison?

4. So I opened a master bias and made a clone. I used the auto-stf on the original and using HT permanently stretched the clone to the same STF. When blinking the two..I *can* see a slight difference. It is on the order of 1 grayscale (out of 256). However... if I zoom in to any area and blink... I cannot detect a flicker (difference of brightness). I tried enabling the 24bit -LUT... but it had no effect when zoomed out. Zoomed in... no change. So...I do not know if this helps- but mathematically everything seems OK.

5. The above observation does not explain your original screenshot. :)


Super weird. Definitely same image. I only opened that one to make the screenshots for this post. Happens across multiple data sets and the 24 bit STF does not change the effect. I notice most by observing the star brightness difference, and haven't tried comparing other types of frames. I can also apply the stretch and then undo and see the difference without making a clone. Even tried linked vs unlinked, although the image is mono.

Nothing has changed in these tools recently. Both HT and STF use exactly the same image stretching algorithm, so this is very strange. To know why this happens, I need the image. Can you upload it?

Yes, I can upload the image this evening. Though this is not isolated to this particular set of data. It has been ongoing and I've largely just ignored it thinking I messed something up.

So somewhere a few updates back it seems like transferring the STF to Histogram Transformaiton tool in order to apply the STF stretch permanently no longer produce results that look like the original STF. Primarily the stars are much, much dimmer. Did I bump a setting somewhere along the way? I'm on Does this on all my PI machines (windows, linux, and mac).

Thoughts are appreciated. The image on the left is the STF view, and the image on the right was permanetly stretched by dragging the STF triangle to the HT tool, removing the STF, and then applying to the image. It looks completely different from the STF version.

Did something change in the program, or am I just more observant now  ???

I will be anxiously awaiting the Linux version of this tool!

Have you tried the Average Spiral Galaxy model? G2V is biased toward reds. Maybe check the spectral types of the predominant stars in the trapezium and try a model that is similar?

Could you tell us the type of frames being used (OSC, LRGB, etc.) and at what point in your processing you are using PCC?

General / Re: Resolving M31 Core
« on: 2018 November 12 18:25:22 »
Try the DarkStructureEnhance script for your dust lanes. Default amount is pretty good. Try lowering it to suit taste. Easily overdone.

If you're worried about your core you could do as mentioned above, or shoot some more frames at a much shorter exposure, then use HDRComposition to create a HDR image. Works well.

I’ll add to the above to be sure and reset the screen transfer function once you’ve drug it’s triangle to the histogram transformation window. Otherwise I think your live preview will apply the stretch to the stretched image (double application of stretch), and not represent the changes you are planning on applying to image.

Once you apply the stretch through histogram transformation your preview window will again look off because you are stretching the image you just stretched again. Reset the HT tool after applying the stretch for your preview to be accurate again. This applies to similar tools like curves and saturation. Apply, the reset and evaluate if further application is needed.

Thanks Rob. On some other images I get the comment that my stars are lacking color. I notice this on the raw subs as well. I wonder if this could be a side effect of the LP filter. It’s been a while since I imaged without it, so maybe a test is in order. I’m nearing the end of my DSLR career and begun researching mono astrocams.

General / Re: Photometric Color Calibration Problems after stacking
« on: 2018 September 17 12:07:29 »
I recently had this happen. In my case the previous target coordinates were still being used even though I was selecting "get coordinates". I had not changed the target in the search box at the top of the get coordinates window. Once searched for new target the proper coordinates popped up and it worked fine.

Also be sure to check the pixel scale and focal length settings. If you drizzle at a scale of 2 you have to double the focal length or half the pixel size (I think I did both and it still worked). From the support documentation:

If you are using drizzle, please remember to change the focal length or the pixel size according to the Scale parameter value used in DrizzleIntegration. For instance, if using a Scale value of 2, you should then multiply the focal length by 2 or divide the pixel size by 2.

Pages: [1] 2