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.
Green colour overall despite the correct debayer with optolong L-extreme
Hi all is anyone else getting issues with the L-extreme when wanting to process rgb colour images?
for some reason they turn out completely green, ha extract and )3 extract and recombining all work fine but straight out rgb for some reason gives me this strange result
@nicholas64 I have taken many images using an L-Extreme filter and they come out just fine. What camera do you use? What file format are the input images in? What calibration frames do you use? What algorithm is selected in tab 0? Do you change any of the settings in tabs 1 to 6 of do you use the defaults (which we recommend you do)?
Funny thing is this is the first time this has happened, my rosette data was fine just this M42 was an issue.
I used the defaults, force rggb , etc nothing seemed to change it. It still comes out Green. Just the M42 data from that night.
Only thing I can think of is that the data may have been corrupted or there was some intermittent interference as there was some horrible banding when it was stretched.
ASIAIR pro 30 second subs 120 of them fit files darks etc. everything as per normal just that horrible green
I tried the defaults, tried the rggb bggr hao3 debayering etc etc etc and green each time. When i extracted ha and 03 then did a colour combination it worked fine in Hoo1 and Hoo2
As I said it's just the data from the M42 acquisition, my Rosette data seemed fine and worked.
I'm pretty sure there was an acquisition glitch as it only is that bit of data that seems to have been affected.
and user username and password upload5. Please create a folder called nicholas64_green and place the files in there. Then I can have a look and try to help you salvage your data. Not sure if I will succeed though.
Also, please check the settings of the camera driver and make sure that the white balance for red and blue both are set to 0.5. ZWO for some reason that's beyond me uses 0.52 and 0.95 for red and blue respectively and that messes up the color balance in the end. However, I don't think that's what happened here though I don't know what did.
Did you find a solution to this? I have the same problem with some data from the ASI 294MC Pro, ASIAir and L-eXtreme. Some of the subs in my dataset must be different:,although I do not see a visual difference.
I noticed that I can stack a subset of the subs without problem - but as soon as I include a corrupted (?) sub, the result is flawed.
@rudibarani Hi no I havent found a solution, it's hard to see which file would be corrupted they all looked good on observing them, I did find that using windows helped instead of the mac. It never is an issue with the ha extraction and O3 extraction just rgb or hargb
Thanks Nick. Exactly my symptoms. I had tried to stack batches of 10 subs and found that some batches work while others don't. Visually and by the metadata, they all look alike. If - as you say - they work fine in DSS, maybe the APP-team can identify the problem and find a fix. Either from ZWO or in APP.
@rudibarani@nicholas64 Without having access to the flawed data there isn't much we can do. We requested data in January but never got confirmation that the data were uploaded. So, please upload some data to
I took the liberty to upload my files. They where acquired using a ZWO ASI294MC Pro, ASIAir and the Optolong l-eXtreme filter. Usually one would process these files differently - but I noticed the problem when I just stacked them using the Adaptive Airy Disk-Algorithm to get an impression of the data. I made no changes to any default settings. Just loaded the subs, added the master files and startet the integration.
If you have a look at the fits-files derived from subs 21-30, you will notice they look as expected and quite differently when compared to the first ones. Especially subs 6-10 lead to a very green tone that dominates the stack even if you combine all subs. Subs 1-5 and 11-15 have strong blue hue. The stack from subs 16-20 looks close to normal. I guess somewhere here is the transition from flawed to normal...
Please let me know if you need more info to have a look at this data.
@nicholas64 I see you only uploaded lights so it is a bit hard to do a propor analysis. However, I loaded all 10 second exposures in one session, all 180 second exposures in a 2nd session and all 30 second exposures in a 3rd session. Then I kept everything default except that I wanted to integrate the three sessions separately. The result are three beautiful, albeit uncalibrated, images of M42. Here are screenshots of the integration result.
What is the problem exactly? Because the images look as expected to me.
Mabula and I have been discussing Nick's data. It looks like the 10 sec data have been clipped because of the very short exposure time of 10 seconds only while using a filter with two very narrow pass bands. Also, please upgrade to APP 1.082 (or even 1.083 Beta 1) because those versions have many improvements in the algorithms. We keep on investigating the data.
Hi all is anyone else getting issues with the L-extreme when wanting to process rgb colour images?
for some reason they turn out completely green, ha extract and )3 extract and recombining all work fine but straight out rgb for some reason gives me this strange result
Okay I have done several tests this afternoon. I see from your screenshot that you were using APP 1.080. So I tried to process your data with APP 1.080 and also with APP 1.082. Even tried with the current APP 1.083 code from active development. No matter what I try, I get normal results and not the green result that you get.
Did you get it just with only light frames, like you have uploaded? Or were there calibration files involved? Any additional details that you can provide can help me to find the cause of your problem. I do advise to install APP 1.082 first if you have not done so already 😉
Did you find a solution to this? I have the same problem with some data from the ASI 294MC Pro, ASIAir and L-eXtreme. Some of the subs in my dataset must be different:,although I do not see a visual difference.
I noticed that I can stack a subset of the subs without problem - but as soon as I include a corrupted (?) sub, the result is flawed.
I have studied your data. Your problem is caused by incompatible darks and bias relative to your lights it seems.
If I process your data without the masters that you supplied, i get a result as expected:
Now if I use your Masters, the MasterBias, MasterDark, MasterFlat and BPM I get the same problem:
Now I have studied your lights and your masters for the sensor offset value to see if that makes sense, and they clearly are not compatible. So the problem is that the MasterBias and MasterDark were shot with a different sensor offset than your light frames. Let me explain this in detail
In your lights we see in the metadata the following information:
FITS HDUs: 1 HDU1 - SIMPLE = T / file does conform to FITS standard HDU1 - BITPIX = 16 / number of bits per data pixel HDU1 - NAXIS = 2 / number of data axes HDU1 - NAXIS1 = 4144 / length of data axis 1 HDU1 - NAXIS2 = 2822 / length of data axis 2 HDU1 - EXTEND = T / FITS dataset may contain extensions HDU1 - COMMENT FITS (Flexible Image Transport System) format is defined in 'Astronomy HDU1 - COMMENT and Astrophysics', volume 376, page 359; bibcode: 2001A&A...376..359H HDU1 - BZERO = 32768 / offset data range to that of unsigned short HDU1 - BSCALE = 1 / default scaling factor HDU1 - CREATOR = 'ZWO ASIAIR' / Capture software HDU1 - OFFSET = 30 / camera offset HDU1 - XORGSUBF= 0 / Subframe X position in binned pixels HDU1 - YORGSUBF= 0 / Subframe Y position in binned pixels HDU1 - FOCALLEN= 1461 / Focal length of telescope in mm
We notice that ZWO ASIAIR has stored the sensor offset in the metadata. The value is 30 for the 14bits camera, according to :
The asi294mc is a 14bits camera. The sensor offset is 30 ADU in 14bits. This is 30*4=120 in 16bits. So we expect the median and average values of the MasterBias and MasterDark to be roughly 120 ADU as well. If we look at the provided MasterBias and MasterDark, we see that the offset in the masters is much ! higher:
FITS HDUs: 1 HDU1 - SIMPLE = T / Java FITS: Sat Apr 03 13:08:04 CEST 2021 HDU1 - BITPIX = 16 / bits per data value HDU1 - NAXIS = 2 / number of axes HDU1 - NAXIS1 = 4144 / size of the n'th axis HDU1 - NAXIS2 = 2822 / size of the n'th axis HDU1 - EXTEND = T / Extensions are permitted HDU1 - BSCALE = 1.0 / scaling to 16bit HDU1 - BZERO = 32768.0 / offset data range to that of unsigned short HDU1 - DATE = '2021-04-03T11:22:41' / creation date of MasterDark HDU1 - SOFTWARE= 'Astro Pixel Processor by Aries Productions' / software HDU1 - VERSION = '1.082 ' / Astro Pixel Processor version HDU1 - CALFRAME= 'MasterDark' / master dark frame HDU1 - INSTRUME= 'ZWO ASI294MC Pro' / instrument name HDU1 - CFAIMAGE= 'RGGB ' / Color Filter Array pattern HDU1 - NOTE-1 = 'INTEGRATION METADATA' HDU1 - EXPTIME = 300.0 / exposure time (s) HDU1 - GAIN = 120.0 / gain or ISO depending on instrument HDU1 - INT-METH= 'average ' / integration method HDU1 - OUTL-REJ= 'adaptive rejection' / outlier rejection filter HDU1 - OUTL-KL = 7.8 / outlier rejection kappa low HDU1 - OUTL-KH = 3.8 / outlier rejection kappa high HDU1 - LNC-DEG = 'noLNC ' / Local Normalization Correction not applied HDU1 - AD-PED = 0.0 / adaptive pedestal from data calibration HDU1 - FILTNUM = 1 / data combined from 1 filter HDU1 - FILT-1 = 'all channels' / filter used HDU1 - SESSNUM = 1 / data combined from 1 session HDU1 - SESS-1 = 'session 2' / capture session HDU1 - MEAN-R = ' 1,9219E+03' / mean of channel-R HDU1 - MEAN-G1 = ' 1,9215E+03' / mean of channel-G1 HDU1 - MEAN-G2 = ' 1,9215E+03' / mean of channel-G2 HDU1 - MEAN-B = ' 1,9218E+03' / mean of channel-B HDU1 - MED-R = ' 1,9200E+03' / median of channel-R HDU1 - MED-G1 = ' 1,9200E+03' / median of channel-G1 HDU1 - MED-G2 = ' 1,9200E+03' / median of channel-G2 HDU1 - MED-B = ' 1,9200E+03' / median of channel-B HDU1 - SIGMA-R = ' 1,1997E+01' / standard deviation of channel-R HDU1 - SIGMA-G1= ' 1,2119E+01' / standard deviation of channel-G1 HDU1 - SIGMA-G2= ' 1,2716E+01' / standard deviation of channel-G2 HDU1 - SIGMA-B = ' 1,1812E+01' / standard deviation of channel-B HDU1 - NOISE-R = ' 2,3005E+00' / MRS gaussian noise estimate of channel-R HDU1 - NOISE-G1= ' 2,3002E+00' / MRS gaussian noise estimate of channel-G1 HDU1 - NOISE-G2= ' 2,3012E+00' / MRS gaussian noise estimate of channel-G2 HDU1 - NOISE-B = ' 2,3039E+00' / MRS gaussian noise estimate of channel-B HDU1 - NUMFRAME= 30 / # number of frames used in MasterDark creation HDU1 - END
So the median/average value of the MasterDark is 1920, this is much higher than 120. It would equal a sensor offset of 1920/4 = 480 in 14bits compared to the offset of 30 in the light frames.
We can actually see this problem if we disable the adaptive pedestal (2)Calibrate) in the calibration engine and look at what happens if we subtract the MasterDark from a light frame, we see that extreme data clipping occurs on the balck level which really should not happen with your exposure time of 300seconds:
Notice that in 2)Calibrate I disabled the adaptive pedestal. I loaded the light frames and the MasterDark. I set the image viewer mode (above the image) to l-calibrated and I double clicked 1 of the light frames in the list. This light frame has now been loaded and calibrated with the MasterDark. So we are seeing the calibrated light frame in the image viewer. Now notice the histogram which is not free from the left side allthough the B(lack) slider of the preview filter is set to 0. This is not good and confirms that the masterdark + masterbias are not compatible/suitable to calibrate your light frames which were clearly shot with a different sensor offset. Because of the severe black clipping, the adaptive pedestal can not solve your problem. And the actual problem is then created in the normalization engine, where the blue channel becomes the biggest problem... to many pixels have no real information after calibration leading to miscalculations for data normalization...
Solution: create the MasterDark and MasterBias with the correct sensor offset 😉
Do you still have the original bias and darks? Can you check which sensor offset is stored in the metadata?
Kind regards,
Mabula
This post was modified 3 years ago by Mabula-Admin
I will try again tonight on a windows machine and see if that reproduces the result.
I can also upload the dark frames as well
give me time 🙂
Allright @nicholas64 ,please upload the dark frames and I will check what is wrong with them 😉 because we probably find the root cause in the darks then..
Hello Mabula, would it be possible to explain this data in more detail. Relating to what can read everything from it. For example (circled in red) sometimes there is a minus sign and sometimes a plus. Green circled what do the individual data. Mean and median I think refer to the whole image or to the background value? A more detailed explanation would be nice. With best regards.
@minusman This is a scientific notation. 1,9219E+03 means 1,9219 x 10 to the power of three. 10 to the power of three = 1000 so the value means 1921,9. The comma is the standard Dutch decimal separator.
