wimvb

Christmas bell. Merry Christmas and a happy new year with fewer clouds.

Merry christmas to you too. This is a real gem.

Great iamge, Rodd. Here's a trick I just picked up that can help boost colour saturation in the galaxy, using PixInsight Clone the image and call it "small_structure" Use MLT to remove the residual layer, leaving only the lowest 8 wavelet layers. You may need to experiment with the number of layers. Use pixelmath to create a new image called "large_structure": original - small_structure. Do not use the rescale option Use the colour saturation tool (c-curve) in CurvesTransformation to increase the saturation of the large_structure image Rebuild the image using pixelmath: large_structure + small_structure. Now, use rescale result and create a new image Lower the background level of the new image a little to make the galaxy 'pop' (I usually go down to 0.07 in background value for galaxies) Hope this helps

Pixinsight has a process/script called hdr composition. Try that. Otherwise the integration process just calculates the average of all the subs. Btw, the vertical lines can be removed with CBR, canon banding reduction. Fastrotate 90 deg CBR Fastrotate back

How and when in the process did you mix the short an long exposures?

If you use 10 s exposures with your Canon, I think your subs are underexposed. The lines/bands are a typical read pattern of a dslr sensor. Flats should be as neutral as possible, but PI can handle a colour cast caused by the calibration process. Post processing will take care of this. It will be corrected during backgound neutralization. Personally I would try to avoid doing any processing on calibration frames, other than calibration and integration.

Next you could check your dark master, but this is also a likely candidate: If the problem persists, it's vey likely something in the calibration process, but otherwise atmospheric conditions could be to blame. Are all subs affected equally, or are some subs worse than others?

Yes, I currently use one of those with an ESP32 module. They're easy to use, but you won't have humidity measurements. BME280 are cheap on Amazon, and just as easy to work with. They need two data lines, as opposed to just one for the DHT module.

Great image. I had to look it up, it's an unusual target.

Is there a risk that the fork itself may flex?

Sorry, I assumed the camera without the filter wheel was an OSC camera.

Your master flat is not neutral, which means that it introduces the opposite colour to your light frames. Eg, if the flat frame has RGB values 0.25, 0.5, 0.5 (scale 0 .. 1), the calibration routine will divide: (Light_R - Dark_R)/0.25 (Light_G - Dark_G)/0.5 (Light_B - Dark_B)/0.5 This will give a higher Red signal in the calibrated light frame than Green and Blue. Things to consider Try to create neutral flats. I believe that EL panels can result in non neutral flats Make sure you do the calibration before deBayering (ie, calibraton frames should not be deBayered, only lights just before star alignment) Create proper darks for flat calibration

If you suspect the calibration process of the master flat, try calibrating one flat frame with the master flat, and the master flat dark. This should give a completely flat flat. I guess that this means that the originals are NOT 8 bit, and that lights and calibration frames are all the same bit depth.

The intermediate step between manual focus (even when using the APT metrics) and autofocus, would be a motorized focuser with hand set. I have found that on my SW Newtonian, focus can shift when I lock the manual focuser. But as long as a motorized focuser is powered, the stall torque will keep focus position, so there is no need to lock focus. A motorized focuser also causes less problems with vibrations during focusing.

Here are James' and my solutions to the protection problem:

As far as I know it isn't, but the math behind it isn't straight forward, because the quality of the final image is not only determined by single sub exposure time, gain, and number of subs. At low gain, a CMOS camera has a higher dynamic range than at high gain. When you stack multiple images that have low dynamic range, you increase the dynamic range again. The advantage of high gain is that you can use shorter single sub exposures. During stacking you can then exclude images that have star trails, satellite trails, passing clouds, etc. Also if you use short enough exposures, you may get away with not guiding. Generally the better astrophotographs have long and similar total integration times, regardless of which gain setting and sub exposure time was used. ZWO wrote this in their blog: https://astronomy-imaging-camera.com/tutorials/cooled-asi-camera-setting-in-ascom-driver.html I do most of my imaging at low gain, below unity, and 120 - 240 seconds (the shorter time for L, the longer time for RGB). My camera has a somewhat high read noise (compared to other ZWO cameras), and I like to image at high dynamic range.

The original Mesu design perhaps 😋 : http://www.astro-imaging.com/Equipment.html http://www.sternwarte-hattingen.de/hatt/hatt2010.htm (scroll down to the 10th image) @Gina: if you put the DEC wheel on the side with the colour camera, won't that give you a better weight distribution? Also, which parts will be in metal and which will be 3D printed? I wonder where material stiffness is most critical.

With the Raspberry Pi, you will also need a power adapter and a micro SD card. You then need to install the software on the SD card. I believe that the astroberry site has all the information you need. https://www.astroberry.io/ The StellarMate is sold as a hardware/software bundle or as software only (if you have a Raspberry Pi) https://www.stellarmate.com/ As an alternative, you can install INDI and Ekos/Kstars from scratch on a Raspberry Pi. This is straight forward, but requires some basic knowledge of Linux. Astroberry and StellarMate are easier.

How about the BME280? You will get humidity, temperature and pressure from one device. It uses I2C which is quite straight forward to set up with Arduino

Nr 1 for me too. After all, it's a VEIL, it's supposed to be thin imo.

Those must be cheap in your neck of the woods. Over here a barebones nuc with zero storage costs about the same as an asiair v1. And then you still need to configure that nuc and get all the software. If I didn't have a working Ekos/Kstars solution, I'd definitely go for either this or the StellarMate. The real downside of asiair imo, is that it's locked to only zwo and dslr cameras.

I read on the agena astro site that the 12 v outputs can handle up to 3 A each (10 A max, total), and some are pwm controlled = can be used for dew heaters. That should be enough for the eaf and camera power. I just wonder how much heat will be generated if you run both the sbc and the power outputs at full capacity.

That's not going to happen anytime soon. The next version you'd have to pay for is 2.0. The newest version is 1.8.8, while I bought 1.8.4. Version 2.0 isn't even on the drawing board yet. Pixinsight is cheaper. Otoh, if you do daytime photography, PS clearly is the better choice.

The Liverpool telescope is. And on a high mountain top above the clouds. And with a pixel scale of 0.3"/pixel. So

That argument is one of the reasons why I bought Pixinsight some three years ago. It has so far saved me roughly 200 €. Pay once, cry once. But I agree on the rest.