seventeen suggestions for AMARES and jMRUI

Home > Forums > jMRUI Software > Feature requests > seventeen suggestions for AMARES and jMRUI

Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
  • #1725
    Ronald Ouwerkerk

    I would like to thank all code contributors to the jMRUI for their work in making jMRUI what it is today. I am a very frequent user of jMRUI and I think jMRUI has improved enormously over the years. Even so, there are some points that would make the use of jMRUI for fitting large numbers of MR spectra easier, quicker and more reliable. Here are some suggestions for things I would love to see fixed in future versions of jMRUI, specifically in AMARES which I use most. (I am using jMRUI 5.2 build 008 on a Windows XP virtual machine v7.1.1 on a Mac OSX 10.11.6)
    1. In AMARES the stating values (*.sv files) and prior knowledge information (*.pk files) have to be loaded separately even though in most cases the two are closely linked. Why not load a *.pk file with the same base name as default and allow users to load a separate file only when needed.
    2. In AMARES the default setting for starting values and prior knowledge is not the default (meaning that you have to load the default values explicitly to see them). The real default appears to be no peaks defined. In the phase tab the default appears to be the settings last used.
    3. The “Default Quantitation” button is useful, even though you get no inspection of what the default settings are before fitting. However, it would be better though if there was a quick way to to choose the most recently used settings.
    4. I often fit water suppressed and non-water suppressed 1H-MR spectra and spectra from different organs and now it is most efficient to group them so I can use one set of initial values and prior knowledge repeatedly (with “Default Quantitation”). I would like a quick way to alternate. The fact that we have to load .pk and .sv files separate makes alternating between two sets worse. So, how about a recently used file list?
    5. In AMARES when using save file as mrui the filename in the spectrum display window doers not change and subsequent ‘save’ commands will save the file as the original filename (overwriting the original file with a modified version). My workaround: I close the .mrui file and the open the one I just created with ‘save as’.
    6. Even with this workaround of point 1 the filename saved in an HTML file when I publish results is still the original filename. I used to change the name in the displayed HTML before saving as a workaround, but now that no longer works (the HTML save still uses the original filename). The name in the HTML should be the last “saved as” filename so data and fit results are linked.
    7. With “file/save All/save All as Text” in the results window a text file is generated with only the first filename and lists of amplitudes, frequencies etc. that have no spectrum file identification. A list of all filenames of the fitted spectra (with index numbers mirrored in the amplitude and frequency lists ) would help a lot to keep track of results. For now I use the HTML export to keep the link between spectrum filename and results.
    8. I use “file/print/publish/Publish All” in the results window to get results of a series of spectra in one file with the spectra filenames linked to the results. I then run a script (in Matlab) to extract the results and write them in a comma separated values (*.csv) file that can be imported in Excel.Can we have a direct save to *.csv in a format that keeps fit results and spectrum filenames linked?
    9. I want to be able to distinguish a fit from a spectrum that has been modified from an unmodified spectrum. I use the filename for that (e.g. adding Ave or HSVD to the filename so I know the result was an averaged spectrum or HSVD filtered).
    10. The method of entering prior knowledge for multiplets is not user friendly. The pattern for doublets and triplets could easily be defined with a J coupling (hard or variable with soft J constraints) and a setting for locked or unlocked relative amplitudes and line widths. And a doublet plus triplet with the same J should be coupled with the same (slightly variable?) J in prior knowledge.
    11. The chemical shift prior knowledge and soft constraints are all locked to a reference frequency. A lot of the chemical shift variations are just offset variations. In 1H-MRS the distance between water and for instance creatine really does not vary much. A more ridged set of initial values and tighter soft constraints could be combined with an overall variable for spectrum reference shift. For individual peaks that do shift (e.g. with pH) the individual soft constraint boundaries can then be widened whilst getting a more reliable fit on all others.
    12. In the publish results output an array of graphics files is produced. I would like to choose which ones I want in the settings.
    13. For a series of fitted spectra the HTML published files (“file/print/publish/Publish All” in the results window) comprise an HTML file, a series of svg graphics files, one postscript file and one pdf file (of the first spectrum only). The svg are needed to make the HTML for all fitted spectra, but he PDF and PS are more or less equivalent and since they are from the first spectrum only they have no real purpose that would not be covered with a separate save result to PS PDF (or EPS) button.
    14. In the settings for export directory I have ‘use last’. However I would prefer to have the option ‘same as data directory’. I don’t want all results in one big pile, but saved together with my raw data.
    15. I would like to see improvement in the accessibility to prior knowledge files for any fit method so that prior knowledge can be more easily fine-tuned based on results (using external software). I would like to be able to fit hundreds of in-vivo spectra and then use statistics to find the mean (relative) positions of resonances and then build a starting values and prior knowledge files from that with soft constraints based on chemical shift standard deviations
    16. A more accessible format for prior knowledge and starting values would also make sharing these between different researchers easier. Adjustment for B0 field or TE could be made more easily.
    17. The prior knowledge files cannot easily be modified in terms of peak order. It would be great if we could sort the peaks in the list by name or by chemical shift.

    Ronald Ouwerkerk
    National Institutes of Health (NIH)


    Thank you so much for your suggestions.

    jMRUI dev team.

    Anindita Sengupta

    Hello Ronald,

    Thank you so much for the suggestions. Can you please guide me to figure out where I can get the .pk and .sv files to work in AMARES for quantification of my results.


    Minh Vo

    Hello Mr. Ronald,
    How can I create sv and pk files?
    Thanks and Best regards,
    Minh Vo

    Ronald Ouwerkerk

    Hi Minh,Anindita,
    Sorry for the late reply. NIH was throwing jmrui e-mails in the spam-quarantine.
    The prior knowledge and starting value files cannot be edited outside jMRUI. There is a new text export feature that lets you export them to a text file which easily reads into Excel as comma-separated values.
    I have been trying to read the .pk and .sv files in Matlab and in a binary read you will recognize the peak labels, but I cannot decipher the file format enough to back-engineer the file format. Would be great if we got the Java or C++ code made public.


    Ronald Ouwerkerk
    National Institutes of Health (NIH)

Viewing 5 posts - 1 through 5 (of 5 total)
  • You must be logged in to reply to this topic.