Temporal Resolution (0020,0110) is 77196.0256347656 ≈ 1,29 minutes according to the DICOM tags. This seems more reasonable.
Indeed, but not “reasonable enough”. Temporal resolution should be on the order of 5 sec (the smaller the better) for a meaningful analysis. 1.29 min can’t be right, we would not see the dynamics we see in the data with that resolution.
Hi,
Thanks @mschwier and @fedorov for your investigations. I`ve just contacted with someone who oversees the MRI equipment. He said the following:
- The images are not gated so you can ignore the trigger times.
- The DICOM headers from this system aren’t always perfectly accurate.
- The temporal resolution will be the TR x the number of phase encoding repetitions. (You’ll have to check the TR for each individial DCE scan because most are 53.335 but some are 69.746 because there were more slices added to the slice package) To calculate the temporal resolution it would be 53.335 x 96= 5120.16 ms.
Hi @kirezgik,
@fedorov changed the temporal resolution manually to see if this fixes the problem. Unfortunately the curve fitting still looks as wrong as before. This means we’ll have to debug deeper into the computations to see what is the cause for this. We’ll try to extract a tiny sample from your image and see if we can reproduce the error with this sample. With a small sample it is a bit easier to retrace the computations.
1 Like
Hello!
I had a look at the data. First of all, I could not visually identify any ROIs that could be used to define the AIF, so possibly you may need to estimate that. Just for testing, I used some voxels that exhibited AIF characteristics (sharp peak etc.) but were probably more related to motion than to blood vessels.
With this ‘AIF’ I was able to calculate a Ktrans map in the kidney - see below - albeit the values were higher than expected, probably due to the AIF being extremely innaccurate, and the T1 values unknown. Remember to input a BAT frame number in the Advanced options. The Output Fitted data did not align with the actual data but perhaps that is a problem with the fitted data output of the module and not with the fitting procedure.
Sharon
@kirezgik, @fedorov and @mschwier - I did find some vessels for the AIF and analyzed the mouse data using my own DCE analysis program using MatlabBridge in Slicer and the results look fine - see below Ktrans map and fitted data graph. After giving it some more thought, I think that in the PkModeling module perhaps the function that generates the fitted data reads parameters from the Bruker perfusion dataset header incorrectly e.g. reads the sequence TR in msec when it is expecting seconds or something like that.
-Sharon
2 Likes
Hi Sharon @speled,
Based on the ROIs we identified, it seems difficult to define the AIF manually because of the small spatial dimensions or the location of the tumor in mice. So we will try to use some proposed algoritms to automatically define the AIFs, that way we can have a more accurate AIF and Ktrans map, hopefully.
Could you please share the Matlab script you used for your analysis? Then we can try it here in our Slicer.
Thanks for your help,
Ezgi
Hi. fedorov!
How can I change the original DCE-MR datas into MRMLMultiVolume, and when I use the MultiVolumeImporter to get the data, but I don’t kown how to fill in the parameters in advanced setting, thanks very much!
You need to load the DICOM series from the DICOM Browser module. How do you load the data right now and what happens?
Which parameter are you trying to set? All except the first two are for creating output volumes. “Constant BAT” applies only to UseCostantBAT, and should be set to the multivolume frame where you see the beginning of the contrast uptake.
Thanks for help！When I use the MultiVolumeImporter to acquire the 4D image, I get some parameter like RE, RT and FA, etc, but I don’t know the Initial value, step, Frame identifying DICOM tag, how can I get those parameter?
The original DICOM data contain 1920 slices, and 60 frames.
Can I send the data to you?
And when I load the data from the DICOM Browser, I get some deformation images, and it can not be used in pkmodeling.
Sure, you can send me your de-identified dataset and I can take a look.
@kirezgik we are preparing for the NA-MIC Project week that will take place at MIT Jan 8-12 (see https://na-mic.github.io/ProjectWeek/PW27_2018_Boston). We will have a focused project to investigate issues in PkModeling, and will specifically look into the issues that are reproducible with the dataset you kindly shared (see specific project here: https://na-mic.github.io/ProjectWeek/PW27_2018_Boston/Projects/ModelFittingTools/).
You are more than welcome to join project week - this will give you a great opportunity to learn more about Slicer, work with the developers, and refine Slicer DCE analysis implementation. We would be very happy to see you at the project week!
If you are not there, following the project week we should have more understanding, if not the solution, to the problems you identified.
1 Like
Hi @fedorov, I am sorry I missed this message and have not seen earlier. I could not join anyways, but I appreciate your effort and helps to solve this issue. Hope you can have a better idea and maybe solution to that at the end of the project week. I look forward to hearing your updates soon.
Thanks.
Hi @fedorov, I was wondering if you have any updates regarding to this issue.
@kirezgik no, unfortunately we do not have any new results. @speled and @mschwier did not identify the issue at the project week, and I have not been able to make time to investigate this myself. I am sorry!
Are you a developer yourself? Would you be comfortable investigating this issue? We could perhaps give you some pointers?
Hello @kirezgik, (cc: @fedorov,@mschwier)
The issue is probably not in the PK Modeling module, but in the multivolume loading of Bruker data - specifically in recognition of the frametime. I will probably be working on correcting this during Project Week in June. I do not have your problematic original data anymore - if you share it I think I can send you a solution.
all best
Sharon
Hi, I am not a developer myself, so I`d appreciate your help for that. @speled I just shared the original data with you.
Thanks,
Ezgi
@kirezgik (cc: @fedorov)
After you load the multivolume data, and save it (e.g. as .nhdr and .raw.gz) look at this field:
MultiVolume.FrameLabels:=0.0,9074472.1875,18148944.375,27223416.5625,…
This is a list of 90 values, and here it looks like the frametime is 9074472.1875 milliseconds, i.e. 151 minutes!
The frametime is usually in the range of 1-8 seconds…
Here’s how to correct this manually in the .nhdr file.
In the Slicer Dicom browser, highlight your DCE dataset and click the ‘metadata’ button at the bottom. You will see these fields:
0018,0080 RepetitionTime 65.64288
0018,0089 NumberOfPhaseEncodingSteps 96
Usually, the frametime in 2D sequences is the Repetition Time multiplied by the phase encoding steps. In this case that would be 6.3017 seconds.
So you should replace the FrameLabels list in the .nhdr file by 0,6301.7,etc…
Here is a Matlab script that generates the new list:
TR=65.6429;
numtimepoints=90;
PE=96;
%-----
framelabels=[0:TRPE:TRPE*(numtimepoints-1)];
newstring=sprintf(’%0.3f,’,framelabels);
% take off final comma…
newstring=newstring(1:end-1)
Let me know how this works for you?
all best
Sharon
@speled the issue of temporal resolution has already been discussed - see this post: How to analyze DCE-MRI data - #23 by kirezgik. That did not help.