symmetal

I thought I'd have a go at this as something different. 🙂 This is after 5 hours of LRGB with an FLT98 and ASI6200. It hasn't been stretched all that much to avoid clipping the foreground stars too much. There are many small galaxies in the image though as the ASTAP annotation image shows. The small stretched image shows you where it is as you'll be hard pushed to locate it in the full size image. 😊 The brightest star in the image is HIP 74605, magnitude 5.15 It wasn't discovered until 1955 and is a spheroidal satellite galaxy of the Milky Way containing little to no star formation. It's longest dimension is about half a degree. Alan

Most impressive gorann. I've taken over 14 hours worth of data on this subject since you last posted it, and my result looks fairly pitiful. My f6.3 FLT98 just isn't fast enough. . Most were taken with a partial moon around which wouldn't have helped, so I'll wait for moonless nights before adding any more. Can't give up now after spending so much time on it. 🙂 Alan

The easiest way to adjust tilt is to make a wooden test jig and get a cheap laser pen as shown in this thread. I wasted many nights trying to adjust tilt by analysing star shapes but got nowhere. 5 mins on the wooden jig and it was easily fixed. Keep the camera, filter wheel and OAG screwed together and place the whole assembly on the test jig. Adjust which ever tilt adjuster is easiest to access. Cost is minimal. 🙂 Alan

I've wondered about that, that as the sky gets darker the stars themselves become the SQM reading limiting factor. The Unihedron has a wide acceptance angle so will always have stars in view. It will be interesting to see what actual sky background SQM values you program will reveal. Your graphs show ASTAP reading slightly lower than Unihedron at 20.00 SQM so I assume if the readings are correct at some darker sky level ASTAP will start to read higher than the Unihedron. Alan

Hi Han, I like the SQM feature. 😊 Last week when there were several clear nights in a row I took a Unihedron SQM meter reading around midnight and it reported 21.20 as far as I can remember. Not sure of the last figure. I've just checked some 60s L subs of M101 I was imaging around that time, near the zenith, and using a dark and flat your program's SQM measurement was 21.21 at 71 deg, which is very impressive. I checked some subs around 03:00 the same night and your program measures 21.89 at an altitude of 78 deg. I didn't think it got that dark here but could be wrong. Next time I'm imaging, (may be a while as next week doesn't look good) I'll note down the Unihedron readings at various times and compare it to subs at the same times and let you know. 🙂 Alan

Looks like I misread the meaning of the original formula, but it does seem to provide a consistant difference though less in comparison to your method. I did your calculations on calibrated subs from my ASI6200 and the background ADU seems to correspond to around 4 x RN which is not too far different to your 5 x RN. I think if perhaps tweaked to taste, the method I use does provide a useful indication of what the results will be when calibrated. 🙂 I was casually treating unwanted signal as noise, but you're right. Alan

I'm confused as to where you are saying your calculated 1156 ADU is actually measured. It seems to be on a calibrated sub which is not quick to determine, having to take a sub and then calibrate it to get the background ADU value. This is not available in the capture program. The method I use just takes the background ADU ( median or mean of sub will be similar for small targets ) from the captured sub itself, readily displayed on any capture program. This is its intention, to be a quick check. This will include the sky background signal, sky background noise, offset, dark noise, and read noise. The 10 * RN^2 ADU value (which includes offset) is when the sky background noise is at least 10 x read noise, which is the same as sky background is at least 10 x read noise^2. There will also be dark noise present in the sky background ADU read, so in reality the sky background measured will actually be greater than 10 x read noise^2. I think 🤔 Read noise is the only one not removed by calibration so as long as the sky background noise is significantly greater than the read noise to make read noise essentially insignificant is what's important. These are really only figures to aim for as a rough guide to avoid unnecessary under or over exposure. Flak jacket donned for vlaiv's reply. 😬 Alan

Ah! I thought on your initial post that 1290 was wrong and 1156 was to be preferred which was what confused me. Read Noise at unity gain I estimated to be 1.75 e- from the ASI1600 graphs. 10 * RN^2 = 10 * 1.75 * 1.75 = 30.6 electrons Convert electrons to ADU by dividing by the gain in e-/ADU which is 1.0 at unity gain 30.6 / 1.0 = 30.6 Offsets. AFAIK, for the 12 and 14 bit Zwo cameras, an offset increase of 1 increases the ADC output by 1. Certainly true for the ASI1600, ASI071, ASI178, and ASI224 which I have. For my 16 bit ASI6200 an offset increase of 1 increases the ADC output by 10. Most likely true for the ASI2600 as well. Add the offset to the above figure to get the actual output from the ASI1600's 12bit ADC for a 10 * RN^2 sky background value. 30.6 + 50 = 80.6 ADU (12 bit) Convert 12bit ADC output value to the actual 16 bit value which the camera outputs by adding 4 zero value LSBits, equivalent to multiplying by 16. 80.6 * 16 = 1289.6 ADU (16 bit) TA DA! 😊 If I use the 1.7e- read noise figure that you read from the graph then the figure becomes 1262 ADU For interest, using a 1.7e- value, working backwards, 1156 = 7.9 * RN^2. On the discussion on the CN forum years ago when the 1600 came out, some advocated 5 * RN^2 as an acceptable value, but 10 seemed to gain most traction. Your value is right between the two. 😁 Alan Edit: Checking your formula vlaiv you don't seem to take the offset used into account so using offset 50, then 800 ADU needs to be added to your 1152 ADU making 1952 ADU the figure to aim for in your case. 🤔

There's no hard and fast rule to use. But the difference between your value and the one I use, that seemed to be widely quoted when CMOS cameras came out is not that significant. 1290 ADU vs 1156 ADU. Using blue, your calculation implies the exposures overall could be reduced to 65% of their current value, while mine implies they could be reduced to 72%. That's not a difference to be concerned about I would have thought, and they are only guidelines after all. If there is some moon about the exposures could be reduced far more to like 25% but that means loads of different sets of darks needed for different sky conditions so is it worth all that hassle. 🙂 Alan

Here's my effort using Startools and ( PS to lift the background). Not so much noise reduction but that's a personal thing. The Spacially Variant PSF Decon has made spots in the bright stars but I used the default mask. I usually just create a second blurred layer in PS and soft edge mask in the blurred version over the star centres Alan

I forgot to add that your darks and flats look fine and the minimum ADU on your darks is around 40 so offset 50 is fine. Flats are nicely centred on the histogram. APP did give me the same warning as you had about flat and flat darks not matching but checking the fits headers I can't see what the problem. I though that APT may have been mis-labeling something but they all look fine. It's worth asking on the APP forum why this is happening. Your optimum sky background ADU for 10 * RN^2 is 1290, Your subs are on average L 1950 ADU R 1960 ADU G 2200 ADU B 1770 ADU The L matches the RGB fairly well so 3 x RGB exposure is correct. You can reduce the overall exposures in proportion, but if you go too far you run the risk of blue going below the optimum as blue is the least sensitive. Personally I would leave them as they are. When you've got more experience you can tinker with them a bit if you wish. Don't try using different exposures for RG and B to match the sky ADU better as it becomes a nightmare, as you need different darks for each colour. 😬 Alan

Brendan, here's my effort with StarTools . The 'Wipe' coped pretty well with the background, but setting the 'gradient fall off' to 75% helped quite a bit too. On Autodev after selecting the bulk of M81 as a ROI, setting 'Ignore Fine Detail' to 2.5 pixels helped avoid accentuating the noise. On 'Color' module using the Star sampling technique gets the colour much closer. I used the default Noise Reduction settings as it didn't seem to overdo things like it sometimes can, and left enough noise to be more realistic. I used Photoshop to raise the background to around RGB 23,23,23 and did slight colour adjustments to taste. All in all, a pretty good result as you didn't have a great number of subs in total. 🙂 In APP, after doing your integration it's bebeficial to show the analytical graphs to see which subs are the worst and can then be removed from another integration. Right click on the file list at the bottom of the screen and select 'sort on quality'. Then right click again and select 'Create Analytical Graph' and on the next screen again select quality. The resultant graph shows your channels sorted best to worst and bad subs show up lower down the graph. The sub numbers refer to the entry in the ordered list at the bottom and you can untick, remove or even delete poor subs to excluse them from another integration. Repeat the above using 'sort on star shape', and then 'sort on SNR' to get graphs corresponding to those traits to see the worst subs again and exclude them if you wish. Then do another integration to see if the result looks better. Alan

I'll have a go with your file later but the main problem is you've overdone the noise reduction which makes the background look too artificial. The default setting in Startools is too strong. Some noise in the image is more realistic and fine noise makes it appear sharper. Also raise the black level in PS or Gimp etc. so it;s not so dark which will help reduce the background noise blockiness anyway and give a more pleasing image. Alan

Brendan, I'll process your files later with APP and Startools to see how I get on. You've applied far too much saturation in your postings though that may have been to indicate the colourd patches. Alan

When you load your image files instead of clicking the channel they correspond to just have the 'apply filter Header tag...' box ticked as shown below. It will then assign the files to the correct channel depending on the information stored in the fits file header. This is quickest if all your lights are in the same folder, all the flats are in another folder, so one click will load all the lights selected, another click loads all the flats selected. For darks they still have to be assigned to the relevent colour channels as you've been doing as there's nothing in the fits header that says which channels they will correspond to. Dark flats will auto allocate if there is sufficient fits header info. I also use master flats, darks, and flat darks previously created with APP and the master flat darks fits headers are labelled such that they can be auto sorted to channels. You can have all your lights, flats, and possibly flat darks in the same folder and APP will assign them all with a 'select all' and a load click, but this can be a bit awkward to manage and keep track of what's what. Thinking about it, although I haven't tried it, it may also be possible for darks to be auto assigned too, if the exposure info in the darks fits header can be matched to the exposure info in the lights. Whether APP does this I don't know. Will have to try. Alan

I always create the masters separately as I reuse the flats many times until new dust spots become noticeable so haven't come across this issue. When you receive this error it's worth checking the file listing at the bottom of the APP screen to confirm that the correct flat darks have been assigned to the correct flats, (and in the correct session if multiple sessions are being integrated). I use the automatic assignment feature of APP when loading files, which requires the frame type and filter to be correctly identified in the fits file header. In the past I've taken flats while mistakingly labeling them as lights in the capture program, so requiring manual assignment in APP. As your integrations work some times and produce the error on others, I can only think that the assignments are different. I assume all the APP integration options are the same each time. I find it a bit annoying that default option settings are applied each time you start APP and any different options you want have to be set every time. Also the working folder has to be changed from 'Documents' every time. Alan

Brendan, The latest Ascom drivers by default have offset 50 for all gain settings on the 1600MM-Cool which you can override by clicking the 'Advanced' button. I would recommend using that rather than 21 which was the setting on the original drivers for unity gain. You need an offset value large enough to avoid any black clipped pixels on your images. Normally a bias frame will tell you this as normally the bias will give the lowest ADU values and longer exposures will always have higher ADU than bias frames. On the newer ASI cameras this seems to be the case, and with them having no amp glow, bias can be used as darks. I still take darks on my ASI6200 as habit but I've done comparisons using bias as darks and can't see any difference in the results. As mentioned, the 1600 and some other earlier cameras internally process short exposures differently. At unity gain, offset 21, a bias frame probably won't show any black clipping but exposures over a second probably will. Hence why the later drivers from ASI have 50 as the default offset for all gain settings. I use 2 sec darks as test frames and found I had to increase the offset to 64 to totally eliminate any black clipped pixels. I believe vlaiv has his ASI1600 offset set to 72 for the same reason. Take some darks around 2 seconds and examine them for black pixels. Fits Liberator is good for this. The histogram shows the range of ADU values in the image and the latest version of the program will also highlight black and white clipped pixels. If at offset 21 there are no black clipped pixels and the minimum value on the histogram display is at least 50 then by all means use offset 21. 🙂 For previewing fits files quickly I use Nebulosity. It has a nice 'Preview Files' option. The trial version won't let you save images but for previewing that shouldn't matter. I did purchase it many years ago when there were few capture/process programs around but I now mainly use it for previewing fits files. 🙂 Alan

That's a good point. I was wondering why the gradients changed so quickly over certain areas, particularly on the RGB stacks. Alan

Brendan, Running your fully stacked LRGB images through Startools produced the same results as you had, terrible colour patches which changed dramatically depending on how much cropping was applied, but couldn't be eliminated. The 10 sub samples you posted yesterday were much better in that respect so I think you need to check your subs individually and discard any that look bad before stacking them. You possibly had clouds passing through or haze and moon affecting some of them. Your 10 sample subs you provided just exhibited a small gradient which 'Wipe' corrected well. I loaded your full stacks into ASTAP as a preview and here's a composite of then given similar stretches. They are very different to each other and the colour channels have very different complicated gradients and blocky dark artifacts. I think that Startools Wipe just doesn't know what to do as there are no areas where a 'reference' background can be determined for the Wipe to work on. There is no standard scope vignetting and no visible dust spots so I don't think your flats are a problem in that respect though if you used short exposures for the flats the flats probably added some noise which hasn't helped. Given the total integration time the colour channels in particular are very noisy too. The short colour exposures haven't helped here. I think the charts you linked to giving exposure lengths are for luminance exposures only as they seem about right for L. For RGB only roughly a third of the light reaches the sensor compared to L so 3 times longer RGB exposure is required to achieve similar sky background ADU levels. You used half unity gain too which hasn't helped. Personally I can't see the point of using less than unity gain as you are just throwing away photons. At unity gain (139) one photon received registers 1 ADU (12 bit) on the camera. At half unity (75) two photons need to be received to register 1 ADU, so you are effectively throwing away every other photon received. At gain 75, offset 21, the 10* RN^2 sky background ADU level to swamp the read noise is 723 ADU (16 bit) as shown below. Your RGB background ADU levels are well below this so read noise is noticeably adding to every sub. Increasing your RGB exposures by three will bring the background ADU up to between 900 and 1100 depending on the colour which is higher than the 723 ADU on the chart but not enough to worry about for the moment. What bortle skies do you have? I suggest unity gain (139) and offset 50 for your next outing. Try some test subs using 60 sec L and 180 sec RGB (when there is no moon) and view the image statistics or move your mouse over the sky background in your images and see what the ADU values are. 1290 ADU is the calculated 'magic' value I would use for read noise swamping. If they are closer to 2000 or higher on all channels then you could reduce the exposures but I would always keep the RGB exposures 3 times longer than your L. Once the read noise is effectively swamped by the sky background then there is no difference in SNR between say 1 exposure of 10 mins, or a stack of 10 exposures of 1 min. The 1 min exposures won't have such clipped stars so the stack will be better. Your darks look good. Your average value is 1/200 of peak white. Mine are 1/75 of peak white as I use a higher offset so are much 'brighter' than yours. The dark flats and flats look good too. As I mentioned there is no noticeable vignetting or dust spots on your stacks so the flats are doing their job. Just retake then using longer exposures (around 2 seconds) to make their noise profiles match your lights for better calibration. I think that covers it Brendon. 🙂 Alan

Brendan, I stacked your files in Astro Pixel Processor and loaded the results into Startools. Flats have worked well. I've cropped a lot less than you have as shown. I couldn't get a useable stretch with AutoDev as the image is very noisy and the selected area on the DSO very small, so I used FilmDev for a quick stretch until the background noise became too noticeable. As a result you can see that the DSO is itself quite dim but there are no coloured patches. Your posted images are significantly overstretched by AutoDev so any slight colour errors are being exaggerated though not sure why they are as localised as in your first image. Startools 'Crop' selection just to avoid any stacking artifacts. No vignetting or dust spots so your flats work fine. 'Wipe' Luminance result is good. Bright star top left causing some flaring. 'Wipe' RGB result is good too with no significant coloured patches. Result from 'Colour' module after 'FilmDev' stretch. I could have stretched it a bit more seeing the final result, but the background noise would start to dominate. You need longer RGB exposures and many more of them too including Luminance. At a minimum I go for 60 Luminance of 60s, and 20 each of RG and B of 180s, giving 1 hour total each of LRG and B. Then add more luminance exposures, (and sometimes more RG and B ) until the background noise is acceptable. I made this chart many years ago when the 1600 came out to get optimum exposure values so that the camera read noise is swamped by the sky background and so doesn't contribute to the final result to any significant degree. The 10 x RN^2 column is the one I use for a suitable sky background ADU value. I don't know what gain you used but when starting out, unity gain is recommended. When it first came out using variable offset with gain was suggested, used to maximize the dynamic range but this is a real pain and it was generally decided to use a fixed offset to cope with any gain setting but avoiding black clipping in the image. 50 was the generally accepted value though I used 64 in the end as 50 still gave some black clipping in the images. Also for the 1600 use flat and dark flat exposures of at least 2 seconds or more to avoid the different camera internal dark processing for short exposures, meaning short flats and dark flats of a second or less will have the wrong noise profile to calibrate your long exposure images correctly. This means having many sheets of paper in front of the scope for flats to get long exposures. Your Luminance subs have a median ADU (sky background level) of 1800 ADU which seems reasonable, but your R,G and B subs median ADUs are 608, 624, and 528 which are much too low. As a rule your RGB exposures should be 3 times the duration of your Luminance exposures to achieve the same sky background ADU level and so swamp the read noise the same. Using an offset of 50, 800ADU is added by the offset alone (50 x 16, converting 12bit to 16 bit) so any image taken should be around 750 to 800ADU or so at a minimum, depending on its internal ADC (Analogue to Digital Converter) setup. Let me know what gain and offset you're using and are your RGB gain/offset settings different to L, so giving such low image background ADU values. My 1600 flat darks subs have a median ADU of around 860 ADU at offset 50. Hope this helps. 🙂 Alan

Brendan, Are you using Startools for processing? This is a typical effect of not cropping off the stacking artifacts from around the edge of the frame, before using the 'Wipe' tool. Alan

The old Eumetcast channel names stopped being used on 22 March, and the ini update matches the new names to the old download locations so your MSG Data Manager keeps working. EUMETCastView will process pretty much any geo-stationary and polar orbiting satellites. It's not so easy to use as MSG Data Manager and takes a bit of learning but is worth it. Currently I believe you're subscribed to polar orbiting Global Metop AVHRR data (now on E1B-EPS-10) and the regional (Europe) Metop and NOAA AVHRR data (now on E1B-RDS-1) You can on the Basic service also subscribe to (Geostationary satellites) Meteosat IODC SEVIRI, the same data type as your currently receiving but centred over the Indian Ocean Russia's Electro-L N3 China's Fengyun-2 (Polar Orbiting) NOAA-20 VIIRS which should keep you busy. 🙂 Alan

Thanks Ian, I use EUMETCastView to display the data. It's free to download. 🙂 It'll also display many other satellite image formats. You'll need to subscribe to GDS-SNPP/NOAA-20: VIIRS EDR RDS-EARS: VIIRS on the Eumetsat EO-Portal and they appear on channels, E1B-RDS-1 and E1H-RDS-2. If you only receive the Basic service you'll get RDS-1. For RDS-2 on the HVS-1 service you may need a larger dish. 😉 Here's another NOAA-20 VIIRS image mapping three of the different IR channels to RGB. This pass is at 01:44 UTC on 21 Mar. Clouds and land mass at night show up very well. Much better than the AVHRR channels which are intended for daytime use. Alan

I recently subscribed to receive VIIRS (Visible Infrared Imaging Radiometer Suite) NOAA-20 and Suomi NPP polar orbiting satellites data via Eumetcast and the VIIRS DNB (Day/Night Band) channel detects visible and IR light from 500nm to 900 nm. The night time pass instrument is very sensitive and shows the intensity of any light sources. On moonless nights it will even measure the visible radiance from the ground due to airglow. I've been waiting for a clear night over the whole UK and yesterday obliged, though there was a full moon, but the reflected moon radiance shows ground features very well and you can get an idea of how dark your site is. The resolution is 750m directly below the satellite. Lights on fishing boats in the North Sea show up clearly. NOAA-20 VIIRS DNB Image pass 2022-03-19, 02:20 UTC (Image centre). Full moon illumination. Click for full size Alan

Another option AstroNebulee is to try an Astronomik L3 UV/IR cut filter in place of your Zwo one though it's a bit pricey for the 2" one. The L3 cuts off the shorter blue wavelengths which is a main cause of blue star bloat on less than perfect optical systems. Alan