I usually calculate the peaks with sh2peak and then use your Matlab Code to read the Peak,mif Files.
I did the latest update and after that I get these error messages in Matlab and cant read all the values I need:
Did you change something in the File format? Or did I something wrong.
I am close to sure that I didnt change something in my sequnce of analysis using MRtrix. I regocnized that the files are some kibytes bigger. Is the header different?
Are those the only warning messages? If so, MatLab shouldn’t be providing you with any less information than it was previously; it’s just that the MatLab code hasn’t been updated to reflect some of the goodies we’ve added in 3.0_RC1 (yet more stuff we forgot to add to the changelog):
Each time you run a command on an input image to produce an output image, command_history will be concatenated with the latest command string. So you end up with a history of the commands used to produce an image, right there in the image header.
Whenever a command converts a DWI to (something that is an image but not a DWI), the diffusion gradient scheme that was used in the calculation will be written to prior_dw_scheme, and any dw_scheme entry in the header will be erased. This prevents terminal warnings from appearing that complain about the DW scheme not matching the number of image volumes, but still keeps the information there in case it’s of interest. The full development debate (debacle?) is here.
thanks for the answer.
Its a bit more complicated. It doesnt give me all the values, like before.
For instance:
I calculate the norm of the vectors of the peaks. If I read an “old” peak file it gives me like 30 norms. If I calculate the peaks from the same old FOD.mif file with the last version of MRtrix and use the exact same matlab code to read and calculate it gives me like 20 times the “prior dw scheeme” message and only 5 norms of 5 vectors.
I have no idea and didnt change something just update mrtrix.
So, I hoped that somebody of you changed something in the last version.
If I have time I go trough my matlab code (very long) to see what the “read_mrtrix.m” doesnt read in for me.
But something is different somehow. with the last update and I would say the sh2peak command. I only used that command with the old data.
You understand what I did?
Short: From the old mrtrix 3 caculated data, I processed just a new peak.mif.
Now I have:
peak_old_mrtrix3.mif -> works
peak_new_mrtrix3.mif -> doesnt
The “old” one works and the “new” one works too, but gives me not enough and a lot of dwscheme info lines!
OK, I’ve just checked, there’s been no changes to sh2peaks beyond those required as part of the update - it should behave identically. Moreover, we’d have picked up any difference in the automated testing. So I think the issue is something else.
What I’d be worried about though is that you say that with your previous installation, sh2peak identified 30 peaks from each FOD…? That sounds just plain wrong… Any chance you could post the commands that led to the production of that file, and the subsequent sh2peaks command? Could it have something to do with changes we made recently to the default lmax value in dwi2fod…?
In any case, we might consider changing the way these unknown keys are handled in the Matlab code, possibly by adding them as fields in the output structure, which would make it possible to actually make use of the data, and avoid all these unnecessary warnings. Might be worth filing an issue for that…
The 30 was just a guess. The code I wrote fpr Matlab is a while ago and I noticed just that it is different and the message lines new.
The code gives me the 3 of the first vectors of a line from the peak file.
And now it gives me still the right values with the old peak file and less with the new peak files.
The new peak files comes just from the old FOD data…so just sh2peak what I used. So, I oped you have an idea.
I will go trough my code to narrow it down what is different in the new peak files. Orrrrrrrrrrrrr, can there be aproblem using the old FOD files with the new sh2peak command…orrrrrrrrr…other…,not using th enew FOD command?
OK, so starting from the same FOD.mif file, and just running sh2peaks on it, you get different results between your previous installation and the new one? Weird…
Can you check which version was your previous installation? If it’s anywhere near recent, the MRtrix version used when the file was generated would have been stored in the output image header. Use mrinfo to check what that was for your old peaks file (I’m hoping it’s in mif format…).
No. There would be a problem using FOD files from the previous MRtrix 0.2.X line, but everything should be fine and self-consistent using the MRtrix3 line.
I assume you mean dwi2fod…? No, I can’t see how that can have any effect if you’re starting from the same FOD.mif image anyway…
the oldest I use are: > mrtrix_version: 0.3.15-95-g789c7399-dirty
Its MRTrix3…I am sure of that , but it says 0.3!
But with these files it workes fine.
Did you change something how the files are stored since then?
Another question: where is the vector Tool in mrview. I didnt use it for along time, but I thought there was one to look at the peak vectors.
Tommorrow I go trough my code. Maybe I find the problem with the new files.
OK, yes it is MRtrix3 - the 0.3 version number simply reflects the fact that the software was considered to be in beta until last week (version number is now 3.0_RC1).
So, yes there have been a few changes since your version - over 1,300 commits… But as far as the code that would be relevant for sh2peaks, nothing stands out as particularly different between your version (789c7399) and the current 3.0_RC1. You can check what the changes are exactly with:
However, the dirty suffix at the end of your version string suggests that you have modified the code from what it was. Not sure what changes you made…?
It’s still there - it’s just called ‘Fixel plot’ now. Not entirely convinced it’s the best name for it, given you had to ask… We might need to rethink that one.
sorry for the late answer.
I fixed it. I made my code fully new with the last MRTrix Version and it works.
I dont fully understand, why the old code didnt work any more.
The dirty suffix came from an issue I had with MRTrix3 and a new Ubuntu Version. Donald and Rob fixed it for me back then. I think EIgenvalue or something.
Thats why the suffix … I think.
Maybe that was the problem after all.
I am glad it works now and I get my values from the peaks.
Ill keep the fixel plot in mind. You could change the name, since its possible to view some other vectors with it too not only fixel.
OK, this is clearly causing a bit of confusion… There’s really nothing to worry about: with the latest update, MRtrix3 adds a few additional entries in the header, including command history. The Matlab code doesn’t know what to do with them, so just ignores them - but clearly it’s being a bit alarmist about it. But these additional keys are not required to read the data, they just provide additional information about the data - this shouldn’t affect your processing in any way.
I’ve just pushed a commit that now allows any unknown fields to be imported, which should solve this issue: not only will read_mrtrix no longer complain about unknown keys, but you’ll be able to access them from Matlab. It should be available shortly once it’s passed all the required tests.
