Subject: Re: New IMOD group


   Thanks for getting the ball rolling, Niels Jørgen!

   From my POV, it would be nice if this function became part
of a larger set which reads the whole available detector data
for the user. This creates a bit of overhead but nothing I
consider worrysome. In this view your function would be one
of the lower level pieces.

   As you may remember from my twice sent draft ideas, I had
proposed the following  C struct:

/*
  * Several bits and pieces of detector information are grouped in
  * one struct to keep function APIs shorter, while maintaining
  * flexibility in the future.
  * NOTE: the pixelArea values are in cm^2.
  */

typedef struct {
     double         area;
     unsigned short detMap[J_NUM_X_PIXELS][J_NUM_Y_PIXELS];
     double         CorX[J_NUM_X_PIXELS][J_NUM_Y_PIXELS];
     double         CorY[J_NUM_X_PIXELS][J_NUM_Y_PIXELS];
     double         pixelArea[J_NUM_X_PIXELS][J_NUM_Y_PIXELS];
     double         pixelLowerLeftX[J_NUM_X_PIXELS][J_NUM_Y_PIXELS];
     double         pixelLowerLeftY[J_NUM_X_PIXELS][J_NUM_Y_PIXELS];
} JEMXdetectorData;

in which detMap is not a shadowgram but a map with settings
for outside, bad anode, ...

   This struct could be extended to hold the conversion data you
read in. Do you think this makes sense? One issue I see is
that you imply linear mapping, while I had 2D arrays above
- we should agree on one logic.

   Regarding naming conventions: long names are _GOOD_ as long
as they are explicit. My proposition for the function name
would be JEMXdetectorGetRegularizedPixelMapping, but this is
really quite open as long as we agree on a common, logical style.

   Cheers,
   Peter