May 27 2026 APP 2.0.0-beta45 has been released !
Fully Multi-Threaded LNC, many improvements for the registration engine, platform upgrade, and further tuning of internal memory consumption and memory release back to OS.
Apr 14 2026: Google Pay, Apple Pay & WeChat Pay added as payment options
Update on the 2.0.0 release & the full manual
We are getting close to the 2.0.0 stable release and the full manual. The manual will soon become available on the website and also in PDF format. Both versions will be identical and once released, will start to follow the APP release cycle and thus will stay up-to-date to the latest APP version.
Once 2.0.0 is released, the price for APP will increase. Owner's license holders will not need to pay an upgrade fee to use 2.0.0, neither do Renter's license holders.
Hi all,
Recently I aware that post-processed editing from 32 bits tiff would make images have higher dynamic and more vivid. However, I found that the 32 bits tiff from APP was very difficult to handle in Lightroom and Photoshop. I solve this problem (and noise reduction tool) by using PI after linear processing from APP. But when I was asked by my friends that 'do I really need to go to PI?' I come back to think again. Most of us have some image editing softwares. And they have strength in adjustment and noise reduction. Instead of editing our precious astro-images in 16 bits, it would be nice to have 32 bits images that are 'easy' for post-processing retouch. These 32 bits tiff images, when imported in other softwares, Â should be look almost the same as be seen on the preview window of APP. Here is my final image of the Cygnus wall using APP, PI, and Lr. I took this image with QHY163m, Takahashi TSA120, Antlia 3.5nm SHO filters. Total integration time was about 9 hours.Â
Clear skies
Kijja
Your results look fantastic. You probably have excellent editing skills but I wonder if one really needs 32-bit editing. I use APP to auto-stretch (in 32-bit) and then output for editing in 16-bit tiffs. The final editing is done in Lightroom and at this stage - no more stretching - 16-bit seems to be sufficient. If there is noise in the image at this stage, it would have to be in the 8-bit range to be visible, far above the 16-bit noise floor.
However, I admit that human perception is an amazing thing. We seem to be able to perceive the most minute details even if we can't see it directly - like fine dust on surface - we can't see the dust be we see the loss of lustre on the surface.
@astrogee, Thank you for sharing your point of view. Until recently, I used to think like you. I probably ask a different question 'how to make best use of 32 bits APP tiff file?'. To be clear what I meant in this topic, the two images are made from final image but exported to Lr in 32 bits tiff and 16 bits tiff. Both were exported from Lr in highest quality JPEG without any adjustment. I think they were quite different.
Cheers,
Kijja
Wow, the difference is clear. But I wonder if the difference has more to do with colour space and conversion method than bit format. So it looks like APP's conversion to 16-bit is lacking, or at least, its using a different colour conversion method - for example, relative colorimetric vs perceptual - than LR. Also, it looks a bit like a contrast difference, something you see sometimes when converting between Adobe RGB and sRGB.
I have no idea if increased bit depth is the main cause of the difference between these images. Although the results from PI may not hold true in APP, but I think that 32 bits tiff image file would worth to be explored. Right now stretched 32 bits tiff files from APP are not suitable for making final images for publication. I've tried editing un-stretched 32 bits tiff from APP in Photoshop with some promising results (and difficulties!). Hoping that Mabula will make a better use of 32 bit tiff files that more easy for post process editing.
Cheers,
Kijja
32-bit shouldn't be really necessary I think as the signal in 16-bit can make use of the entire data range already (right?). But a lot will also depend on how the other package is loading the data in. Usually the other package will have to apply its color profile etc. It's not always a 1 to 1 thing.
