Datasqueeze Software

Frequently Asked Questions

Home
Technical Details
Screen Shots
FAQ
Download
Purchase
Plans
About Us
Contact
Manual
Privacy Statement
Site Map

Installation

File Types

Images

Calibration/centering

Plots

Run-time errors

General/Complaints

Your Questions Answered!

Installation

File Types

  • What kinds of data file can Datasqueeze read?
    Currently supported formats are the Bruker standard (wire or CCD Detectors), Bruker-Nonius KCD format, ADSC CCD detectors, Brandeis CCD detectors, Ditabis Image Plates, Gatan DM3, MAR CCD detectors, MAR Image plate detectors (300, 345, and pck formats), Molecular Metrology detectors, Rigaku image plates (Raxis-II , Raxis-IV and Raxis-IV++formats), Nonius DIP-2000 (image plates), Princeton/Roper CCD, Fuji image plates, Black/White TIFF, and XDR. It is also possible to read in Grayscale graphics images (TIFF, PNG, GIF, JPG only)--this might be a way of reading in an image that is a Fourier transform of some real-space data, for example produced by a microscope or AFM. (Graphics images are not the preferred way of reading in data from x-ray detectors).
  • Datasqueeze does not read data files produced by my detector. What can I do?
    We are continuously adding more format as the demand arises; contact us if there is a particular data format you would like to see added.
  • I saved my data as a GIF (or JPG or PNG) file. I can read it back with Datasqueeze, but the data are quite different. What is wrong?
    Graphics files are really intended only as a way of reading in non-xray data, for example produced as a Fourier transform of some optical image. A graphics file is not the same as the original data file. A typical data file is at least 1024x1024 pixels, and has a depth of at least 16 bits (depending on the detector type). Graphics images are generally much smaller (so spatial resolution has been lost) and have much less dynamic range. Additionally, note that Datasqueeze expects grayscale images. It converts the image color to an intensity by adding the red, blue, and green components. If you start with a color image, this is almost certainly not how the data were originally encoded.
  • Can Datasqueeze read in graphics images that are not TIFF, GIF, JPG, or PNG?
    Not right now--expansion of this feature will be driven by customer demand.
  • Datasqueeze returns an error when opening a file that I think is valid. What should I do?
    There are several possible origins for this problem:
    1. You may have selected the wrong file format. In the dialog window that opens, there is a drop-down box listing all the data file types that Datasqueeze knows about. This should be set to match the type of file you are opening. If you do not know the file type, select "Unkown".
    2. Your file may have been corrupted. This can happen, for example, if you use FTP or a similar protocol to transfer the file from one computer to another. When doing this, you should always using the "binary" option if it exists, rather than "Auto" or "Text." If you suspect that your file may be corrupted, try transferring it back to the original datataking computer and see if the original software that wrote it can read it.
    3. You may be looking at a graphical image of the file rather than the data file itself. With rare exceptions, a graphics image (jpeg, gif, etc.) has far less information content than the original data file, and in any case is in a different format. Look at the size--a typical x-ray data file is at least 1MB, and often much larger.
    4. If your problem is none of the above, it is possible that this is a data file format not currently recognized by Datasqueeze. Please contact support (support@datasqueezesoftware.com) with as much information as you can provide about the file you are trying to read.
    5. My image plate data seem to consist mostly of zeros, even though I know that there is really structure there. What is wrong?
      The Fuji image plate data are recorded in logarithic form. When they are read back in, they are restored to linear form by exponention (i.e., Icalc = A x 10^(Imeas/I0)). Depending on the range of the data, it is possible that many or most of your data points are less than 1 (such as 0.01). Try multiplying the data by some large number such as 10000 when you open the file.

Images

Calibration/centering

  • What are x-center and y-center?
    In most diffraction applications, the primary beam is blocked by a beam stop. The beam center is the position at which the beam would have hit if it were not blocked. It will be at the center of any Bragg rings. Often this is close to the physical center of the detector, although sometimes it is near one edge of the detector. X-center and Y-center are the values of the pixels corresponding to the center of the diffraction pattern. So for example for a 1024 x 1024 pixel2 detector with the beam exactly in the center, X-center and Y-center would both be equal to 512.
  • What is the q-range?
    It is the value of q (= 4 pi sin(theta) / lambda) corresponding to the maximum horizontal range of the detector. This is set once for a particular data set to determine the relationship between the distance in pixels between a feature of interest and the origin and the q-value corresponding to that feature.
  • What is a Bruker standards file and how do I use it?
    You are supplied with a file called agbe.std, which is a text file containing powder diffraction information on Silver Behenate, a common calibration standard. If you have previously calibrated your detector with AgBe you can use this file with the Calibrate window to easily establish the center, q-range, etc., of your detector. If you have used some other calibration standard, you can easily use any text editor to create a standards file of your own, using agbe.std as a model. Note however that this is one place where the number format is not locale-dependent; the d-spacings should all use the American format. That is, a d-spacing that is a little over 45 Angstroms should be written as 45.3 rather than 45,3.
  • Diffraction patterns that should be circular look oval. What is wrong, and what can be done about it?
    This can come about in one of several ways. The most common is that your detector is not exactly perpendicular to the incident beam. It is also possible that the x- and y-directions have different gains, or equivalent that the pixels are not exactly square. All of these can be easily corrected by Datasqueeze. The Tilt/Azimuth combination on the Image and Calibrate windows correct for a detector that is tilted an arbitrary amount about an arbitrary axis relative to the central beam.

Plots

  • When I go to make a plot it does not graph the full range that I selected.
    Check the "Delta" value (the increment corresponding to the spacing between points). If it is larger than the full range of the plot then you will only get 1 or 2 points. If it is much smaller than your plot might actually consist of thousands of points, and the program cuts off with a maximum number of points. You should typically set the "Delta" so that you have something like 100 points in your plot, but also so that the increment is not smaller than one pixel.
  • When I go to make a plot I get something crazy-looking that oscillates rapidly.
    See the previous question. If the "Delta" increment is smaller than one pixel then some points will have data associated with them and some will not.
  • The text file that is produced by saving plots seems to have a lot of blank lines (every other one).
    Did you transfer your file from one computer to another? These extra newline characters are sometimes inserted by ftp application (e.g. Fetch, WS_FTP, Filezilla) if it recognizes the file as being "text." Try telling the ftp that the file is "binary". This is a slower, but more reliable way, of transferring files.
    The problem arises because different operating sytems have different ideas of what constitutes a "new line." Datasqueeze inserts "\r\n", which seems to work on all the operating systems we have tried, but is sometimes translated by ftp applications into "\n\n".
  • Peaks do not Appear at Expected Q-Values or Angles.
    This is almost certainly a calibration problem. You need to know enough about your detector to set several parameters. Go to the Calibrate window. First, you need to set Lambda (the wavelength). This is crucial! After that, you have several options:
    1. You can set the Q-range. This is, roughly speaking, the value of Q at one edge of the detector if the beamstop is in the center. You optimize it until peaks appear at the right position. See the manual entry on Calibration for more details.
    2. You can set 2theta-max. This accomplishes the same thing as setting Q-range, for those who are more comfortable using the language of angles than the language of momentum transfer.
    3. You can set both the sample-detector distance and the detector radius. (The radius should always be the same for a given detector, but the sample-detector distance may vary from one measurement to another).
  • Peaks are broadened or distorted.
    If plotted peaks appear broad or distorted even though the powder diffraction rings in the false color image are sharp, this is almost certainly a calibration problem. There are two obvious things to check:
    1. The beam center (X-center and Y-center in the Calibration window) may not be completely set. Note that the beam center is not in general exactly at the geometrical center of the beam stop. Use the "Circle" option in the Image window to see whether the powder diffraction rings are really centered. Or, make radial plots over limited ranges of Chi and verify that the peaks come at the same positions independent of Chi.
    2. It is also possible that the diffraction rings are not perfectly circular--see the discussion of Oval patterns above. You may need to change the Tilt in the Calibration window.
  • I want to make a Qx-Qy plot through a fiber pattern that is somewhat tilted. Is there a way to do this?
    Yes, as of 2.0.7 there is a "Chi Offset" feature that allows you to change the definition of the orientation that we call the "equator".

Run-time errors

  • Datasqueeze seems to make other applications on my computer run slowly. What is going wrong?
    Like other graphical interfaces, Datasqueeze goes into loop cycles and consumes system resources even when it is not being used for anything. If it is being used on a single-user computer this is not a big issue, although if it slows down your other programs you might consider exiting the program when you are done (first saving your current configuration for future use). If it is being used on a shared-time computer used by others then courtesy indicates that you should exit the program when you are done.
  • Datasqueeze unexpectedly crashed. What went wrong?
    If you generate a reproducible error please contact us with as much information as you can supply and we will try to fix the problem. (Most such bugs have already been eliminated).
  • I got an error message that said that Java is out of memory. What went wrong?
    If you get an out of memory error, you may be trying to read in a larger file than Datasqueeze can hold in memory.In the File window, check the box marked "File Swap." This will slow things down a bit but allow much larger files to be manipulated.

General/Complaints

Last updated December 30, 2007

Send Us Your Comments