15th Feb 2024: Astro Pixel Processor 2.0.0-beta29 released - macOS native File Chooser, macOS CMD-Q fixed, read-only Fits on network fixed and other bug fixes
7th December 2023: added payment option Alipay to purchase Astro Pixel Processor from China, Hong Kong, Macau, Taiwan, Korea, Japan and other countries where Alipay is used.
I'm having trouble with calibration on the data I captured last night. I created a master flat, that was calibrated with a master dark, master bias, and bad pixel map. I then calibrated the lights with all of the above masters.
However, when I view one of the lights in linear-calibrated mode, the master flat is over correcting the image. The same is true for the final integration of the lights. Instead of correcting the vignetting and dust motes, the corners and dust motes go from being darker than the rest of the image, to much lighter than the rest of the image. It's as if the master flat is being applied more than once.
One thing to note. The lights were captured via Sequence Generator Pro, and were stored as fits files on the laptop. The darks, flats and bias frames were capture on camera in Nikon RAW (NEF) format.
Any idea what I am doing wrong here? Thanks
Replying to my own original post. I had a suspicion that the issue was related to the lights having been taken with SGP and stored on the laptop in .FITS format, while the flats were stored as Nikon .NEF files on the SD card. To test this theory I converted the flats from NEF format to FITS format before loading them into APP. I then calibrated the new .FITS flats with the same MB, MD and BMP as before, and generated a new master flat.
I then calibrated the lights with the MB, MD, BPM and new MF. The calibration now looks correct, with the flats removing the vignetting and dust mots. It is now clear to me that the original issue was somehow caused by the flat files being loaded as .NEF while the lights were loaded as .fits.
This would seem to me to be a bug in APP. I am using version 1.0.68.
Thanks,
Scott
Hi Scott,
Thanks for your own research into this! That is indeed very interesting. I'll let Mabula know (@mabula-admin), he should be here tomorrow.
Yes, I'm getting this problem in general with version 1.0.70 - but not solved. I've used data from a Canon 6D (CR2 files - flats and lights) and SBIG camera (fits files - flats and lights). Attached is an example of the SBIG mono camera. I used only 5 luminance lights and 5 luminance flats:
I put the files in this dropbox folder: https://www.dropbox.com/sh/ouknnqzqseog5br/AADt1uk7P62o1H-LCAYNz02Ta?dl=0
Thanks
Greg
Well this is a bit of a surprise but I added bias frames and now the calibrated frames are flat. Looks good.
Could it be you didn't use bias frames while making the masterflat?
Could it be you didn't use bias frames while making the masterflat?
Hi Vincent, thanks for your reply.
Yes, that seems to be the issue. I made the mistake of trying to use a master bias that was generated by another program but that didnt work at all. So I tried without bias and didnt realize it would affect the master flat as much as it did. Finally I regenerated the master bias and master flat with the original bias frames and I'm getting very nice results now.
Indeed the best workflow in APP is to always use raw data, not touched by any other processor, to go forward. APP uses the entire sensor data which many other programs don't do as they use dcraw to convert the data. This causes the dimensions not to be the same and it fails on that. There's a lot of statistics at play when using calibration data and for that to work correctly, a masterflat needs to be bias and dark-signal free as much as possible (I always use bias, darks and a BPM to correct them). If those signals are still there it'll cause APP to make a wrong estimation of the gradient-signal in the lights.
