wimvb

If you post or pm the 3 unstretched masters, I can have a go at it. Mind you, I have very little experience with nb data, but would love to learn and will of course share my experience.

You already gave the answer in your question. More data gives a higher snr, which allows you to stretch more aggressively. This reveals weaker detail and increases apparent dynamic range. In a camera, dynamic range = full well / read noise, which has nothing to do with images. But in an image, whether it's a single sub or a stack, the limiting noise is either dark current noise or light pollution noise, which should be higher than read noise, because you expose above the read noise floor.

The first image has the histogram a bit high. It looks like you have a very high level of light pollution, which adds to the signal. Try lowering iso to 800 or even 400. I guess that the second image shows the histogram for the region inside the ellipse? If so, it's over exposed. Again, lower iso or exposure time (90 - 150 s). Also consider using a light pollution filter.

That should do it. When I made one from resistors, I used higher value resistors in parallell. I found it mechanically more flexible. Resistors in series don't bend that well. The wire between the resistors can be multistrand to allow easier bending. If you have 1000 ohm, you can use 10 pcs also.

Nice. But, did you use a mask around M82? 😋

Cosmetic correction in both DSS and Pixinsight can take care of this. Otoh, you need very good tracking for ordinary pixel rejection not to work. I guess that AstroArt's hot pixel filter has similar functionality.

Have you seen these? By our one and only @swag72 https://www.swagastro.com/astro-pixel-processor-tutorials.html

Can you elaborate on that (or pm me). I've tried doing ppec on this mount, but never succeeded.

That looks very good. With guiding problems, start here https://openphdguiding.org/tutorial-analyzing-phd2-guiding-results/ Guide scopes are generally smaller than imaging scopes, so they should cool down fast enough. Unless you use a 6" apo as guidescope, of course. 😀

The ADC is 12 bit, which means that each AD unit (ADU) is a digital number 16 (2^4) in the image file. For the ASI1600, gain setting 0 is 5 e/ADU. Since the largest digital value = 4095 (2^12 - 1), this gives a full well of 20000. The graphs on the ZWO website are worth studying.

I don't know if anyone ever investigated that. But I would follow zwo's data and use 0 gain which is supposed to have the highest dynamic range and full well. An object with such high contrast will still need a combination of exposures, if you want to go really deep.

Unfortunately, ap has a learning curve, and the European climate isn't supportive. But you have a few options. 1. High gain short exposure imaging. Not quite lucky imaging, where you try to beat seeing, but rather try to beat guiding. You'll end up with lots more subs, and probably need to throw many away, butwith cooled cmos, this is an option. I've done it on occasion when the guiding gods were against me. 2. Go for a shorter focal length with a light weight refractor or tele lens where guiding is less critical. I've done some of my better images with a pentax 135 mm lens. When you've worked out the wrinkles in your guiding, you can go back to a longer focal length reflector. 3. Live with guiding rms slightly above 1", and enjoy those rare nights when it all just works, and rms suddenly touches 0.6". A friend of mine with a high end mount gets guiding rms of 1" more often than he would like, but he still manages to produce excellent images. Just not of super detailed galaxies. On those nights of good guiding, you make the luminance filter your best friend. On other nights you go for colour with rgb filters.

The best way to analyze guide logs is with phd guide log viewer. https://openphdguiding.org/phd2-log-viewer/ It can show you if you have an oscillation, such as pec, or a gear acting up. You should analyze th ra behaviour in the second graph. This graph seems to show some sort of mechanical issue, but the third graph may very well just show poor seeing. The phd forum is also a good place to get help. Also, be aware that phd won't apply corrections if the deviation of the guide star is less than MinMo. That's why the second graph shows so few corrections in dec. The random movements in the third graph may, as I already said, be caused by seeing. I probably would keep using those settings. The final rms is about 1 pixel on the imaging camera, not too bad at all. If you use the settings next time, you'll develop a sense for how atmospheric conditions affect guiding. One phd tool that I find helpful, is the bulls eye. If ra and dec movements are truly random, the errors will show a round "cloud" in the center. And the better your guiding is, the tighter that cloud will be. But if ra and dec movements follow each other, that cloud will become a streak. The stars in each sub will show the same pattern as the bulls eye. If they don't, you probably have flexure somewhere. Especially if the bulls eye shows a round cloud, but the stars are elongated. In that case, there should also be a constant drift between subs. You'll notice that during stacking.

Thanks, guys. Tonight was clear from about 10 pm, so I opened the roof and managed to do a polar alignment. Had a mishap with a usb cable to the guide camera, which caused kstars to crash. But I managed a pa error of less than 1' according to Ekos (not sure how accurate that is, but it was repeatable) . Also focused the imaging camera, but hfr values indicated that sky quality wasn't that good. Ekos acted strange when I tried to create a pointing model near the neridian, so I have to figure that out. I don't think it's a balance problem, but I will check for that anyway. @Firas: I got a long ethernet cable, so will have internet access from the obsy network. The obsy wifi just reaches the dining room in my house, so once everything is set up, I can control from there.

Fixed a basic video surveillance. I had a wireless camera lying around which I mounted on the south wall between the piers. However, hooking it up and getting it to stream was an entirely different matter. D-link are lousy at supporting their own devices. The built in software isn't supported by any web browser, although they claim that IE and Firefox have support. MyDLink wouldn't connect to it, and D-LiveView isn't even proper windows, and doesn't support the camera (which I bought new a few months back). In the end I got it to work with an older version of D-LiveView, but I have no idea if the motion detection actually works. Anyway, here's a screen shot before I figured out how to set the proper date and time. D-link seem to think that their software is sooo good that it doesn't need a manual.

Great image, @alacant. My guess is too that the difference is one of quality control. They are both probably made in the same (chinese?) factory. Have you done an imaging comparison? It would be nice to see two identical images side by side.

Wow! Excellent write up, @vlaiv @Calzune: välkommen till forumet. I think this part is the most important for you, atm Furthermore, the darker skies you have, the shorter time it takes to go to a certain "depth". The more light pollution you have, the longer it takes to get to a certain "depth". Light pollution adds noise, and you need more data to average that out.

Some dslr models (Canon & Nikon) are also supported. More info on the zwo site. https://astronomy-imaging-camera.com/product/asiair-pro

Nice progress. The box looks very deep.

Indeed, LED lighting is a game changer. Where is a good shoot out between filters when you need one?

Have you seen this article by zwo? https://astronomy-imaging-camera.com/tutorials/cooled-asi-camera-setting-in-ascom-driver.html

On paper, Baader filters don't have much of a gap between green and red (sodium and mercury light pollution). Optolong filters (and Astrodon of course) seem better in this respect. If you google "Baader rgb filters" and check the transmission graphs, you'll see. My guess is that they are not very efficient at cutting out light pollution. Otoh, I have found that rgb imaging in general is less sensitive to lp than osc. (That is with zwo filters, which only have a slightly wider gap between red and green than Baader.) 4.5 nm filters block more lp than 8.5 nm filters, but I have also heard that Baader Oiii can suffer from reflections. Some people have no problems, other do.

Many people interpret this graph as meaning that there is a large decrease in dark current going from 15 to 0 C, but hardly any decrease going from 0 to - 15 C. While we both know that the dark current keeps on decreasing in the same manner. A log scale would have been better, imo.

The graph is misleading. It seems to me that dark current halves every 7 degrees or so. It may well keep doing so beyond - 5 C, but the graph won't show that properly. Your remark about frosting is very relevant, though.

As long as you limit it to electronic sensors (essentially, no wind sensors), it's really easy. The bme280 (temp, pressure, humidity) , MLX90614 (clouds) and tsl2591 (sqm) are all i2c devices. You just need those, an mcu (again, the esp32 adds wifi, web server, cloud data logging), a lens for the tsl2591 and a box.