wimvb

@fozzybear do you know how accurate the data from that service is? If you want to use the data to control the obsy, it needs to be fresh and accurate. Or would one upload data from a home weather station to the weather service, and read that back? The advantage of such a scenario is that it becomes easy to test functionality, and that there is redundancy. The data can come from other sources should the private weather station decide to quit working.

Take the darkest images. Clouds reflect terrestrial light, ie light pollution. The histogram shows that your light pollution is mostly in the red channel, with some also in green. Red + green = orange, which is the colour of sodium and mercury lamps. The histogram on the left still has a fair gap on the left side. You can experiment with shorter exposures, but compensate by taking more. Remember, if you have more light coming in, you also get more noise. The light from light pollution will be subtracted during processing, but the associated noise remains. Increasing the number of subs is always the best form of noise reduction you can apply.

How does dss determine image quality?

That is a very nice group

Do you have an ngc number for that? (If I google Sheraton star I get completely irrelevant information. Weird. 😉😋 )

Just for the fun of it, compare this result with one where you are more restrictive in selecting subs. Clouds will brighten the overall image and reduce contrast. The added light due to clouds is easy to correct, but the associated noise can spoil the image. You might get a better result with fewer subs that lack clouds than with more subs that include clouds.

Atm ngc 7771, a galaxy group with a weak shell structure much like ngc 474. Ngc474 is a bit low in the sky for me, but looks very interesting.

It's been a long time since I visited the tutorial section of the INDI web site. https://www.indilib.org/community/indi-tutorials.html https://www.indilib.org/developers/dev-howtos.html I was convinced that I had seen more tutorials there on weather station integration, but can't find them now. If I find any, I'll report back here.

@AstroMuni: I haven't tried connecting to a weather service. My guess is that you need to do some reformatting of the response of the weather service. Have you found anything in the tutorials?

I did a proof of concept, but never found a good place to set it up permanently. And the one long usb power cable I had failed. So far I haven’t followed up on this. The weather station that I used also lacked rain and wind sensors, and those are the two most critical sensors in any observatory warning system. There ’s still a lot to do before it can be deployed, but most of that is straight forward. If only I could stop procrastinating. 😁

Great image. PixInsight image solver can be quite tricky. But at least you can use the annotation script on any image that has ra and dec coordinates in its header.

Thank you, Peter. Thanks, Göran. I have another image in the pipeline: ngc 7771 which is a pair of galaxies messing up each other. So far I have collected about 4 hours of RGB data, and a shell structure is just starting to show. It needs a lot more data before it is presentable, so hopefully those clear skies will come with the waning moon. (One can always hope.) Cheers,

Thanks. I use arcsinh stretch on the rgb data and scale the stretched L down to 0.9 - 0.95, ie the brightest stars have a value no higher than this. If luminance is at 100% somewhere, that part of the image will be pure white after lrgb combination. So I avoid that by scaling L.

The smaller galaxies around it can have a stronger gravitational pull on the arms of ngc 772 than its own mass has. This is just a result of who is closest, not necessarily who is heavier. It moves matter from ngc 772 to those other galaxies. I haven't checked it any further, but this is one of two possible scenarios. It is also possible that what we see here is ngc 772 pulling in matter from smaller ngc 770. Whoever is being pulled apart, this is similar to what will happen with our own Milky Way and the Andromeda galaxy several billion years into the future. Eventually, after millions of years, this galactic dance will result in a full merger of the galaxies involved.

This galaxy, ngc 772 in the new general catalogue, has number 78 in Arp's catalogue of peculiar galaxies. It is located at a distance of approximately 130 Mly in the constellation Aries. The galaxy is surrounded by numerous smaller galaxies, notably ngc 770, just below the main target in this image. There is a gravitational tug of war going on between several of these galaxies, which has left its mark on ngc 772, giving it it's lopsided shape as well as a tidal stream. The brightest knots in this stream are barely visible in a superstretched version of the luminance data. A hint of the tail is just about visible below ngc 770. Technical details: Telescope: Skywatcher MN190 on a SW AZ-EQ6 mount Camera: ZWO ASI294MM with Optolong LRGB filters Exposures: L 76 x 2 minutes (152 minutes), RGB 20 x 4 minutes per channel (240 minutes). Total integration time: 6.5 hours Processed in PixInsight. The image could well do with double the integration time. Most of the data was collected under a bright moon earlier this month. Because of this especially the luminance data is weak and quite noisy. If the weather plays nice, I will try to double the amount of data on this target. Annotated version (with two quasars indicated) As always: click on the image to get to a larger version.

Different image processing packages have different philosophies. In PI it helps to think in terms of levels of brightness, levels of detail (1 px level, 2 px level, 4 px level, etc) and to separate luminance from colour (chrominance). And it helps if you have a decent knowledge of math terms, because the processes rely on strict mathematics, and the process names refer to the math that is used. I guess that's why people tend to be put off by it. PS on the other hand comes from image manipulation with strokes, air brush techniques, and applying filters (among many others), so you refer to areas of an image that need adjusting. In the end it's very much down to understanding the tools, how they work, and getting better at applying them.

The workflow I used was roughly this: Aligned the masters Cropped all the masters to remove stacking edges and the worst of the light intrusion Combined R G B RGB: Flattened the background with Dynamic Background Extraction Neutralised the background Colour calibration using photometric process Colour noise reduction in the background Arcsinh stretch which preserves and boosts colour Increased colour saturation in ngc 7331 L: DBE to flatten the background Deconvolution to increase sharpness a tiny amount and shrink the stars ever so slightly Brought in the black level to just before clipping Histogram (levels) stretch with the midpoint slider set to 0.25. Applied this several times until the core was getting very bright. Doing the stretch in small steps gives better control HDR compression (HDRMT) to manage the bright core of ngc 7331 Continued histogram and curves stretch Local contrast boost using Multiscale Median Transformation to enhance the spiral arms in ngc7331 and give a little more detail in the quintet Bring the white level down to 0.85, meaning that everything that was pure white (star cores, intensity level 1 in PI) now is at 0.85. LRGB combination Blurred RGB and applied a 20% mask LRGB combination with colour saturation increase Blurred the image but less than before with the mask disabled LRGB combination with the 20% mask. Repeated this several times. This controllably adds luminance to the colour data without washing out the colour. Finished off qith traditional star reduction (morphological transformation) Although this workflow is specific to PI, it can be adapted to other software. Hope this helps.

Yes It's possible that I stretched the core to slightly past its naximum, but the linear image definitely wasn't blown out. What I wanted to avoid is this: https://pixinsight.com/examples/NGC7331-CAHA/index.html And as long as the core isn't blown out you can always combine a lesser stretched copy with a more heavily stretched one.

The exposure time you should be using depend on scope, light pollution and gain setting. To avoid clipped pixels set the camera offset to a high enough value.

AfaIk, there’s no way around this. The scheduler is intended for automated operation, and since you’re focusing manually, there is no real automation. In your case it’s probably easier to start an imaging sequence in the capture module and set an alarm to signal when it is finished. (Or get a focus motor, of course.)

I understood as much. It will be interesting to see the stacked binned data, but I think that quality wise the improvement will not be that obvious. I found your master images to have a good signal to noise ratio already.

That is the recommended amount of dithering. I believe that it was first suggested by Tony Hallas in a presentation he gave years ago. The presentation is still available on youtube: Tony Hallas astrophotography.

With your ccd camera, binning during data collection will give the most benefit in terms of noise reduction of course. If you use an auto focus routine, the hfr or hfd measurements normally give you an indication of sky quality. (Hfr is half flux radius, hfd is half flux diameter. Hfd is similar to fwhm, full width at half maximum.) I find that these values can differ quite a lot. On nights with high hfr values, you'd use bin 2x2, while if you experience exceptionally crisp and clear nights with good seeing, you could do unbinned data collection. Although even then binned 2x2 may give you enough details. The masters you provided where very clean as regards to noise, and I didn't have to do any noise reduction, other than my usual chroma noise reduction of the rgb image before lrgb combination.

Here's my result. I think you managed to capture some IFN, but I found the background a bit too uneven in RGB to enhance it. The stars in your image are quite large, and oversampled. With a 2 m focal length and 6 micron pixels, your image scale is about 0.6 arcsecs/pixel, which I think the sky can't really support. If you bin 2x2, even for luminance, you will probably get better subs without losing detail.

I just downloaded your masters, and it seems a very nice dataset. In the luminance data, there is inverted vignetting, so you might want to check your flat calibration. With cmos cameras inverted vignetting can be caused by inconsistent darks or bias being used in stead of flat darks. I don't know what might cause it with CCD cameras. Too bright flats perhaps? The core of ngc 7331 definitely is not burnt out, but it requires carefull stretching. In your original image, you may have brought the black point and white point in too far. I'm working on the image now, and will report back when I've processed it.