wimvb

Very nice. What scope/camera did you use? Stars are elongated along one diagonal. Can that be a mismatched flattener to sensor distance issue?

Very nice first light. Reflectors are a bit trickier than refractors. I think it's to be expected that they need collimation before first use. My 150PDS was so much out of alignment when I first used it, that the finder scope view wouldn't align with the main scope. As a newbie, it took me some time to figure out what was wrong. Even now, I always check collimation before use. With a barlowed laser, it only takes a few minutes.

I think it's just a matter of processing. Nr 2 has good quality data, as far as I can see.

Great image of this galaxy. I like image 2 in your first post best. A little creativity with curves should make this even better, I think. Image 1 looks clipped on my mobile phone. That may be my screen, though.

Lovely. You may have pushed the stretch/saturation a little too far. Careful use of curves, with an L-mask, can cure this.

I like the view of that helmet floating in space. What filter did you use on this?

I never doubted that. I think that you've shown your ability to handle curves. Your images are proof of that. Oh, the horror!

It's not a negative curve, but you're compressing the middle values, and you risk ending up with a "muddy" image. When I use curves, I make sure the section above the stretch remains straight. I.e. I'd pin the curve that you have now at the midpoint (x = 50%), and lift it where you have your midpoint marker (x = 70%).

The main difference between PixInsight and PS is that in PS you have to stretch the image first. PixInsight has a so called screen transfer function (STF) that shows the image stretched on you screen, but it doesn't apply that stretch to the data. PS also has a plugin for the arcsinh stretch. It was developed some time ago by SGL member Mark Shelley (@sharkmelley). You can find the original thread in his profile. Histogram transformation in PI is the same as levels in PS, and curves transformation is (no surprise) curves in PS. As for darks with a DSLR, some people use them, and some can't get them to work properly. The problem is that DSLR cameras aren't cooled, and dark current is very much temperature dependent. If you can't get your darks to match the lights, darks may do more harm than good. The only way to find out is to experiment, and stack your subs once with darks, and once without darks (but with bias frames). Then compare the results.

Here's mine. Processed in PixInsight. Crop DBE x 2 to remove the sky light gradient (subtraction) and the vignetting (division) Colour calibration (background neutralisation, colour calibration) TGVDenoise on Luminance MMT denoise on chrominance Arcsinh stretch Colour saturation adjustments and several histogram tweaks

You have a nice result already, with some nebulosity showing. I may have a go at your data later. Just an early remark: lens correcting software can, imo, never be an alternative to calibration frames. Not if you really want to make every photon count. With a dslr, you should at least take bias and flats. Darks can be replaced by sigma clipping and cosmetic correction, if you can't make them to match your lights.

Much less pink, but not completely red either. But remember: red + brightness = pink. A star as bright as this will need to be rendered white. Keeping colour in the core won't be convincing. Comparison of Masked stretch + curves transformation and repeated use of curves transformation. Using only masked stretch leaves a false coloured core, even after HSV repair. But this is minimised in curves transformation.

It worked for me, afaIk. I used default settings, but radius set to 32. Aldebaran is a red giant, so it still comes out red, but not pink. The only problem I had was getting a proper colour calibration with this tight crop. Standard colour calibration made the star too blue.

That would be nice. The quantities you're refering to are quantum efficiency (photons to electrons) and uniformity of gain (electrons to ADU). Strictly, one would also need to add atmospheric extinction: light loss due to atmospheric effects. An imaging rig will perform better on a high and dry mountain top, than in a damp valley. Or 40. That effort goes by the name dragonfly: http://www.dunlap.utoronto.ca/instrumentation/dragonfly/ I think we've discussed that before. Btw, the formula for light gathering efficiency (including atmospheric extinction) is in one of their publications.

There's nothing to worry about, this is perfectly normal. The histogram shows the amount of each colour (y-direction) at a certain intensity (x-direction). The peaks represent the background. Your histogram shows a good alignment of r, g, and b; a neutral background. If at a later stage during processing, any one colour starts to dominate, you can either realign the histograms, or use scnr on that colour. My usual workflow is: Rgb combine, DBE, colour calibration, denoise in L only in L*a*b mode, then denoise with MMT on chrominance only. With a fairly strong mask (at least 50 %). Then I stretch the image with arcsinh, ht or masked stretch. I don't always do linear fit, since colour calibration will also align the histograms