Rallemikken

That's more than I've got in total so far, well beyond mid-season. Once I hit mid-april it's over. This far north it don't get dark at all during summer. A real sh**ty winter.

I know, must learn to balance gain/exposure. 100ms is to long. Not worried about oversampling, files are pretty small. Conditions are bad up here, skies drifting all night. Not much else than planetary to do. I'll do another try, maybe tonight. Curious to see what I can achieve with socalled "consumer grade" gear. We have argued over pixel size before. Maybe I'll drop the barlow, but you can't beat the "Wow!"-factor when the planetary disk spans half of the frame! Cool!

I am, or at least I think I can. Camera support it. But the planet was already so big, I was nervous to loose it in the frame. Next time I think I'll use the same settings, but capture more frames. When time permits I'll do a restack of what I have, keeping only 5%. Just to see what I had, I converted the SER-files to fits in Siril. Took ages, but once finished I could examine each frame. Sorted on "Quality", the top 10 frames was dramatically better, almost as a finished stack. Got a lot to go on.

No red spot this time either. Stacked in AutoStakkert from 11 SER-videos, 30 seconds each. Captured in KStars, 10 FPS, 3300 frames total. Not sure what to expect, but great improvement from my Canon 600D. I used my 8" StellaLyra RC with a 2.5 Celestron barlow; together that summed up to 4000mm focal length. Once I had it in the frame, the guiding kept it in place. I've got a lot to learn, but this doesn't scare me off! During capture, I saw that framerate was, to a certain degree, dependent on exposure time. This is captured with 100 gain (that's no gain in Touptek terms) and 50 offset, with an exposure time of 0.1 second. That limited the FPS to 10. This is a 8.3 MP camera with a diagonal of only 6.39mm. The planet itself is more than 600 pixels wide off the camera. I experimented with more gain and shorter exposures, but the playback of the SER-videos during the session lead me to 0.1 second. Next time I'll try even longer exposures to catch more details, at least 0.2, maybe 0.3 seconds. The camera itself does not promise more than 47 FPS at full resolution, I never got above 30 myself. The conditions was good, bortle 3/4, moon below horizon. Focus was as good as I got it, and the planet stayed fixed in the frame. I used my usual workflow; capture in KStars, PIPP to collect the SER-files into one huge AVI-file, stacking in AutoStakkert (10% of frames this time) and wavelets, this time, in Siril, I could not get RegiStax to handle the .tif from AutoStakkert. Maybe because of the size of the file, it just hanged and finally locked up. Remenber, I'm a Linux guy, nothing of this is done in windows!! Final touch in Gimp. Tip-of-the-day: If you don't get PIPP to work, remember that this camera is 12-bit. Pretty odd. No "auto-function" to catch this. And I turned up the "Input gain" under the "Processing options" to 2. And enabled cropping to 1500x1500. Ps: The two dots are Io and Callisto. Just to get them in the frame was a bonus! Captured on december the 20th, early evening norwegian time.

Try this: The camera into the barlow, the barlow into a 30-40mm extension and the extension into the focuser. This is how I must do it when I use barlow's on my reflectors.

Spent the last day downloading the missing index files in my Ekos install. It summed up to 66 Gb. The monthly data cap is uncomfortably close, and christmas is coming...... The files are already replicated on four machines. They are static, not prone to get obsolete. Ususally stored in /home/user/.local/share/kstars/astrometry Will I need them all? Probably not, but with a 2.5x barlow on my 8" RC and the imx715 in the scope's butt my FOV is no more than 0.08° x 0.05°. That is pretty small. Less than 5 arcminutes. I always try to platesolve on a nearby star when I do planetary, it makes the hunt for the planet itself easier. I had troubles getting the downloader in Ekos to work on all files. The missing ones were downloaded from here: http://data.astrometry.net/debian/ For those NOT on debian-based systems (or, God forbid, on Windows) the files can be downloaded and extracted as regular archives. You may have to monkey around a while until you figure it out, but most archive programs in the Linux ecosystem handle them without a hitch!

Astronomy With Claire -- https://www.youtube.com/@astronomywithclaire The most charming, without a doubt! A year since her last video, hope she gets back on the horse. Runner-up 52 Night Sky -- https://www.youtube.com/@52NightSky Been silent for three years, but he did some excellent videos on my favourite software, KStars and Ekos.

Wise. Possible vendor lock-in is a good argument for NOT to choose ZWO. The pink cameras have a couple of very enthusastic and competent ambassadeurs on youtube, and I trust them both. Most manufactorers rebrand cameras from ToupTek, and does their own twist. The Altair's are regarded as good on both noise and ampglow compared to their counterparts, as far as I have seen. And the ecosystem around them seems friendly, so that will most likely be my choice. My smallest scope is a 6" f/4 StellaLyra newt, with the reduser the focal lenght is 540mm. That mean that I need a big sensor to image the bigger targets, so I'll most likely go for the 26C. Doubt I'll ever buy a frac, they look so tiny, and cost so much money. A perfect fit if you have endless clear skies and nothing else to do. I'm lucky if I get a couple of nights each month. Can't waste time on toys on those small occacions.

Heard only good reviews of this. Considering either this or the more expensive 26C. The 269C is currently out of stock. I've got a ToupTek IMX294C lately, mostly for my 8" RC on galaxies and small things. My first astrocamera. Not superimpressed so far, but I'm learning. As a supplement, the 26C seems the logical choice. Should be a step forward from my astromodded 600D that has been my workhorse so far.

Well, this one is amazing! M33 is a difficult target, don't be fooled by it's close proximity. It takes fewer subs to get a decent image of ie. M81, Bodes, because the light is concentrated on a smaller space. The Triangulum galaxy falls between two chairs. It is by far not as bright as Andromeda, and even if it's closer, some of the further-away galaxies are easier targets due to their limited angular surface and inherent brightness. Guess you started with a DSLR like the rest of us. What difference did the Altair Astro 269c do?

There is a "legacy" download for Linux on the download page. I have tested this version on both a recent vanilla Linux Mint Wilma (22) and an older vanilla Debian Bullseye (11). I've run the denoise on a RGB tiff, full mode and strenght 0.6. The application run on both, using the same amount of time. Afterwords the two resulting images shared the same md5sum. What we call a "reproduceable build". A little impressed. Conclusion: If you have a slightly old install it might be safest to download the "legacy" version. When it runs on Debian "oldstable", it runs virtually everywhere. If it don't, start it with a dot and a slash in the terminal in the folder and post the error messages here.

Wice words. Not a developer myself, so I don't know your options. But a wider audience could mean more funding..... Your app is a hefty download. I don't know how tight the two main binaries are tied to the libraries and the other things that are attached. Seems like a lot is going on

They have done their development on a very recent install. Unless you develop for a fixed repository or a PPA they should try to make their software useful for people with older versions. To do this, they have to compile and test their binaries in an environment where they expect to find their users. A good starting point would be the FORMER Ubuntu LTS (22.04 in this case) and/or the current Debian "oldstable" (currently Debian Bullseye), whichever of the two who has the oldest development framework. In this case it was libc which caused the havoc. To see whats going on under the hood, open a terminal and place yourself in the directory with the binary. Start it in the terminal preseeded by a dash and a slash: boss@kjeller-mint:~/tmp/CosmicClaritySharpenDenoise_LINUX$ ./SetiAstroCosmicClarity [PYI-2210:ERROR] Failed to load Python shared library '/home/boss/tmp/CosmicClaritySharpenDenoise_LINUX/_internal/libpython3.12.so.1.0': dlopen: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.38' not found (required by /home/boss/tmp/CosmicClaritySharpenDenoise_LINUX/_internal/libpython3.12.so.1.0) In this case, it's my version of glibc thats to old. We both (Mint Virginia 21.3) have libc ver. 2.35. Debian Bullseye have 2.31. Standalone binaries compiled for linux are not further backwards compatible than the machine they were compiled on, unless you take precautions and include what's needed. On the other hand, once they are compiled they are forward compatible for many, many years. My tip would be to build the binaries in Debian Bullseye. That would cater for 95% of potential users. If we want to run this on Linux Mint today, we have to upgrade to Mint 22, Wilma. It is almost three years until end-of-life of Mint 21.3, and I will keep it at least one more year. So no CosmicClarity for me.

But not yesterdays machines.... Will not run on the former Ubuntu LTS. At least not on my Mint 21.3 _Virginia based on Jammy. Your binaries demand `GLIBC_2.38' while Jammy ended up on 2.35. We AP'ers are conservative, and reluctant to run the "latest and greatest". Would be nice if you considered a more conservative approach on this issue.

https://drive.google.com/drive/folders/1cL0h-7WNhmfF408RQDx-aPGJNGp1gBWj

+1 Just got one going. I took the compile route as you described, but had lots of trouble. Puzzling, this always works. Things would not compile, and those that did throwed segfaults and error messages. Even Jasem's PPA don't behave as i should. Things installs OK, but drivers crash. Don't trust them to work, test the install before first light, and have a backup-image. These are combos that works for me on eq-mod, gphoto, asi and touptek: - 64-bit AMD: Bodhi 7 - based on Ubuntu 22.04 LTS. Mint is my daily driver, but no version is stable on the newest INDI on my machines. HP EliteDesk 800 and Thinkpad T450. - RPi5; 64-bit ARM: Armbian_community_24.11.0-trunk.202_Rpi5b_noble_current_6.6.51_gnome_desktop.img.xz -- Based on Ubuntu 24.04 LTS. Both Bodhi and Armbian accept the PPA, things installs OK and everything I need work. Install tasksel and use that to install xfce4. That pulls in xorg, and you can use the VNC-solution of your liking. Bodhi comes with lightdm, Armbian with gdm3. I tried to replace gdm3 with lightdm, but that failed. Get used to it. Stock Ubuntu might work, but that is not an option for me. To unstable, to much overall. Ubuntu has become very business-oriented over he years, and have stuffed in all kind of things we don't need. Things that phones home, phones to the cloud and things that hangs and crashes your computer. Be warned.

Makes no sense. The whole idea that the scope should point in a specific direction when calibrating is nonsense. You calibrate the guider EVERY TIME you start to guide, and you do it after you have framed the target. In KStars/Ekos you tick a box to force calibration before every start of guiding. There is also a box you can tick that forces new calibration everytime the scope slews. The calibration takes under one minute, and the scope tracks as normal while doing it. When you slew a scope, short or long, many tings can change. The gears have travveled. Balance. Wind. Seeing. Skyglow and light pollution. Unless you have high-end equipment or is dedicated to and understand the calibration logs, it's safest to do it this way. I sometimes find the guiding much improved after a meridian flip. Why? Because during the previous run the parametres may have changed during the night, and the calibration you started with 4 hours ago don't fit anymore. With a new, automatic calibration the guiding gives lower RMS after the flip than before. Lastly, don't worry to much about the guiding. I've had nights where I've not been over 0.3 and others where I could not get below 1. No big deal. Guiding combined with dithering has made a change for me. It can hide sloppy PA, and it's handy to know the target stays framed.

Telescopius is the place where I sort my targets. When in the season, late/early and which scope/camera combo. When it's time, I tells KStars to slew to the target, and the tedious work of setting up the frame starts. I take preview exposures at 15 sec and high gain/ISO, and frame the composition based on the visible stars. If I have to loosen the camera for rotation, I swing by Vega for a focus check before the run starts. KStars have a "Load and solve - Slew to target" function. You can build a "library" of framed targets you plan to image on not-so-clear nights. If you take notes of rotation (so-and-so much clockwise/anticlockkwise) you can be up and running in no time. I use Stellarium on PC to get a notion of where in the sky the targets will appear, and how they will travel. If you delve into the settings there, it will show you everything you need, but it may become overwhelming and slow your computer down. The planetarium in KStars arn't usable in this way, at least not on my computers. To laggy and to coarse. Much depends on platesolving in my setup. I use local platesolving (the built-in solution in KStars/Ekos) and have all the needed index-files on my computer. Much depends on that platesolving works without a hitch. Even if you are a bit out of focus. Take notes of how deep each camera sits in the focuser on the different scope/camera/reducer combos. Searching for a star to focus on with a long scope way out of focus can be a nightmare.

It is. As you said, the mount stood roughly where it should. Guiding is effective if the intervals ain't to long, and the short scope you used (430mm) is pretty forgivving. I have an obsy, and a HEQ5 on a pier. I did polar align, but only once. Three years ago. Don't think it matters that much as long as you guide and you'r not totally in the wild.

Boiles down to philosophy, I want real colors, and I won't let anything tamper with it on it's way to the sensor. And the days around full moon means rest and restitution. Long nights this far north, I know from experience there will be plenty of integration time this winter too!

Hope so. Must learn to tune it. And the smaller sensor size (for me that are used to old Canon's) means that I don't have to bother to much about what happens near the edges. The fullframe 5D can be demanding. As for filters, don't use them. Bortle 3/4. I'm also hesitant to use any glass between the mirrors and the sensor. I also have two newt's, one f/4 and one f/5. The f/4 must have a flattener, with the f/5 it depends on the target. How much I can crop out.

Hesitated to do that, would not resample. Now I see that SGL HAS RESAMPLED AND SCALED, so the whole post has been in vain. But I see your point. Some makes an big issue of pixelscale. The IMX294 has pretty big pixels, 4,63um, but the 5D has even bigger pixels at 6,41um. A scaling would show if there are some truth in this. I got the 8" RC (1600mm focal length) and the IMX294 for use on galaxies and small, but not to dim targets. Season has just started for me, looking forward to test it some more.

Full moon, not much you can do. Did a small comparison; 5 frames with my new IMX294, and 5 more with my trusted Canon 5D. Not super-impressed by the new kid in town. Top: Canon 5D MkII, 120 seconds, ISO 800. Stacked with 5 calibration frames of each, color calibrated and a pretty hard stretch. Bottom: Touptek IMX294, cooled to -10C, 120 seconds, gain 398, offset 100. Stacked with 5 calibration frames of each, color calibrated and a pretty hard stretch. Scope: 8" RC, target M82. Blindingly bright and full moon, but no moonlight into the tube. No skies. 10 degrees celsius, that means the Canon had a big disandvantage, as I turned on the cooling on the Touptek. Not sure what to expect. Stacked and photometric color calibrated in Siril. Both images are stretched with levels in Gimp until the histogram looked similar. Pixelscale 1:1, only crop, no resampling. The IMX294 has smaller pixels and brings the galaxy closer. That means that the targets brings more light into the frame, and the background gets darker as long as I insist on identical histogram peaks. M82 will be my next target with this scope when conditions permit, not sure what camera to use after this.

As you should do. On Debian-based systems there are four main types of installing packages: 1: From the distro's main repos. The recommended way. Sometimes you have to engage parts of the repo in /apt/sources.list or files in /apt/sources.list/d due to non-free software or software with binary blobs. This is the case with the indi-asi-driver in Debian stable. Neverthelsess, what you install in this way works 100% in 98% of the cases. Tested and trusted. 2: From repos you add yourself. You add a line in /etc/apt/sources.list or a file in /etc/apt/sources.list/d. Often done in order to use stellarmate's repo onto Debian-based systems. If the external repo is based on the same distro, this also works well most of the time. In the example of stellarmate, the newest version is compiled against Debian Bullseye. This means that if you use this on an original RaspiOS for RPi5 you might face problems, it's based on Bookworm, but it's worth a try. If it doesn't work, you just uninstall and remove the access to the repo. 3: From PPA's. This works only on Ubuntu-based systems (which in turn are based on Debian). Jasem Mutlaq's PPA for KStars and INDI is a good example. This works well in most cases, but as the Ubuntu family widens out this approach is starting to crack up. If you stick to Ubuntu, you'r good, but if you use Mint, Armbian or another member of this family you might face problems. Two or three drivers can work well, but if just one crashes you're out. Also a safe way, you can always uninstall and your system is pristine again. The PPA can be unhinged. 4: From source. This is the most complicated way, and you have to know what you are doing. You can make your install unbootable. Been there, done that. There are plenty of scripts to help you in this endevour, but it doesn't take much effort to learn the basics. The guide on https://github.com/indilib/indi-3rdparty is very good and holds your hand on the way. Take one command at a time, learn what it does. Read error messages, use google, and keep on until everything is in place. Number 1 and 4 should give you stable and solid installs. Recently, especially on arm-based hardware, I've had problems with all four methods. You should troubleshoot any driver that causes problem BEFORE you wipe or reinstall. Just a few commands can give insight in what's happening. Sometimes it's just a small detail. * Open the directory /usr/share/indi Here there are .xml-files for different hardware groups. Open the one that matches the defect driver, i.e. indi_asi.xml in a text editor. * Look for the right hardware and the driver assignment, i.e. indi_asi_ccd if you have just one ASI-camera and it causes problems. * Start your computer, don't touch any software. Turn on the device (camera), and open a terminal. * Type in this: indiserver -vvv indi_asi_ccd No sudo, and replace the name of the server in question. * Read the output. See if anything means sense. Terminate with Control + C * If you run a remote indiserver, SSH into it and pull the same commands. The directory structure should be the same, unless you are using something really special. If you get a message that says something like "bind: Address already in use -- good bye" the server is already running. Stop it with killall indiserver and start it from fresh.

If you are building from source, you don't add Jasem's repo??? AFAIK ppa's are not supported in Debian and Debian-based distro's. Maybe I'm wrong and things have changed, but ppa's used to be for Ubuntu and Ubuntubased distros. Like Mint. Raspios is based on debian. That said, all distro's based on Debian 12 Bookworm HAS THE MOST COMMON INDI-DRIVERS IN THEIR REPO's ALREADY! INCUDING THE ONES FOR ASI! You just have to add 'contrib and 'non-free'. Some are missing and have to be buildt from source, mainly the ToupTek-derived cameras. Armbian has images for RPi5 based on Ubuntu Jammy (22.04 LTS). https://fi.mirror.armbian.de/archive/rpi5b/archive/ With these images you just add Jasem's repo and install as usual. No building from source. But be aware: I've had mixed experiences with this approach. Jasem's repo is in many ways a moving target. On a bad day you can have driver chrashes and connection problems. Not nnecessary the repo's fault, more the fact that the family of these distro's starts to get big, and the variations between them starts to show. The ONLY distro based on Jammy that gives me consistent installs is Bodhi 7. Mint 20 and 21 has been my daily drivers for years, but lately I've had trouble with both my EQMOD and TOUPCAM drivers on Mint 21.3.