IanL

MaskedStretch is useful to retain colour in stars as a single global stretch tends to oveestretch them to the point where the cores are (nearly) white and no amount of further processing will get the colour back. One downside is that the rest of the image lacks contrast so you have to do more work to boost contrast, etc. You can try masked stretch and a normal stretch on clones of the image and then use a star mask to blend the two, but it can be tricky to get a mask sized appropriately for large, medium, small and tiny stars. It might work better to do a masked stretch and then use a star mask to selectively apply further stretches or curves just to the background. The unwanted colour tints seem to be a byproduct of the fact that the stars are different diameters in each of the RGB channels, especially in DSLR/OSC images where you can't adjust the exposure time per filter to balance the sizes (if you don't you can also get colour casts when combining your LRGB image when using mono and filters). When the masking process is operating each channel gets a series of stretches that accentuate the problem as each channel ends up with different star profiles, leading to the magenta cast. Usually it is the medium stars that suffer most in my experience. It's pretty hard to avoid and harder to get rid of once created. I've tried things like extracting the colour channels, applying different star masks and using morphological transformation to shrink the stars so they match sizes across channels, but it is not ideal as clearly tge star has a Gaussian or similar profile. You can also try selective curves and a mask to desaturate the magenta, but this risks unnatural star colours. There is no magic bullet as the best approach seems to vary from image to image.

Agree with the above posters, second hand might be good or a disaster depending on your luck. EQ mounts are definitely not a good idea for a 7yo. I think you need to be realistic about how much she will be able to do without the help of parents, but observing the sky together is a great activity and if you get a reasonable scope she will grow in to it. Take a look at this for one guide to possibilities: https://www.firstlightoptics.com/beginner-telescopes.html Also the first item on this page offers a bit more information and a wider selection (disclaimer, I wrote it, up to date as it was revised this month): https://www.northessexastro.co.uk/free-astronomy-resources/

Thanks, will do, but the Baader is definitely larger than 6mm. I'll measure it again and drop them a line.

Thinking about what to do here myself. I've got a Baader Diamond Steeltrack (refractor), but likewise frustrated by the disappearance of the steeldrive and seems to be no urgency to replace it. I "successfully" built a DIY setup using a stepper, easydriver and pro-micro (arduino clone). It was all working earlier in the year, except I had problems with the belt drive. The Steeltrack has a HTD pulley machined in to the fine focus knob, and is designed to be driven by the steeldrive (contrary to a lot of advice not to drive the fine focus, the Baader is engineered for it). I couldn't find a matching flanged HTD pulley, and having tried a wider pulley the belt wanders and causes the focus to slip. So recently I got a pair of pulleys and switched to driving the coarse focus shaft on the other side, plus an improved bracket and spacer to mount it all. Should be OK with 1/8th stepping and the 2:1 gear reduction through my belt drive. Having done all that, the stepper won't budge (even off load and with max current set in easydriver), have had it all apart, resoldered everything, etc. and no joy. I'm sure it's either a dodgy connection, the easydriver has been fried or the stepper coil burned out. Fixing it would be a few quid to replace the suspect parts but I'm at my wit's end with the whole thing. Last decent imaging run was January this year and don't want a whole year to slip by without getting some use out of my kit. So regardless of it only being a few quid to build your own, looking at a commercial setup. The Senso doesn't appeal as the attachment mechanism seems entirely likely to be the weak point with tiny Allen head grub screws and stripped threads (why not just machine some decent sized holes and screws is beyond me). It's also pricey, as is the Lakeside. I'm looking at the Pegasus focuscube. It's c. £100 less than all the other options, and I don't need a manual focus control since it's for a permanent imaging setup. I can't see much written about it anywhere so not sure about hardware and software quality. The main issue is what it the maximum size of focuser shaft the flexible coupler will accept? Can't find that information anywhere and the Baader's is pretty chunky (about 7-8mm dia. I seem to recall but haven't checked). Of course it would be relatively simple to get a larger bore coupler if needed, but just dread getting in the pulley situation where I can't find the right combination of focuser and stepper shaft diameters. Anyone know?

What is the camera? You didn't say in the original post? Nowhere have I used the words 'very noisy', but it's a fair assessment of the situation. It's not a sleight on you or your equipment, just a fact that DLSRs are noisy for all the reasons I and other posters have explained. Even high-end CCD cameras have limitations and compromises in their design. One needs to understand the limitations and the correct techniques to get the best out of the equipment.

There are two other issues to consider with one-shot-colour CMOS cameras (i.e. DSLRs and some astro-cameras): - Telegraph or impulse noise: This is not fixed like hot or cold pixels, but not is it random. A large subset of pixels with small defects in the sensor well will sometimes give 'normal' readings, i.e. close to the true value plus or minus a small noise component, but are prone to reading out a number of much higher values from a set of specific values for each pixel. This makes it impossible to calibrate them out like hot/cold pixels and will build up in to a pattern. Again the only real cure is a large dither in both axes between frames to randomise the pattern and aid the pixel rejection algorithm to weed these values out when stacking. - Chromatic noise - this is simply due to the fact that each pixel only detects one of red, green or blue depending on the Bayer matrix filter. Debayering estimates the missing colour data from adjacent pixels, but any noise affecting a pixel 'infects' its neighbours in that colour channel depending on the debayering algorithm. This is especially apparent when you don't dither since the noisier pixels (hot/cold/telegraph) tend to build up in to larger colour 'blobs' in a given channel, and when you overlay these noisy blobs from each of the RGB channels, you will get the delightful rainbow background you are seeing - with DSLRs it is usually most apparent in the red channel since that gets the least signal and therefore has a lower signal to noise ratio, but it affects them all. Practically: - Red is the primary component of a lot of nebulosity, and unfortunately DSLR cameras which haven't been modded to remove the IR filter are not good at picking it up. There is no point in chasing really faint Ha features with an unmodded camera as you'll end up with disappointing results but even with it's still an issue due to only 1/4 of the pixels detecting red. If you can't mod the camera then pick your targets to avoid the problem. You can see that the upper left of the second image looks pretty good, it's the rest of it that is poor. If you can, increase the focal length to get in on the brighter stuff and cut out the rest. - Dither aggressively (15-20 pixels between subs). If you can't do that due to the Star Adventurer, then manually repoint the camera in Dec as often as you can stand to, every 5 or 10 frames say. - Lots more frames - if you've got light pollution, then there is usually not much benefit in going for long exposures, 1 min or 30 seconds is probably the right ballpark as you are doing, but get as much total exposure time as you can. 90 minutes with a noisy DSLR under light polluted skies is nowhere near enough, you'd want 3 hours as a minimum, and 5 or 10 would be a good aim - I know it's tempting to hop around between targets to tick them off having been there myself, but actually spending a few nights on one target will get you much cleaner results. - I'm a lot less convinced of the benefits of dark frame subtraction on CMOS cameras due to telegraph noise, plus the lack of temperature control means you will not be able to get a matching master dark in any event. I did a lot of experiments in this area and the upshot is that the temperature readout in the EXIF data is not to be relied on for Canon DSLRs and I'd be cautious about any other make unless you verify the reliability through testing. If it's a Canon, you can pretty much forget darks anyway as there is on-camera processing that suppresses dark current in a way that makes it impossible to apply them usefully (not talking about the camera setting to subtract a second dark exposure on camera, this is in the firmware/hardware for all images and not user controllable) - Upshot is that darks may actually end up making the image more noisy, not less. Instead try using a large master bias to remove large scale fixed pattern noise, combined with a defect map process to remove hot and cold pixels. - After that, as others have said, you are over-stretching your data. The highlights are blown out which may be the stretch or just over-exposing when capturing, and the background is way too bright. You can try creating masks for the stars and nebulosity to stretch them more, and then apply a much lesser stretch to the background for example. You can also use the same mask to de-saturate the background (especially red). The background shouldn't be black, but nor should it be nearly as bright as the rest of the image. Good luck

Not necessarily, but I had assumed you were trying to join two or more tables in your query, and that is a handy way to create a primary key for tables that aren't properly normalised (simplistically normalised means every table has a primary key and all other columns in the table are fully dependent on it. E.g. Naïvely you have a table with employee names and addresses in it, composite primary key of forenames and surname. To normalise you first realise that more than one employee may live at the same address, so split it in to employee and address tables as the address columns are not dependent on the employee. Address table has composite primary key of house name/number and postcode (should be unique), which you also add as a foreign key to the employee table so you can join them in queries. Next you realise that some families work for you and like to name their children after themselves so your employee primary key is invalid. Create a unique payroll number for each employee and use that instead). In this case you have a query on a single table for this data, and the primary key should be the catalogue number; if these are duplicated then you need to dedupe the data first as clearly some errors exist. Adding indexes to other columns used as criteria in queries is the next step. There is an overhead for creating, maintaining snd using indexes so you shouldn't add them to every column just in case, but less of a concern here the contents of the table are static so it's a one-time process rather than an ongoing one for a table with frequent updates, inserts and deletions,. Your main issue is whether all the indexes can be held in memory rather than on disk. For example, look at the minimum magnitude in your data set. Say it's 12.999, instead of crunching through 3 million records, an index could reduce it to 230 records (3,000,000 / 12,999). That's assuming a perfectly even distribution of magnitudes across the dataset and looking to match one value. Your mileage will vary and it's not quite as simple in terms of resources saved due to many other overheads but the gains are huge. Optimising database and query performance is a huge subject. Professional DBAs make very lucrative careers out of their experise for a reason.

Glad you sorted it, but yeah, tables without primary keys are the DBA equivalent of being the apprentice sent out to find a left-handed spanner. If you've got duplicates in a field, by definition it cannot be a primary key. It's a dreadful hack and I should probably hand in my Comp Sci degree for telling you this, but in the real world (vs. Codd-land) in that situation just add a field at the start of the table with an integer type large enough to encompass the maximum number of rows you expect and make that the primary key. It's not ideal but it will avoid the performance issues you hit here. You should also add indexes to any other columns that are used intensively in queries - I can't remember but I think Access had some optimiser tools that suggested what you needed based on analysing the queries you built.

Access doesn't support multithreading even in the latest version, never mind a version from 18 years ago. Regardless of any other bottlenecks, it will only use one half of one core at most; assuming a four core hyperthreading CPU, maximum utilisation reported by Windows could never go above 12.5%.

If you have amp-glow or any other sort of large scale non-uniformity in your darks, you need to turn off dark frame optimisation when calibrating lights in PixInsight. Dark frame optimisation in PI determines a global scaling factor based on minimising residual noise after dark subtraction. This works well for darks which are uniform and enables use of different exposure or temperatures between darks and lights. For sensors with amp glow, the scaling factor will cause the amp-glow area to under or over correct. You need to turn it off and use well matched darks and lights (same temperature and exposure).

They definitely run quite hot, that is normal hence the aluminium casing. It would be simple enough to add an old computer heatsink and fan if a concern. I have two that have run 24/7 for a large part of this year including the epically hot summer without any ill effects so would be happy to buy another if needed.

If you're just getting started, look for the meteor scatter posts in this subforum. Yoy can build the "Sky at Night" Yagi antenna and get a cheap SDR dongle for about 50 or 60 quid all in assuming you've got a PC or laptop you can run the software on. It's a simple and satisfying project to dip your toes, you don't need anything more than a small hacksaw, tape measure, Stanley knife and screwdriver by way of tools to build it. You can then look to try other projects using the SDR like weather sat data.

The length of the antenna is directly related to the wavelength one wishes to receive/transmit, usually some fraction of the wavelength. A quarter wave is fairly typical but it depends on the type. The basic point is that the antenna needs to resonate at the desired frequency. Using a quarter wave dipole, if you superimpose a wave on the dipole, one end will be at the point where the wave crosses the horizontal (zero) axis, and the other end will be at the peak of the wave. The EM wave induces a voltage differential between the two ends, and by splitting the dipole in the middle and connecting each side to the opposite sides of a circuit (via the coax), a current will flow through it which can then be measured. At the receiver, one then measures the voltage and turns it in to sound, pictures or data depending on the application. How that is done will depend on the signal - AM, FM, etc. For SDR it's relatively simple, the basic premise is that one samples the incoming signal using an analog to digital converter which turns the measured current to numbers. You sample at at least twice rate of the highest frequency you wish to measure (Nyquist). You then use the FFT process in software to extract the different frequencies in the samples. That's the simple version as I understand it, but it's a big subject and lots to learn.

Read this: https://www.astrokraai.nl/software/Sky & Telescope - September 2016 [68 - 72].pdf Software is here: https://www.autostakkert.com/wp/

It was specifically covered in the paper above in the context of head echoes. I can't see why it wouldn't be a factor in the static reflections, but they are considerably more complex to model due to Fresnel zones / constructive/destructive interference, under/over dense regimes, etc.