Hi all,
I’ve noticed a bug when saving control points to FCSV in Slicer version 5.4. There is a trailing ,2,0 written at the end of each data line. These additional columns have not been in previous versions of Slicer and are not defined in the header info. I’ve found the same behavior in Slicer 5.2.
Greydon
Fcsv is a legacy format and you should use json to store markups (there should be warning popping up each time when you are saving a markup in fcsv fomrat)
Those two fields store the status of markup point (being editted, missing, not olaced etc) and are necessary.
I am aware of the switch to mrk.json. However, our lab has many pipelines and datasets implementing this format so we prefer to hold this version stationary for as long as possible.
In future Slicer versions, would it be possible to remove these two additional columns when writing FCSV or update the file header to include the two additional column metadata?
This change in how Slicer hands FCSV files breaks a previously working file standard. I understand that the majority of users will convert to the new standard but it would be great to have legacy support for previous FCSV files.
Correct if wrong but the behaviors associated with the new columns only occur when the vtkMRMLMarkupsNode is open. I do not see the reason for needing to write them to the FCSV file.
It is of course your call, but the longer you hold on more troublesome the transition will be. (we also have thousands of files almost a decade).
I can’t speak for others, but it is unlikely that anyone will spend time doing anything for a format that might be deprecated pretty soon. It is also not that trivial, if we add those two columns in the header then older slicer versions will not be able to read the format. if we do not write it, we will be ignoring information. (these were all the reasons for switch to json, fcsv cannot be expanded easily).
Where are you having trouble reading this files, as far as I know any Slicer would read the fcsv file correctly. If you are trying to read the file to some other software, your best best would ignoring the header and parsing the file.
FYI, if you are using any of the status features, FCSV may not be even saving coordinates correctly.
This is what I have in my scene:
# Markups fiducial file version = 5.4
# CoordinateSystem = LPS
# columns = id,x,y,z,ow,ox,oy,oz,vis,sel,lock,label,desc,associatedNodeID
1,-322.5806451612903,-5.684341886080802e-14,-35.993208828522924,0,0,0,1,1,1,0,crossed,,,3,0
2,-517.4872665534805,-5.684341886080802e-14,122.92020373514431,0,0,0,1,1,1,1,locked,,,2,0
3,-361.6298811544991,5.684341886080802e-14,44.82173174872663,0,0,0,1,1,1,0,editing,,,0,0
this what JSON reports correctly:
"@schema": "https://raw.githubusercontent.com/slicer/slicer/master/Modules/Loadable/Markups/Resources/Schema/markups-schema-v1.0.3.json#",
"markups": [
{
"type": "Fiducial",
"coordinateSystem": "LPS",
"coordinateUnits": "mm",
"locked": false,
"fixedNumberOfControlPoints": false,
"labelFormat": "%N-%d",
"lastUsedControlPointNumber": 3,
"controlPoints": [
{
"id": "1",
"label": "crossed",
"description": "",
"associatedNodeID": "",
"position": "",
"orientation": [-1.0, -0.0, -0.0, -0.0, -1.0, -0.0, 0.0, 0.0, 1.0],
"selected": true,
"locked": false,
"visibility": true,
"positionStatus": "missing"
},
{
"id": "2",
"label": "locked",
"description": "",
"associatedNodeID": "",
"position": [-517.4872665534805, -5.684341886080802e-14, 122.92020373514431],
"orientation": [-1.0, -0.0, -0.0, -0.0, -1.0, -0.0, 0.0, 0.0, 1.0],
"selected": true,
"locked": true,
"visibility": true,
"positionStatus": "defined"
},
{
"id": "3",
"label": "editing",
"description": "",
"associatedNodeID": "",
"position": "",
"orientation": [-1.0, -0.0, -0.0, -0.0, -1.0, -0.0, 0.0, 0.0, 1.0],
"selected": true,
"locked": false,
"visibility": true,
"positionStatus": "undefined"
}