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.
I know everyone's been asking for a save-my-work option, but I have an alternative that would largely use existing code: a standard folder-layout model and "auto-load" feature. As I saw suggested elsewhere in this forum, a persistent "Master" folder setting where you keep reusable calibration frames (dark, bias, BPM) would save a lot of clicking. APP already knows how to match darks with lights, so you could just have one for each combination of gain and exposure in use and APP could grab them all.
As now, the user would still be prompted to select a "working" folder, this would be where lights and flats go. Each session is a folder in the Working folder, and APP assigns the session name based on the name of the folder. Within each session folder are "Lights" and "Flats" folders (or Aries could decree any other name they like!). So select one location, and the single most incredibly tedious task in APP is accomplished with one click (or two, if you add a confirmation dialog with "load lights and flats from standard locations?" -- three if there's a "don't ask again" checkbox!).
Maybe the session folders have to be named according to a convention too, so that people don't choose say, their All Pictures folders by mistake and have APP load up years and years of images!
You can get more complicated from there. The user could simply iterate through folders with an "Add Session" dialog box that appears by default, rather than auto-recognizing session folders below a home folder; click the "Done Adding Sessions" button when finished. APP could mandate that folders below "Lights" be named according to a particular convention, e.g. "H-alpha", "Red", etc., so that one could get by without a FILTER tag in a FITS file (dunno how often that use case comes up, I imagine most people doing multichannel imaging have files with the tag!).
Of course, none of this would obviate the current mechanism of picking the files out of folders onesy-twosey, so no one would lose any functionality at all. People who didn't like the prescribed folder layout could ruddy well ignore it.
And of course one could imagine UI that allows people to define their own layouts. But I'm going for max-bang-for-programming-buck, here.
Thanks for the suggestion @rickwayne. I think it would be very hard to think of one way to organize the data that everyone agrees with. But I will pass on your suggestion to Mabula to see what he thinks of it.
Â
Wouter
I agree that one size won't fit all. Then again, no one has to use any standard layout -- it's just an additional bonus for people who can easily adjust even if only one layout were provided.
I can imagine a Java properties file that would contain the various folder names and could contain relative or absolute paths. The standard one would ship with APP and live in some standard place (e.g. installation folder or user's home folder).
If people wanted to change the layout, everybody who can do AP can wield a text editor, or we could create ones for various layouts and post them here.
Additional refinement: the master file can be overridden by a local one. So the user could edit the file to put in the absolute paths to their master calibration frame folders, and either leave the defaults in place or change them to suit. By using relative paths, a user would never have to change anything if they followed a standard layout, APP would just recognize and load their lights and flats, master BPM, master bias, and perhaps even master darks. Or they could produce a different layout for a given APP run if they preferred and put it in the "working" directory.
Finally, of course, a user interface for generating these things instead of the UNIX-greybeard style of editing text config files would be great. But I'm trying to think how to give the most people the most bang for the least programming buck.
I'm only a few years from retirement. Maybe I can get Mabula to hire me as a volunteer software developer. 🙂
