Using STF to permanently stretch produces results that don't match the STF view

[monkeybird747]

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 1.08.06.1475. 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 

[Juan Conejero]

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?

[johnpane]

Juan,

Looks like this can be reproduced by using NoiseGeneration to create a very low signal that requires a similar midtone stretch.

John

[ngc1535]

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.

-adam

[monkeybird747]

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.

[monkeybird747]

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.

-adam

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.

[monkeybird747]

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.

https://www.dropbox.com/s/in3dxzbni3e25vb/Panel4_LIGHT_Ha_600s_BIN1_-20C_001_20190720_025739_011_PA266.65_E.FIT?dl=0

[monkeybird747]

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

https://www.dropbox.com/s/bzwb1poc9dbdwej/Panel4_LIGHT_Ha_600s_BIN1_-20C_001_20190720_025739_011_PA266.65_E_c_cc.xisf?dl=0

Thanks for the help,

Ty

[ngc1535]

HI,

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?

-adam

[monkeybird747]

HI,

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?

-adam

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.

[ngc1535]

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!)

-adam

[monkeybird747]

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!)

-adam

Thanks for the input Adam!

Ty

[monkeybird747]

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?

[Juan Conejero]

Hi Tyrell,

Here are side-by-side comparisons between the linear images with automatic STFs enabled and the same stretch applied with HT:

With your 32-bit floating point XISF image:
https://pixinsight.com/forum-images/20190729/stf/01.png

With your 16-bit FITS image:
https://pixinsight.com/forum-images/20190729/stf/02.png

Both screen representations are essentially identical in both cases, as expected.

As for (usually small) visible differences between a linear image with STF enabled and the same nonlinear transformation applied with HT to the same image, there are three causes on current PixInsight versions:

-  For reduction screen zoom ratios (1:2, 1:3, ..., 1:100) STF is always applied to the subsampled data, that is, to the pixel data interpolated at the screen representation scale. However, when the same transformation is applied via HT, it is evaluated pixel-by-pixel on actual image data. This leads to small differences because input pixel values are different in each case.

- For reduction screen zoom rations under 1:2 (1:3 ... 1:100), pixel data are interpolated using a very fast but inaccurate sparse image subsampling algorithm. Fast sparse subsampling is less accurate as the zoom ratio decreases (hence you may observe more significant differences for zoom ratios under 1:5 or so), but is extremely fast for screen image visualization. This default behavior can be disabled with Preferences > Miscellaneous Image Window Settings > Use fast screen renditions. However, disabling this option is not recommended because it may degrade performance of the user interface considerably, especially if you don't have a fast machine (CPU benchmark indexes above 12000) and work with large images.

- STF is always applied through lookup tables (LUT) at 16-bit or 24-bit resolution (depending on the 24-bit LUT STF setting for each image), while HT is always applied directly to 32-bit and 64-bit integer and floating point pixel data. This may cause visible differences for 32-bit integer and 32/64-bit floating point images, as a result of roundoff and truncation errors. However, normally these errors are negligible and undetectable visually, except for HDR images as posterization artifacts (and 24-bit STFs solve posterization problems in virtually all practical cases).

Sorry for the slightly technical explanation, but there is no other way to describe this efficiently. Representation of large images on the screen is not a trivial task, especially for an application with the performance of PixInsight, where you can work with huge linear images in 5 pixel formats under a fully color managed environment. This requires a well balanced, carefully designed image navigation and visualization interface, where screen representation accuracy has to be sacrificed to some extent for the sake of performance and usability.

[monkeybird747]

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?