Back to the main page.

Bug 3061 - implement support for output files from sensor 3D scanner

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
Depends on:
See also:

Robert Oostenveld - 2016-02-03 11:21:03 +0100

We are experimenting with a 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 and 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:

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 .obj

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:

Robert Oostenveld - 2016-02-22 17:03:30 +0100

I just merged 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

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


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

Robert Oostenveld - 2019-08-10 12:41:19 +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