UCL/STIR

blocks on cylindrical geometry still unexpected geometry

KrisThielemans opened this issue · 4 comments

Looks like we don't correctly centre the "bucket" in transaxial direction when there are gaps between blocks. Below are examples wtih 2 blocks/bucket and 1 block/bucket. with the blocks_spacing 20% larger than the block (generated with an improved plot_scanner_LORs.py, now even better on #1391).
2D-2BlocksPerBuckets-ObliqueAt0degrees-XY-LOR
2D-1BlocksPerBuckets-ObliqueAt0degrees-XY-LOR
Of course, a gap between trans-blocks if there's only 1 block per trans-bucket makes no sense. We could use this to "shift" blocks, but I can't see why anyone would want to have such a PET scanner, so I don't think we should do this.

I think we should just centre the bucket.

in axial direction, it looks fine
2D-YZ-LOR

@danieldeidda @markus-jehl @robbietuk

When using the commented code for start_x as opposed to the csi stuff at

float start_y = -1 * scanner.get_effective_ring_radius();
float start_x
= -1 * r
* sin(csi_minus_csiGaps); //(
// ((num_transaxial_blocks_per_bucket-1)/2.)*transaxial_block_spacing
// + ((num_transaxial_crystals_per_block-1)/2.)*transaxial_crystal_spacing
// ); //the first crystal in the bucket

is what I expect.
2D-2BlocksPerBuckets-ObliqueAt0degrees-XY-LOR
2D-1BlocksPerBuckets-ObliqueAt0degrees-XY-LOR

@danieldeidda you made this change in 42bf1e9. Can you remember why?

Yes I agree. The second images are correct. There should a test to ensure this is the case...

@danieldeidda could you have a look at this? @markus-jehl will make a PR

When using the commented code for start_x as opposed to the csi stuff at

float start_y = -1 * scanner.get_effective_ring_radius();
float start_x
= -1 * r
* sin(csi_minus_csiGaps); //(
// ((num_transaxial_blocks_per_bucket-1)/2.)*transaxial_block_spacing
// + ((num_transaxial_crystals_per_block-1)/2.)*transaxial_crystal_spacing
// ); //the first crystal in the bucket

is what I expect.
2D-2BlocksPerBuckets-ObliqueAt0degrees-XY-LOR
2D-1BlocksPerBuckets-ObliqueAt0degrees-XY-LOR
@danieldeidda you made this change in 42bf1e9. Can you remember why?

looking back at my drawings I think this was when we had the configuration with first detector at 0 degrees but the calculation of the starting point doesn't seem to make sense for this configuration. Possibly I had used this because of the failing tests, I can't remember very well though.