M13 (maybe work in progress?)

[dx_ron]

Sooo - it appears the "what we have here is failure to calibrate" (apologies to Strother Martin). I was zoomed way in on the brighter red star and checking its roundness across all the subs, starting with the red channel. It looked pretty good, as did the green channel. Then I got to the blue channel:

00_red-star-blue-layer_image1.jpg (111.78 KiB) Viewed 6258 times

Whoa! Negative pixels? Yikes. Are there any zero-value pixels in a dark, or a light, or a bias? No, of course not - I set my bias value ages ago such that there weren't any. Investigations ongoing.

[Mike in Rancho]

Well, I'll take the easy one first. I checked that AP130 data and indeed, very little in the way of saturated pixels. The subs were 60s through the mono version of QHY's 571, of the M4 region which is low on the horizon (from Canada) and really only has three mag 8.x stars at the brightest. No idea of his gain and offset, but yeah composed and in still linear form, just a couple white dots on the screen. If June Gloom ever goes away, I may have to do a very short subexposure test and see if there's a big difference in SVD. Not that I would want to do that in reality. I cringe at what smiller puts his computer + storage through with his (admittedly impressive) DSO-dob work.

Which red star is that with those dark pixels, and what form is the file in for examination? Weird that it's blue channel when I see greater splotching amongst the red channel, and even then only in that first big Siril stack, not the one pre-flip session I've stacked myself in three different stackers.



The subs and cal files I looked at all seemed to have gain 100 offset 300 in the header. I don't know what that means but seems to result in a black floor of right at 300, so perhaps it is a one-one offset. My ZWO offset of 30 and gain 0 gives me basically the same black floor.

Anyway, so the file is clearly autostretched to some degree to inspect that star, and as you mention channels I presume it has been debayered. Now, as far as I know, debayering never looks to "wrong-channel" pixels for interpolation of any particular R, G, or B channel?

Baffling. I wonder if it is at the root of anything here, though it sure sticks out so seems promising. With sufficient field drift or dithers, low rejection should take care of that? I suppose low sigma could be tightened though as a test.

Also query if actual 60s darks would change anything. I do use a dark library myself for lights, and bias for flats, but that should be more a hot pixel deal I think, not cold.

Grumble grumble. An intriguing mystery.

[dx_ron]

Progress - though maybe in the sense of "We are not retreating, we are advancing in a different direction"?

First - the recent closeups have all been of HIP 81848

I had the same idea about trying 60s darks (I also took flat-darks for the flats, because why not). Maybe some improvement, though calibration still results in the min pixel values in the R and B channels negative. I went back to older images and see the same thing - either it did not cause such obvious star-color defects or I was just not paying such close attention until now.

Gain 100 (Low-Conversion Gain), offset 300 should indeed be the same settings as your ZWO gain 0 offset 30. Though it is not an absolute floor of 300. The average for darks (and bias) is just a nudge over 300 ADU, but all images, including lights have their minimum pixel values below 300. The stacked 60s dark (100x) has min values of 285 / 286 / 290. A random light is 288 / 339 / 281. I also took bias frames the other night at offset 700. A frame from that has mean values of 700.9 / 701 / 701.2 and min = 570 / 577 / 592. (I haven't stacked the o700 bias yet) It remains a complete and utter mystery how blue pixels near a star core get negative values - they should have substantial positive values before dark subtraction..

I calibrated a couple of lights with every debayer option in Siril. All give negative pixels, but a few methods (including RCD) have much lower max-negative values than others.

Tonight is supposed to be clear but smoky - I plan to shoot M13 again with the 700 offset value to see if that impacts calibration.

On to the main show. I have not separated using 60s darks from stacking with stricter low-pixel rejection, I just did both. Going to low (sigma-1) resulted in an obnoxious cross-hatch banding pattern, but sigma-low=1.7 seems OK (using additive-with-scaling frame normalization also helps a lot with the banding).

Registering and stacking both sides of the flip (the first 80 frames are pre-flip), rgb-aligned:

both-sides.jpg (26.34 KiB) Viewed 6224 times

That's with no color adjustments beyond setting the overall saturation to ~145%. *Maybe* a full processing effort can minimize the impact of the green arcs?

Post-flip only, before rgb realignment:

post-flip_base.jpg (22.54 KiB) Viewed 6224 times

After rgb realignment:

post-flip_rgb-aligned.jpg (31.98 KiB) Viewed 6224 times

Obviously that is the best overall. And it appears that the green arcs when stacking from both sides of the flip are some sort of misalignment (that I have no idea how to tweak).

[Mike in Rancho]

Ah, very good progress, Ron.

Yes those arcs are very much the splotch shapes I was seeing, though query whether it has anything to do with those "cold?" pixels, or is a completely separate issue.

On the pixels, well, Siril can use a synthetic bias in lieu of the stacked master bias, right? Probably set it to 300, and see what happens.

I opened up PI stats on one of your bias subs, and no doubt, the min and max were pretty widely strewn, going as low as 180-ish. I made a sub-selection of the field to ensure that I wasn't just reading off of edge pixels too. How can that happen with an offset of 300 ADU? I have no idea. Especially with gain basically being zero, meaning the histogram peak isn't really being fattened such that the tail might clip off.

So I then loaded one of my ZWO bias subs (zero gain, 30 offset, zero degrees C) and found the exact same thing. So I then did the same for the master bias files. The min/max range was tighter, but still decently wide for your bias masters, made in both Siril and PI. Oddly, my PI master bias was quite a bit tighter, with the low pixel being maybe 280, compared to about 200 for yours. Maybe due to my master being made from 50 subs rather than the 20 I used for yours?

The splotches though, resulting in the misshapen color arches. I guess first narrow down that it is either multi-session or pier side, and then figure out why. RGGB readout should be the same regardless of flip, but I suppose is worth checking. I would lean towards something going wrong in star alignment for the two pier sides, though why I can't figure. Might have to alter up star registration settings or see if other stackers also produce splotches when including multi pier sides.

[dx_ron]

Hey - I think I have a workable stack, finally. Thanks for sticking with it, Mike!

I re-calibrated everything with new darks (still have some negative pixels, but not nearly of such large magnitude). I tweaked the star detection for registration to use fewer (so only bright-ish) stars as well as only nice round stars, then RGB aligned. The off-center color artifacts appear to be gone.

What remains is the strong ringing that deconvolution leaves on the bright stars that have saturated cores. Not sure if I want to try to Layers in pre-SVD stars for those, or wait and hope Ivo comes up with a solution.

M13_363x60s_NR_1600_500k.jpg (466.2 KiB) Viewed 6192 times

Ringing:

ring.jpg (16 KiB) Viewed 6192 times

Link to the full-res .png on dropbox: https://www.dropbox.com/s/zq6bjrf1w4u4w ... e.png?dl=0
And the stack: https://www.dropbox.com/s/vqs6d46ltd1i1 ... b.fit?dl=0

[Mike in Rancho]

Sweet! Good job working out the solution. The new stack is just so much better and cleaner than the prior stuff.

I don't believe you ran an extract and channel alignment, but I don't think it's necessarily needed. On something like MaxRGB the center core dots all seemed pretty centered to the star profile.

Still a bit of a fight against purple, as well as some multi-colored stars - especially lower left corner? - but night and day compared to before.

A bit of tweaking, green cap, and then feeding green bias back in, along with some other fiddling (I still used highlight repair, but then added global and dark sat to try to make up for it) gets almost all purple to normal blue, and the reds aren't as much of that metallic pink either.

After some testing I just ran it at 71% bin, though I probably should have tried full res. I also didn't get any additional improvement beyond 50% on SVD linearity. Here's my 71% full tiff with the color balancing I ended up with. https://drive.google.com/drive/folders/ ... sp=sharing

Just Open, Crop, Bin, Wipe (still did Uncal1), very mild HDR core, SVD, Color, and DN. No extra Shrink deringing.

I did perhaps find a little issue with Denoise, which (default settings) was adding some blue pixels inside several stars. Not sure what's up there.

The various rings can be disconcerting, and I'm still unsure what is causing what, or if things are supposed to be certain ways. For bright stars you can actually see this starting out with AutoDev/OptiDev. Query how that might affect SVD. I did run a test using FilmDev for the global stretch, and still had to add deringing. Also overall I don't think SVD worked nearly as well on M13 itself as with OptiDev.

I ran some 3D plots on that big blue star to see if it might tell us anything. The linear graph shows it slightly flat-topped rather than pointy, but not by a whole ton I don't think? OptiDev of course results in a flat top with a center spike and perhaps a ridged rim, maybe like a meteor strike? FilmDev (as well as most autostretches in other software I think) results in more of a rounded-over profile.

dxron newM31 linear and stretched 3D plots.jpg (419.09 KiB) Viewed 6170 times

Not sure what the colors mean, maybe nothing. No relation to RGB channels it seems. I also haven't tried any plots yet of SVD results or what the deringing parameters make it look like.

[dx_ron]

Interesting. The linear 3D plot is sensible - the flat top is the bit with fully saturated pixels. But once stretched I think the ring of lower luminosity is real, but doesn't seem to show up in the lower 3D plot.

The stack you have, by the way, was split and RGB-aligned. I don't think it made nearly as much difference as with the weirdly mis-matched stacks, but it does help a bit.

I processed again today with the "add back some green after cap-green-to-get-some-more-blue" thing, and it came out quite like what you got. Will try to edit my first post to include the new version. Maybe I'll post the stack in the CN "process my data" thread just to see what totally different approaches give.

[dx_ron]

Since we last saw our hero (M13, that is) exactly one year ago today, we have learned about 12-bit donuts and 32-bit black hole artifacts. This spring I added a bit more time with the same scope/camera/settings. The total is about 8 hours, but I prefer the stack below which is culled to the best seeing (2.5" FWHM max) and thus is only 3 hours. All of the subs were re-calibrated with 16-bit master flat and dark and stretched with 16-bit Optidev. Not hugely different from where I eventually wound up last year, but without any weird black holes and donuts.

M13_2.5a-s_max_188x60s_700k.jpg (642.57 KiB) Viewed 4177 times