View Issue Details

IDProjectCategoryView StatusLast Update
0004408Slicer4Module Modelspublic2017-09-27 19:05
ReporterlassoanAssigned Tolassoan 
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
Product VersionSlicer 4.7.0 
Target VersionSlicer 4.7.0Fixed in VersionSlicer 4.7.0 
Summary0004408: Save coordinate system in surface mesh file
Description

Slicer saves mesh in RAS coordinate system, while most other software use LPS.
Save coordinate system in the header of the mesh file so that Slicer can transform the coordinates as needed.
After the coordinate systems are saved we would still interpret mesh files without coordinate system information as being in RAS, but in 1-2 years - when most Slicer-saved files have the coordinate system information embedded in the file - we can change the behavior to assume LPS if coordinate system information is missing.

It would be also good to add a file IO option so that the user could choose orientation (auto, RAS, LPS).

Currently supported file formats: (.vtk .vtp .vtu .g .byu .stl .ply .orig"
" .inflated .sphere .white .smoothwm .pial .obj)

See details in this discussion:
https://discourse.slicer.org/t/specifying-coordinate-system-in-surface-mesh-file/724/6

TagsNo tags attached.

Relationships

related to 0004445 assignedjcfr Model files should be saved in LPS coordinate system 

Activities

jcfr

jcfr

2017-09-26 10:20

administrator   ~0015127

Hi Andras,

Is it something you plan on fixing for the release ?

Jc

lassoan

lassoan

2017-09-26 17:14

developer   ~0015140

In 4.7 I only plan to add saving of the coordinate space name (hardcoded to RAS).

In the next major release we can change Slicer to save in LPS by default. In a few years we can change Slicer to read as LPS by default (if no coordinate space is specified in the file) - by then there should not be too many legacy files around.

lassoan

lassoan

2017-09-27 09:16

developer   ~0015141

Partial fix is implemented in https://github.com/Slicer/Slicer/pull/798

lassoan

lassoan

2017-09-27 19:00

developer   ~0015210

Discussion on github:

pieper:

Steps 1 and 2 make a lot of sense and there's no reason not to do that.
Steps 3 and 4 sound risky to me, but if there's no better alternative that can be the default plan.
What I'd much rather see that if we are changing the default storage of models we pick a completely different format to avoid ambiguities. DICOM surface segmentations could be a good choice but we could see if there are others that would make more sense. We could maintain VTK export, with the SPACE declaration, as a backwards compatibility mode along with STL and OBJ.

lassoan:

Yes, step 3 and 4 may cause troubles so probably a few year transition time is preferable.
I agree that it would be nice to go towards using DICOM as a primary format for saving data, and in general save everything into DICOM. Currently, saving is mixed with exporting, so it is all somewhat complicated and error-prone, but hopefully we can separate them a bit better in the coming years.

lassoan

lassoan

2017-09-27 19:05

developer   ~0015211

Merged in r26398. Future steps will be discussed in https://issues.slicer.org/view.php?id=4445

Issue History

Date Modified Username Field Change
2017-08-04 09:18 lassoan New Issue
2017-09-26 10:19 jcfr Status new => acknowledged
2017-09-26 10:20 jcfr Status acknowledged => feedback
2017-09-26 10:20 jcfr Note Added: 0015127
2017-09-26 17:14 lassoan Note Added: 0015140
2017-09-26 17:14 lassoan Status feedback => new
2017-09-26 17:15 lassoan Assigned To => lassoan
2017-09-26 17:15 lassoan Status new => assigned
2017-09-27 09:16 lassoan Note Added: 0015141
2017-09-27 19:00 lassoan Note Added: 0015210
2017-09-27 19:04 lassoan Relationship added related to 0004445
2017-09-27 19:05 lassoan Status assigned => resolved
2017-09-27 19:05 lassoan Resolution open => fixed
2017-09-27 19:05 lassoan Fixed in Version => Slicer 4.7.0
2017-09-27 19:05 lassoan Note Added: 0015211