StarXTerminator and STF -- operator error?

D

DavidAckerman

Active member
Following DBE with a very starry .fits file (Flaming Star Nebula) and then operating with StarXTerminator (STX) as PI plugin, I get two new frames -- call them noStars and onlyStars. As STX output, they appear with a stretch. If I save onlyStars as .xisf, close it and then open it, it appears in its linear form. STF then restores it to the way it appeared as STX output. In other words, everything seems to work. If I save onlyStars STX output as a .fit file, close it and open it, then it, too, appears in its linear form -- at least to the eye. However, STF then seems to distort the file making it very bright (and weird). Seems like operator error. Why would PI treat the STX output saved as .fit different from that saved as .xisf? Russ of RC-Astro does not think it is a STX issue. (I've included screen shots of the upper left corners of the reopened and STF'ed files -- you'll know which is which.)
 

Attachments

  • Screen Shot 2023-03-23 at 8.57.16 AM.png
    Screen Shot 2023-03-23 at 8.57.16 AM.png
    832.4 KB · Views: 32
  • Screen Shot 2023-03-23 at 8.57.25 AM.png
    Screen Shot 2023-03-23 at 8.57.25 AM.png
    901.3 KB · Views: 31
Could you upload the .xisf file and post a link. We could then try to duplicate this. One possibility is that you selected an integer format when you did the FITS save. This would very likely cause truncation of low level background pixels, giving much less variation in the background, which STF may then not devote as much stretch to.
 
DavidAckerman said:
If I save onlyStars as .xisf, close it and then open it, it appears in its linear form. STF then restores it to the way it appeared as STX output.
Click to expand...
When I open the .xisf it displays with an STF that was saved with it (and appears like your left-hand screenshot). When I cancel the stored STF and re-apply STF, I get an image like your right-hand screenshot. This is with the .xisf file - no .fits files involved. I think this sort of STF output is a consequence of the stars-only file having no background (i.e. zero background), so all the STF stretch is applied to the bright stars. I think you will get the same effect if you cancel and re-apply STF to your .xisf image.
 
This can be seen in the histogram after STF. With no background peak, all the stretch is devoted to the stars:
1679582559713.png
 
I see what you mean. Thank you. To recap: Saved .xisf opens with 'normal' look. Enabling/disabling STF does not create a 'mis-stretched' image. However, if I reset STF and then operate on the re-opened .xisf file, STF fails because, as you point out, the image has an artificially zeroed background which apparently STF does not like. The most important lesson learned here is that .xisf file records the STF setting so that starting STF from scratch is not necessary and recovery of the SXT output is possible. However, .tiff and .fit formats do not maintain a record and therefore always start from scratch -- and therefore STF fails because of the pathology of the SXT stars-only image (with zero background.) Thank you for solving this
 
DavidAckerman said:
apparently STF does not like.
Click to expand...
It's not really about "not liking". What autoSTF does is very simple: it applies a specific non-linear scaling function in such a way that the median value of the (non-zero pixels of the) image is scaled to 50% brightness. In most images the median value is dominated by the background, but in your image the median value comes entirely from stars.
 
Didn't mean to sound glib about STF. Thanks for the explanation -- I would have guessed that the median value of the image would have been taken over all pixels but it is interesting that zero values are excluded. That explains (1) the brightness of the stars and (2) the strange 'truncated glow' around each star in the mis-stretched image. Really answers all the questions. (I had been a bit resistant to .xisf but this is strong motivation to be more open-minded.)
 
Provided you use the same data representation as xisf (usually 32 bit or 64 bit floating point), the image data should be identical in any other lossless saved format.
DavidAckerman said:
it is interesting that zero values are excluded
Click to expand...
I think it may exclude saturated pixels as well (i.e. it processes the same pixels as the "clipped" Statistics output).
 
DavidAckerman said:
Didn't mean to sound glib about STF. Thanks for the explanation -- I would have guessed that the median value of the image would have been taken over all pixels but it is interesting that zero values are excluded. That explains (1) the brightness of the stars and (2) the strange 'truncated glow' around each star in the mis-stretched image. Really answers all the questions. (I had been a bit resistant to .xisf but this is strong motivation to be more open-minded.)
Click to expand...
I have no feelings one way or the other regarding the XISF format compared with other formats. But as a rule, I think it's always a good idea to save ANY files created by an application using the native format of that application. I usually save everything I want to keep from a project in XISF format, and then separately save them as either FITS or 16-bit TIFF as necessary for exporting to other apps.
 
Fred, Thank you for that clarification. Since clipped pixels on both ends of the distribution carry less information than non-clipped pixels, it makes sense to ignore them. But the artificial clipping of the background in my onlyStars image is an exceptional case. To which Cloudbait's comment applies.

Cloudbait, Thanks for the sensible advice. (When in Rome ...) As you can see, I learned this lesson attempting to rebuild an image created with a PI plugin which I think of as an extension of the native app. When I export for final polish, say to Photoshop, I will use tiff format.
 
DavidAckerman said:
To which Cloudbait's comment applies.
Click to expand...
I don't think his comment, while it is correct, is relevant to this issue. Remember, the STF is not changing the image data, so it makes absolutely no difference to any decision about what format to save the file in. The true, exported presentation of the image is the display with the STF cancelled. AutoSTF is a "quick view" facility; when you finally decide on a non-linear image stretch you may choose to start with an autoSTF, but with a starless image that would probably not be a sensible choice. I agree with @cloudbait that once you have an image in PixInsight you should always save an xisf, whatever format you export, because an xisf holds PixInsight metadata theat no other format will save.
 
DavidAckerman said:
I would have guessed that the median value of the image would have been taken over all pixels
Click to expand...
Just think about that for a minute. If more than half the pixels are zero (background) - and background is usually much more than half the image - then the median would be zero, so zero would be displayed as 50% grey, and the whole of the non-zero image would be compressed into the >50% levels. It is really not surprising that PI leaves these pixels out.
 
...however, on closer examination of the Statistics, the great majority of the pixels in this image are not zero; the difference between the clipped and unclipped median is very small. But the image is still strongly biased by removal of the (usually dominant) background.
I have also observed that the %50 (mid-tone value) is set to 3 x median (not median) ... of course 3 x 0 is still zero.
 
Last edited:
You must log in or register to reply here.
Back
Top