Issues loading swc somas

Managing anatomically complex model cells with the CellBuilder. Importing morphometric data with NEURON's Import3D tool or Robert Cannon's CVAPP. Where to find detailed morphometric data.
Post Reply
wlkath
Posts: 18
Joined: Wed Jun 08, 2005 12:39 am
Location: Northwestern University
Contact:

Issues loading swc somas

Post by wlkath »

Hi,

What format should a swc soma have to convert properly to hoc using Import3D?

The single point soma example at http://research.mssm.edu/cnic/swc.html gives a single point warning upon loading, and another upon exporting to the CellBuilder. The example at http://neuromorpho.org/neuroMorpho/dabl ... AR.CNG.swc, which I believe is following the newer 3-point soma representation (http://neuromorpho.org/neuroMorpho/SomaFormat.html), doesn't give a a warning upon loading, but does give two single point errors/warnings upon exporting to the CellBuilder.

I'm using NEURON -- Release 7.3 (999:cdec6759122c) cdec6759122c

Thanks,

- Bill Kath
ted
Site Admin
Posts: 6289
Joined: Wed May 18, 2005 4:50 pm
Location: Yale University School of Medicine
Contact:

Re: Issues loading swc somas

Post by ted »

wlkath wrote:What format should a swc soma have to convert properly to hoc using Import3D?
The question is, what formats can Import3d handle properly despite the best attempts of those who create morphometric data files to screw things up.

The chief problem with swc format is that it is not a completely specified file format. The most serious issue is lack of a uniform policy for how the soma should be digitized.

Dead wrong IMHO is to try to describe the soma as a pair of cylinders protruding in opposite directions from a center point, but that appears to be what is going on with THINSTAR.CNG.swc (or maybe it happened when the original morphometric data were cleaned up for NeuroMorpho.org). To see this for yourself, import that file, then in the Import3d tool do the following:
View type / Root sections
zoom in on the soma until it appears to be a filled black circle about 1 inch in diameter
enter 1 in the numerical field next to the Select id button and hit return
note that the red dot is right in the center of the black circle
use Select id's spinner to increase the point index to 2
note that the red dot is now at the top of the circle
increment the point index to 3
red dot is now at the bottom of the circle

Look at the output in NEURON's interpreter window and note these three lines:
Line 25: 1 1 -0.7 -0.16 0 6.145 -1
Line 26: 2 1 -0.7 5.97 0 6.145 1
Line 27: 3 1 -0.7 -6.31 0 6.145 1
The data format is
line_number datum_type x y z radius parent_index

As near as one can infer intent from the contents of an uncommented bunch of numbers, it appears that the user was trying to to describe the soma as two 6.145 um diameter cylinders pointing in opposite directions from the root point (specified by line 25).

What kind of soma specification results from importing this morphology? Exporting to a CellBuilder, saving that to a ses file, exiting NEURON, then restarting and loading that ses file and putting the CellBuilder in Continuous Create mode, here's what happened to the soma data:

oc>soma for i=0,n3d()-1 print i, x3d(i), y3d(i), z3d(i), diam3d(i)
0 -6.8449998 -0.16 0 12.29
1 -0.69999999 -0.16 0 12.29
2 5.4450002 -0.16 0 12.29

Note that the soma's x and y axes are swapped but the lengths and diameters are correct (the x and y axes of the rest of the cell are _not_ swapped). Also note that the origin of the model cell is the end of the soma that has the most negative x value. From this I expect that the soma would have converted without complaint if the digitizing wallah had only started at one end of the soma and proceeded in orderly fashion toward the other end along a path that did not reverse direction. That said, people will do what they will do, so it is good that NEURON's Import3d knows enough to do the right thing.

Whether it also does the right thing by the "single point soma example" depends on how one interprets the provided example. The second line of those data is for a point of "unknown" type. What the heck does that mean? Import3d takes it to specify the proximal end of a dendritic tree that is attached to the soma. IMO (not so humble this time), in the absence of any advice to the contrary from the person who generated that data file, the meaning of line 2 is whatever the user of the data decides to call it. Import3d prints a message to NEURON's interpreter window that says how it dealt with that line and concludes with this statement
"If this is an incorrect guess, then change the file."

All this is yet another reason to be cautious about morphometric data. None of it is perfect*, and the only question is: are the imperfections benign (tolerable for your intended use) or deleterious to the point that one is forced to either make a "best judgment intervention" (read "justified hack" to fix the problem) or abandon that file and look for a different one.

*--Disclaimer: I don't want anatomists to feel unfairly singled out for criticism. No biophysical data is perfect either. I'd better stop before I say anything about model source code or simulation results, and lose whatever friends I may have left in the neuroscience community.
wlkath
Posts: 18
Joined: Wed Jun 08, 2005 12:39 am
Location: Northwestern University
Contact:

Re: Issues loading swc somas

Post by wlkath »

ted wrote:The question is, what formats can Import3d handle properly despite the best attempts of those who create morphometric data files to screw things up.

The chief problem with swc format is that it is not a completely specified file format. The most serious issue is lack of a uniform policy for how the soma should be digitized.

... stuff omitted...
Ted, I understand and concede all of what you write in your reply. If, however, you were going to *write* a swc file that *is* correct, and that NEURON could import correctly, what would the syntax be?

For example, suppose I change the first three lines of the long example to

1 3 -0.7 -6.31 0 6.145 -1
2 3 -0.7 -0.16 0 6.145 1
3 3 -0.7 5.97 0 6.145 2

Here I've changed the type to "3" and put the sections in order. Now I don't get any errors, but upon conversion I don't get one long cylinder (comprised of two pieces), I get two at 90 degrees from one another. I get this:

dend {pt3dclear()
pt3dadd(-6.845, -6.31, 0, 12.29)
pt3dadd(-0.7, -6.31, 0, 12.29)
pt3dadd(5.445, -6.31, 0, 12.29)
}
dend[1] {pt3dclear()
pt3dstyle(1, -0.7, -6.31, 0)
pt3dadd(-0.7, -0.16, 0, 12.29)
pt3dadd(-0.7, 5.97, 0, 12.29)
}

What happened here? What's the *right* way to do this? Should I only have a start and an ending point (i.e., 2 points instead of 3)? I tried this and again got an error. I have tried a lot of variations and it's hard to find one that gives what I think it should without errors.

Also, let me point out that the Neuromorpho page, http://neuromorpho.org/neuroMorpho/SomaFormat.html, claims that "In response to ongoing discussion in the research community (The NEURON Forum), NeuroMorpho.Org is updating the soma format in the standardized reconstruction files... The conversion was agreed upon and coordinated with the developers of NEURON, L-Measure, and NeuroML." They then go on to detail the soma format, which the long swc example appears to follow. Is it not correct that the way the soma is laid out in the file is some kind of agreed-upon format?

Furthermore, the above Neuromorpho web page points back to a NEURON forum post where specifying a soma as a cylinder, instead of a single point, appears to be recommended (at least in the case when someone doesn't have a fully reconstructed soma).

Just to give you a bit more background, I'm not really interested in converting and using these old swc files. I have been helping someone who is doing semi-automated reconstructions. The output from their software is in a completely different format, but it's a fairly easy jump from their output to swc format (the data is x, y, z, diam, and they have information about connectivity, but there is no "type"). I thought that if I understood the swc syntax that NEURON regards as correct then writing a program that reads their data in and writes it in the "correct" swc format would provide an easy stepping stone toward getting these reconstructions into hoc format. (Since conversion from swc to hoc is a "previously solved problem".)

So, to say all of this another way, what swc format specification does NEURON assume/understand for Import3D? Whatever that format specification is, I can get the data in that format.

Thanks,

- Bill
ted
Site Admin
Posts: 6289
Joined: Wed May 18, 2005 4:50 pm
Location: Yale University School of Medicine
Contact:

Re: Issues loading swc somas

Post by ted »

wlkath wrote:
ted wrote:I understand and concede all of what you write in your reply.
including the part where I noted that NEURON does indeed "correctly" import swc data from NeuroMorpho, in the sense that it produces a result that is what those who wrote the file intended?
If, however, you were going to *write* a swc file that *is* correct, and that NEURON could import correctly
I would never do that. I don't want to become the keeper of a morphometric data standard. With regart to the swc format in particular, that is an incompletely specified format, and its ambiguities are therefore resolved by what people actually do with it. In practice, swc is adequate for most tasks.
For example, suppose I change the first three lines of the long example to

1 3 -0.7 -6.31 0 6.145 -1
2 3 -0.7 -0.16 0 6.145 1
3 3 -0.7 5.97 0 6.145 2
Not sure why you'd do that. No soma data. soma data are treated differently than data from other neurites.
What's the *right* way to do this?
The way that works is to leave the original soma data alone. Import3d will handle it correctly, even though it complains while doing so. You've taught students, so you must have experienced that kind of thing from time to time.
I'm not really interested in converting and using these old swc files. I have been helping someone who is doing semi-automated reconstructions. The output from their software is in a completely different format, but it's a fairly easy jump from their output to swc format (the data is x, y, z, diam, and they have information about connectivity, but there is no "type"). I thought that if I understood the swc syntax that NEURON regards as correct then writing a program that reads their data in and writes it in the "correct" swc format would provide an easy stepping stone toward getting these reconstructions into hoc format.
How about this: tell me what kind of soma data you have (sequence of xyzdiam measurements, trace of profile, stack of profiles, or what) and we'll see if Import3d can be made to deal with it. Probably good to take this discussion private at this point.
Post Reply