Back to the main page.
Bug 969 - ft_volumerealign interactive gui doesn't show "R" & "L" indicators
| Status | CLOSED WONTFIX |
| Reported | 2011-09-19 18:15:00 +0200 |
| Modified | 2011-11-11 11:19:34 +0100 |
| Product: | FieldTrip |
| Component: | core |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Mac OS |
| Importance: | P1 normal |
| Assigned to: | Eliezer Kanal |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: |
Eliezer Kanal - 2011-09-19 18:15:56 +0200
Small issue... the realign screen should have the letters "R" and "L" on the coronal and axial views (as well as "A" and "P" on the sagittal view, but that's less important). Given the whole "left vs radiological left" confusion with MRIs, this could potentially be a problem. Attached code with potential fix; please check to ensure that I got my own "R" and "L" labels placed correctly :)
Eliezer Kanal - 2011-09-19 18:16:31 +0200
Created attachment 135 add location indicators
Jan-Mathijs Schoffelen - 2011-09-19 20:11:06 +0200
Hi Elli, In my view, ft_volumerealign should be used to establish left and right, and is usually unresolved a priori. It's the user's responsibility to indicate what is left and what is right. The function shouldn't do this.
Eliezer Kanal - 2011-09-19 22:30:50 +0200
For what it's worth, I don't know if I agree. Correct me if I'm wrong, but at least for DICOM files, isn't the patient orientation written into the file itself? Assuming patient lying face-up, then the orientation is written in the header (see [1]). Granted, in the DICOM files of my own data I don't see the "AP/LR/HF" strings, I have a vector of numbers, but those probably correspond to the orientation in a way I'm not familiar with. That all being said, I'm not familiar enough with the file formats to fix this up myself, so if you want to close this as a WONTFIX that's fine with me. [1]: http://www.dclunie.com/medical-image-faq/html/part2.html#DICOMOrientation
Robert Oostenveld - 2011-09-20 14:26:49 +0200
Note the general problem is not only for MRI, but for all data with a geometrical "quality", such as gradiometers, electrode positions, source positions, volume conduction models. For these geometrical data objects we have the field xxx.coordsys, which can be assigned a value like 'ctf', 'spm', 'neuromag', 'mni', 'tal' and potentially others. This pertains to the orientation of the axes relative to the anatomy, and to the location of the origin (which also varies). We also have the field xxx.units which can be 'cm', 'mm' or 'm'. See FT_*_COORDSYS and FT_*_UNITS in fieldtrip/utilities At this moment when the geometrical object is being constructed (or read from disk) the coordsys and units are not always assigned to the data structure (or better: most of the times they are not explicitely assigned). Consequently, once the data is in memory you don't know how the anatomy is in the data structure. The user can look at the MRI and determine the nose, and figure out left and right, but the software cannot do it automatically. It would be nice to already assign as many information (coordsys, units) to the geometry at the time of reading. It might be that the coordsys can be determined as RAS, which would already help in distinguishing left from right (the other directions are not ambiguous upon visual inspection). At the Donders however we do this http://fieldtrip.fcdonders.nl/faq/how_can_i_convert_an_anatomical_mri_from_dicom_into_ctf_format, which means that we don't care. I summary: it would be nice to have better support for coordsys and units, where it probably makes most sense to start implementing it from the reading functions onward. I leave it to you whether you want to assign a specific action to this... (perhaps you might want to look into the ft_read_mri for the dicom and see whether that one can be improved)
Jan-Mathijs Schoffelen - 2011-09-20 14:45:54 +0200
(perhaps you might want to look into the ft_read_mri for the dicom and see whether that one can be improved) I tried this once, but at the time we decided that we shouldn't do it.
Eliezer Kanal - 2011-09-20 17:09:56 +0200
Thanks for the discussion. As I'm not comfortable enough with the details, I'm going to mark this bug as RESOLVED WONTFIX, and if I - or someone else - figures out a better way to determine orientation from the datafiles we can reexamine this issue and reopen the bug.