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 seem to be another user who's been stricken by the odd black image after stacking with APP. I'm using a relatively new to me Touptek ATR3-16000-KPA OSC camera, very similar to the ASI-1600MC. I used the camera to capture some images of the Rosette Nebula and registration and stacking went fine with that image. A few nights ago, I set up to capture some images of the Horsehead and Flame nebula. I took 105 x 120 second exposures and the light frames look fine when blinking in PI. I took 15 dark frames using the same exposure time, gain and offset and then took the flats and dark flats using same gain and offset. I've verified all of the values of the light frames and calibration frames to insure all settings match (sensor temp, gain, offset, exposure times) and they do.
Unfortunately I'm getting a completely black image when stacking with APP. I chose "BGGR" in the RAW/FITS and force CFA, which was the same settings used for the Rosette. BGGR is the pattern this camera uses. I tried stacking without using the dark frames or master dark created, and result was the same. Anyone have any ideas as to what may be going on here? Thanks!
I don't know if it's the same, but in my ASI 1600MC, I'm using GRBG. All fine with it...
The pattern for my camera is BGGR. I've stacked previously using BGGR and force CFA, with no issue.
I seem to be another user who's been stricken by the odd black image after stacking with APP. I'm using a relatively new to me Touptek ATR3-16000-KPA OSC camera, very similar to the ASI-1600MC. I used the camera to capture some images of the Rosette Nebula and registration and stacking went fine with that image. A few nights ago, I set up to capture some images of the Horsehead and Flame nebula. I took 105 x 120 second exposures and the light frames look fine when blinking in PI. I took 15 dark frames using the same exposure time, gain and offset and then took the flats and dark flats using same gain and offset. I've verified all of the values of the light frames and calibration frames to insure all settings match (sensor temp, gain, offset, exposure times) and they do.
Unfortunately I'm getting a completely black image when stacking with APP. I chose "BGGR" in the RAW/FITS and force CFA, which was the same settings used for the Rosette. BGGR is the pattern this camera uses. I tried stacking without using the dark frames or master dark created, and result was the same. Anyone have any ideas as to what may be going on here? Thanks!
Dear Jason @jasonjeremiah,
Please try with the new 1.083 release 😉 that issue is solved. It was a problem in 1.082.
But... the problem is always triggered due to a problem with your data as well. The problem will occur if you have
1) underexposed or
2) have a light leak in your setup or
3) the sensor offset of the calibration frames is not correct for your lights.
APP 1.083 will be able to process your data but you might receive a warning about the data issue after data calibration.
Mabula
@mabula-admin Will do. One other thing, is it possible the issue may also be some of the info in the FITS header? I noticed using PI FITSheader process, the instrument (camera) is listed as 'ATR3CMOS16000KPA(U'. If I look at the instrument for the Flats or Darks taken it is 'ATR3CMOS16000KPA'. This may be due to images being acquired by two different instances of NINA - Lights were acquired with a different laptop than the laptop I used to capture the darks and flats. Same camera and optical train were used, though. Just putting it out there in case that may make a difference. Thanks for your help!
@mabula-admin Will do. One other thing, is it possible the issue may also be some of the info in the FITS header? I noticed using PI FITSheader process, the instrument (camera) is listed as 'ATR3CMOS16000KPA(U'. If I look at the instrument for the Flats or Darks taken it is 'ATR3CMOS16000KPA'. This may be due to images being acquired by two different instances of NINA - Lights were acquired with a different laptop than the laptop I used to capture the darks and flats. Same camera and optical train were used, though. Just putting it out there in case that may make a difference. Thanks for your help!
Hi Jason,
I don't think that will be a problem, APP will only use the Instrument name if you have several masterdarks for instance. If you only provide one, that one will be applied if the sensor dimensions fit the ligth.
Let me know if all works okay in 1.083 😉
Mabula
Just an update as it may help others that experience this problem. The Touptek camera I'm using has a 12 bit sensor but the driver does NOT upscale the data to 16 bits. It merely dumps the 12 bit data into a 16 bit container but it still only represents 4095 ADU. NINA has a selection that allows for upscaling to 16 bits, but the laptop I used to acquire the light frames had this disabled in NINA. I shot the dark frames and flats with a different laptop but it had upscaling enabled so the darks and flat frames had been upscaled and were obviously much brighter than the light frames. I'm going to try and manually upscale the lights using PixelMath in PI to match the darks and flats. Just an FYI in case this should happen to someone else with a similar camera as this camera is a rebranded camera that comes in many different names (Omegon, ES, Orion, ToupTek, RisingCam, etc.) Thanks!
Just an update as it may help others that experience this problem. The Touptek camera I'm using has a 12 bit sensor but the driver does NOT upscale the data to 16 bits. It merely dumps the 12 bit data into a 16 bit container but it still only represents 4095 ADU. NINA has a selection that allows for upscaling to 16 bits, but the laptop I used to acquire the light frames had this disabled in NINA. I shot the dark frames and flats with a different laptop but it had upscaling enabled so the darks and flat frames had been upscaled and were obviously much brighter than the light frames. I'm going to try and manually upscale the lights using PixelMath in PI to match the darks and flats. Just an FYI in case this should happen to someone else with a similar camera as this camera is a rebranded camera that comes in many different names (Omegon, ES, Orion, ToupTek, RisingCam, etc.) Thanks!
Dear Jason,
You can simply use the Batch Multiply Tool in APP to scale your images 😉 Simply multiply the 12bit frames with a factor of 4 with the Batch Tool.
That should work fine.
Mabula
@mabula-admin I didn't know APP could do that. One question though - why would the multiplier be 4 and not 16? Wouldn't the data need to be upscaled times 16 to match corresponding ADU values for a 16 bit image? 4,095 (12bit ADU) x 16 = 65,520 (16bit ADU) or am I totally misunderstanding how the batch multiply tool works?
It does appear the multiplier would need to be 16, but using the Batch Multiply also does something else that's not preferable - it debayers the original FITS file. When Batch Multiply is run on the FITS file, the resulting file is split into RGB channels with the correct corresponding 16 bit depth values. Is there anyway to do the upscale of bit depth and maintain the original greyscale FITS data?
@mabula-admin I've attached screenshots that show the differing results when upscaling the data using a PixelMath expression in PI vs using the Batch Multiply in APP. I very well may be doing something wrong in APP, but the PI works, it's super fast, and maintains the original greyscale format and file size (32MB). Not only did Batch Multiply debayer the image into RGB channels, it tripled the file size of each sub to 90MB. This makes sense, though, since it is splitting the file into 3 channels (3 x original file size).
