Back to the main page.
Bug 3061 - implement support for output files from structure.io sensor 3D scanner
Status | CLOSED FIXED |
Reported | 2016-02-03 11:21:00 +0100 |
Modified | 2019-08-10 12:41:19 +0200 |
Product: | FieldTrip |
Component: | fileio |
Version: | unspecified |
Hardware: | PC |
Operating System: | Mac OS |
Importance: | P5 normal |
Assigned to: | Simon |
URL: | |
Tags: | |
Depends on: | |
Blocks: | |
See also: |
Robert Oostenveld - 2016-02-03 11:21:03 +0100
We are experimenting with a http://structure.io scanner for electrodes and head shapes. Its default output is *.obj. In meshlab it can be converted to *.ply or *.stl (retaining color). ft_read_headshape does not support *.obj yet. It does support ply and stl, but on the ply file it fails and with the stl file the color is not returned. So some code improvements are needed. The OBJ format is detailed on https://en.wikipedia.org/wiki/Wavefront_.obj_file and http://paulbourke.net/dataformats/obj. It is simple ascii file format but it can contain complex geometries. Also, the color coding is represented in a separate (jpg) file with a mapping between them. The ply and stl files contain all data in a single file, hence I suggest to improve the existing implementation for those, rather than making a new reader for the obj files.
Jörn M. Horschig - 2016-02-03 13:44:55 +0100
I happen to work with wavefront object files for our 3D visualization. For Matlab, there is a File Exchange toolbox that can read and write these files: http://nl.mathworks.com/matlabcentral/fileexchange/27982-wavefront-obj-toolbox
Robert Oostenveld - 2016-02-03 13:50:50 +0100
(In reply to Jörn M. Horschig from comment #1) cool, thanks!
Simon - 2016-02-22 11:26:52 +0100
Implemented to read the headshape data from the structure.io .obj https://github.com/fieldtrip/fieldtrip/pull/101
Robert Oostenveld - 2016-02-22 11:45:07 +0100
(In reply to Simon from comment #3) Please look at the ft_hastoolbox function, add the URL there and toolbox detection code, and call ft_hastoolbox just prior to the actual code in ft_read_headshape to manage the path. I suggest to call it "wavefront" in all lower case (and hence fieldtrip/external/wavefront) instead of "WOBJ_toolbox_Version2b" and to add a VERSION file to that directory.
Simon - 2016-02-22 13:55:31 +0100
(In reply to Robert Oostenveld from comment #4) Added suggested code: https://github.com/fieldtrip/fieldtrip/pull/101
Robert Oostenveld - 2016-02-22 17:03:30 +0100
I just merged https://github.com/fieldtrip/fieldtrip/pull/101 We should also add the color mapping to the output head shape, e.g. as headshape.color or head shape.rgb. There is now for some formats 'sulc' 'curv' 'area' 'thickness' 'atlasroi' as additional fields (that I am aware of). @Jan-Mathijs, is there also (perhaps for FS or Caret) a color mapping that is already added to meshes? If so, we should reuse that field name.
Jan-Mathijs Schoffelen - 2016-02-22 17:14:10 +0100
in caret/workbench speak these files are referred to as 'metric' files (typically with the extension .shape.gii. Specifically, workbench/hcp seems to hold on to the convention Subjectid.L/R.thickness.someresolution.shape.gii, where L/R is either L or R, and some resolution can be something like 'native' or 32k_fs_LR if surface registered to the freesurfer template). Actually, the atlasroi, curv, sulc, and thickness are inspired by FS/workbench I am not aware of another standard name for a metric quantity. And of course my whole blabla above does not necessary apply at all, because 1) the headshape contains both left and right 2) there's no surface registration involved, doh.
Robert Oostenveld - 2016-02-22 17:15:25 +0100
(In reply to Jan-Mathijs Schoffelen from comment #7) I am simply thinking of something similar to "headshape.curv" with three RGB columns...
Simon - 2016-03-03 16:50:18 +0100
Added colorcode to ft_read_headshape for structure.io https://github.com/fieldtrip/fieldtrip/pull/115
Robert Oostenveld - 2016-03-03 17:51:48 +0100
(In reply to Simon from comment #9) did you receive the comments (by mail) that i typed into the github site, commenting on your suggested changes?
Simon - 2016-03-04 10:30:49 +0100
(In reply to Robert Oostenveld from comment #10) Yes, I got them.
Robert Oostenveld - 2017-05-10 09:37:02 +0200
hmm, I think that this issue is fully resolved. @Simon, can you confirm and if so, close this bug?
Simon - 2017-05-10 09:39:48 +0200
(In reply to Robert Oostenveld from comment #12) This is resolved. I close it.
Simon - 2017-05-10 09:40:16 +0200
closed.
Robert Oostenveld - 2019-08-10 12:35:08 +0200
This closes a whole series of bugs that have been resolved (either FIXED/WONTFIX/INVALID) for quite some time. If you disagree, please file a new issue on https://github.com/fieldtrip/fieldtrip/issues.