Green colour overal...
 
Share:
Notifications
Clear all

Green colour overall despite the correct debayer with optolong L-extreme  

Page 2 / 2
  RSS

(@mabula-admin)
Universe Admin
Joined: 4 years ago
Posts: 2618
May 2, 2021 14:00  

Hi Nick @nicholas64 & Phillip @rudibarani,

I am investigating as well at the moment what the cause is of your green results... Will report back later 😉 when I have done some tests.

Mabula


ReplyQuote
(@wvreeven)
Galaxy Admin
Joined: 3 years ago
Posts: 839
May 2, 2021 14:38  

Hi Nick @nicholas64 & Phillip @rudibarani,

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.


ReplyQuote
(@mabula-admin)
Universe Admin
Joined: 4 years ago
Posts: 2618
May 2, 2021 18:31  
Posted by: @nicholas64

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

Screen Shot 2021 01 18 at 11.01.51 pm

Asi 294mc pro camera

Hi @nicholas64,

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 😉

Mabula


ReplyQuote
(@nicholas64)
White Dwarf Customer
Joined: 2 years ago
Posts: 19
May 3, 2021 00:06  

Hi Mabula

I upgraded to both 1.082 and the beta as well

I did use dark frames

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 🙂

 


ReplyQuote
(@mabula-admin)
Universe Admin
Joined: 4 years ago
Posts: 2618
May 3, 2021 13:56  
Posted by: @rudibarani

@nicholas64 @wvreeven

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. 

image
image

 

Dear Phillip @rudibarani,

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:

Normal without data calibration

Now if I use your Masters, the MasterBias, MasterDark, MasterFlat and BPM I get the same problem:

Bad with calibration Masters

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 metadata

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 :

https://astronomy-imaging-camera.com/product/asi294mc-pro-color

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:

MasterDark

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:

BlackClipping

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 1 month ago by Mabula-Admin

ReplyQuote
(@mabula-admin)
Universe Admin
Joined: 4 years ago
Posts: 2618
May 3, 2021 13:57  
Posted by: @nicholas64

Hi Mabula

I upgraded to both 1.082 and the beta as well

I did use dark frames

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..

Mabula

 


ReplyQuote
(@nicholas64)
White Dwarf Customer
Joined: 2 years ago
Posts: 19
May 3, 2021 14:03  

Hi Mabula I used the latest beta version after reinstalling it from scratch and all works well 🙂

thanks for all your assistance


ReplyQuote
(@mabula-admin)
Universe Admin
Joined: 4 years ago
Posts: 2618
May 3, 2021 15:20  
Posted by: @nicholas64

Hi Mabula I used the latest beta version after reinstalling it from scratch and all works well 🙂

thanks for all your assistance

That is great Nick @nicholas64, thanks for the feedback 😉

Happy all is well now !


ReplyQuote
(@minusman)
Neutron Star Customer
Joined: 4 years ago
Posts: 195
May 3, 2021 21:48  

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.

HUD 01

 


ReplyQuote
(@wvreeven)
Galaxy Admin
Joined: 3 years ago
Posts: 839
May 3, 2021 23:33  

@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.


ReplyQuote
(@minusman)
Neutron Star Customer
Joined: 4 years ago
Posts: 195
May 4, 2021 11:07  

Hello Wouter, would then be calculated with a minus as a sign / 10 to the power of 3?


ReplyQuote
(@wvreeven)
Galaxy Admin
Joined: 3 years ago
Posts: 839
May 4, 2021 11:15  

@minusman Sorry, I forgot to mention that. 10 to the power of -3 = 0.001 or 1/1000.


ReplyQuote
(@minusman)
Neutron Star Customer
Joined: 4 years ago
Posts: 195
May 4, 2021 11:25  

Thank you very much Wouter, Now I can start with the numbers. Because when normalizing a stack, scientific notation comes up too. Unfortunately I couldn't do much with it, but now I know.


ReplyQuote
(@rudibarani)
White Dwarf Customer
Joined: 10 months ago
Posts: 15
May 4, 2021 14:59  

Dear Mabula, @mabula-admin

thank you very much for your time and the thorough analysis. I can reproduce the histograms you describe above and get what you believe causes the problem. I have checked every single frame from the lights, darks, bias and flats and they all have the Offset of 30 you mention. The ASIAir does not even offer an option to modify the offset - it seams to be built in. The only parameter that one can change are the temperature and the gain settings.

Next, I rebuilt all master files having verified that the Offset is 30 on all input files - and the resulting master file show values in the "high" 1920 range you show above. This is also the case with all other master-files from other imaging sessions. Maybe that's okay after all?

Do you have any other idea what causes this problem?

Thanks for pondering about this,

Phillip


ReplyQuote
(@minusman)
Neutron Star Customer
Joined: 4 years ago
Posts: 195
May 4, 2021 19:03  

Hello Philipp, you can upload 5 pieces of each calibration image (DARK, darkflat or bias & flat). No master files. There you can better judge what is going on with the files.


ReplyQuote
(@wvreeven)
Galaxy Admin
Joined: 3 years ago
Posts: 839
May 4, 2021 19:42  

@rudibarani Actually that was going to be my next suggestion. Can you do that and let us know as soon as the data are there? Please use the same directory as before. Thanks!


ReplyQuote
(@rudibarani)
White Dwarf Customer
Joined: 10 months ago
Posts: 15
May 4, 2021 21:12  

Dear Wouter, @wvreeven

thanks for the chance to upload additional data to help solve my problem. 

I have uploaded darks, bias and flats - 5 files each. 

Flats were created using the Lacerta Flatfield Box and the auto-exposure function of the ASIAir. 

If you need additional data / information, please let me know.

Best,

Phillip


ReplyQuote
(@minusman)
Neutron Star Customer
Joined: 4 years ago
Posts: 195
May 5, 2021 22:28  

Hello Phillip, when I look at the statistics of the data I see that the exposure time for this filter is still much too short. The Mean ADU value is only slightly above that of the darkframe despite the 300s. This is also visually visible by the stripes in the lights. I have the same camera and always expose so that the stripes in the lights almost disappear. But this does not explain the bad darkframe calibration. I can only assume, maybe a USB connection problem.


ReplyQuote
Page 2 / 2
Share: