sharkmelley

Generally speaking if the artifact appears purple when white balancing has been applied (e.g. in the in-camera JPG) then the cause is an IR leak. The question is whether the IR source is inside the camera or the inside the lens. For the Canon 6D, if you have the camera live-view switched off then the lens is the most likely origin of the IR. Mark

That would appear to be consistent with an IR source internal to the lens.

Without seeing example pictures it is impossible to diagnose. But many lenses do have an internal IR LED that leaks IR light: https://www.infraredcameraconversions.co.uk/copy-of-tamron-lenses https://kolarivision.com/canon-mirrorless-rf-lens-internal-infrared-led-fact-or-fiction/ Mark

Finally I obtained a result I'm pleased with from stacking those 60 one-minute subs: Mark

Stunning result! You have a perfect mix of fast optics and dark skies. In my opinion that's cometary heaven! Mark

Here's a single exposure captured at 20-Jan-2023 04:40GMT Unmodified Canon EOS R on Tak Epsilon 180ED. 60sec exposure at ISO 1600 with sky brightness SQM 20.98 (Bortle 4)

It certainly isn't a waste of time! If it's a fast lens (such as f/2.8) then even better. Mark

Hi Peter, That's a great image and excellently processed. The Tak Epsilon 180ED and ZWO ASI2400MC Pro form a great combination. Even better with dark skies! Mark

I set the alarm clock early, so here's a single exposure captured at 18-Jan-2023 03:40UT Unmodified Canon EOS R on Tak Epsilon 180ED. 60sec exposure at ISO 1600 with sky brightness SQM 20.96 (Bortle 4) I have 60 similar exposures to stack, when I get the time. Mark

Agreed. On the bright arm of M51 nearest to NGC1595 there are also squiggly bright artifacts. Once you start seeing them, you can't unsee them. In my opinion, for this data and for the settings used, BXT has created structural artefacts that are not present in the HST image.

The reason for the offset is to ensure that the values coming from ADC are unbiased, given that the ADC has read noise. Suppose the offset is 100 and the pixels have received no light. The ADC will report some pixels as 100, some as below 100 and some as above 100, all because of the read noise. But the average is exactly 100, which is the correct (i.e. unbiased) value for a pixel that has received no light. Now suppose the offset is zero and again the pixels have received no light. The ADC will report some pixels as 0 and some above 0 but it cannot report values below zero because the ADC does not produce negative values. Therefore, the average ADC value will be greater than 0 which means the ADC is giving a biased estimate of the true value. This would cause all sorts of problems for low light imaging. Mark

Relax, I'm pretty certain this is not caused by the hot tub chimney! Instead, it is more likely an artifact generated by the bright star Schedar, outside the field of view. Alnitak, near the Horsehead, is another star that typically causes this type of problem. Mark

I would not expect gradient removal to clip the data. But it's easy to test for yourself if gradient removal is causing the problem!

CMOS sensors don't have an ADC at each pixel site. There's no room to do so! The ADCs are sited away from the light sensitive area of the sensor and typically there will be one ADC per row or column or one ADC per group of rows or columns. It's a misconception that the discrete values coming from the ADU somehow cause image banding. The discrete values (quantisation) can only be seen in the background noise (read noise and/or shot noise) and this noise prevents any banding in the image. The only way that banding (posterisation) can be made to appear in the data is by faulty post-processing e.g. reducing the bit depth too early. Mark

The spikes on the left of the histogram are where data values have been clipped at some stage in your processing. So you end up with many pixels having the identical (clipped) value. Mark

Did you take your darks with the same software as your lights? FITS files can be stored in a "top-down" or "bottom-up" row order and different software might store them differently. Mark

Or could it be the camera window?

Just to be clear here, in case there is any remaining confusion. There are IR pass filters and there are IR blocking filters. For astrophotography, an IR PASS filter is only useful for planetary and lunar imaging where you don't want any colour information from the visible spectrum. An IR BLOCKING filter (or IR/UV blocking filter) is what you need for DSO imaging. Mark

It looks like a false colour "Hubble Palette" image produced with 3 different narrowband filters (SII, H-alpha, OIII) which are then combined, one filter for each colour channel. Although it is possible to do this with a full-spectrum DSLR, it is not easy because it complicates both the acquisition and the processing. I strongly recommend starting off by taking "normal colour" images with an IR/UV blocking filter on your modified camera.

The Heart Nebula will look red (and not brown) using a H-alpha mod or using an IR/UV blocking filter with a full-spectrum mod. Unmodified, it is pinkish-red.

It depends on the adaptor you are using. Some are designed to accept 1.25" or 2" filters but other adaptors cannot accept filters. You need to check what adaptor you have.

You won't go far wrong with the Astronomik L-2 filter - it's the one I use. But there are many other alternatives.

Baader, Astronomik and many other manufacturers of astro-accessories produce a range of IR/UV blocking filters in different sizes, including clip-in filters.

The larger ellipses (up/down/left/right) are caused by microlens diffraction, sometimes erroneously called microlensing. It's a property of the sensor and many dedicated astro-cameras have the same problem. There's really nothing you can do to prevent it.

Yes, you should use an IR cut filter (or IR/UV cut filter) designed for astronomical imaging. They still allow all the H-alpha to reach the sensor, which is the point of the modification.