BCN_Sean

Between borrowing my grandfather's binoculars when I was a kid and building a barn door tracker when I was in scouts got me interested, but it wasn't until the virus made everything stop that I realised that I was running around doing a lot of unimportant things and really I could use that time to do something I wanted to instead.

One of the first things I did was replace the lever when I got mine, the wedge really does show it was put together for pennies (the washers on the alt axis are where it is really noticeable, and any 0.5mm plastic disk is a lot better); any reasonable hardware shop should carry metal locking handles for a couple of coins a piece, though I can't remember off the top of the head if the thread on it is an M6 or an M8.

Biggest for me is to improve my imaging, as at the moment it's ok for things like Facebook or Instagram but nothing I'm really satisfied with just yet. Aside from that probably try to find an older mount to restore/modify, and hopefully if the situation allows wrangle up a couple of my mates and go on a road trip to somewhere darker than my sqm 20.9 back yard.

Only thing I can think of here is that either you, or your import settings have zero'd the images in LR and that's been rendered at export time. Whilst I like Lightroom for nearly all types of photography, it's been my go to since before it was Lightroom, I'd suggest the same as @alacant and go with SiriL for the conversion. There's too many things in LR (and other similar things) that can potentially adjust the data that can catch out the unwary or tired without realising that it's happening (default noise reduction in Lightroom/Photoshop Camera Raw tries to map out hot pixels, as an example).

I've not done planetary with my Pi, so only half a thing here. With testing transfer rates to the machine (Pi4 8GB running Astroberry) as my imaging camera is gobbing out 70mb a time, even with a really quick SD card it's still orders slower than a USB3 flash drive, and then that's still orders slower than an SSD; so if you're lumping big data around or requiring a lot of sequential read/write, or caching then the latter is the better option not just as a data store. Down sides to it, is that for it to work the drive may need to be connected to a powered hub as it may push over the peak on the internal USB hub; had that one one, not on another. The other down side is that as of yet I've not found any imaging (as in disk) software that will treat the SSD the same as an SD or a flash drive (though this may be down to the controller in the drive holder) so each backup of the disk is the same size as the physical drive itself instead of being a compressed to used space only image.

I purchased one of the dummy batteries with USB convertor and for my Nikon, pretty similar to what Dr_Ju_ju linked, and I'm regretting it a bit at the moment because of the USB convertor on it. There are two different types of USB to convertor protocol with these things, the USB-C PD and the USB-A QC, and having both on the same power supply I've found to the detriment of the pocket that they can butt heads and cause some other issues even if the power supply used may claim to support both protocols, both mine do (one purchased before, one after) just not reliably at the same time; so I'm using the two supplies at present, one for the Astroberry/guide cam (PD), one for the imaging camera (QC), which has added an extra power supply and will cost more in the long run when I've either changed the power to the battery coupler or found a supply that can support both reliably. If you are planning on running it direct to it's own supply, or using a buck convertor from a 12v rail, then that scenario won't arise, but if you are thinking of a similar route to what I did then whilst it may seem a simple power supply thing, it could cause another layer of frustration on the top.

Just had a look in to it, and there's some nice bits in there but there's also a few things that need poking further with a stick as I think there are some bugs in the mix (calling some stacking parameters from scripts, sometimes refusing to connect to get astrometry data), but will have to test some more out on that. This pixel math stuff looks interesting, not really looked in to it before but from the video and having a read up on it, it's going to get a good dose of looking at.

I'd say mine would have to be fast internet. First time around doing anything astronomy related, it was limited to a small village library and the few things they had in there for any information regarding anything; now I can get on here or poke round in other corners of the internet and find answers that I don't even have the questions to yet. The access to collective knowledge, information and different viewpoints, as well as discovering equipment and techniques really has opened up more than what three dusty tomes and a dog-eared copy of Popular Astronomy could ever do.

I've tested the jpg route for solving and really didn't notice that much speed difference to leaving the camera in native; and with looking at what was occurring in the fit preview windows with the image artefacts that were appearing there (though, that could have just been the fit interpreter trying to throw a pretty preview and failing), it made me wonder about the process which I couldn't see, so in the end I left the camera running native all the time and didn't try it for focusing. Then there's the other bit about forgetting to swap the camera back, as whilst it can be done from the comfort of indoors through the Indi panel, after doing a setup out here on a autumn/winter night the grey matter does freeze over, so less things to forget the better!

I'm using it with an SLR, albeit with camera lenses, a homebrew focuser and it's certainly a lot tighter than what I can get it to by eye with a mask. The setup I'm using for it is 1 second exposures at ISO 800, SEP/Linear with 40 step * 8.0 outstep, can't remember tolerance off the top of my head and that takes 9 - 12 images to get to focus. To my limited experience with it (as in not testing it against anything else), it certainly works to what I consider acceptable, and the only real big downside I've found with it is that with the file size of the camera I use is that it can take a bit of time between downloading the frame and finishing the calculation to move the focuser to the next position; though that could be down to the limitation of the Raspberry 4 that is running my EKOS environment.

Open up APP, and when the file dialog appears for looking for the files open a Finder window to the root of the computer (mine is the icon that says iMac, but it may be different depending on model) where all the drives are. Drag the icon of the drive and plop it down on the file dialog and APP should open the drive like that. If not, it's something else amiss.

Just had a very quick and dirty look in to this, as not got the machine fully set but this is what I came up with on the astroberry. Starting off with one instance of kstars, setting ekos to start on the default internal server starts it up; then after opening terminal up and then putting in to there as an example "indiserver -p 9876 -v indi_driverA indi_driverB" (though I don't know if it'd work with identical drivers unless you map the port, as in /dev/tty* to device), then opening a second instance of kstars, and in the profile setting it to use a remote server assigned to the same port as inputted in the terminal. Had the mount slewing around with one instance and the guide camera looping on the other. As for any more I don't know, as for stability again I'm not sure with; however it's certainly an interesting proposition that I've put on my notepad to have a look at in the future.

It's not an issue of Photoshop itself, it's something to do with the Camera Raw plugin; the way I got around it was opening up Photoshop and under the Preferences menu going in to the options for Camera Raw (it may take some digging around as it's not the most front and centre of things) and then in the file handling setting TIFF to "Automatically open all supported TIFFS". The other way around it, though not tried this is as you say it opens in Lightroom, either use the Edit In function on the context menu (and open as smart object) or export it as a TIFF from there and open it.

I hacked mine to work with Linux the beginning of this year, I found that the firmware update from the ZWO site didn't work, but the firmware in this package did. zwo_fwtool_usb2.zip I can't remember which of the 120MC firmware I used on it now (I think it was the ASI120MC-compatible.iic in the bin->firmware folder, but try both for the 120MC), it needed the latest firmware updater from the ZWO website on an account with admin level privileges on Windows and if Windows popped up security questions they needed accepting as it would throw other issues on the Mac and also on Linux. Also the other thing with these things is if that you plug them in to a USB 3 port they can cause some real headaches and need to be connected directly to a USB 2 port. After that, it worked quite well most of the time, but occasionally it could have issues that made it untrustworthy for a full session; and I swapped it out for an Svbony 305 Just plugged my T7C in and had a look, it identifies as "03c3:120b 03c3 ASI120MC" just missing the serial number; but that's with the firmware as flashed above.

Have a look at DisplayCAL; might seem a bit odd recommending a software package before the hardware, but get a look at the list of compatible hardware for it as a lot of hardware that has been obsoleted by manufacturer (software support mainly) still works well with it and some of the meters can be picked up for junk value. The meter I use on my machines, I paid a pint of ale for about 10 years ago.

An Olympus OM10 with a 50mm on a hand cranked barn door was my first foray back in the early 90's; with not having any processing capability at home, and waiting on the local lab the whole feedback loop was 7 - 10 days, now it's a handful of seconds. That's the type of nostalgia I really don't fancy revisiting!

One thing I've found with the solving under EKOS, especially with using a D810 (if this is the thing that's causing you the issue) is that in the solvers default configuration it's scratching for any shred of available memory on the solving computer and will crash with a memory segmentation error or lock up completely. Down in the settings for the solver in the bottom right of the panel, there's a selection asking if you want EKOS to load all of the indexes in to memory; knocking that to off should give it a bit more breathing room in the memory area, but it will slow solving down a bit as it's loading the correct profile on demand. It could be the same issue your facing, or a different issue with the same symptoms; look into debug logging as Wim suggested, but also look at the system logs as well, as they may give you better insight if it's something happening at system not Ekos level.

I don't think MS are being restrictive with it; it's more of a safeguard of their reputation/product image. I'd say that most (probably not the bargain basement Amazon jobs) computers from a processor/GPU/RAM standpoint built in the last 10 years would easily support the operating system, a lot of these systems are probably carrying obsolete ancillary hardware like sound chips/webcams/network adapters and the like where the manufacturer of those parts has ended support for them (or in some cases, vanished); so even with attempting to install W11 on that machine, the support and guaranteed compatibility wouldn't be there. If it was offered to all, then a lot of folk would blindly click the "update now" button, and then start banging away in all caps on every sounding board they find because Windows 11 broke their computer instead of realising it was their computer that broke Windows 11. Drawing that line with TPM has probably brought them some flak, but probably a lot less than X million folk like my other half who wouldn't understand why their 10 year old cheap end of the spectrum (when new) machine isn't working right because some other vital parts of the recipe were EOL'd back in the middle of the last decade.

That's a sweet image, I'd be happy if I'd got that one!

Not in asinh, the one on the actual histogram; I can't remember how many times I've forgot to hit apply and then just hitting close. When it comes to the way to commit a modules change in SiriL it looks like there's been at least three different development teams on it, each with their own chain of design and that has introduced a few little flies in the soup because of it and if not wary of it (or it's like my usual, about five in the morning) then it's easy to get bitten with them.

Ah, that's not too bad... Forgetting to click "Apply" before clicking on OK after spending a few minutes getting the perfect histogram is one that gets me more often than not!

Yeah, I generally use it in a script or via the command line (eg seqsubsky light 1), but there is an option in the interface as well, just open the light sequence and apply; a polynomial order of 1 should be sufficient on untreated lights. Just helps getting rid of simple gradients which when stacked would turn in to a complex one; then after stacking just hit it again.

I've been using it for a bit, and still getting my head around it, well still getting my head around the post capture in general. One thing I've found with it is that the background extraction tool if run after photometric can pull out all sorts of nasties if the optics used aren't up to snuff. As for the photometric itself, with shooting an SLR and converting within SiriL, I've found it best to open one of the untreated lights in astap, solve that and then enter the co-ordinates manually (and maybe downsample as well) as sometimes even if the image is out only by a smidge of a degree to what it expected then it may fail to run. The deconvolution, that is something that I've had hit and miss results with as well; if the image is fairly under sampled, then it doesn't work well but if it's not too far off the mark then it works well. Best thing I've found with it is to extract the background before registration (very useful if stacking multiple nights) and then running that before any colour calibration on the stacked fit. The biggest gotcha I've found with the newer version, is that when opening a freshly stacked fit file, it looks though it's been cropped to remove the border but it's best to crop it in a bit further as there may still be some stacking artefact present that it's missed or just masked.

@astrochumak, finally got around to getting some files off the computer; I left the other half supervising the new lines going in as I'd pulled an emergency call out, and they'd installed everything to the wrong side of the building to the network cabinet and the uninterruptible power supplies. Three days of routing network connections and power cables through the place, and hopefully (off to test it tonight) it's not caused any fun with the astro gear. This here is the sigma 70-200 at 200mm in length, with the rings I was saying about above, seems to be caused by reflections off of one of the elements, and it's noticeable in single unprocessed subs; I think it's when the zooming portion of the assembly (as it's a reverse zoom design) is picking up light that is reflected off the rear element. Whilst it's not impossible to correct out, it's a bit time consuming. This here is just colour balanced, stretched and size reduced.

At the moment I'm using it up to 180mm and also use a 300mm F:/4 which has its own set of curiosities (mainly coma on the left side). I don't have any images from either lens on this computer at the moment but I'll try and dig some out in a bit but I'm in the middle of ripping the network to pieces in the apartment and rebuilding it so it could be a bit of time.