symmetal

Just been processing a 2 panel narrowband mosaic of the Cygnus Loop using a RASA 11 and ASI6200 and all was going well until I ran StarXterminator on the top panel and the result is shown on the lower three images. It's really hard, if at all, to see the flares on the before images. The Sii oddly has two circles close together for each ring. I looked to find a nearby bright star causing this and there wasn't one until I simulated a sensor of the maximum useable 52mm image field of the RASA 11 when it placed Aljanah pretty much right on the edge of the scopes FOV. 6200 FOV Simulated 52mm sensor FOV I'll need to do a third panel at a higher Dec with Aljanah more inside the scopes FOV so that it doesn't cause this effect, hopefully. I think the AI of SXT has accentuated these beyond their actual presence in the image. Perhaps there could be a future option in SXT to ignore large 'perfect' circular features. It may be woth posting the images to Russell Croman to see what he thinks. 🤔 Alan

Around 1mm more spacing I would suggest. The filters and the glass protect window will increase the required FF spacing distance by 1/3 of the total glass thickness which is about 1mm. 😉 Your bottom left stars are pretty good compared to the rest so their may be some tilt as well, but with the spacing increased to a more correct value this tilt may not be a problem. Alan

Striking image. 🙂 Thanks for sharing. The floodlight works well in that it silhouettes the gravestones in the foreground making them stand out. Perhaps a better edge blending between the land and sky wouldn't be amiss though. 😉 Alan

The USB2 sockets on your Startech hub are likely giving a better connection for USB2 plugs than the USB3 sockets on your Pegasus. If you look in at the sockets on each you can see the 4 usb2 sprung pins are further back on the USB3 socket to make space to fit the 5 USB3 pins in front of them. The curvature on the pins is also less so there is a possibility of a less solid connection using USB2 connectors in USB3 sockets, particularly in the adverse conditions of outside use. Trying to anchor the cables in place is a good idea. You seem to have solved the cause of the issue though which is the main thing and you can continue using SGP. 🙂 Alan

Glad you seem to have it all working again now. 😊 USB connections sem to be the cause of most erratic problems. I don't know if you have done so, but I've mentioned in the past about applying ACF-50 to all the connector contacts on your outside gear. I've done so and the days of having to replug things to get them working again have gone away. It's anti-corrosion and water repellant and doesn't affect the electrical connection. I just spray a little into a small container, and apply it with a toothpick. SGP isn't a subscription to keep using it. Once bought you can use it forever and it includes a year of upgrades. I tried NINA when it first came out but preferred SGP's way of working and layout, so bought the latest version 4, 64 bit. 🙂 Alan

Hi Adam, I checked on the SGP forum and filter wheels seem to be a source of frequent problems. Here's a link to a setup like yours with a similar problem and it includes a reference to another link. They are from 2020. Atik had replied to the second link saying there was a error in their driver which is now fixed in the latest release. It's worth signing up to the forum to see the full messages as I think not all replies are shown if you're not a member. Have you checked that USB power management is disabled too, as windows updates can re-enable it without you knowing, and this can be a source of problems in astro imaging. Here's a link to doing it via device manager and the Control Panel if you're unsure. Alan

Apparently, just one star, HD206267, shown on the left of the crop below, is responsible for all of IC1936's appearance. It's ionizing radiation compressing the gas to form the circular edge. The trunk itself is a source of star formation and 'winds' from these stars pushing back against this radiation have formed the dense compressed left edge of the 'trunk'. HD206267 is actually a double star as can be seen. Alan

Very good detail but I have to agree with ONIKKINEN that it looks too colour saturated now. 🙂 Alan

Thanks very much. 😊A full-frame camera helps with getting a larger FOV if the scope can handle it. 🙂 Six hours in total. One hour per filter per frame. This is Foraxx mixed 50:50 with standard SHO palette. Foraxx on it's own gives more red rather than the orange/yellows seen here. Alan

Taken over the past two months in many sessions as the weather's been very uncooperative. Each panel was 1 hour each of Ha, Oiii and Sii. Processed in PI using a blend of SHO and ForaxX palettes and finished off in PS. I usually add just the Ha stars back in as mono, but with Erakis, (Garnet Star) showing significant circular diffraction rings from the semi-circular cable routing of the RASA, StarXT wouldn't touch it in Ha or Sii, though did remove it in Oiii, the rings being closer together in this case, possibly helping. I therefore processed the three separate star images the same as the starless images as far as the colour palettes went, and added them back in PS. The range of colours produced don't look too abnormal and Erakis doesn't look so out of place now. RASA 11 and ASI6200MM with Astronomik FastFR 2" filters on an EQ8. Binned 2x2 to keep final image size down. I notice that none of the filters give halos either which is good. 🙂 A full frame camera gives a 3 deg x 2 deg FOV at 620mm FL so can manage fairly large targets. Not wanting to rotate the camera for framing, I opted for 2 panels instead. As the image is fairly noise free, I think for binned mosaics 30 mins of each filter may be OK. I'll do test stacks of just half the frames taken to see. I did find that StarAlignment in PI gave poor stars using 'auto' resampling where it uses Lanczos-3 when little to no resizing is needed. Oiii was the worst for this. This gave good backgrounds but the stars were smaller and squarer with undershoots giving black lines around bright stars. The 'clamping threshold' to reduce the undershoots had little effect. Lanczos-4, also gave bigger square stars and Lanczos-5 gave large diamond stars. In the end I used Bicubic B-Spline which was the best for not messing with the star shapes but did make the whole image noticibly softer. Adding Ha back as luminance tended to mitigate this. StarXT can give round patches on the Oiii background around bright stars where Lanczos resampling was used, but not when using Bicubic B-Splines. Note the colourful planetary nebula top right of Erakis and the lone small blue patch half way down on the left. The bright star at bottom left is actually a double star rather than an odd optical distortion. 🙂 Alan

That's looking much better. 😁 Alan

The flattener has an 'integral' T2 adapter, the knurled ring on the end so I would now assume that it is present in the 55mm spacing quoted, which is measured from the right edge of the ring, in which case the purple line is the 49.5mm required. If the adapter is not included in the flattener 55mm spacing specification then the green line is the 49.5mm required. I would think it is part of the flattener as Peter above has said so the purple line would be the one to use. Note the front of the camera body is as I've indicated, and not where you've placed it. The sensor is 6.5mm to the right of the of the purple or green line end. Note: pictures of the flattener on the web don't show the ring as knurled anymore, implying it's not usually removed, so it is now almost certain that the purple line is the one to use. 🙂 Alan

You don't say what model of reducer/flattener you're using to confirm that it's 55mm, but assuming that's the case: The 533 has 6.5mm 'backfocus' from the front of the camera body, or 17.5mm from the front of the attached 11mm spacer. Your ruler is showing the 55mm mark around 10mm from the camera front face so that's not quite right. As the filter and camera protect glass will add around 1mm to the required back focus it's better to aim for 56mm back focus distance, so you want 49.5mm betweeen the rear face of the flattener and the front of the camera body. I'm assuming the knurled ring at the rear of the flattener isn't part of the flattener itself, in which case your start point for measuring is correct though parallax is likely making it look a little off. Alan

The ASI120MM has a clear protect filter so a UV/IR cut filter would be recommened for planetary imaging. I posted some tips here and further down on using Firecapture but they will apply to whatever software you use. Focal ratio should optimally be around 4 x pixel size in microns. The ASI120 has 3.75um pixels so aim for around f15 focal ratio by using a barlow of powermate with your scope if you can. Alan

Most impressive. 🤗 I've done the Dark Shark and Wolf's Cave area separately with my RASA 11, but it's nice seeing them all together. Alan

I've just noticed the colour coding on the connector you posted is different from the one I posted so you'll need to change your wire colours to match. For T-568B as looking at your photo Top row left to right Orange/White, Orange, Green/White, Green Bottom row left to right Blue, Blue/White, Brown, Brown/White Confusing isn't it 🙂 Alan

There are two wiring conventions for RJ-45 ethernet connectors called T-568A and T-568B. The difference is that the orange and green pairs are swapped over between the two standards. Ethernet cables are wired straight through so if the same is used for both end then either method works. If you want an ethernet crossover cable to connect two PCs together without going via a router or switch inbetween then you wire one end as T-568B and the other as T-568A. https://incentre.net/ethernet-cable-color-coding-diagram/ Standard ethernet cables you buy are wired to T-568B at both ends. The colour coding in your picture is T-568A so is that what you actually need. Here;s your connector wired to the common T-568B which is probably what you want. The top two colour rows labelled B are the ones used here. If you wanted to wire it as T-568A you would use the bottom two colour rows labelled A. Note it's just the orange and green pairs that are swapped over which is the difference between A and B. These are the ethernet transmit and receive pairs. The blue and brown pairs aren't used for standard ethernet cables but can be used for supplying power to devices like IP cameras when it's called a POE connection. (Power over ethernet). Nowadays, crossover cables generally aren't needed as modern PCs can usually detect what signal is on the wires and if necessary make the changeover internally automatically so a standard ethernet patch cable can be used between two PCs. Alan

Good detail and 'natural' looking. 😊 Holmberg IX is showing up well too. Alan

I installed CUDA 11 on my lower spec PC (Nvidia GTX 960) and PI crashed and exited as soon as BlurXT finished initialization and began processing. Not good but at least it was trying to do something, unlike CUDA 12. 🙂 Not having high hopes, I thought I may as well try it on my high spec PC (Nvidia RTX 2070) and woohoo! 🤗 It worked. What BlurXT took 3min 15s to process previously, now took about 20s for the same image. Around 10x faster. Task Manager showed the GPU working hard. 😁 I left CUDA 12 installed as well as they are in separate CUDA subfolders so if the CUDA 12 issue is fixed I just have to change one environment variable to make the switch. It may work with the latest tensorflow.dll 2.10 but I used tensorflow.dll 2.90 as in the posted instructions, and as it's working fine now, I'll leave it for the moment. Thanks all for your help. 😃 Alan

Thanks fireballxl5. The video uses the same installation info as sinbad40 posted. It's probably me worth trying the CUDA 11 files rather than the latest CUDA 12 I used, to see if it makes a difference. The tensorflow.dll for Windows is an older version than the latest release for linux systems so maybe it isn't so compatible with CUDA 12. Alan

Deleted the CUDA installation and ran the network-install of runtime libs only instead but no change. 😟 Actually the GPU version of tensorflow is over twice the size of the CPU version, not smaller as I first thought, so it's possibly still running just the CPU routines still embedded in the GPU library, which is why it takes exactly the same time to run BlurXT etc. Tried adding /deleting environment variables to match those stated in Sinbad40's posting but no change. The only difference is I'm using version 12 of CUDA and CUDnn while Sinbad40's posting uses version 11. It would be nice if the XT processes indicated in the console area whether the CPU and/or GPU were being used for processing and if CUDA is present why it's not being used. Alan

Thanks for that. The only difference I can see is you did a custom install of Cuda, installing just the runtime libraries, while the RC version did an express install which installed everything including development files. This also installed 2 path entries automatically while your version requires 1 of these paths to be entered manually. I'll try your method and see what happens. 🙂 Alan

I followed all the steps in Russell Croman's guide to enable Nvidia GPUs to do the AI processing in BlurXterminator etc. but it's had no effect. One of the steps is replacing the AI tensorflow.dll in the PI bin folder, (which is a CPU only version), with a GPU enabled tensorflow.dll. Running BlurXterminator it took exactly the same time to run before and after, and checking Task Manager, apart from a burst of GPU usage when BXT is initializing, when processing, the GPU usage is zero. The tensorflow.dll is being used, or at least checked, as removing it causes errors when loading PI, and the X modules are unavailable. The Nvidia RTX 2070 (8GB memory) graphics card is fully CUDA compatible. I looked to see what programs there were for testing CUDA and they all just seem to be source code examples, with none ready compiled for Windows use. 😟 Has anyone successfully managed to get this working in PI? The new tensorflow.dll is a lot smaller than the original one, presumably as most of the work is now farmed out to the GPU so something is doing the calculations, as the X Suite programs still work. I'm using PI 1.8.9-1 in this machine, and I also tried it on my backup machine running 1.8.9-2 with a lower spec CUDA graphics card, and it's just the same. Alan

MosaicByCoordinates for 1.8.9-2 has now been fixed and a new version of 1.8.9-2 is due to be released next week with the fix. Alan

If you have upgraded to PI 1.8.9-2 recently, I would recommend rolling back to 1.8.9-1 for the moment. It's not an automatic update, you have to download it from the PI website. Many posts on the PI forum have mentioned it runs very slow with the update, though others haven't noticed it. It seems to be machine hardware dependant. I found the ImageSolver script took around twice as long to run, along with the Mosaic problem Onikkinen mentioned. If you haven't upgraded then ignore all I've written. 😊 Alan