So are my stars saturated or not?

[TinySpeck]

When I load my integrated images into PI and hover my mouse over the cores of the biggest, brightest stars, it looks like I have plenty of headroom.  50% - 80% maximum is typical for each of R, G, and B on the readout at the bottom of the screen.  The maximum pixel values in Statistics also show no more than about 80%.  When I look at the linear image there are typically a few dim dots for the brightest stars.

But when I try to stretch the linear image (with no other processing) it gets messy.  HistogramTransformation and STF stretches work fine, bringing the star cores up to full white with a natural falloff to the background.  But with ArcsinhStretch, MaskedStretch, and AdaptiveStretch there is a big off-colored blob in the middle of the brightest stars.  See the example photo attached.  You can see an off-colored blob in the linear image (the star halo is blue and the central blob is magenta) and this just gets brighter in the stretched image.

So what's going on here?  Are my stars actually saturated?  If so, why doesn't that show up in the Readout or Statistics data, and why do some stretches handle the saturation just fine?

[pfile]

DSLR? if so it's a 14-bit camera and a saturated star will show up as 16383/65535 or roughly 0.25 in PI's normalized 0.0-1.0 space.

rob

[TinySpeck]

Yes, a 14-bit DSLR.  But the data is much larger than .25.  Like I said, it's typically 50% - 80% maximum.

And why would some stretches handle it fine, but not others?

[pfile]

well something is weird, was it captured with SGP?

the pink core is pretty normal for saturated stars from an OSC... so i think they probably are saturated.

rob

[TinySpeck]

No, I use AstroPhotography Tool to coordinate and capture my shots over USB.  My camera is a Canon 100D.

I tend to think the stars are saturated too, but I'd expect the data to hit a hard ceiling at 25% if PI doesn't scale the raw 14 bit data to 16 bit.

[pfile]

PI shouldn't. i guess that's why i was asking about SGP - because if you save as fits using SGP, they scale the data up to 16 bits. and i don't think it's just shifted up by two bits, i think they are using DCRAW's built-in scaling.

if this is an integrated image though perhaps the subframe weighting has caused the change in the 'saturated' value from the expected 0.25. maybe if you look at the calibrated subs you'll see 0.25 everywhere for those stars.

rob

[John_Gill]

Hi,

I also use a DSLR and often find the star core turns pink after stretching.  So before stretching,  I run the script "Repaired HSV Separation " and then ChannelCombination for HSV.  This seems to fix the pink core issue.

space is not black
John

[TinySpeck]

Thanks, John.  I use that script too.  I found I had to set the "repaired level" down to 20% or so to get it to see my saturated cores though, and the result usually needs a little smoothing to look natural.

Rob, when I look at bright stars in a single calibrated debayered light I see the magenta core but the RGB values are roughly 17%, 14%, and 40%.  So the same strange >25% in B.

If I load a raw .CR2 image direct from the camera (still bayered) it shows up in PI as a checkerboard grey scale.  The core of bright stars are a uniform gray fixed at K = .2335 over many pixels though.  Not quite .25, but this sure looks like 14-bit saturation to me, coming straight from the camera.

So I guess cal and debayering scale the data to >25%.  I think my stars are indeed saturating in the camera.

There is still the question of why some stretch processes handle saturated data fine while others seem to propagate the false core color.  I probably wouldn't understand the reason anyway, so I should just put up with it.   

[pfile]

yeah, thinking about it more the application of the flat during calibration probably changes the 0.25 saturation value to something else.

in essense i think the problem here is that the data needs to be rescaled channel-by-channel to make sure that all the saturated values are 1.0 before the images go thru the rest of the pipeline. i think because in the stacked frame these saturated values don't seem to be saturated anymore, strange things happen when stretching. "regular" stretches like HT tend to blow out bright structures, so that may end up masking the problem. something like ArcSinh/Masked Stretch is going to try its best to preserve the color and as far as those processes are concerned you have a legitimate image of something pink, since the values are nowhere near 1.0.

perhaps SGP's method of rescaling the data when captured as fits is actually a good idea - i have always frowned on it a bit because in essense it ties the camera to the software in a way that can't be undone... the data saved by SGP is less raw than the camera provides, and the scaling makes the fits files incompatible with CR2 files you might have captured with different software, meaning that once you collect lights modified in this manner you are obligated to capture your flats, bias and darks in the same way. but if saturated stars come out as 65535, that's probably a good thing.

you can debayer the raw CR2 with the debayer process if you want to see what happens next. BPP also uses the Debayer process behind the scenes, but of course it debayers the calibrated frames.

rob

[TinySpeck]

Good thoughts, Rob, thanks.  Yeah, I also realized that flat calibration (by division) could certainly skew the data beyond 0.25.

With the image I'm working on now, I ran the HSV Repaired Saturation script kind of early in the process (with a repair level of 0.20), and ArcsinhStretch is working well now.  I think I'll try to use that stretch in general because it is so good at preserving color without having to boost saturation afterward.

Thanks for clarifying the 14-bit thing for me, and now that I see that data values can exceed 0.25 due to preprocessing it all makes sense.  I can work with it now.