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.
Hi there,
I have just started a trial of APP, and I have some data which I will be stacking. Â This is a mix of narrowband subs, mostly at 300 seconds unity gain, but some at high gain and some at different sub lengths; all have appropriate temperature matched darks and matching flats and flat darks. I love that APP lets me specify both a filter and a session, and I am hopeful that it's going to be able to stack everything correctly (this is going to take a while, it's at 12% complete on calibration so far, so I have plenty of time to write this post ;-)).
I have a question which I can't seem to find an answer to on the forum. My data was collected over about six days with a mix of capture software, including SharpCap and N.I.N.A. My camera has a 12 bit ADC, so the values of each pixel are in the range 0-4096; I always save as FITS. Sharpcap by default scales the images up to 16bit values (effectively bitshift right four, or multiply by 16), so each pixel is in the range of 0-65535 (obviously with a step of 16 between each value). NINA didn't used to scale, so you'd get a FITS file which was a 16 bit FITS but each pixel was in the value 0-4096 on a scale of 0-65535. For some stacking software this doesn't seem to make a difference, for example the excellent ASTAP seems to automatically handle the differences, even say a calibration frame is scaled and a light frame not scaled, or vice versa. However other stacking software (notably Deep Sky Stacker) mandates that all files be either scaled or unscaled (and there is an option in its FITS settings to multiply by 16, which makes a dramatic difference to the stacked output if you are using unscaled FITS).
So, my question is -- how does APP behave? Do I have to scale all of my images up? Will it automagically notice that some images are in the range of 0-4096? Is it looking at FITS headers and doing the appropriate thing? (Actually I'm not even sure whether NINA sets those headers right for unscaled images -- I'm just looking at a file which has values in the range 61-4094 but it has BZERO set to 32768 and no BSCALE header). What should I be doing to make this lot behave correctly with APP?
Many thanks,
-simon
Hmm...well I messed something up somewhere, I must have missed attaching one set of darkflats.  Any chance that APP could tell me which flats are actually missing the matching dark flat so I can see where I screwed up?  I clicked OK and assumed it would point it out, but it just carried on calibrating! 🙂
Â
Hi Simon, welcome to the forum and thanks for trying APP!
So regarding bit-depth, I don't think APP minds as long as you have the proper calibration frames of each session. Since you're using different capture software, this is basically the same as "different sensors" funny enough, but that's how you should think about it and you can select the option to reflect this. It's usually best practice to just get the data from the camera, without any upscaling or other processing going on if possible, just to make sure the software isn't changing the data (which happens, depending on the conversion software used, many change the noise levels for instance).
And yes, would be nice to have more warnings beforehand I agree. Nice tip for @mabula-admin.
Oooh, telling it that I have "different sensors" and using the functionality already in place to stack from various setups sounds like exactly what I need -- thank you. Â I'll need to change some of the darks (I took them in 16-bit scaled) but I can batch process them with fitsworks4 and just have two sets so that each session matches.
In terms of whether or not to upscale -- the vast majority of 12 or 14 bit astro cameras upscale in their drivers, e.g. if you have a 12 bit ZWO or ASI camera then the driver actually gives you a 16 bit image.  This actually makes sense, as the FITS file format doesn't actually specify a 12 or 14 bit file format, so you're storing in a 16 bit file anyway.  That said, my camera is an Altair, and their drivers give you 12bit data dumped inside a 16bit FITS file -- which is fine if the program processing it knows that.  SharpCap for example has an option to leave the raw data as is, "for photometry purposes" (but Robin argue's against doing so here https://forums.sharpcap.co.uk/viewtopic.php?t=644), and NINA used to leave the raw data as is but accepted a change request I made to allow bit scaling like this.  It's a lossless operation and simply moves Altair cameras into line with other manufacturers, and means that processing software doesn't go crazy 😉
