wimvb

The background looks much better now. A good thing about digital astrophotography is that once you've collected the data, you're no longer dependent on the weather. Images can be reprocessed at any time. And as you learn new methods, you can revisit old data. Have fun.

The first image is suspicious. What would the physical reason be for a hole in ifn just where a galaxy is situated, and that hole being symmetrical as well? The second image does show some background variation, but I can't completely match it with the background in your image. If you want to pursue this, this reference will come in handy. http://www.aicccd.com/archive/aic2005/The_unexplored_nebula_project-smandel.pdf There is no reason to assume that IFN is only limited to the polar region around M81 and Polaris. But the reference pdf shows that IFN varies a lot in intensity across the sky globe. That is probably why it has not been picked up regularly before other than near Ursa Major.

I stretched the living daylights out of the tiffs you provided, and this is what I came up with Process: crop to remove any stacking artefacts DBE with the minimum number of samples to get rid of vignetting. Sample size 35, one sample in each corner, one sample on each edge, one sample in the middle, and one sample midway from each corner to the centre. No samples anywhere near a galaxy or larger star. Layer 1 removed (1 pixel information) to reduce the noise Histogram stretch MS HDR compression to get some details in the galaxies, to keep the image pleasing) Further stretch resample 50% saved as jpeg I think that the dark patch immediately next to M95 (?, right) is a dust bunny, as is the dark circular pattern midway but somewhat lower than the galaxies. The slightly brighter area below and to the left of M96 (left) may be a real dust cloud.

Quite easy in pixinsight. Create an image container with the 89 subs. Make sure that the target directory is set, and that you DON'T overwrite the images. Then apply the resample process to this container.

Now that you have multiple mounts, you can always put the sct on the eq8 next to your obsy. Assuming you have the eq8 tripod as well.

I've read several posts (not just this forum) about power issues with qhy cameras. Check your power supply and cables. Keep data and power cables well separated. Also, try changing to another usb port.

Time to make your transition to PI complete. http://pixinsight.com.ar/en/info/processing-examples/28/maskedstretch-stars-sores.html

I think that that is part of the reason. The larger central obstruction (secondary and hole in the primary) pushes more light out to the edge of the diffraction pattern. And if bright stars are overexposed, the brightness will be further out. This seems to be the major reason here, since there is detail in the galaxy (not overexposed), but the stars are fat (pverexposed). Another reason is that the fl gives a much smaller field of view with any given camera (here the Atik 460), and if that field is stretched across a computer screen, then stars will look bigger. Further, the longer fl demands more of guiding. If you can guide 0.5" RMS when you image at 1.2" (1 m with 5.86 um pixels, my camera and scope combo), you're doing fine. But if you get the same guiding RMS when you image at quadruple the fl (3.9 m combined with 4.54 um pixels, that's roughly 0.23"), then you will see fatter stars. I would actually use the same technique as proposed in other threads by @ollypenrice: stretch one layer (image) for detail in the galaxy and another layer (image) for stars. Then combine the images with a mask. In PixInsight one would use masked stretch for the second image, and pixelmath to combine.

I can relate to that. I've never been able to image the Orion neb properly, due to either houses or trees being in the line of sight. The trees are nowadays my own. I may remedy that problem some day. With a chain saw. Good luck.

They are a so called Moiré pattern, caused by pixels on the screen interfering with pixels in the imaging camera that was used to photograph the screen. That pattern is not part of the problem. It's just the stars that are the problem, as I understand it.

As far as I know, that telescope is a planewave 0.7 m located at 6800 m in a US national park. In astrophotography the same mantra applies as real estate: it's all about location, location, and location. And size. But you're right of course, there is a limit to what any imaging setup can achieve. I believe that a few years ago, when low read noise cmos where starting to emerge, we discussed on this forum the use of small sensors with small pixels and photographic lenses as an alternative to telescopes and ccd cameras. As technology advances, the rules of astrophotography are constantly being rewritten. But we will always be banging our heads against solid limitations; "aperture limits optical resolving power" being one of them.

We've had our fair share of snow, but most of it has melted by now (already). Otoh, we may have more of the stuff until Easter.

Very nice image, Nigel. You definitely got a lot more detail in the main galaxy and its small neighbour than I have. That's the advantage of a much larger fl and aperture. But ultimately, I think it's the European skies that work against us. When I discussed possible candidates for my scope update, Göran first suggested the EdgeHD 8 and MN190, while I was contemplating an astrograph like TS 10" ONTC or Lacertas 10" Newton reflector. But at about the same time, I grew tired of star spikes, and finally I chose the MN190. Regarding the background in your image: the small scale noise looks like it's from deconvolution. You can avoid it by either using a strong mask, or by increasing the regularisation parameters slightly (especially the value for layer 1). I always spend quite some time tweaking the settings. The colour mottle can be killed by MultiscaleMedianTransformation on chrominance, with a 50% mask (applied inverted)

It's common in pixinsight to get miscoloured cores if you use masked stretch or arcsinh stretch. The remedy is to use the hsv repair script before stretching. The cores are a result from the colour calibration routines, I believe. Normal stretching isn't affected by it, because the cores will be saturated by the stretch.

Thanks. I platesolved the image, but the solver missed the rather obvious one right next to the main target. Here's the solved and annotated version (click to enlarge).