2023-03-15: APP 2.0.0-beta14 has been released !
IMPROVED FRAME LIST, sorting on column header click and you can move the columns now which will be preserved between restarts.
We are very close now to releasing APP 2.0.0 stable with a complete printable manual...
Astro Pixel Processor Windows 64-bit
Astro Pixel Processor macOS Intel 64-bit
Astro Pixel Processor macOS Apple M Silicon 64-bit
Astro Pixel Processor Linux DEB 64-bit
Astro Pixel Processor Linux RPM 64-bit
[Sticky] Very strange integration result - check if you're using a FAT32 filesystem
The account must have reset, I uploaded 10 L frames and 5 each of D, DF, B, and F
It was reset yes, thank you and I'm downloading the data as we speak.
Ok, so some of my observations;
- The darkflats seem to have some amp glow or light bleeding on the right hand side. This is different from the darks, so this needs some investigation as that shouldn't be the case.
- With the resulting masters I checked their effectiveness on a light by loading a light and selecting "l-calibrated" on top of the APP window. This seemed to show a nice calibration, including proper removal of dust.
- I proceeded, switching the darkflats off and integrated with automatic settings and just switched on LNC and MBB in tab 6.
This was the result;
Then I did some Light pollution correction and star color calibration. This won't do a huge amount as there is not enough data to get proper color signal (for that the 30s exposures are too short);
I overstretched it and over saturated, but I'm not seeing the stripes. Maybe some additional frames cause this?
I might be able to shed some light on that (pun intended). When I have finished my Darks, and Bias frames, I line up for the Flats, using NINA Flat Generator. I uses an illuminated tablet and tshirt for the flats and start to tear down while the Flats are bring taken, this usually means I turn my garage light on which bleeds out to my telescope. It is possible that the lens cap is allowing some of this light into my Dark Flats.
So do you think the banding pattern I saw was from some bad Light frames, or the light bleeding into the DFs.
If I have Bias files, do I even need DFs?
I just pulled up my MDF, and see the light, I crack myself up. I can just about bet that is light leaking in from the garage through the lens cap. In the back of my mind, I was always thinking turning that light on was a bad idea.
@tmyers I'm not sure where the banding is coming from. It could be it shows in some frames and when using all of them it shows up. But then again, I would have expected it here as well. So maybe it's a data calibration issue.. for that I would probably need all the data. At least this shows it's not unsolvable, so that's progress. 🙂
I am rerunning with a better MDF. Will see what I get from this run.
Great. And for the flats you can also use bias btw, for some CMOS camera's it's advised to stay with darkflats or bias taken at like 0.05 seconds instead of super fast as these fast exposures cause other issues on CMOS.
So are you saying I should have DF or Bias but not both. As for the duration I Have heard from many with the ASI 1600 to not shoot Bias frames any faster than .3 seconds, which is what I use.
So this is interesting, following is a screenshot of the integration before the application of any tools.
And the image after batch cropping, look wnat is back!!
I went back to my previously processed images and found that the banding was not present itself till after the image was cropped
But why is the image having this amount of vignetting? Your flats are working quite well from what I saw, so that shouldn't be the case.
ps. You use either DF or bias for correction of the flats.
OK I will re-run later this weekend. I did notice that the vignetting was bad and the flats didn't appear to take out any of the dust. I will figure that out.
Interesting thing is that i did some post processing and then cropped and the banding did not appear. This is only a couple hours of data, so I need to get more but it is getting there.
I have been away for awhile. Purchased a rental license today for APP. This will give me a year to figure things out.
I processed the M101 again today and left the Bias frames out of the mix. Still had the horizontal banding. I was looking things over and noticed that I had 40 each of flats, and dark flats. I then remembered that I had mistakenly taken my first set of F and DF at 0 gain. I usually take my F and DF at the same gain as my lights, so I retook them. I had been selecting all forty of each, so I am running it again just using the ones that match the gain of the Lights, to see what comes of it.
Trying to fully understand what Mabula is suggesting for L, D, B, F, and DF.
Do I need both Bias and DF frames or just one of those? Should everything be at the same gain?
Ran the processing a second time still had the horizontal banding. I checked my MD, MDF, and MF, didn't see anything out of the ordinary with the image. Oh and this time the banding was present before cropping. At some point I am going to have to decide it is the light frames that are the culprit and try processing a different data set.
For now I am going to run with a reduced number of lights (takes less time) to see if the banding is there.
You had mentioned me sending the entire data set, I might take you up on that
Ok, an update. I ran multiple processes. Six in total. Hit a string of data sets and finally landed on success with L, D, DF, and F, no bias.
Dropped to 30 L frames, with no banding.
Did 84 frames, no banding
Then I ran with all the L frames checked frames after calibration and Normalization to see if there were any issues, but none were present. I removed any frame with a score less than 20, just in case they were causing the problems but in the end the banding came back.
Suggestions? Running tests with all the data takes up to 3 hours to perform, slow process.
More information, I went ahead and did some Tools work on the image and noticed that as I choose different stretch values that the horizontal lines would eventually turn to vertical lines. Quite bizarre.
Yes this is getting a bit bizarre indeed. We would need to have a look at the dataset to be able to really understand what is going on. If you want you can upload the data to our server;
https://ariesprodstor.astropixelprocessor.com:7001/ with username and password: appuser
Please create a directory called “tmeyers-bizarredbanding” and upload in there. 😉
I uploaded the files
what's the matter with this plz help I have those artefacts on all pics.
Stc dual narrowband filter
What's the process you went through, like what APP version, what settings did you use and what type of data (including calibration data)?
Difficult to see what might be wrong here. Just FYI, you don't need the cosmetic correction when you have proper bias, darks and flats usually. Only when there is clear residual noise present (like bad columns and still quite a few hot pixels).
This does look like a data issue somehow, I think I need to look at the data to get a better understanding.
Please upload some of the relevant subs to our server;
Go to https://upload.astropixelprocessor.com and use upload2 as username and upload2 as password.
Create a directory named “fotografiepeterkuehnlgmail-com” and upload in there. Thank you!
I sent you the pics via upload link thx for the help
Thanks Peter, I will download those shortly.
Looking at the data now. First thing I notice is that they went through Adobe Lightroom and are already stretched and not linear. It's always better to take the raw files from your camera and feed them straight into APP. Other software may change properties about the data that may cause issues and I think this might be the case, looking at just one light and zooming in to 100%, the stars look like this;
Which seems odd, they are somehow not round or fully visible. Could you try again with the raw files? Also do this with any calibration data you have, use the original files.