STIR FAQ: Difference between revisions

From STIR
stir>Krthie
→‎STIR FAQ: added info on incremental backprojector
stir>Krthie
added license statement and higherlevel sections
Line 1: Line 1:
Frequently asked questions about how to use [http://stir.sourceforge.net:STIR STIR].
Frequently asked questions about how to use [http://stir.sourceforge.net:STIR STIR].


=Image related FAQs=
== How to display images generated by STIR? ==
== How to display images generated by STIR? ==
STIR comes witha very basic utility called '''manip_image''' that displays image slices, but it
STIR comes witha very basic utility called '''manip_image''' that displays image slices, but it
Line 55: Line 56:
For details on orientations etc, see the STIR Developer's Guide.
For details on orientations etc, see the STIR Developer's Guide.


= Testing related FAQs=
== Why do the tests of the recon_test_pack fail? ==
== Why do the tests of the recon_test_pack fail? ==


Line 74: Line 76:
incremental backprojector for the iterative algorithms anyway as  
incremental backprojector for the iterative algorithms anyway as  
there's no corresponding forward projector.
there's no corresponding forward projector.
= Content license =
All content on this wiki uses the
[http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike 3.0 Unported License]
[[Image:CreativeCommons-BY-SA-Logo.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]

Revision as of 11:41, 6 September 2011

Frequently asked questions about how to use STIR.

Image related FAQs

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.

Testing related FAQs

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