(Peculiarly, blogspot only shows previous posts, but not subsequent ones. Here is the follow on to this post:
more epl3 noise results)
The
noise issue that has come to light recently with the Olympus OM-D E-M1 in long exposures
caught my attention last night, so I decided to take a look at the output from my camera, an Olympus E-PL3. While the E-M1 and E-M5 use a 16 Mpix Sony sensor, my camera has a Panasonic 12 Mpix sensor. In both cases, the technology is CMOS, not CCD.
So far, I've only taken one image and reduced the data from that single frame:
- 60 sec exposure
- ISO 200
- IS off
- Noise reduction OFF
- Noise filter OFF (not sure if this matters w/ raw image)
- f/22, lens capped to minimize stray light.
I converted the raw file into a FITS file using
dcraw
% dcraw -D -4 -c file.orf | pnmtofits > file.fits
and then imported the file into ipython using the astropy library.
On my sensor, rows 4056 to the end have some overscan garbage, so data in those rows were removed from further analysis. In the first figure, below, I histogrammed the noise from the sensor. The main peak is at 64 ADU and does not extend much beyond 100 ADU (top panel). In the middle panel, the Y scale is expanded, and the second noise peak is evident. This
might be analogous to the noise seen in the E-M1. The bottom panel shows the noise binned into 50 ADU chunks. All of the information in the top two panels fits into the 5 left-most bars of this histogram. There are two more noise peaks, at 500 and 1200 ADU.
I found 93 "high count" pixels, mapped below. Looking at their spatial distribution and density, I think they are unlikely to cause any imaging problems.
The second noise peak, is more interesting. It peaks at 179 ADU and is done by ~230 ADU. There are 37000 pixels in the 130-230 ADU range. As you can see below, their distribution is (at least by eye) uniform and the worst offenders tend to cluster in the corners.
I have no idea if this is the same problem that the E-M1 has, but if anyone wants to send me some E-M1 dark frames, I'd be happy to run the same analysis on them. I'll probably take a few more frames to verify my hunch that this is a fixed-pattern problem, which is why noise reduction can kill it off easily.