search

UCL / pet-rd-tools

Command line tools for PET-MR (pre-)processing
Apache License 2.0
14 stars 4 forks source link

--head Resampled image is misaligned with NAC. #18

Open ashgillman opened 6 years ago

ashgillman commented 6 years ago

Hi,

I have run a STIR non-attenuation corrected reconstruction on my data, and compared the output with nm_mrac2mu's umap output. It is misaligned in the y direction. Any suggestions/speculations as to what might be causing this?

Cheers, Ash

NB: If you click the images they will open in a new tab and you can cycle. Look between the UTE and the NAC, since they are a similar scale the silly colorbar won't make the image move.

410141_umap hv 410141_ute2 hv nac_sirf_s21i30_30 hv

bathomas commented 6 years ago

Strange. Your NAC file name says SIRF but you state STIR. Which are you using?

ashgillman commented 6 years ago

SIRF sorry

ashgillman commented 6 years ago

Perhaps because the resampled origin is set to be the same as the input origin? Usually, our radiographers will play around with the acquisition FOV, I'd have thought the resampled origin would not depend on the input.

https://github.com/UCL/petmr-rd-tools/blob/master/lib/nmtools/MRAC.hpp#L692

ashgillman commented 6 years ago

I'm also getting

E0718 23:21:20.582680  5732 MRAC.hpp:683] Input x or y size is odd. Unsure how to resample!
E0718 23:21:20.582690  5732 NMmrac2mu.cpp:143] Failed to scale image

Which is an error I inserted, since I had made some assumptions about how the output size calculation should go. But is there a reason that the output shape isn't just set to 344*344*127?

Although note this is probably unrelated, but potentially the same solution

ashgillman commented 6 years ago

If I could add a third unrelated "problem" with potentially the same solution: When I also run mrac2mu on the vendor reconstruction, it has a different size in the z axis 410141_recon-vendor hv

I put quotes around "problem" because I think that STIR/SIRF can handle this (offset in z). But, still if you are using the --head option I might think you'd expect to always get 344x344x127?

ashgillman commented 6 years ago

The solution I am hinting at is that perhaps the output size should be taken from the JSON specification in the beginning. As an added bonus, you could potentially in the future extend this so that you could supply a JSON file input with resampling parameters (I assume this was the original intent).

bathomas commented 6 years ago

Your assumption about the JSON is correct, I just haven't got round to it. (More than happy to accept a PR...)

Yes, I would expect to get 344x344x127 with --head, but I didn't really think about resampling other images. If you are rescaling is failing because x and or y are not even, then this means that your input image is not 192^3? If so, then the code as it stands will fall over.

What do you mean when you say radiographer's play with the FOV, do you mean the MR acquisition or they retro recon. the PET with a zoom and/or offset?

ashgillman commented 6 years ago

My input is 192x192x128. As I said, I think that STIR/SIRF handle z offsets, so long as the z resolution is acceptable (half the ring spacing?), so it /has/ worked for me (just not this time).

I mean the MR acquisition, so it is not necessarily centered transaxially.

So if the output transform is constant (identity) and the output size and spacing are parameters, that leaves the origin and the direction to be calculated.

Origin I guess the image should lie in the center, such that outputOrigin[0] = outputSize[0] * outputShape[0] // 2 and likewise for the y-axis. I am not sure for the z-axis though...

Direction Currently this is taken from the input, but I think maybe it should actually also be a constant? Again, I am not sure which. The default doesn't work for me currently, so I have to use --orient RAS. My DICOM direction is (0020,0037) DS [1\0\0\0\0\-1] # 12,6 Image Orientation (Patient)

I am happy to make some changes, test and make a PR. The main issue at the moment though is that z-origin.

Does this sound correct to you?

bathomas commented 6 years ago

Origin, yes, but I feel like the direction should come from the input. I deliberately chose RAI as the default because I believe this is what Siemens appear to uses in e7 tools. The reason for this is that (assuming everything goes fine) the output volume of nm_mrac2mu without any switches should be almost identical to the raw mu-map volume from e7 tools.