[Loris-dev] A question re MRI tables

[Najmeh Khalili-Mahani, Dr]

Hi David, thank you this makes the logic very clear.

For my application (1) is unimportant, but (2) is important. However, I
would need some flexibility, as the MRI data is likely to be generated with
new experimental sequences.

I understand that DICOM inconsistencies could be an issue. But assume we
are getting data only from ONE scanner, and we make sure that the
DICOM-2-MINC is reliable for any image that is produced on THAT scanner.
Then I would assume that at the moment I am uploading a dicom file into my
MRI table of a new project, then it can simultaneously/automatically read
the header and fill in the values for MRI attributes. In this case we need
a table that accommodates all sequence attributes (FOV, resolution, TR,
TE1, TI, etc.), but allows to fill in only those that are pertinent to one
particular sequence.). Would this make sense and be feasible?

I am curious how this issue will be handled for a BIC-LORIS instance, where
one would expect the data to be collected over many experiments, with
customized sequence designs (e.g. work from Rick or Bruce's lab).

Much thanks
Naj




On Wed, Nov 11, 2015 at 10:03 AM, David MacFarlane, Mr. <
david.macfarlane2 at mcgill.ca> wrote:

> Hi Najmeh,
>
> That might be possible to do for some projects, but there's a few small
> problems in a general case for LORIS:
>
> 1. The mri_protocol table that you're referring to is meant to enforce the
> acceptable protocol range for a study, not describe the existing data. This
> is a form of QC to ensure that scans which are far out of range don't get
> inserted.
> 2. The mri_protocol table is used to identify the scan type for scans as
> they come in based on the header ranges. There would need to be a better
> way to identify what type of scan and link it to the scan_types table (you
> can already use the series description instead of the ranges in the
> mri_protocol table, but there's no standard for series descriptions so you
> still need to manually link the series description to the protocol type in
> LORIS) and
> 3. New projects don't have scans to extract the header information from,
> because the scans haven't been acquired yet.
>
> Having a script to automatically populate the mri_protocol table based on
> an existing DICOM data set would certainly be a useful for some projects,
> though, for people who aren't concerned about point 1.
>
> - Dave
> ------------------------------
> From: najmeh.khalilimahani at mcgill.ca
> Date: Tue, 10 Nov 2015 09:49:50 -0500
> To: loris-dev at bic.mni.mcgill.ca
> Subject: [Loris-dev] A question re MRI tables
>
>
> Hi,
>
> If I understand correctly, before starting to load the MRI data via Image
> Uploader, one must manually populate tables with information about the
> acquisition times of different sequences (T1, T2, TR, etc.)
>
> This is perhaps a naive question, but I wonder, might it be feasible for
> LORIS to have a PERL script that extracts those information from the DICOM
> or MINC headers and stores them without human intervention?
>
> Much thanks
> Naj
>
> ==================================
> Najmeh Khalili-Mahani, PhD
> Research Associate
> McGill Centre for Integrative Neuroscience
> Montreal Neurological Institute
> McGill University
>
> NW-143, 3801 University St.
> Montreal, QC, H3A 2B4
> Office: 514-398-1799
> email: najma at bic.mni.mcgill.ca
>
> _______________________________________________ Loris-dev mailing list
> Loris-dev at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/loris-dev
>



-- 
==================================
Najmeh Khalili-Mahani, PhD
Research Associate
McGill Centre for Integrative Neuroscience
Montreal Neurological Institute
McGill University

NW-143, 3801 University St.
Montreal, QC, H3A 2B4
Office: 514-398-1799
email: najma at bic.mni.mcgill.ca
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.bic.mni.mcgill.ca/pipermail/loris-dev/attachments/20151111/68e5cad7/attachment.html>