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.
After looking at this picture I don't think the issue is amp glow, this is some of the subs not aligning correctly probably because of clouds or haze. After the image analysis is complete sort the order by quality and then look at the low quality ones. You can also sort by the number of stars and look at the ones with the least amount of stars.
Also on the integration tab you can set the number of images to integrated form 80% to 90% and this will usually remove any bad images causing issues with the stack.
@dheyergmail-com yes, this is my main issue after stacking. Okay, I try to use 80-90/100% right now.
Okay..... WTF???? 😳 😳 😳
Thanks for uploading the image of the Bad Pixel Map.
I can already see the cause of the problem with the strange artifacts. In the Bad Pixel Map you can also see a part of the amplifier glow on the right side. Actually, only hot pixels should be visible, but parts of the amp glow are also detected as hot pixels. As a result, too much of the lights are subtracted during calibration.
Astropixelprocessor automatically creates the bad pixel map in the default settings from the flats and darks.
There are now two options, either in Tab(2) and change Bad Pixel Map from Automatic to Disable. Then reload the images (lights, flats, darks and dark flats) then calibrate and stack again.
Second possibility is to take separate darks but the cooling of the ASI294 must be off!!! Exposure time 300s approx and 20 images should be enough.
Now load again in tab (1) only these darks and a current masterflat, then in tab (2)
with activated automatic (default setting) create the bad pixel map. So with Create Masters button. The amp glow should now have disappeared from the map, at least that's how it is for me.
Now the created bad pixel map can be loaded with the other subframes in tab (1) for each session. Astropixelprocessor notices this and no longer creates a new one.
I always use the second method.
Best regards.
@tobiasthale
The noise on the edges is normal if you are dithering during imaging. If you save the registered frames and look through them you will see some have back bars on the edges.
Hm, I can´t accept the way only deactivate the bpm in app. Because a friend of mine has the same camera and stack too with app and had the bpm at autoamtic and he has nothing an issue like mine.
I show you the bpm of him and my again.
The only difference between him and me is the temp of the sensor. He use -10° and I have used -15°.
Could you post your image and calibration files on dropbox or google so we can try processing it? I see you have two sessions also - could be an issue there.
@astrogee yes I can upload all the data at google drive and put the link in here.
Thanks for uploading the image of the Bad Pixel Map.
I can already see the cause of the problem with the strange artifacts. In the Bad Pixel Map you can also see a part of the amplifier glow on the right side. Actually, only hot pixels should be visible, but parts of the amp glow are also detected as hot pixels. As a result, too much of the lights are subtracted during calibration.
Astropixelprocessor automatically creates the bad pixel map in the default settings from the flats and darks.There are now two options, either in Tab(2) and change Bad Pixel Map from Automatic to Disable. Then reload the images (lights, flats, darks and dark flats) then calibrate and stack again.
Second possibility is to take separate darks but the cooling of the ASI294 must be off!!! Exposure time 300s approx and 20 images should be enough.
Now load again in tab (1) only these darks and a current masterflat, then in tab (2)
with activated automatic (default setting) create the bad pixel map. So with Create Masters button. The amp glow should now have disappeared from the map, at least that's how it is for me.Now the created bad pixel map can be loaded with the other subframes in tab (1) for each session. Astropixelprocessor notices this and no longer creates a new one.
I always use the second method.
Best regards.
As you can see in the pictures posted, the amp glow is more visible at -15° than at -10°.
As described in the quote, make separate darks and do not cool down the camera.
https://drive.google.com/drive/folders/15WSTNs768pSfqOJu_XdT7euElxAeXI0_?usp=drive_link
Here is the data.
I don't see anything so far in the images but there were no darks so calibration could not be done. About the bad pixel map. I do not see it in your BPM but it was generated without the darks - I see the amp glow in my bad pixel maps when generated with darks but I have to say that I think it shouldn't be that way. I think the amp glow on the 294 may be so bad that APP declares them bad.
Anyway, Can you add you darks to the set?
EDIT: Here is my result so far without Dark calibration
Regarding the possibility of a problem with the BPM, here is a discussion that may be helpful. There is also a suggestion that different settings for creating the BPM may help in some cases. https://www.astropixelprocessor.com/community/main-forum/adaptive-pedestal-creating-dark-artifacts/#post-26257
Oh, my bad. Here are the darks.
https://drive.google.com/drive/folders/1dmfSraRMRltXu1UcM8AtiXi--FfzzB9Y?usp=drive_link
Hi @tobiasthale,
So its definitely the BPM. I found that the "artifact" which after looking more closely I would call a "smear" is created by applying the BPM and it shows on individual calibrated images as well as the stack. I was able to reduce the effect by increased the hot pixel kappa in the calibration tab. However, there was still some smear even with max kappa. The problem is that the amp glow is so bad that the BPM has an area - or streaks - of hot pixels so there are no good pixels in between for interpolation to blend the data. Data is just repeated and you see a smear. My final solution was to not use the BPM. It may be that your friend, working at -10c has just enough difference to create a useable BPM. I also use -10c and I do see slight amp glow effect but not the smear artifact. I hope this helps. It's been helpful to me and I can see that in the case of the ASI294, probably best to just not use the BPM... unless Mabula can come up with a fix 😉
I have recently noticed that amp glow from my ASI294MC is not completely removed on some integrations. Does amp glow increase over time from that camera? Could the recent betas have some change in the reduce Amp-Glow algorithm?
I have recently noticed that amp glow from my ASI294MC is not completely removed on some integrations. Does amp glow increase over time from that camera? Could the recent betas have some change in the reduce Amp-Glow algorithm?
Yeah, APP suggests new darks every year or two. I do a new batch every spring. The last batch I did was only with only one exposure setting and I'm counting on APP to do dark scaling. I've decided to keep things simple, everything is at -10c, offset=30, gain=121/180/240, and dark exposure=480s only - could maybe even have cut that exposure to 300s.
I have recently noticed that amp glow from my ASI294MC is not completely removed on some integrations. Does amp glow increase over time from that camera? Could the recent betas have some change in the reduce Amp-Glow algorithm?
Yeah, APP suggests new darks every year or two. I do a new batch every spring. The last batch I did was only with only one exposure setting and I'm counting on APP to do dark scaling. I've decided to keep things simple, everything is at -10c, offset=30, gain=121/180/240, and dark exposure=480s only - could maybe even have cut that exposure to 300s.
Actually, it just occurred to me that maybe darks should be done with less exposure to prevent the extreme amp glow from resulting in a bad BPM. Maybe one or two minute exposures would work better and APP can scale them up to longer exposures.
You are right that I probably need to update my dark files. I am not sure but can darks be scaled up? My notes (not sure of the source) say that darks can only be scaled down to shorter exposures by APP. My notes also say that only darks that were created with bias frames (as opposed to darkflats) can be used for scaling. Is that correct?
Yeah I vaguely remembered about needing the bias so I looked and found this thread confirming that but also says you need proper darks for sensors with severe amp glow. So scaling doesn't work with the ASI294 ;(
I am not sure, but I seem to remember that it is not the amp-glow alone that prevents scaling, but also whether it increases linearly as exposure times increase. It might be interesting to try scaling with an ASI294 and see the result.
@astrogee yes, I try to put all the kappa settings in the BPM tab at maximum and this can't handle the ampglow too. Here is the result.
Can i ask why do this without cooling, should it not match the lights are cooled.
Hi @moviecells, indeed like Vincent indicates, no cooling gives much more dark signal and hot pixels so the hot pixels are detected easier and thus the BPM will become more robust if you create a BPM with uncooled darks 😉 But, to be clear, even on well-cooled darks it works very well !
And yes, only use the uncooled darks to make the BPM, don't use them for light frame calibration 😉
Hello everyone. You have to make separate darks for the BPM and the cooler power has to be at 0% and let's say 300s exposure time. This is recommended by the app developer.
@tobiasthale, so what I did was create a whole set of master darks but I only used the shortest exposure for generating the BPM - i.e. the MD for exposure = 120s - and I turned up kappa to 20. This gave me a BPM without the streaks. It should not affect any images adversely. I think we have to count on the MD being more important for calibration than the BPM.
So I think my issue is solved. At my new project the Sadr region and surroundings I have no streaks after stacking, also with the BPM. I only change my sensor temperature from -15 to -10.
Thanks to all!
