Strange colours whe...
 
Share:
Notifications
Clear all

19 June 2021: Our upload server https://upload.astropixelprocessor.com/ has been migrated successfully to our new office with higher upload and download speeds (nearly 10MByte/sec up/down ) ! We now have 1 general upload user called: upload with password: upload. The users upload1 - upload5 have been disabled.

31 May 2021: APP 1.083-beta2 has been released ! APP 1.083 stable will follow soon afterwards. It includes a completely new Star Reducer Tool, New File Saver Module, Improved Comet registration and much more, check the release notes here!

DOWNLOADS are available HERE!

 

Strange colours when darks are used  

  RSS

(@ajnilsen)
White Dwarf Customer
Joined: 2 years ago
Posts: 21
September 22, 2020 10:29  

Hi....
I experienced a strange result yesterday evening.  Integration of 54x180 sec of Elephant trunk taken with ASI294 (color) and RASA 8.  I implemented bias, flats, darks and BMP.  Then the colours came out very strange ("supported" and "force deBayer" were used) ATTACHMENT

I tried the same integration without using flats and darks and then the colours came out normal (ATTACHMENT).  

When I implemented flats, BMP and bias only (no darks) the colours were normal.

When darks were added, back to strange colours.

The master dark looks normal (ATTACHMENT)....

 

No clue what could cause this.  Darks were made using the same camera of course, same temperature and same integration time (180 sec), 30 frames were used for building the masterdark....  I suspect something must have gone wrong obtaining the darks, but don't know what this could be...

 

Help needed! 🙂

best

Alf J.

Dark ASI294 Gain 120 180s Bin1x1 2020 09 14 19 18 57
ET bias flats BMP darks
ET bias flats BMP

 


ReplyQuote
(@ajnilsen)
White Dwarf Customer
Joined: 2 years ago
Posts: 21
September 22, 2020 15:53  

Hi again....
I have been fighting with the dark frame colour problem all day.  I did a second experiment processing 86x30secs of M31.  Same result (see attachments).  Master flat and  master dark are both listed as RGGB (4144x2822 pix, 16b RGB). When the master dark is implemented, the colours get viered.... am I missing something crucial or is there a bug in the software here? Really frustrating, hoping for suggestions....

M31 86x30secs flats bias BMP
M31 86x30secs bias flats BMP dark

Stay safe!
AJ


ReplyQuote
(@ajnilsen)
White Dwarf Customer
Joined: 2 years ago
Posts: 21
September 22, 2020 18:35  

Hi again...

I am happy to say that I found the cause of the problem described above.  The problem is linked to Astro Photography Tool (APT) the software I use for imaging.  It might be the settings I use that cause the problem OR it might be a software bug, I do not know.  When I obtained dark frames with MaxIm DL (ver 6) and integrated them, deBayering in APP worked fine.

Good to know...:)

AJ


ReplyQuote
(@mabula-admin)
Universe Admin
Joined: 4 years ago
Posts: 2715
September 24, 2020 22:03  

Hi Alf @ajnilsen,

Please send me a subset of all frame types, so lights, bias, darks, flat, flatdarks so I can test what is happening.

Are you sure that all frames have matching gain and offset ?

Did you shoot all frames with the same capture software ?

There is a chance that the darks shot with APT don't match properly for gain + offset, that is my suspicion.

Kind regards,

Mabula


ReplyQuote
(@ajnilsen)
White Dwarf Customer
Joined: 2 years ago
Posts: 21
September 25, 2020 07:45  

I have uploaded two frames of each type to your server.  I shot all frames with APT and I think they all had gain 120 offset 08, but not 100% sure.... so the error might originate here...  But again, when darks were taken with MaxIm DL, no problem and the same frames were used except for the darks... 

 

Many thanks for your help!

AJ


ReplyQuote
(@mabula-admin)
Universe Admin
Joined: 4 years ago
Posts: 2715
September 28, 2020 17:07  

Dear Alf @ajnilsen,

thank you for sharing the data, the source of your problem is indeed in the capture process with APT. The lights and bias+darks are completely incompatible due to different sensor offsets:

I have sent you and Ivo (APT) the following conclusion:

I have looked at Alf’s data and indeed, I come to the conclusion that there is a data problem here which is created in the capture process. Either due to wrong settings in APT, or due to a bug in APT.

 

From the metadata of the frames it is hard to tell since the sensor offset can be found in the light frames header, but it is missing for some reason in the bias and darks frames.

Only the gain value of 120 is consistent between all frames.

 

In the light frames, a sensor offset is reported of 8 (which might be a bit low ? but okay):

HDU1 - SITELONG= '+06 32 04.000'      / The site Longitude                            

HDU1 - FOCUSPOS=                 2500 / Focuser position in steps                     

HDU1 - GAIN    =                  120 / The gain set (if supported)                   

HDU1 - OFFSET  =                    8 / The offset/black level set (if supported)     

HDU1 - END                               

 

Now the asi294 is a 14bit camera, right? So the adu offset of 8 in 14bits would translate to a value in 16bits of: 8 * 2^2 = 8*4 = 32.

 

So you would expect the darks and bias frames to show that roughly as the median value in the masters, which they clearly don’t :

 

MasterBias from APP created from the bias:

 

HDU1 - MEAN-R  = ' 1,9116E+03'        / mean of channel-R                              

HDU1 - MEAN-G1 = ' 1,9113E+03'        / mean of channel-G1                            

HDU1 - MEAN-G2 = ' 1,9113E+03'        / mean of channel-G2                            

HDU1 - MEAN-B  = ' 1,9116E+03'        / mean of channel-B                              

HDU1 - MED-R   = ' 1,9120E+03'        / median of channel-R                           

HDU1 - MED-G1  = ' 1,9120E+03'        / median of channel-G1                          

HDU1 - MED-G2  = ' 1,9120E+03'        / median of channel-G2                          

HDU1 - MED-B   = ' 1,9120E+03'        / median of channel-B

 

MasterDark from APP created from the darks:

HDU1 - MEAN-R  = ' 1,9117E+03'        / mean of channel-R                             

HDU1 - MEAN-G1 = ' 1,9114E+03'        / mean of channel-G1                             

HDU1 - MEAN-G2 = ' 1,9113E+03'        / mean of channel-G2                            

HDU1 - MEAN-B  = ' 1,9117E+03'        / mean of channel-B                             

HDU1 - MED-R   = ' 1,9110E+03'        / median of channel-R                            

HDU1 - MED-G1  = ' 1,9110E+03'        / median of channel-G1                          

HDU1 - MED-G2  = ' 1,9110E+03'        / median of channel-G2                          

HDU1 - MED-B   = ' 1,9110E+03'        / median of channel-B

 

So this indicates an offset in the bias and dark frames in 16bits of 1912 roughly. In 14bits this would be 1912 / (2^2) = 1912 / 4 = 478 … which is very high ! It is a factor of 15 higher than the sensor offset in the lights…

 

Now, to know that the lights and the darks/bias are completely incompatible is to simple look at the peak of the histogram in the light frames and the darks and bias.

 

The light frames have a peak at an ADU level of around 1400 in the weakest channel which is Red.

 

The bias/darks have a peak at ADU level of 1900… so if you subtract a bias or dark then part of the data becomes seriously negative….if the darks and bias would match the lights for gain + offset, this should not happen.

 

So either the sensor offset was set incorrectly to create either the lights or the bias + darks, or APT mistakenly used a wrong offset while capturing either lights or bias+darks?

Kind regards,

Mabula


ReplyQuote
Share: