Neurolucida to NEURON best practices?

[bsuter]

Reconstructions saved in the ASC format from the most recent version of Neurolucida (v10) seem to identify the soma contours with the header "Cell Body", whereas the previous version (v9) used the "CellBody" header. There may be other changes as well - I've requested clarification from MicroBrightField.

An easy fix for the problem described by Sherif is to open a v10 ASC file in a text editor, replace all occurrences of "Cell Body" with "CellBody", and resave. Import3D will properly recognize the soma after this transformation.

I've heard (via Sherif's colleagues) of an alternative workaround, which however requires access to a running Neurolucida v9 installation: open the v10 file in a Neurolucida v9 installation and resave as an ASC file.

I believe both versions could be simultaneously supported by a small modification to line 924 in file lib/hoc/import3d/read_nlcda3.hoc:
http://www.neuron.yale.edu/hg/neuron/nr ... nlcda3.hoc

[bsuter]

In its present implementation, Import3D should be able to handle somas whose morphometric data were obtained in any of these three different ways:
1. as a sequence of x,y,z,diam measurements, i.e. like any other neurite.
2. by tracing an outline of the perimeter of the soma at one z level. In this case, Import3D's code identifies the principal axis of this "soma silhouette", then cuts the silhouette into 20 (as I recall) slices of equal thickness dL by a series of lines orthogonal to the principal axis. Each slice is then treated as if it were the side view of a very short cylinder (like a thick washer)--its surface area and volume are computed as PI*w*dL and PI*w*(dL/2)^2, where w is its width (measured orthogonal to the soma principal axis). The total somatic surface area and volume are computed by summing over all the slices. These are reasonably satisfactory approximations to the true area and volume as long as the actual shape of the soma does not deviate too far from having rotational symmetry about an axis. If there are two or more nonoverlapping soma outlines, each will be treated as defining a separate soma and cell.
3. by tracing soma outlines at multiple z levels. Import3D's code divides each outline into some number of equally spaced points, which are used to construct a triangular mesh approximation of the surface of the soma. Somatic surface area and volume are computed from this mesh. A stack of outlines that overlap is interpreted as defining a single soma; if there are two or more nonoverlapping stacks, each individual stack is treated as defining a separate soma and cell.

Could you please elaborate on #3? What would you expect the resulting 3D points to be in NEURON?

I've used Import3D to load a .ASC file, which contains a soma (marked "CellBody") that was constructed as a series of 12 contours in the x/y-plane. The z-coordinate of the contours decreases (becomes more negative) monotonically. Import3D appears to succeed, with the following messages printed in the interpreter:

Code: Select all

10257 lines read
somastack_process 12
center
268.016 -905.776        -72.38  
Principle values
7.78297 1786.83 785.695 
Principle axes
 0.994    -0.0656  -0.0907 
 0.102    0.193    0.976   
 -0.0465  -0.979   0.199   

I thought that Import3D would attempt to identify the primary axis and remodel the soma as a series of conical sections, with the "0" end of the soma near the "base" and the "1" end near the "apex". However, the conical sections are similar to the original contours, with the "0 to 1" axis of the soma lying along the z-axis (rather than parallel to the y-axis).

Are my expectations (for the additional conversion by Import3D) incorrect?

My expectations are based in part on prior forum posts, and mostly on the somastack_process() procedure (line 263):
http://www.neuron.yale.edu/hg/neuron/nr ... nlcda3.hoc

Code: Select all

    266       // The stack defines a volume. Determine the principle axes
    267 	// and slice the volume along the major axis, approximating
    268 	// each slice by a circle and shifting the circle to be
    269 	// along the major axis. So the set of soma contours ends
    270 	// up being one straight cylindrically symetric soma centroid

In my case, I believe the greatest extent is along y, and would have expected Import3D to identify the "major axis" as roughly parallel to the y-axis. However, the resulting soma after Import3D seems to be aligned along the z-axis. Also, in Shape plots it does not look appropriate when the Diam is drawn. Note: Initially in Import3D, prior to exporting to CellBuilder, the Shape plot showed what looked like the original (Neurolucida) contours.

Perhaps I'm confusing alternatives #2 and #3, and the somastack_process() procedure really only applies to #2, i.e. when the original reconstruction contains a single contour (rather than a sequence of contours)?

Thanks for any help you can provide.

[ted]

What version of NEURON are you using?

[hines]

The bizarre thing about the 'proc somastack_process' whose comment is mentioned above is that its analysis is not used in further processing and is
informational only. Apparently I intended to carry it forward sometime in the future ...
Instead, import3d_gui.hoc::contourstack2centroid is used to define the 3-d points for simulation and that has all the simplistic properties you mentioned.
It does print an accurate area which you might compare to the area of the eventual soma section (you can adjust the latter diameters so they match more closely, the only
parameter of electrical concern is the membrane area but of course there are also issues about the area taken up by dendrite connections.)
Anyway, all this soma detail is becoming important again for reaction-diffusion modeling and having a satisfying visualization. All the efforts on both aspects are taking place in python
Import3d is being extended to communicate with the python package we are writing.

[bsuter]

Thank you very much for your help and explanation. I'm using v7.2, but have used v7.1 in the past with the same experience. I'm happy to hear about your ongoing improvements / expansions.

It does print an accurate area

Could you please elaborate? As you suggest, I'm interested to "compare to the area of the eventual soma section". Is one of the following values the soma area as calculated from the "informational" procedure:

Code: Select all

10257 lines read
somastack_process 12
center
268.016 -905.776        -72.38  
Principle values
7.78297 1786.83 785.695 
Principle axes
 0.994    -0.0656  -0.0907 
 0.102    0.193    0.976   
 -0.0465  -0.979   0.199

By the way, my workaround has been to edit the .ASC file, removing all contours except for the one at "maximum diameter", i.e. close to the central cross-section, and then pointing Import3D at this revised reconstruction. As expected the resulting rotationally symmetric soma has a more useful orientation. I then did my best to verify/compare soma area external to NEURON.

Thanks,
Ben.

[ted]

It does print an accurate area

Could you please elaborate? As you suggest, I'm interested to "compare to the area of the eventual soma section".

If the soma is represented by a single section called "soma" and soma.neg is 1, then you need only execute this statement
soma print area(0.5)
If soma.nseg is > 1, it's better to

Code: Select all

func soma_area() { local tmp
  tmp = 0
  soma for (x,0) tmp+=area(x)
  return tmp
}
soma_area()

[bsuter]

Thanks Ted - the way you described is indeed how I've been measuring section area. Perhaps I misunderstood Hines' post - I took him to be saying that the "somastack_process" procedure (or possibly some other procedure) report the area of the soma after remodeling it based on the principle axis derived from the contour set. That would be useful simply as a way of measuring the area of the reconstructed soma, in order to compare it to the area of the final .hoc soma.

[bsuter]

A few years back here in this thread we figured out that your nice 'proc somastack_process' code for importing a cell body modeled as a z-stack of xy-contours was not being used by Import3D. Instead, older code (import3d_gui.hoc::contourstack2centroid) was generating a 3D mesh. At the time, Michael wrote:

Anyway, all this soma detail is becoming important again for reaction-diffusion modeling and having a satisfying visualization. All the efforts on both aspects are taking place in python. Import3d is being extended to communicate with the python package we are writing.

At present, this does not seem to be resolved when using the GUI: such somata result in a 3D mesh, often with the 0-1 section axis orthogonal to the intended primary axis. I'm not sure if you fixed this back in 2013, but it has somehow since reverted to old code? Or perhaps it was never fixed? I'm using the GUI, not Python, so maybe that's my problem?

For now, my workaround is to delete all but the central xy-contour in Neurolucida, prior to using Import3D, under the assumptions that the soma is rotationally symmetric and that the xy-contour cuts through the soma in a plane parallel to the primary axis. When I import a single-contour soma in this way, the resulting soma properties and appearance are as expected. However, in some reconstructions these two assumptions aren't reasonable, and for those cases I'd prefer to use your 'proc somastack_process' approach.

Alternatively, if there is a current "best practice" for Neurolucida-to-hoc import that differs from what we figured out in this thread, please let me know so I can catch up! Thank you.

[ted]

Can you send me ted dot carnevale at yale dot edu a file that demonstrates the problem you encountered?

[bsuter]

Dear Ted, I have sent you the requested files by email.

[bsuter]

Dear Ted, have you had a chance to look at our files? Or do you know if Michael has ever implemented the fix (for contour-stack somas) that was discussed above (but several years ago)?

We have a large number of reconstructions suffering from this issue, and are stuck until we find a solution. I've considered redrawing the soma in Neurolucida using a single contour, which would presumably import smoothly into NEURON - but due to some cells being rotated out of the xy-plane, the single-contour approach would likely be inaccurate. Alternatively, I've considered replacing every soma in NEURON with a soma template (i.e. a standard soma based on the average soma size in the population) - this would be an efficient workaround, but does not seem ideal. If there's a way to make the existing contour-stack soma representation import properly, that would be preferable.

Thank you!

[hines]

It appears nothing has been done in this area since late 2007. There was a hook added in python for rxd in 2013 but is not being used.
The translation of the soma stack to a centroid of 3-d points with diam continues to be:
Approximate each contour of the stack as a circle. Center is the average of all points and the circle radius is computed from the average of
the contour perimeter and the approximate circle. When loading your g45.ASC, the mesh area is (sum of the triangle areas of the mesh, not
the area of the elipsoid defined by the principle axes and values of the entire set points in all the contours)

Code: Select all

stk_triang_area = 367.498

and as there were three contours, instantiation of the cell generates a centroid with 3 3d points. ie.

Code: Select all

-19.676136 -51.56678 -4.6500001 12.551055 0 
-19.439165 -51.484474 0 13.245581 4.6567618 
-21.824448 -50.56284 4.0999999 8.6595259 9.4888403

with an area of

Code: Select all

area(.5)
	373.25708

You are of course correct that since this stack is similar to three pancakes of different sizes on top of each other, the centroid with this method is not at all the
principle axis associated with the largest principal value.