Subject: Teknisk note om pixels



What is in a pixel?

Technical note TN DNSC-JEMX-2005-0001
Niels Lund

Purpose: 

To clarify the content of the pixels in the JEM-X skyimage.
Can we extract true source fluxes from the sky images? Is the best
measure for source flux the value in the pixel at the summit of a
source peak, or should we rather integrate over the peak out to a
specified radius?

Background: 

The JEM-X microstrip detector is determining photon interaction 
coordinates through an (noisy) analog process. The RMS uncertainty 
in this proces can be larger than the 1 mm precision by which the 
coordinates are digitized before transmission to the ground. 
Additionally, the JEM-X detector is a three dimensional detector, 
the photon interaction volume is 55 mm deep. The depth of the photon 
interaction point is not known, and for off-axis sources this 
introduces a "parallax uncertainty" in the photon position at the 
detector window. The random noise in the positioning is particularly 
important for low energy photons - the parallax effect is important 
for high energy photons arriving from off-axis sources. (The RMS 
uncertainty can be several mm for the lowest photon energies, the 
parallax uncertainty can be up to 6 mm along the track projection)

Discussion:

For both of the above reasons it cannot be guaranteed that all 
detected source photons will backproject to (or correlate with) the
source position. Therefore the pixel at the summit of a source peak
in an image generated by backprojection will in contain only a
fraction of all the detected source photons. The photons missing at
the summit will backproject to surrounding pixels. But, unfortunately
some of the photons at the summit may backproject also the surrounding
pixels (this depends on the specific hole configuration through which 
they passed the mask) so if we integrate over the peak we will in many
cases count the same photon several times.

Our present 
OSA and 'midisky' skymaps shows the photons which geometrically are
consistent with a number of sky positions. We may generate a second 
skymap which at the same positions would show the number of additional
photons which are 'almost' consistent, i.e. which only needs to be
moved to a neighboring detector pixel to become consistent with the
skymap position. And we may generate a third skymap counting the
additional photons we could gain if we relax our 'almost' condition
one detector pixel further. Based on such a sequence of skymaps we
may improve our estimates of the source strength based on skymap
data. In particular it may solve the problem of deriving the strength 
of sources sitting between two skymap positions. Here the additional
data for both (or all four) points would probably allow to derive a 
good source strength. The important thing here is that we take care
always to work with independent sets of photons - no photon must 
appear twice in the calculations of the flux of a particular source.

An alternative method is used by Carl in his IDL algorithm. The true
mask is replaced by a mask with small holes (1 mm2) located at the 
center of the open mask hexagons. He correlates this mask with the 
observed shadowgram quantized into 1 mm2 pixels. The counts in one 
particular detector pixel will now only appear in sky pixels 
separated by about 3.3 arcmin (the angular separation of the JEM-X 
mask pixels). So no photon can appear twice inside a hexakonal region 
of "diameter" 3.3 arcmin. As described above the positioning errors in 
the JEM-X detector can be larger than this (1 arcmin = 1 mm on the
JEM-X detector) but less than half the photons should have such errors, 
so using this method we may get closer to creating a map where the 
strength of a point source can be obtained by integrating over the peak 
in the image out to 1.65 arcmin. We will need an energy dependent 
correction factor to recover the full source flux but taht appears like
a solvable problem.

I dont believe we can implement this method in 'j_ima_iros' for OSA 5. 
At the moment we work with 1.5 arcmin pixels in the sky images. But it 
may be tried later.

Of course even with the current limitations mosaics are still very 
useful. What we need is maybe not something formally correct, but 
something which works in practice!

I would appreciate to have your comments on this.