M39 - 1st light for RisingCam IMX571C, minimal processing

[dx_ron]

2 hours, AT65EDQ
60s subs at gain 100 (Low-Conversion Gain)
Stacked in Siril

There weren't too many suitable widefield, broadband targets at darkness. The goal was to try different exposure times on stars, so I went with a field that is stars, more stars and only stars. I settled on 60s exposure as by 90s many more star cores were showing as clipped.

For processing I used only Crop -> Wipe -> Autodev -> SV Decon -> Color. I left it unbinned to expose any flaws, plus I don't think I need to maximize SNR with no nebulosity to stretch.

For the Autodev I set IFD as usual, and then put Shadow Linearity way down to 2%. Does bad math happen if you set SL to 0%? I am just naturally leery of setting ST parameters to 0 if that's not their default.

I am curious if other people have a different approach for non-nebula starfields. Also curious if anyone thinks I should run any Shrink or SuperStructure or NR. I don't see this as the final version, necessarily.

For orientation, I framed it with M39 in the lower-right, NCG 7082 in the upper-center and NGC 7062 the tighter little cluster in the upper-left.

Here is a link to a high-res jpg https://www.dropbox.com/s/ngguukkvdvz0j ... y.jpg?dl=0

M39_07-22-22_60s_LCG_-10c_after-clouds_st_decon-only_1600.jpg (488.12 KiB) Viewed 2858 times

[Mike in Rancho]

Cool! What do you think of your 571?

I think my stars/open cluster process has been pretty similar, except I would have binned and likely run a light denoise. But the denoise would depend on pixel peeping and checking before/after while modifying the grain size and probably scale correlation. Plus...tracking...ST's innovative difference from all other processing! Might as well let ST clean out what it has determined is the junk!

I would also bin because, big APS-C sensor on a short frac is probably majorly oversampled. Maybe I'm wrong on that? I would knock that back to probably 35% (my go-to these days with the 2600), which usually leaves around 2200 pixels wide and seems sufficient to get a good SVD. Or you could go 50% at about 3K wide. I guess you could check some stars to make sure they aren't squared off.

Plus, as you say, you can augment some SNR. I think this is good for stars too, and of course the background sky, even if you don't have a main nebulous or galactic target.

I wonder if you might end up using less A/D shadow linearity reduction with that binning. Or you could then do sufficient shadow compressing in the Contrast module. I don't know if one is more preferable than the other though.

Now for the post you did resample down to 1600 wide or so, of course, and I suppose that also helps accomplish some SNR increase even if after the fact - though I would guess it would be better to do it earlier and hand that SNR off to ST to process with.

[dx_ron]

So far so good. It seems to stress the resources available with the RPi, as I've had a couple of software crashes. There's a feature involved with displaying each image that I can turn off in Ekos, but I an Intel based mini-C is in the future even if I stick with linux. I am quite pleased that most of the stars or mostly-to-all "filled" with color, rather than being a ring of color around a white center. I will start playing with Shrink some on its stars. (the file is still open in ST - still playing with some things before I lock myself into NR)

Sampling is "good" (whatever that really means!). The 3.7u pixels at 420mm focal length = 1.85"/px. Getting close to undersampled, rather than oversampled, so I suspect deconvolution will always best be done before any binning.

I won't normally keep my images at anywhere near the full 6224x4168 (which you can see if you go to the dropbox link), or skip noise reduction - this was about seeing things warts and all. The 571 sensor seems to live up to its reputation as having very low noise - way, way different from my 183 with its giant starburst of amp glow.

Would you really run the Contrast module on this image? I think of that as for contrast between large-scale structures, of which there are none.

[Mike in Rancho]

Ah you are correct, Ron. I wasn't thinking of the pixel scale and don't often deal with much wide field. So yes that makes sense as to the sampling.

In fact, I just sort of had an epiphany last night working on the Cygnus Loop - since it is a mosaic of two panels, if I bin down to my more "normal" width and height, the stellar profiles are shrunk too much for me to get a good SVD. So I ran a test this morning with less binning and was able to get SVD to work properly. I'd still like to recover more SNR, especially with my limited integration, but perhaps that can be done later in the process.

Also correct that I typically would not use contrast in your situation, other than to compress some shadows of the background sky if I thought that seemed needed. I brought it up since you mentioned cranking down the shadow linearity in the A/D. I'm presuming you were looking to suppress the background?

But again I don't know which is the more preferable way to go about that. A/D might have more range to do so, along with the fact that you can use ROI's and IFD as well.

[dx_ron]

I would expect binning to increase SNR regardless of where it comes in relation to other processing steps, but I obviously do not know if "bin-late" vs "bin-first" affects tracking's view of the noise term for any pixel. Is there any reason to always postpone deconvolution until after contrast & sharpening? I could see going from 2nd autodev to SVD then bin then contrast/sharp, though the the time savings for binning on those two steps are not huge.

My thinking with how I used Autodev on this image was that Autodev is setting the shape of the initial stretch curve, and without anything for Contrast / Sharpen to work on it is also pretty well setting the final curve. There are normally three ways to affect the stretch in Autodev, Ignore, ROI and Shadow Linearity (I have bumped up the initial gamma on my globs, but I'm not at all sure how that changes the final outcome). Anyway, with just stars there isn't an ROI to use (or would you make a square around the brightest star? hmmm), and there isn't any information in the 'shadows' that I wanted to preserve, so cranking down linearity seemed the way to go.

[Mike in Rancho]

Yeah Ron this stuff is getting close to the edge of too-advanced for me, and I haven't done enough experimentation yet.

For sure I can say, just in the past few days, that too much binning down will wreck the ability to deconvolve. So, my 25% bin on the stitched mosaic file of Cygnus Loop just plain failed. And even synthetic deconv had to be dialed way back or else the stars all went to [expletive]. As one would expect, the detail recapture was poor as well. But, at 50% bin, SVD worked great. And subsequent downsampling, such as to post the jpg, didn't ruin all that, though of course some detail resolution is lost.

So sequence does seem to matter. I kind of recall that I had a similar issue using HDR back in 1.7.

I believe the ST reason for delaying deconvolution until later is so that you can make your SVD parameter decisions based on the live view ST gives you of how the image is going to react and look, with all those modules implemented -- even though in the pixel formula the deconvolution will happen "first."



As for AutoDev, I've read the documentation and understand that the gamma and shadow linearity alter the data before it is then passed through to A/D for optimizing dynamic range stretch based on the other settings, but what that really means as a practical matter I'm not terribly sure. They both can make things brighter or darker.

I suppose I need to learn more about what gamma and linearity actually mean.

[decay]

Hi Ron,

that's a very impressive star field.

Here are my thoughts, no idea if it helps: Some time ago I wanted also to develop a star field, but my goal was to get a nice looking star field (whatever that exactly means) and not to show as much as possible, as you did. I had very much the same thoughts about the use of AutoDev in this case like you described in your posts and therefore I decided not to use AutoDev, but FilmDev instead. (I know, it' strongly discouraged to use Filmdev and in almost all other cases I do use AutoDev of course.)

My workflow was like this:
AutoDev -> Bin -> Crop -> Wipe -> FilmDev (final stretch) -> SVDecon -> Color -> Denoise

Regarding binning:

if "bin-late" vs "bin-first" affects tracking's view of the noise term for any pixel

From my understanding of StarTools and the use of this module I would assume exactly that and therefore Bin should be used at the beginning of the workflow. I'm curious, if someone has other thoughts.

As for binning vs. deconvolution I can confirm what Mike wrote: With my images I have to leave enough resolution (bin down to 50% at 6000x4000 px sensor pixels) to get deconvolution to work. But these images seem to be a bit oversampled at the end and so I shrink them afterwards a bit further (not necessarily with ST). I think that’s some kind of trade-off or dilemma. In fact I would like to bin down enough at the beginning of the workflow, so that ST can take advantage of the additional SNR, but I can’t, because I have to leave enough resolution for SVDecon. I have no solution or idea for this.

As for FilmDev I only pushed the Digital Development so far, that the background level at the left side of the histogram showed no shoulder. (That’s probably not what you wanted to do.)

like this

hist1.png (22.74 KiB) Viewed 2761 times

and not like this

hist2.png (24.05 KiB) Viewed 2761 times

And I did not use SuperStructure because it sometimes leaves a kind of mottled background with wormholes or something similar. And I think it is not necessary in this case.

Best regards, Dietmar.