Mar 28 2026 APP 2.0.0-beta40 will be released in 7 days.
It did take a long time to have the work finished on this and it will have a major performance boost of 30-50% over 2.0.0-beta39 from calibration to integration. We extensively optimized many critical parts of APP. All has been tested to guarantee correct optimizations. Drizzle and image resampling is much faster for instance, those modules have been completely rewritten. Much less memory usage. LNC 2.0 will be released which works much better and faster than LNC in it's current state. And more, all will be added to the release notes in the coming weeks...
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.
Just ran with out darks and pattern is still there see attached
, i did notice another problem that night not happened before look at this lum light same night same target and the is a ring pattern light and dark just above and to the right of M51 and idea what that could be ? can't tell if its all colous or just lum its easy to see in that channel
Â
Strange, what is your setup exactly, how do you connect the data- and powerlines when taking photo's? I'm wondering if it might be a power issue on the data lines or something. The strange rings I can't explain, that is more likely a flat and optical problem.
telescope is am william optics GT81 camera then ZWO filter wheel with Baader filters ZWO ASI294MM USB 3 to a PC. I don't think it can be a power issue as i said i ran the camera in a different mode the night after and it was fine. I will have to try Bin2x2 again to see if the problem may be the camera i will report back as soon as the weather clears could be a week looking at UK weather.
Â
Mike
Is the USB3 a direct connection to the PC or are you using a USB hub? I do know hubs can sometimes cause an issue. Also, I do see issues sometimes when not everything on the scope has a common ground connection, which can result in power leaking into data lines. Just thinking about any possible issues..
I run 4 USB 3 active extension cables each is 5m long each one has a common power at the telescope end as they are active. I have already tried a swap of cables and problem remained the same. As every cable is the same type and same power i don't think it down to connection or power.
I may have found a clue if i integrate with darks only problem gone, i am now running it again with flats as well may be there is a issue in my bin2x2 flats not sure why i took them with the same light panel just after running the bin1x1. i know given bin2x2 there will be a lot more gain going on and i was already running flats at 0.02 seconds i think i will try adding a ND filter over the panel and see if i can get that figure to around 0.5-1s range. I would love to be able to run LRGB in that range but if i do that my narrow band run in the 50-120s range. I may have to run my flats in two goes splitting up LRGB and NA,O,S.
Mike
Hi strange results and i don't know why here what i did
Took the lights and only ran integrate with darkmaster and files look fine no bands
Took the lights and this time added darkmaster and flats files look fine no bands
Took the lights and this time added darkmaster and flats and dark flats files look fine no bands
Now on each process above i just changed the deep sky odject name so to get new integration files. Runing each again after adding the extra files so doing it this way i don't see a problem.
I then closed pixel processor and added all the files again but in one process so light, flats,darkflats, masterdark and results are files with bands are back.
Its like there is some kind of interaction when the process is run in one go. Do you want some files to try not sure what to check next.
Â
Mike
Â
Â
Ok that is really weird then, what happens if you first make the masters, save those, then reload APP and add the lights and only the masters? I think I'm also going to ask for your data to have a look myself later on.
Hi i think i have found the issue is in the flat files i can banding in the master flat files might be related to short exposure times of my flats in bin2x2 found some forum posts about the 294 sensor not liking short exposures in bin2x2 mode.
Still not sure why the strange results in the bit by bit test but never mind i am getting some where.
is there a super pixel mode in pixel processor found some posts about using that mode in the same forum post.
Â
Mike
Hi Quick question is it better to remove light pollution and caibrate background on each channel or once combined.
mike
@moviecells You can do both, I think doing it after combination is fine as correcting that beforehand still differs in results for each channel. I do tend to do that though as I like to think "the cleaner the data in, the better". But that's not really a very scientific argument I guess. đŸ™‚
Hi Vincent
I have also found that adding lum channel to narrow band images seem to wash out any colour am i doing it wrong in some way. At the moment i add just say 10% lum to HA/O/S data.
Â
Mike
Yes it does do that, so adding a lower amount is a good idea when the color signal isn't as strong. Mabula is going to have a look at improving that mixing in the future as well.
Hi Vincent
Still have some issue with my final intergation image it like my flats are being applied over corrected. Here a image of my flats for lum, Light for Lum and final integation. I can see ring where the flats show through the lights in the final image.
Â
light
flat
final images
Here a link to all the files if neededÂ
https://www.moviecells.net/astro/
Not sure what going on tried new flats same results. Running 1.083 beta2
Â
mike
Â
Â
Ah yes, a ring artifact I usually see when there is more going on then just vignetting. Usually it points to internal reflection in the setup which needs to be solved in the setup itself.
Hi Vincent
Any idea where to start there I have the the main scope a meade 14 inch ACF then a reducer then filters 2 inch Chroma then ASI2600 camera
Â
mike
@moviecells What source if illumination do you use for the flats? It is possible that the rings are caused by IR reflections in the tube. "Black" paint in telescopes sometimes turns out to be highly reflective in IR. On the other hand, you are using Chroma filters which have a fabulous reputation. Still, what source do you use?
Hi I have a a few different types i have tried a flat panel which is a LED drawing pad i have a ND filter over it then a perspex opaque sheet givens nice flat white light that gives about 07-1.2 LRGB exposure times. As a test this week i tried some sky flats using the double white tee shirt method but again processing the images gives nearly the same results.
Â
I did think of try a very dim light source next for the flats to see if that helps.
Â
Mike
Â
@moviecells It looks like you have tried all light sources that I would try as well. Have you ever tried shining a tv remote into the telescope to see if the camera registers the IR emission? I did that once (albeit with filters of a different brand) and my mono camera registered the response. That’s when I decided to add a UV/IR cut filter to the image train to ensure proper blocking of IR.
@moviecells Do you maybe have any light source that might be shining into the telescope?
Hi I would say a no, at point of flats the panel sit right on top of the OTA so no other light can get in. I do know IR light can cause issues i have a garden camera that has IR lights but i have a cover i fit when i am out using the telescope. I don't know if anyone else may have a IR light source but most of target i try to position high up and i fit a 40cm long dew shield so would think even light to the side could not come in at a angle to make it in to the light path.
Mike
Â
Â
Â
Hi I would go down the IR filter to try but i see this problem in the Chroma Lum filter and that is a IR cut filter i think not just a clear focusing filter.
Â
Mike
Â
Â
@moviecells Mike, I saw this with an L filter of another brand. And also with RBG filters for that matter. The transmission curves usually are published up to about 1000 nm and tv remotes shine at longer wavelengths. I see that Chroma publishes transmission curves up to only 800 nm.
Regarding possible IR sources: the night sky emits IR as well and this could affect your imaging.
It really is as simple as taking an L image without and one with a tv remote shining on the camera and see if there is a difference. And if it turns out that IR is properly blocked then at least you have eliminated a possible cause.
Regarding light leakage: again just try and see what happens if you take flats in the dark. On the other hand, when and how do you take darks? If you do that during day time you should see light leakage as well if that's the cause.
Hi i don't have a IR remote many are now RF types but i do have some IR leds i can use on a battery to try i will give it a go.Â
I take flats during the day but do know i have a small light leak around my moonlite, i know this because when i take matching darkflats in bright sun light i can see it so i cover the area with blackout cloth but we are taking the long 20-30s narrow band exposures. during the night there is no light around i see the issue there even no moonlight nights so don't think this small leak is a issue.
i have tried light panel flats direct on top of the OTA and also sky flats.
Â
Mike
Well it could potentially be, I also hear people sometimes having issues when the back of the scope is not covered (with some Newtonians). Any potential light leak, even if unlikely to be the cause should be dealt with, just to rule out more parameters. It can be quite complex (and frustrating) to find the culprit.
Guys, I don't think removing Flat from the Light in APP 1.082 or Beta2 works and I have tested both.  My results are worse than the original uncalibrated image. What is the exact math APP is using here because I think it might be your math is wrong?  Here are some images and examples I wanted to share to investigate this further......
Light
Â
Flat frame (uncalibrated)
Â
APP Calibrated Frame (Vignetting is worse)
Â
Now, if I use the same images in Pixinsight and remove the Flat via Pixelmath, these are the results I get (Note: obviously, images don't have exact stretch value when compared to APP, but principle still shows the result):
Â
Image divided by Flat (Creates opposite effect, no good) - Pixel Math: Light/Flat
Â
Image divided by inverse of Flat - Pixel Math: Light/(1-Flat) - Looks identical to APP calibrated image, and this we know is wrong as vignetting is worse (Again, stretch is not perfectly matched to APP stretch but it does show).
Â
Now, if I do this: Image times the inverse of Flat - Pixel Math: Light * (1-Flat) - The image looks perfectly calibrated.
Â
Can you please check into the math used in APP because I am unsure why APP isn't giving me correctly calibrated images right now.  Thanks!
Â
BillÂ
Â
@wvreeven  Thanks, I look forward to it.  Â
PS, I am not sure why the "Rule of Thumb" has been to take a Light and divide it by a Flat, even Pixinsight does this which doesn't have the correct effect when using my example images.... example:
Â
Pixinsight ImageCalibration:
PixelMath using division (Same result as above but has wrong effect on image)
Again, if I multiply the Light by the invers of the Flat, My image looks natural without vignetting, so should the actual formula be (Light x (1-Flat))??
Â
@blanshan91 sorry to hear your seem to be having issues too
I thought i was going mad i have two threads open with flat calibration issues so may be there is a general problem. Let me know how you get on if you find out to fix this.
Mike
Dear Bill @blanshan91,
Please upload some lights and calibration frames here and i will test and report back where the problem is.
https://upload.astropixelprocessor.com/
username : upload
password: upload
Please make a folder with your name and let me know once uploaded đŸ˜‰
I must point out, that on all test data that I have which is a lot (from both amateur and professionals), flat-field calibration works perfectly, even on very fast focal ratio's, so chances are very likely that something else, besides the math, in APP is the problem and I will be happy to analyse this. If APP is the problem, I will be happy to fix it of course.
Â
PS, I am not sure why the "Rule of Thumb" has been to take a Light and divide it by a Flat, even Pixinsight does this which doesn't have the correct effect when using my example images....
And that is not entirely correct... Such a Rule of Thumb does not exist really. If you divide a single uncalibrated light with a flat/masterflat, you will not get a correct result. Where did you get this info?
Flat-field correction can only work correctly if
- proper flats are created that have the exact same illumination profile as the lights. A light leakage in the optical train can be very problematic here and shooting proper flats with high-speed optics (F-ratio lower than 4) is a challenge in itself for many.
- Flats are subtracted with either bias and/or darkflats (so the sensor offset is subtracted/removed)
- lights are subtracted with either bias and/or darks (so the sensor offset is subtracted/removed)
In the case where you just divide a light with a flat, that sensor offset/pedestal is not removed leading to a bad result logically. Thus that Rule Of Thumb should be: Divide a bias/dark subtracted light with a bias/darflat subtracted flat đŸ˜‰
Please let me know if this is clear đŸ˜‰
I will look at your data as soon as possible when you have uploaded it.
Mabula
@moviecells Mike, coming back to your issue. What version of APP do you use? If 1.083-beta1 or earlier (so not 1.083-beta2), can you make sure to enable Create 32-bit Masters in tab 2 and try again? Those versions by default create 16-bit masters which do not have enough bit depth to fully correct vignetting.













