area detector, compression,various

[Mark Koennecke]

  Dear Brian and Ray,

  a few comments:

  - I agree, that defining the contents of a NeXus file is sometimes 
    difficult. Perhaps we should install some review system for that:
    i.e: anytime somebody defines a file format for a new type of 
    instrument she encodes it in some appropriate form and sends it
    to the list for review.

  - I can provide example files for a Neutron Powder Diffractometer with
    a PSD. However, I would do these files differently if I could start 
    anew. Then I have examples for SANS and for the TOF-diffractometer
    FOCUS. I can produce simulated data files for a four-circle
    diffractometer operating with a PSD in rotation camera mode and for
    a reflectometer equipped with both single detectors and a PSD. The
    instruments would be TRICS and AMOR in this case. Data in these files
    would be simulated or random numbers as the instruments are not yet
    operational. Therefore these file formats would be open to
    discussion. (I'am more reluctant to change anything about the other
    ones, as I already have thousands of them).
   
  - I made a test with the compression stuff on a 512*150 data array: In 
    the first case I filled that with random numbers and achieved no
    compression at all! In the second case I filled this with a fixed 
    value in order to valiadate read back. This compressed by a factor of
    10. This is for the LZW compression. All these compression algorithms 
    essentially replace reoccuring patterns in the data with a shorter
    version. So the compression achieved is very dependent on your data,
    your detector and the structure of your background. I did not
    observe any significant delay when writing this data. At our place 
    data file writing is bounded in time by the read out of the HW 
    anyway.

 
    
                        Have a nice weekend!

                                Mark Koennecke