 |
 |
The 518 vs 512 was the cause of problems at the hackthon. Subsequently I looked at the Siemens raw data and was still confused. I have since gone back to looking at Philips data where I have access to the third party ReconFrame code that can show the various steps. The reasons why there are 518 and not 512 might be: An intentional slight oversampling (larger FOV) so that the edge of the object does not go past the edge of the field of view (as it would then wrap). A result of zero filling k-space that will adjust the image pixel size. This might be done so that in the image, the pixels are square (as they should be in DICOM). In both these cases, you should chop the FOV, keeping the pixel size un-altered, and NOT do interpolation. In all this it helps to remember a few points: The readout and phase encode directions are completely independent in the sense that the acquired fields of view can be different. If you just naively FFT the acquired data, the fields of view and pixel sizes may differ in the readout and phase encode directions. K-space step size dk is set by the gradient areas (strength*time) at acquisition. The FOV immediately after FFT is 1/dk . Phase encoding costs time and you may find fewer samples in that direction. For example, if I remember correctly, in the data we are discussing, there are actually only about 400 phase encode lines acquired. This might get zero-padded prior to FFT and the fourier transform length, Nft, will then be larger than 400. A key stage in the recon is immediately after the FFT. Here, the image FOV (FOVft) is determined solely by the k-space step size dk which was determined by the acquisition gradient area. At this stage, the image pixel size is FOVft/Nft. Subsequent cropping and zero filling of the image change the image FOV, but do not change the image pixel size. Prior to the FFT, cropping and zero filling of k-space do not change dk and so do not change the image FOVft, but they change the Fourier transform length Nft and thus the image pixel size. David From: "Brown, Richard" <[log in to unmask]> Date: Monday, 11 February 2019 at 08:27 To: "[log in to unmask]" <[log in to unmask]> Cc: CCP <[log in to unmask]>, Kris Thielemans <[log in to unmask]>, David Atkinson <[log in to unmask]> Subject: Re: Spatial calibration MR reconstruction Hi Christoph, Thanks for this, I'll have a look at it when I'm in front of my computer. Just to confirm, you reconstructed from the .h5 file that I sent as opposed to using siemens_to_ismrmrd, is that correct? Cheers Richaed P. S. Copying in David as it may be of interest to him (could be an OSX problem). Sent from my phone. Excuse any mistakes/brevity. From: [log in to unmask] <[log in to unmask]> Sent: Monday, February 11, 2019 7:07:00 AM To: Brown, Richard Cc: [log in to unmask] Subject: Re: Spatial calibration MR reconstruction Good morning Richard, I had a look at the data but I did not have any problems reconstructing it. I used the VM-version of SIRF 1.1.1. I have attached the python script which I used to reconstruct the data. This then gives me 31 slices with the correct positions and 518 x 512 voxels in each 2D image. The 518 rather than 512 are due to same data acquisition restrictions which for this sequence did not allow to acquire 512. I think - but not entirely sure - that Siemens keeps the FOV the same but increases the resolution by this additional 6 k-space points. Hence, in order to get the correct resolution you would have to do some Fourier interpolation from 518 down to 512 pixel. I did not do that, I simply cropped the image to 512 x 512 pixel to compare it to the dicom (see attached screenshot) The top is the dicom data, the second row is the SIRF data and the botton row is the difference image. Looks fairly comparable to me. Let me know if there is anything else I can help you with. Regards, Christoph -- Christoph Kolbitsch, Ph.D. Head of Research Group Quantitative MRI Physikalisch-Technische Bundesanstalt Abbestr. 2-12 10587 Berlin, Germany phone: +49 30 3481 7761 Von: "Brown, Richard" <[log in to unmask]> An: "Christoph Kolbitsch" <[log in to unmask]> Kopie: "[log in to unmask]" <[log in to unmask]> Datum: 08.02.2019 13:19 Betreff: Spatial calibration MR reconstruction Hi Christoph, As discussed in the tcon today, I’ve put the MR data from the spatial calibration phantom on OneDrive: https://liveuclac-my.sharepoint.com/:f:/g/personal/rmharbr_ucl_ac_uk/EoJIDRlWDqhFsJodVh6USSABBfmphdKXhg1li0IUazOObQ?e=5DQJDK The folders are fairly self-explanatory: - dicom: vendor reconstructions - raw: Raw MR data - raw_to_ismrmrd: the raw MR data converted to ISMRMRD using " siemens_to_ismrmrd -f input.dat -o output.h5 " I tried various different methods of reconstructing (both SIRF-Gadgetron and native Gadgetron), including: - Gadgetron: gadgetron_ismrmrd_client -f meas_MID00749_FID151779_t2_tse_sag.h5 -c default.xml -o out.h5 - SIRF: fully_sampled_recon.py - SIRF: fully_sampled_recon_single_chain.py - SIRF: grappa_basic.py - SIRF: grappa_and_steepest_descent.py All the algorithms give different results, none of which look correct. The dicom consists of 31 slices, so I expect to be able to reconstruct a similar image. There’s an email chain in the CCP-Devel list with the subject "Number of slices & slice spacing in MR recon", in which we mention various different image dimensions. Lastly, I’ve put a table below. It shows how the z-spacing varied over the 12 reconstructed slices. It looks like the distance (91.5615 - (-64.4385) would allow for 31 slices with 5.2mm separation. So it looks like slices are missing from the middle. Who knows what’s going on there… Image Projection Distance 1 -64.4385 2 -48.8385 15.6 3 -38.4385 10.4 4 -33.2385 5.2 5 -12.4385 20.8 6 -7.23847 5.20003 7 -2.03847 5.2 8 8.36153 10.4 9 29.1615 20.79997 10 39.5615 10.4 11 70.7615 31.2 12 91.5615 20.8 Anyway, good luck! Let me know if you need any more information/data. Cheers, Richard ######################################################################## To unsubscribe from the CCP-PETMR-DEVEL list, click the following link: https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP-PETMR-DEVEL&A=1