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 used a telescope at iTelscope and when downloading the masters I got the following message: "Bias Frames do not scale with RBI CCD. Please use matching darks."
I understand that the "Residual Bulk Image effect" brings difficulties to produce a conforming "master bias" because on some Full-Frame CCD detectors suffer from kind of “visual memory effect”. Bright parts of the previously acquired image are visible as weak and blurred image on the following exposures, even if they are dark frames, taken with a shutter closed.
Under APP 1.075, is there a solution to remedy this difficulty? If yes, how do that ?
Tanks in advance and have a nice day.
This topic was modified 7 years ago 2 times by Max Surlaroute
To properly process images from a RBI sensor, you will need to make sure that you have the correct calibration data. You will want to calibrate the lights with darks and the flats with flat darks.
So that message while downloading indicates that you will need to use matching darks for your lights and matching flatdarks for the flats (the masterflat should be okay off course and properly created by iTelescope). Whether you use the Masterbias or not is not that important, because the bias signal will off course be in the darks and the flatdarks.
Now the masters should be properly created by iTelescope and if you apply them to your lights, you should end up with good calibrated data. The RBI signal should be calibrated out by the darks and flatdarks giving you correct calibrated data. So the calibration data should take of the RBI signal. This is an example of iTelescope T31 with a RBI sensor:
Light frame stretched, you can see the RBI signal of the sensor:
MasterBias, MasterDark, MasterFlat, check the difference between the MasterDark and the MasterBias, on the MasterDark you see more of the residual signal of the sensor and that is also visible in the raw light frame:
The calibrated light frame stretched with these masters:
So if you have downloaded the proper masters from iTelescope, you should be able to get proper calibrated frames without any magic on APP's part or your part. The key is having correct calibration data to start with 😉
Have you tried calibrating your lights with the masters that you downloaded? Is it looking correct or not?
Kind regards,
Mabula
This post was modified 7 years ago by Mabula-Admin
Wow, first time I hear about image retention as a sensor side-effect. Just read a bit about it, very interesting. Is this just the case in older CCD sensors? I never came across it..
According to my very recent research on the web since my first questioning on this RBI phenomenon, it would not seem so rare and that even on high quality CCDs. It describes a set of solutions or how to deal with it according to the severity of the RBI phenomenon (preflash, etc.).
Indeed I tested your solution and the result seems acceptable to me in the circumstances.
However, when analyzing the BAD PIXEL MAP (BPM) file created from the MASTERDARK (MD), this one had a striking similarity to the MASTERBIAS (MB) that I often used.. I asked myself the following questions:
Q1- Would it have been appropriate to use a BPM as an MB in the absence of this one?
Q2-If yes, how do I proceed or if not, how does APP use BPM during treatment with or without MB?
Indeed I tested your solution and the result seems acceptable to me in the circumstances.
However, when analyzing the BAD PIXEL MAP (BPM) file created from the MASTERDARK (MD), this one had a striking similarity to the MASTERBIAS (MB) that I often used.. I asked myself the following questions:
Q1- Would it have been appropriate to use a BPM as an MB in the absence of this one?
Q2-If yes, how do I proceed or if not, how does APP use BPM during treatment with or without MB?
Q1: no, a Bad Pixel Map is something completely different than a MasterBias, they serve very different purposes...
Q2: not applicable then 😉
The MasterBias is needed to subtract the bias signal with it's bias offset/pedestal. And if there are fixed patterns in the bias signal, the bias subtraction will remove those from the lights/flats.
The Bad Pixel Map is an 8bit map with only 3 values. 0 for cold/defect pixels, 127 for linear pixels and 255 for the hot pixels. The application of the BPM is not a subtraction like a MasterBias/MasterDark. It's also not a division like a MasterFlat.
The Bad Pixels in the BPM (values 0 & 255) are corrected in the light frames by interpolation of surrounding linear and thus good pixels 😉
