Issue with reconstructed image

[kerkelae]

I was able to run the demo on my computer using the smaller dataset (although it took 8 h), but the reconstructed image (03_07_2023_19_48_28-rec4D.nii.gz) does not look right. Below is what I see with fsleyes. Any idea what went wrong and how to fix the issue?

[cariyurek]

Hi @kerkelae ,

I am happy to hear that you were able to run the demo. In this image, you are looking at the very first slice (back of the subject) at the very beginning of the sequence. Could you move to a slice where you could see kidneys and a mid-point in the time dimension? But it is true that this data was acquired with poor quality with some artifacts unlike the actual data (the first dataset) we shared, which produces the images in the paper.

[kerkelae]

Thanks @cariyurek! The coronal slices of most of the volumes look as expected. Is it expected for the sagittal and axial slices to look like this? What is causing it? Is the ordering of the slices correct?

[cariyurek]

Hi @kerkelae ,

This looks good! But not on sagittal and transverse planes... Yes, there is definitely a problem with the slice order here. Although slice ordering is correct when I run the same reconstruction code. So what I suspect is that it is reading the slices in the order of s-0.mat s-1.mat s-10.mat s-11.mat ... instead of s-1.mat s-2.mat s-3.mat s-4.mat ... in os.listdir in slice_to_vol.py when it is writing the 4D volume. We have always run pyGRASP only in linux based systems and we did not have this problem. Apparently, reading order changes in os.listdir with different operating systems. To overcome this bug, we added "0" for the single digit slices, so from now on it will be s-00.mat s-01.mat s-02.mat ... s-09.mat s-10.mat ..., so that it will read in the correct order for all systems. We have uploaded the fixed version of the code. We are glad that there is someone testing our software. We are very sorry for this inconvenience and we will ask you to try it once more with the updated version.

[kerkelae]

I am also using Linux (Ubuntu 22.04 with Anaconda and the packages defined by you), so maybe the issue lies somewhere else. I can try to run the example next week with the updated code.

[thomasediolausson]

Hi,

Thank you so much for sharing the code. However, I'm running into similar issues that the kerkelae has with both datasets. Slices do seem to be mixed around and difficult to interpret what's going wrong.

Did you @cariyurek find a simple solution?

Ideally, I would like to have an array with the entire stack-of-stars k-space in. But now I'm not sure if I can use the output directly from your preprocessing pipeline.

All the best,

[cariyurek]

Hi @thomasediolausson ,

Thank you for reaching out. This is interesting to hear because I thought we have fixed issue by naming the slices as -00.mat s-01.mat s-02.mat ... s-09.mat s-10.mat ..., so that it will read in the correct order for all systems. Could you please share images of what you see as a volume and slices? And in the folders do you see these mat files s-XX.mat?

Best,

Cemre

[thomasediolausson]

Thanks for the quick response.

Sure, it does look like the naming is two digits long.

And just some gif over all the slices

[thomasediolausson]

Apologize for the spam, but I attempted to manually sort the slices. As you can see, the slice indexes don't really match the anatomy. Maybe with this, it's more clear what's going wrong.

[cariyurek]

Thank you @thomasediolausson for sharing your results. I could not understand what has been going on at first look. Is this data acquired by your group or is this the data we have provided?

If it is acquired by your group, I wanted to how the slice acquisition order was. Were they acquired in interleaved fashion?

[thomasediolausson]

Thanks again. Yes this is strange. This is the data that you provide, the 64 Gb file.

I guess steps to reproduce it are Python 3.10, and Ubuntu 18.04.

[cariyurek]

Thanks for the information. This is very interesting. May I also ask what viewer you are using? I am trying to replicate the problem. I am very sorry for the inconvenience. This is very helpful for us to debug the issues.

[thomasediolausson]

No problem, I'm just curious to try your framework.

I'm using this script to load the data from the folder (s-01.mat...s-19.mat). slicer5d is just some in-house developed volume viewer.

%% Load pyGRASP recon
pygrasp_recon = zeros(448,448,20,1,156);
for i=0:19
    disp(i)
    slice_recon = load(sprintf('/mnt/sata1/tolausso/code/pyGRASP/subject_2/sub-1/07_17_2023_13_27_48/raw-rec/s-%02d.mat',i));
    slice_recon = struct2cell(slice_recon);
    slice_recon = permute(slice_recon{1},[2,3,4,5,1]); 
    pygrasp_recon(:,:,i+1,:,:) = slice_recon;
end
slicer5d(pygrasp_recon)

[cariyurek]

Have you checked the 4D result, 'DATE_TIME'-rec4D.nii.gz, which is after post-processing? Could you also share them if one of the above is not 'DATE_TIME'-rec4D.nii.gz?

[liamtimms]

@kerkelae this should be fixed by https://github.com/quin-med-harvard-edu/pyGRASP/commit/9001cb325cd24c201cebf1c725d0f4b878f48ef5 if you have a chance to retest.