STIR FAQ
Frequently asked questions about how to use STIR.
How to display images generated by STIR?
STIR comes witha very basic utility called manip_image that displays image slices, but it is really only useful for a quick check (or to see if STIR did read your image as expected). Your best option is to use an external display program.
By default, STIR uses a version of the Interfile format, although only a subset of keywords is implemented. (See the STIR web-site for more links on Interfile).
Amide and xmedcon read STIR .hv files without trouble as long as the data-offset is zero (e.g. files which are written by STIR). Other packages might ignore the scale factor (but STIR by default writes as floats with scale factor 1). And other packages might insist on using the official Interfile 3.3 standard. The .ahv files written by STIR are closer to that, but they have a tweak to let Analyze (from the Mayo) read them correctly (as Analyze misinterprets the z-spacing). Open one of the .ahv files in your text editor and read the comments.
STIR currently uses a home-grown way to specify the image origin. No other program supports this convention as far as we know (as Interfile currently does not have relevant keywords). STIR currently completely ignores patient orientation etc. So if you have an image of the same object written by a different program, and the display program tries to interpret coordinate systems, it's unlikely the 2 objects will be displayed in the same location.
How does the STIR coordinate system work (e.g. for generate_image)
Details are given in the STIR Developer's guide. Here we attempt to give some more info on how this works for images.
The origin of the STIR coordinate system is in the centre of the first ring of the scanner. Moreover, for an image with zero offset, the origin is assumed to coincide with the centre of the first plane.
Also, a peculiarity is that STIR coordinates are ordered (z,y,x) (with z along the scanner axis, y vertical and x horizontal).
Let's say you want to use generate_image to create a cylinder in the centre of the image (and we use zero offsets). Then we need to compute the STIR coordinates of the centre. Given that (0,0,0) is at center of the first plane (but see below), the center of the last plane is at ((num_planes-1)*z_voxel_size,0,0). And therefore, the middle of the image is at ((num_planes-1)*z_voxel_size/2,0,0). Similarly, if you want to have it in the centre of the scanner, then you need to specify the origin of the cylinder as ((num_rings-1)*ring_spacing/2,0,0)
There's another small complication. The STIR convention in x and y is
actually a bit different. When you have an odd number of voxels in x (or
y), the 0 coordinate is indeed in the centre of the image. But if you have
an even number, it's actually half a pixel off.
For details on orientations etc, see the STIR Developer's Guide.
ERROR: DataSymmetriesForBins_PET_CartesianGrid can currently only support z-grid spacing equal to the ring of the scanner divided by an integer. Sorry
You can see this error when using forward projection of an image (e.g. when computing attenuation correction factors), or backprojection to an image. It happens because the projectors try to save memory (and time) by using a symmetry in the axial direction. To avoid this error, you have to use a z-spacing for the image which is half the ring-spacing of the scanner. (Although the symmetries could be used in other cases as well, there seem to be some problems with the projectors in such cases in the current version of STIR).
Why do the tests of the recon_test_pack fail?
Most likely this due to a bug in the "incremental backprojector" which crops up depending on compiler/optimisation settings etc. An extensive discussion of this bug appeared on the STIR users lists. You might be able to see this using this link.
For example, a known system that has this problem is Ubuntu 64bit using gcc 4.5 in 64 bit mode (and -O3).
There are several ways to check:
- run recon_test_pack with the --nointbp flag to remove tests that use this projector
- display the sensitivity image that you're getting. Most likely you'll see a hot spot in the middle or some 45 degree lines
You could always compile as 32bit even on 64bit linux of course (use EXTRA_CFLAGS=-m32 EXTRA_LINKFLAGS=-m32, and don't forget to either change DEST or make clean). However, we do not recommend using the incremental backprojector for the iterative algorithms anyway as there's no corresponding forward projector.
Content license
All content on this wiki uses the Creative Commons Attribution-ShareAlike 3.0 Unported License File:CreativeCommons-BY-SA-Logo.png
