The purpose of this document is to solicit community feedback on the Digital SWC reconstructions describing neuron morphology (SWC) that was submitted to INCF for endorsement as a standard. The document contains the INCF standards and best practices committee's review of SWC, and the criteria in which it was evaluated (open, FAIR, testing and implementation, governance, adoption and use, stability and support, extensibility and comparison to similar standards). For the next 60 days, we are seeking community feedback on SWC.
About SWC:
SWC files (file extension of .swc) are text-based (ASCII text) files that describe three-dimensional neuronal or glial morphology. These digital reconstructions represent morphology as a vectorized tree structure, made of a series of connected nodes. An SWC file contains a series of text-based rows where each neuron node is described by a single row of only seven space-separated values. The format is simple and intuitive; a parser of or writer to the format could be implemented by anyone with knowledge of any programming language.
Summary of Discussion:
With a 25 year history and over 1,000 publications, the SWC format was considered a strong candidate for INCF endorsement by the INCF Standards and Best Practices Committee. It is open, has strong documentation, is well conceived and executed, and supports FAIR reasonably well. It has strong evidence of community support and use outside of the core group involved in its specification and development. Many tools have been developed to support the format. While it has an established governance framework that clearly defines the composition of the Governing Board and the election process, details about governance (e.g. who makes decisions, how conflicts are resolved) are needed.
Recommendation:
The INCF Standards and Best Practices Committee unanimously voted to put the SWC format forward for Community Review.
No competing interests were disclosed
Comments
Wed, 08/09/2023 - 15:50
specification.
I have helped implement the SWC format at least twice (MorphIO and NeuroM),
and have had to work around the complexity of people's varying interpretations
of the format. Having somewhere to point when questions inevitably
show up will be very helpful.
Some comments on the current specification:
> (1) Node index: Represented by the sequence of increasing positive integers,
> starting at 1 (for the first node) and ending at n, where n is number of
> nodes in the neural arbor
Would it be possible to require that the "increasing positive integers" are
"dense"; ie: [1, 10, 20, 99, 1000000000000] should really be [1, 2, 3, 4, 5]?
This simplifies the implementation, and allows for usage, say, 32 bit
integers as the `index` type; a quick examination of some swc files has a
character count of 80 bytes per node, so (2**32)*80 -> 300GB file; unlikely to be a valid file.
> (2) Neurite type: indicated by a positive integer: 1 for soma, 2 for axon, 3
> for dendrite (or basal dendrite if apical is present), 4 for apical
> dendrite, 5 for custom tags (e.g., oblique branches or other user-defined
> preference), 6 for unspecified neurites, 7 for glial processes.
I think it would be helpful to specify two things:
1) The ordering of the types within the file - at the minimum to say that the
soma is the first sample
2) What the limit is for the 'custom' types. for instance, this morphology was
brought to my attention:
https://github.com/BlueBrain/MorphIO/files/11817467/uint8_ChaMARCM-F000106_seg001.lsm_c_3.tif.v3dpbd.zip
It starts off with:
```
# id,type,x,y,z,r,pid
1 274 230 609 19 8 -1
2 274 230 608 19 8 1
3 274 230 607 19 7 2
```
Which is quite a large type id.
> (3, 4, 5) Three-dimensional node coordinates: X, Y, and Z values of the node
> location, expressed by a double datatype number.
> (6) Radius: Neurite thickness at the node (compartment) location represented
> by the radius of the compartment, expressed in micrometers by a double
> datatype number.
I think it's important to note the unit of the x/y/z coordinates, just so it's
clear.
I'm also not sure the precision of a double is required
since the files are encoded in text, and many of them don't seem to have too
many significant digits. Not the most important point, but it should at least
be considered.
> (7) Parent Node: Node index (1) of the parent node. The parent node column
> consists either of a positive integer strictly smaller than the node index
> of the same row or the value of –1, which is used specifically in the case
> of the root node (since the root node has no parent node). The first row of
> the file must be a root node.
Completely agree with this.
> Every node (except for the root) and its parent node form the ending and the
> beginning, respectively, of the connected compartments that make up the
> complete arbor. The cell body of the neuron can be represented by a series
> of connected compartments representing stacked cylinders (multicompartmental
> soma), as a single compartment representing a sphere or as a three-point
> soma (neuromorpho.org/SomaFormat.html).
This is excellent, one thing I'd like to note is I think it would be
worthwhile for the 'three-point-soma' and it's invariants to be defined in
this document.
For instance:
https://neuromorpho.org/dableFiles/baier/CNG%20version/161124_HuCxBG_10_1.CNG.swc
has:
```
1 1 0 0 0 12.5057 -1
2 1 -0.86 0 12.46 12.5057 1
3 1 0.86 0 -12.47 12.5057 1
```
Which varies the X and Z coordinates, but not the Y. I suspect that this
should be considered a 'three-point-soma', however, it could also be
considered a stacked set of compartments, albeit with a strange layout, and
it's not really possible to guess what the meaning is.
Secondly, I think there should be some guidance on what to do in the case of no soma - if there are multiple neuritis, do they set their parent to -1, for instance? Also, what happens in the case of a morphology with a soma, and a disconnected neurite, is that allowed?
Thanks again.
Sincerely,
Michael Gevaert
Fri, 12/22/2023 - 17:41