Document
NOT PEER REVIEWED
Policy document
Call for community review of the MBF neuromorphological file format v 4.0
Published 31 Jul 2021
(https://doi.org/10.7490/f1000research.1118675.1)
Author Affiliations
Copyright © 2021 Tappan S et al. This is an open access work distributed under the terms of the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.
Published 31 Jul 2021
Policy document
Call for community review of the MBF neuromorphological file format v 4.0
[version 1; not peer reviewed]Author Affiliations
Abstract
Competing Interests
No competing interests were disclosed
Keywords
neuromorphology, standard, community review, MBF Bioscience, INCF, XML based file structure
All commenters must hold a formal affiliation as per our Policies. The information that you give us will be displayed next to your comment.
User comments must be in English, comprehensible and relevant to the article under discussion. We reserve the right to remove any comments that we consider to be inappropriate, offensive or otherwise in breach of the User Comment Terms and Conditions. Commenters must not use a comment for personal attacks. When criticisms of the article are based on unpublished data, the data should be made available.
There is a clear need to standardise file formats to support future development in digital neuroanatomy and neuroinformatics. As closed formats used by proprietary commercial software packages with large user bases can be roadblocks, this initiative by MBF — a commercial entity — is significant and should be supported. Having options for using this neuromorphological file format, either with MBF software, or with other tools and pipelines should benefit both the company and researchers. As shown by other comments, the MBF products have been in use over many years, and so are now mature, reliable software tools with GUIs that are well suited to biologists with limited coding skills. However, this new initiative will now open up further options for analysis, data sharing and data integration.
As noted in other comments standardisation across the landscape of neuromorphological file formats is currently low and so there is a real need for pioneering efforts to seed the process and created the momentum needed to unify this field.
There is a clear need to standardise file formats to support future development in digital neuroanatomy and neuroinformatics. As closed... READ MORE
There is a clear need to standardise file formats to support future development in digital neuroanatomy and neuroinformatics. As closed formats used by proprietary commercial software packages with large user bases can be roadblocks, this initiative by MBF — a commercial entity — is significant and should be supported. Having options for using this neuromorphological file format, either with MBF software, or with other tools and pipelines should benefit both the company and researchers. As shown by other comments, the MBF products have been in use over many years, and so are now mature, reliable software tools with GUIs that are well suited to biologists with limited coding skills. However, this new initiative will now open up further options for analysis, data sharing and data integration.
As noted in other comments standardisation across the landscape of neuromorphological file formats is currently low and so there is a real need for pioneering efforts to seed the process and created the momentum needed to unify this field. READ LESS
Not only has this format been proven capable of capturing key features and details of neuromorphical data, more importantly, it fulfils the FAIR principles. Making it a standard will certainly bring us a step closer towards open science.
Not only has this format been proven capable of capturing key features and details of neuromorphical data, more importantly, it fulfils the FAIR principles. Making it a standard will certainly bring us a step closer towards open science.
Not only has this format been proven capable of capturing key features and details of neuromorphical data, more importantly, it fulfils the FAIR principles. Making it a standard will certainly bring us a step closer towards open science.
Not only has this format been proven capable of capturing key features and details of neuromorphical data, more importantly, it fulfils the FAIR principles. Making it a standard will certainly bring us a step closer towards open science.
These loose ends come in two categories:
1. The file format serves the purpose of storing exactly that information that can be edited in the Neurolucida software. There is no room for user extensions. Limitations of Neurolucida are therefore also limitations of the file format. For example, you can assign a color and some other fixed properties to a tree (like an axon or dendrite), but not to a specific branch of that tree.
Two examples of such limitations:
- Use case: Label points in a neuron that belong to a particular cortical layer. There is no function in Neurolucida to do this, other than splitting up the neuron in many small unconnected pieces.
- Use case: Store multiple images (screenshots) together with the neuron, including their position and orientation. This has two issues: (i) The image is stored as a file name, like "C:\Users\BillGates\Research\Reconstructions\Neuron1\section1.tif" and (ii) If you store a second image, you cannot specify a rotation with respect to the first image.
2. The documentation of the XML format, while the intentions are clearly good, is lacking necessary details. To name a few:- It is not clear which fields are required or optional, the only way to find out is try and see whether Neurolucida crashes.
- There are many 'multiple choice' fields, but the list of allowed choices is not given.
- For some fields it is not clear where they are to be placed, for example by trial and error I know that markers can be placed inside a particular branch of a neuronal tree, but they cannot be attached to a particular point within that branch. I don't know what is the correct behavior for spines.
The category 2 issues really stand in the way for the XML-format to become a standard. They can however easily be solved if the file format gets documented using a proper XML Schema Definition file.The category 1 issues are more about the versatility of the file format. They will stand in the way for this to become a general purpose neuromorphological file format. Without a mechanism to annotate parts of the tree with custom properties, developers will keep using handcrafted file formats where needed.
These loose ends come in two categories:
1. The file format serves the purpose of storing exactly that information that can be edited in the Neurolucida software. There is no room for user extensions. Limitations of Neurolucida are therefore also limitations of the file format. For example, you can assign a color and some other fixed properties to a tree (like an axon or dendrite), but not to a specific branch of that tree.
Two examples of such limitations:
- Use case: Label points in a neuron that belong to a particular cortical layer. There is no function in Neurolucida to do this, other than splitting up the neuron in many small unconnected pieces.
- Use case: Store multiple images (screenshots) together with the neuron, including their position and orientation. This has two issues: (i) The image is stored as a file name, like "C:\Users\BillGates\Research\Reconstructions\Neuron1\section1.tif" and (ii) If you store a second image, you cannot specify a rotation with respect to the first image.
2. The documentation of the XML format, while the intentions are clearly good, is lacking necessary details. To name a few:- It is not clear which fields are required or optional, the only way to find out is try and see whether Neurolucida crashes.
- There are many 'multiple choice' fields, but the list of allowed choices is not given.
- For some fields it is not clear where they are to be placed, for example by trial and error I know that markers can be placed inside a particular branch of a neuronal tree, but they cannot be attached to a particular point within that branch. I don't know what is the correct behavior for spines.
The category 2 issues really stand in the way for the XML-format to become a standard. They can however easily be solved if the file format gets documented using a proper XML Schema Definition file.The category 1 issues are more about the versatility of the file format. They will stand in the way for this to become a general purpose neuromorphological file format. Without a mechanism to annotate parts of the tree with custom properties, developers will keep using handcrafted file formats where needed.
The specification governance processes would appear to be appropriate and suitable for exe.
The specification governance processes would appear to be appropriate and suitable for exe. READ LESS
Thank you MBF for opening up your software and supporting open science!
Thank you MBF... READ MORE
Thank you MBF for opening up your software and supporting open science! READ LESS
That being said, it is important that the format of such files be uniform and easily accessible. Micobrightfield has been the leader in this area for several decades and I believe they are the right company to set the standard for such formatting, which will make data sharing much accessible, interoperable, reusable. I therefore very much support this proposal.
That being said, it is important that the format of such files be uniform and easily accessible. Micobrightfield has been the leader in this area for several decades and I believe they are the right company to set the standard for such formatting, which will make data sharing much accessible, interoperable, reusable. I therefore very much support this proposal.
Use of this website is subject to the F1000 Research Limited (F1000) General Terms and Conditions.
Submission of user comments to this website is subject to additional Terms and Conditions. By clicking "I accept the User Comment Terms and Conditions" before you submit your first comment, you agree to be bound by these conditions every time you submit a comment.
Terms relating to user comments