Proposed display scheme for STXM 5

For STXM 5, the display scheme will change significantly. I propose the following:

read_stxm5.pro can return the 3-dimensional data array in 3 flavors. All three will be specified as optional keywords and not parameters, since in practice most of the time one will be interested only in the kHz array (see below). You can take a look at the calling sequence for read_stxm5.pro if things are unclear.

1. As raw integer numbers as they are stored. Neither a conversion to Volts (for ADC Data) nor a correction for the counts_divideby will be done. In practice, this option probably won't be used much, but I think we should have the option to return it. The array will be of 16-bit integer type (as the data is stored).
2. As raw counts / mVolts. ADC data will be converted to mVolts (If preferred, we could use Volts, but all the silicon detector calibration parameters use mVolts, so that a conversion would have to be done at that point), and scaler data will be given as counts (corrected for any divide_by). This array would be of float type.
3. As calibrated data. Clock data would be converted to msec dwell time, counter data would be converted to kHz, and Sidet data would also be converted to kHz according to the calibration. Any ADC channels which are not Sidet channels would be left as mVolts, since one can't determine their meaning automatically. The array would also be of float type.

Additionally, read_stxm5.pro will return a 2-dimensional kHz array (required parameter, not keyword). In fact, this will be the most interesting data in practice. It can be any linear combination of all available channels in the calibrated 3-dimensional data array as described above (Question: could it be necessary to also look at linear combinations of raw signals?). Which combinations are available will be defined in the IDL routine displays.pro (You can find it already in cvs/idl_local/stxm5). The linear combinations will also include every single Sidet channel (which is then exactly the same data as the corresponding channel in the calibrated 3-dimensional array from above). I am not planning to store this information (the list of available displays) in the data file.

In the GUI, I am planning for a dropdown list to choose between raw integer, raw count / mVolts, calibrated data or specific displays (linear combinations). For the first three options, one can then cycle through the recorded (or to-be-recorded) channels (Obviously, between raw integer and raw counts / mVolts, the difference will only be a scaling factor). For the fourth option, one can cycle through all the displays which are defined in displays.pro (except the ones where all coefficients for the linear combination are zero, e.g., the display ``Proportional Counter'' when only the Sidet signal was recorded).

For anything which can be displayed, min, max and gamma values can be adjusted in the GUI.

Now the question is what to store in the data file. I would say we store disp_name, disp_min, disp_max and disp_gamma, where disp_name refers to one of the linear combinations. If that file is then opened again later in the GUI, this display would be restored. This would have the following consequences:

• If a file is saved with, say, one raw integer channel being displayed, this would not be restored when the file is opened again later (instead, the display stored in disp_name would be restored). I don't think that would be too much of a problem, since normally the calibrated or combined (bright field or maybe DPC) signal is of interest, and if one really needs to see the raw integer or whatever else, it will be only two mouse clicks away.

  If we want to have the option to store that a raw integer or whatever channel has been displayed last, it would be another entry in sm_par.

• As already mentioned above, so far I am not planning for an option to display linear combinations from raw integers or counts / mVolts signals - only calibrated signals. Do you think this would be of any importance?

• The list of linear combinations will not be stored in the data file. In the hypothetical case that the displays.pro file gets lost or messed up, and everybody loses all his memory about what combinations are there, the display couldn't be restored from the disp_name in the file. But since this is very unlikely and we are talking about displays only anyway (no important information about the data itself would get lost), I don't think that's a major concern.

In that scheme, we could get completely rid of disp_num/denom_channels, disp_num/denom_factors and disp_raw since they won't be used any more. In principle one could keep them in case we want to make up some really arbitrary signal, but I don't think that's likely. If we want to keep them, however, the entries in the disp_num/denom_factors should refer to the stored data channels, and not all available data channels as now.