I have run a series of linearity tests to understand whether or not my Atik314L+ has a stable electronics after 2 years of ownership. For consistent results I have run 5 tests in a row by taking 5 series of calibrated flats. According to Arne's recommendation in another thread I have used control exposures (5 sec flats) in between the various frames of each run. I have used Maxim DL to calculate the mean pixel value of each flat. Here are the results:
Mean Pixel value in ADU (whole image analysis)
exp (secs)
Test 1
Test 2
Test 3
Test 4
Test 5
1
952
952
951
951
950
2
1903
1902
1901
1901
1900
4
3717
3716
3715
3711
3711
5
4627
4627
4626
4618
4618
10
9188
9179
9175
9172
9168
15
13724
13719
13713
13708
13701
20
18380
18247
18236
18230
18224
30
27276
27271
27256
27248
27234
35
31782
31772
32006
31761
31718
40
36271
36254
36239
36220
36204
45
40748
40732
40713
40699
40712
50
45214
45198
45233
45381
45174
58
52331
52270
52262
52260
52265
Rate of increase (ADU per second)
exp (secs)
Test 1
Test 2
Test 3
Test 4
Test 5
1
952
952
951
951
950
2
951
951
951
950
950
4
929
929
929
928
928
5
925
925
925
924
924
10
919
918
917
917
917
15
915
915
914
914
913
20
919
912
912
911
911
30
909
909
909
908
908
35
908
908
914
907
906
40
907
906
906
905
905
45
906
905
905
904
905
50
904
904
905
908
903
58
902
901
901
901
901
To summarize the tests shows as follows:
- the CCD seems to produce very stable results as the 5 tests show practically overlapping results
- the light source used for the flats is also very stable as all control exposure (5 secs exoposures) show practically very close mean pixel value (not shown here)
- the CCD show 1% deviation from linearity only in the 4.6K -18.3K ADU range and in the 27.2K - 45.2K ADU range
- the flats for the these tests were taken indoors (operating temperature of the chip was 0.6C)
- if I measure only the central region of the frames (say 100x100 pixels or 25x25 pixels as it does Aip4win) I get the same results (there are only very minor diffences, but the linearity curve has exactly the same trend)
Given all the above I have got a few questions:
- is temperature affecting somehow linearity? Can I get better results by using lower operating temperature?
- can I effectively produce good photometry providing I place the variable and all comp stars within the same range of linearity? I have seen that my data are consistent with the data taken by other AAVSO observers.
- given that this CCD produces stable results in terms of increase rate is there a way to linearize the data? Is there any software that does this sort of job? Can one expect that a linearizing feature will be implemented in VPHOT in the future?
Thank you
Gianluca
The Atik 314L uses a Sony ICX285L interline monochrome sensor. If I look at the linearity curve, it looks like you are very linear from 5sec to 58sec (5000ADU to 52000ADU). There is a "toe" in the linearity curve below 5000ADU; you should remove these points from your linear fit and see how well things reproduce after that. Also, you did not run your test long enough to see where top-end nonlinearity sets in; I would continue your exposures until you get close to 65K ADU (maybe up to 100 seconds or so). You will find the saturation/top-end limit to be the more interesting limit.
There are many reasons why a sensor may not respond nicely to small amounts of light (the "toe" in the curve). You will rarely be in that regime, as faint objects require long exposures so that the sky background will raise the sensor above these values, and short exposures are usually for bright objects, where the important flux is near the saturation of the sensor. That said, you should be aware of possible deviations in your photometry if the raw pixel values are ~5000ADU or less. You can even avoid that issue if your target and comparison star are of the same brightness (same part of the linearity curve).
I don't think changing the temperature will change the inherent linearity. However, if you are subtracting substantial dark current/bias signal, then errors in these values will affect the toe of the curve (one of the possible problems). it would not hurt to try the same experiment at colder temperatures and see what you get.
As I mentioned above, non-linearity is one reason why you take care in selecting comparison stars. The ideal comparison star is spatially close to the target, and has the same brightness and color. That rarely happens (an example is EW Sct - look at that neat field!). Then linearity, extinction and transformation become less important.
Nonlinearity is the "norm" for near-IR sensors like InSb and InGaAs because of the way the hybrid sensors are operated. Our NIR team at USNO-Flagstaff wrote software to "linearize" the detectors (basically, you just invert the linearity curve). I also applied this to the 1024x1024 sensor I used on the 1.0m telescope for all of my calibration photometry with good success. I seem to remember that Richard Berry was writing such a linearity module for AIP4WIN, and other vendors might have one as well. However, this linearity correction is rarely done unless the nonlinearity is extreme (several percent). At the one-percent level, it really doesn't contribute much to the photometric error. Remember, a star profile has pixel values distributed from the peak value to the sky background.
Good luck - and thanks for doing this test!
Arne
Hi Arne,
I have done another linearity test under the same conditions (indoors, chip temp 0.6C). This time I have averaged 2 flats for each exopsure, increased the exposure up to 100 seconds and subtracted a corresponding drak from the flats (calibration for the last test was done by subtracting a master bias as the Atik 314L+ has a very low readout noise and very low dark current). Control exposures consisting in 5 seconds flats taken here and there between the other frams shows the flat box to be very stable. Here are the results:
New Linearity test – whole image analysis average of two dark subtracted flats
exp (secs)
ADU
1
920
2
1840
4
3618
5
4472
10
8875
15
13267
20
17650
25
22020
30
26382
35
30737
40
35084
45
39424
50
43748
55
48069
60
52374
65
56675
70
60957
75
64375
80
65190
100
65224
and that is the rate of increase per second:
exp (secs)
rate of increase ADU
1
920
2
920
4
905
5
894
10
887
15
884
20
883
25
881
30
879
35
878
40
877
45
876
50
875
55
874
60
873
65
872
70
871
75
858
80
815
100
652
In attachment the new graphs. To me this CCD is linear (1% deviation) from 7K-26K ADU and from 26K to 61K ADU.
Even if probably this CCD seems to be pretty good for photometry I am interested in learning a little more on how to use an inverse curve to linearize the data. I think Richard Berry has not implemented a function to linearize the data in AIP4WIN. As I said probably the correction is small but I would like to learn how to linearize the data to see how much error can be attribuited to this small issue.
Thank you
Gianluca
Hi Gianluca,
The way this is normally done is to generate a lookup table, 65536 elements in length. one column is the ADU from your system. one column is the corrected ADU value. Then, for every pixel in your image, you use the raw pixel value as an index into the table, retrieve the corresponding true ADU value, and replace the original pixel value in the image with this new value. It is a very fast operation. You should do it with the raw pixel values before bias/dark subtraction or flatfielding; in this manner, the raw values only fall in the range 0-65535. Once you dark subtract, the noise in the dark current can generate negative values (such as an overcorrected hot pixel), and so a simple lookup table is difficult to use without additional logic. There is an additional assumption that all of the nonlinearity is due to the sensor response and not due to the signal chain digitization.
The harder part is generating the lookup table itself. What you want is ADU vs ADU, and not ADU vs time. So you have to make some assumptions: zero exposure should yield zero counts (or 100 counts, if you are using an SBIG camera; the best linear fit ito your data s used to find the difference between a 1-to-1 relation and your actual device.
The harder part still is how to implement this. I think MaximDL provides plug-in capability. Python could be used with PyFITS. A simple script can be written in "cl" for iraf. It depends on your programming ability and access. Perhaps someone can come up with a simple scheme for some common image processing system.
Testing your implementation is easy - you just run your linearization data through it, and see if you now get a straight line response.
Arne
Arne, Gianluca
I've used Python with PyFITS, mostly to modify FITS headers but if you want help with implementation, feel free to ask.
David