AMcD

It looks like it was indeed a stacking error by the PixInsight WBPP script. DSS stacked it without producing the artefact. I am going to try and do a manual pre-processing of the data in PixInsight, as I think the good bits of the result that WBPP did manage to produce are better than that produced by DSS. In particular, local normalisation appears to have done a better job of removing the gradient that runs bottom left to top right in the stack...

I did, and there is nothing like that in them. I had worried about the top of the observatory wall as the target gets quite low towards the end of the night but all of the frames look clean. On closer inspection of the master light I think I can see a matrix at the border between the properly integrated data and the black strip. I wonder if something went wrong with local normalisation or drizzle. I am trying the stack in DSS now to see if I can reproduce the artefact.

PixInsight has just finished stacking 282 120s luminance integrations on the Iris Nebula from my QHY268M and has produced the master frame below. I used local normalisation and x2 drizzle (which is why the stack took 17hours!!!). The single subs and my master flat, master dark and master flat dark seem fine (also attached), with no apparent areas on the bottom of those frames that could have caused the issue seen on the master frame. Does anyone have any idea what has caused this?

How does this new RC software fit together with the other Russell Croman products? For example, does BlurXTerminator negate the need for NoiseXTerminator? I suspect not, as it would appear they are directed at different issues.

I dismantled the mount this morning and my initial suspicion was confirmed. The worm was slipping in the coupler. The coupler set screws had become loose as the worm / screws had shrunk in the cold. All working again now 🙂

Amen to that 😂

I went out to check the mount when I got back from work. The DEC worm was immovable until I ran a hair dryer over the DEC axis, after which it began to loosen. I guess the grease has become very sticky in the extreme cold. I plan to reset the seating of the DEC worm tomorrow and will look to clean and re-grease the mount this summer. @Xsubmariner, what lubricant do you use. It is interesting that everyone is having issues with the DEC axis but not the RA 🤔

Yes, I suspect that this could be my problem. Over the summer, I installed one piece worm blocks that allow fine adjustment of the backlash and, like you, adjusted it carefully. It will be interesting to see what happens when the temperature improves. I suspect we do not know what 'cold' means compared to where you are 🙂

I wonder whether contraction of the metal parts was my issue. The DEC motor continued to respond to commands but the DEC axis did not move. In the circumstances, I wonder whether a set screw shrunk sufficiently to loosen the connection between the motor and the worm shaft such that worm shaft was slipping within the connector.

Having lost an entire night of imaging last night to a faulty DEC axis, I have decided that there are three cardinal rules governing remote operation of a home observatory whilst working away: 1. Something will go wrong at some point. 2. Because we use our equipment on clear nights, it will always go wrong on a clear night. 3. If it goes wrong, there is nothing that can be done about it until the weekend. Ce la vie 🙂

I am away from work and have just tried to start a remote imaging session with my observatory at home. It has been below zero for a number of days now and I find that the DEC axis on my Losmandy G11 is not moving. This would ordinarily be infuriating given it is a perfect night for imaging, but happily I have just been to the Christmas party at work so I am much more relaxed about it now. I am left wondering whether the DEC problem has been caused by the extended cold. I will investigate when I get back home tomorrow. I will also have to buy a thank you gift for my lovely wife as I also had to break my promise never to send her to the bottom of the garden to investigate what was wrong 😂

Cracking tip Olly, thank you. I have a copy of Registar, and other software that can register. I will give it a try.

As I understand it, it is important to subtract a flat dark frame (i.e., a dark frame that is the same length, temperature, gain etc. as your flat frame) from the flat frame before the flat frame is applied to calibrate the light frame. Otherwise, there is a risk that the flat frame will not work. Flat darks appear to be preferred for this purpose to bias frames for CMOS cameras, although there are those who have equal success calibrating their flat frames with bias frames on a CMOS camera. As with all these things, some people produce amazing pictures without using the 'standard' procedure and some produce amazing pictures using their own, idiosyncratic, methodologies. I think the best approach is what works for the individual, which can best be established by experimentation.

I have been having an infuriating time with flats overcorrection on my Ha frames. Having spent the weekend trawling the forums for solutions I set out below what I have learnt, in case it is any use. I am still working my way through the suggested fixes. Others more than experienced than I may have views on the accuracy of some of this, but appeared to be a pretty consistent view across SGL, CN and Astrobin regarding the problem and potential solutions: Potential Causes: A failure to bias subtract or flat-dark subtract the flat frames. Differential temperature and / or gain between the frames. Differential offsets between the frames. Using bias frames with a CMOS camera rather than flat darks. Variability in temperature of CMOS chip when taking very short flat frames. Differential vignetting profile in the flats and the lights. Brightness / distance of flat light source. ADU of flats not in linear range of camera. Light leak resulting in light in the flats that does not come from objective lens of the telescope. Reflecting parts (e.g. extension tubes) in the optical train. Solutions (root cause): Ensure flat frames are bias or flat dark subtracted. Do not use bias frames for CMOS cameras, just dark flat frames. Use frames all at same temperature, gain and offset. Increase / decrease ADU to ensure it is in linear range of camera. For CMOS cameras ‘flush’ the chip by adding a delay of 15s between flat exposures, especially where flat exposures are very short. Do not change system elements / orientation between lights and flat frame acquisition. Adjust brightness / distance of flat light source. For CMOS take flats of at least 3-5 seconds to ensure linear data. check for light leaks. Check for internal reflections and light leaks. Solutions (mathematical): Add a pedestal in PixInsight WBPP (for example 10 or use Auto). Add a pedestal to the master flat using PixelMath with the formula $T+0.xx with a constant value, for example 0.43. Subtract a fixed value from flats to apply an offset to the flats. For flats with a very high dynamic range, measure the contrasts by taking values manually on the flat, at the center and at one of the darkest corner and the same areas in a Light. Derive the contrast ratio in both images and computed the ratio between them . Then, with Pixelmath, tweak the contrast using (MasterFlat - mean(MasterFlat))/(2*1.7) + mean(MasterFlat).

I have a HUNSN industrial mini-PC permanently installed in my observatory and that has shown no sign of problems, or reduction in speed during this latest cold snap. However, when I went into the observatory yesterday morning, I found that the very old flat screen monitor that I have in there for when I need to do maintenance or configuration on the system had cracked, causing the liquid crystal to leak across the screen 😳

Many thanks @sharkmelley, my wife will be delighted! No chance though of wrapping Schedar in exhaust tape or slapping on some exhaust paint 😂 I think @wimvb nice idea of a shroud is also out.

The optimism displayed by you both @Xsubmariner and @tomato regarding my negotiating powers is most kind, but entirely misplaced😂. I suspect the shiny chrome of the stack is going to be declared off limits DIY wise. I have in mind a tall matt black board that can be mounted on the outside of the observatory to screen the stack on those few moonlit nights when I image at the particular orientation that results in the artefact.

The smokestack gets unbelievably hot. I think the flock tape would bend whether it liked it or not - right before it caught fire 😂

That is going to require a considerable amount of negotiation with my better half 🤭

Life is full of compromises. The quid pro quo for my spending time and money automating my observatory during lockdown was agreement to the installation in the garden of a wood fired hot tub from Sweden. For the past number of clear nights, I have been gathering hours of data on the Pac Man Nebula. Imagine my dismay when I finally got round to examining the integrations (yes, I should have checked earlier) and found this... After scratching my head for a number of days as to what the rather prominent artefact at bottom left could be, I finally identified the culprit. As the full moon has been rising it has been reflected beautifully in the chrome chimney of the bloody hot tub... As can be seen from the warm orange glow on the scope, I already have to contend with an old sodium streetlight that shines directly onto the observatory and which the council stubbornly refuse to convert to something downlit and LED 😠 Interestingly, the artefact only appears when the scope is at a certain orientation to the smokestack of the hot tub. I have now moved to shooting the Iris Nebula in LRGB and the artefact has gone... The moral of the story is: don't put the hot tub next to the observatory... 😂. The next question is whether I can process out the artefact from my hours of data?

I have been experimenting with adding Ha to my LRGB imaging of IC396, using the method whereby the red signal is removed from the Ha image using Pixelmath prior to combining the Ha with the red channel ahead of building the LRGB image. This image comprises approximately 16 hours comprising 4 hours each of LRGB, and 6 hours of Ha taken with my QHY268M attached to my TS Optics130 Triplet APO mounted on a Losmandy G11. I am not sure what the Ha has added to the image really but include the original LRGB for comparison. I think I prefer the LRGB to the LR(Ha)GB as more natural looking. I am at present doing a project on small nebula (the Pacman Nebula and Lower's Nebula), so will try and refine this method on those images. LR(Ha)GB: LRGB:

This is my take on IC1396 taken with my QHY268M and TS Photo Line 130 Triplet Apo on Losmandy G11. The data was gathered on 12-13, 14, 18 and 20 November 2023. L, R, G and B approximately 4 hours each of 120s integrations for a total of approximately 16 hours. Processed in Pix Insight and Photoshop.

I have often wondered whether they could design what might be called a 'filter cube' for the RASAs, at least for narrowband. This would be a cube with openings for the light path at the front and back and enclosing a cylinder mounted across and rotating within the light path. The three narrowband filters would be mounted on the circumference of the cylinder with a hole opposite. As the cylinder rotated, the filter and its corresponding hole would enter the light path. The profile of such a gizmo would certainly be smaller than the filter wheel. Just musing over my lunch...

Thank you for your kind words. Yes, I have a TS Optics 2.5” Field Flattener on the TS130. No h-alpha used in this image. I am going to try integrating some h-alpha into the red channel on my next target - if the clouds ever clear!

Over the past six months I have been upgrading my equipment. I have replaced my QHY8 with a QHY268M and have replaced my TS Optics 152 Individual achromat with a second-hand TS Optics 130 Photo Line Triplet APO mounted on my Losmandy G11 reconditioned with high torque motors and one-piece worm blocks. This is the product of my first proper project with this set up. The image represents approximately 16 hours of integrations comprising 4 hours each of L, R, G and B under Bortle 5 skies. The integrations were acquired using SGPro, calibrated, stacked and processed in PixInsight and finished in Photoshop. I had some problems with my flats, particularly on the R, G and B channels but, overall, I am quite pleased. Constructive criticism always welcome 😀