2026-10-09 APP 2.0.0-beta48 has been released !
This is mainly a bug fix release for the reported bugs in beta47. In addition it has a significant User Interface performance improvement noticable when you need to process 1000s of images in APP.
2026-10-03 APP 2.0.0-beta47 has been released !
This is a very big release... many code optimizations/rewrites, many parts of APP are much faster and more precise, especially star analysis and registration are much faster ! Big mosaics will go much faster 🙂
And we introduce a new preview filter, which includes the new Adaptive Deep Sky Stretch and a General Levels Stretch, this has been long over due. The old preview filter (the panel on the right side to stretch and preview your data) has not been updated for a couple of years and it is a critical part of any APP session.
Adaptive Deep Sky Stretch or ADSS is a much more intuitive stretch algorithm. It is also color preserving (which is a great new addition in itself ! ) which means that the highlights are no longer bleached, color is maintained from the linear data while stretching. You can simply stretch your data using the sky background level and signal width sliders which work much easier and more intuitive. You no longer need to fiddle with the old complicated sliders with zoom buttons. All the zoom buttons for the sliders are made redundant. And you can enter slider values in the slider value fields yourself. I will make a youtube video in the coming days to explain and fully introduce ADSS. Once the video is ready, it will be highlighted on the forum.
RGB Combine upgrade !. The RGB Combine Tool has been rewritten mostly. The tool is faster and easier to use and most importantly, the Luminance slider to inject a luminance channel or channels into the RGB composite is now working correctly. It no longer bleaches the RGB colors. Combined with the new ADSS preview, you will get much better and easier great composites with great color! I will also explain this in a new youtube video.
Hello Vincent, Hello Mabula. I'm having a problem, when I mount a Samba Nas share in Ubuntu in the file manager and want to open a Fits file, I get a message
"This fits file seems to be incomplete and/or corrupt !!!"
But with DSLR files it works.
When I copy the Fits files to the hard disk, they can be opened easily. Other applications like Gimp, Pi can open and display the Fits files via Samba.
Interesting, that seems to have something to do with the file transfer maybe, I'll forward this to Mabula. What kind of NAS do you use and I assume that connection is rock solid? @mabula-admin
Â
It is a Synology Disk Station. The connection is flawless, and the NAS has been performing for years without any problems.
Ok, I've notified Mabula to check your post and see if he has an explanation for the difference with your fits and cr2 files. Normally I wouldn't recommend processing anyway using an external NAS though, as APP needs fast disk access usually.
No processing takes place on the NAS. I only move projects I am not working on to the NAS because of limited space on the SSD of my PC. But sometimes APP wants to access them via network so I don't have to copy them back and forth.
Ah ok, well let's see what Mabula might say, he'll be here when he has some time.
@vincent-mod
Any update on this? My workflow usually has my subs stored on my NAS (QNAP in my case, sharing via SMB) with working directory being on the local drive. Never had an issue before (let's just say bandwidth is not a bottleneck on my network) but always worked with NEF files.
Had a bunch of FITS subs to process yesterday (new EKOS install, forgot to check the file format) who would not process as described above. After a few choice words at potentially loosing a moonless night's worth of imaging, I found the above thread and just copied the FITS locally, and they worked without problem. Extremely weird behavior, I'm guessing APP is trying to read the file header before it's all cached and fails? Don't know enough about the FIT format to analyze this issue further myself.
Not really, it has to do with how APP handles the data and processing it needs a fast bandwidth. I'm sure your network connection is fast, but internal connections are way faster, this is where things can go wrong.As to why it did work with the NEF files, I'm not sure.
I am having a similar problem having used my Synology NAS with APP for over a year.
The problem however ONLY occurs when I am using an rsync'd folder - it's fine when I either use a regular "LAN" NAS share or even (and here's the amazing part), when I use ZeroTier and load the images over the WAN NAS share.Â
But if it's local I get the error above. It of course has me completely puzzled. Just to make sure the image wasn't corrupted in the process of moving it over I double checked and copied the image over to my local hard drive and, it loaded fine.Â
Super strange!
Yay! (I think!)
Being quiet puzzled about this (especially as PixInsight coudl open the same shared files fine) I discovered a little setting in the Advanced Permissions tab that was enabled on the destination - once I switched that off it seems to work fine - let's see....Â
Interesting. I have no experience myself with using data via a NAS, I only use a NAS to store my projects.
