Technical specifications

In BoneJ2 the plugins from BoneJ1 are divided into two parts: wrapper plugins and Ops. Additionally BoneJ2 will have some utility code that the wrappers and Ops share. The wrappers populate the ImageJ menu, handle user interaction and call the underlying Ops. The Ops concentrate on just image processing. Ultimately the goal is to integrate the Ops and the utility code into scijava-common, imagej-ops or other such core module.

General principles

• Assume that axis calibration is linear (CalibratedAxis.averageScale() does not vary)
• All settings for plugins persist between sessions unless otherwise specified
• Use calibration functions held in the Calibration object to handle calibrated pixel values (TODO: ImageJ1 specific?)
• "Use the lowest level functionality possible". This way you can avoid having too many dependencies. Also, results will likely be more consistent with other implementations in the ImageJ ecosystem.
• BoneJ Ops use helper classes to pass multiple related inputs and outputs, because this way they can be passed type safely. We don't use arrays or collections because it's all to easy to leave them empty or forget their length. TL;DR use new MyInputParams(1, 2, 3) instead of new int[]{1, 2, 3}.

Plugins

• Must not show message dialogs when run in headless mode (no GUI) or batch mode
• Must log warning and errors using ImageJ LogService
• The menu paths shall follow the naming in BoneJ1 (i.e. Plugins>BoneJ)
• Must gather usage data, but only if the user has opted in
• All settings must persist between runs unless otherwise specified

Analyse skeleton

Connectivity

Erode/Dilate

• Submenu Plugins > Process
• Dropped from BoneJ, and used from VIB_ via Maven
• Menu paths change from Erode 3D and Dilate 3D to Erode (3D) and Dilate (3D)
• No Help-buttons until a pull request is made into the VIB_ repository
• Help page moved to ImageJ wiki. This is where the old link redirects as well
• Won't collect usage data
• Settings persist

Help

• Menu path: Help>About Plugins>BoneJ2
• Uses PlatformService to open the bundled HTML user documentation in the default browser (doesn't use Java window like in BoneJ1)

Skeletonise

Test Images

• Menu path: Plugins>BoneJ>Test Images
• Ops recreated from the methods in the TestDataMaker class
• Produce ImgPlus<BitType> images which are binary images

Thickness

TriplePointAngles

Volume fraction surface

Volume fraction voxel

Utilities

ResultsInserter

The Legacy and Modern modules

Initially the code base of BoneJ2 will consist of two top level modules: Legacy and Modern. Legacy contains the code from BoneJ1 whereas Modern will contain the features that have been already migrated to ImageJ2. Once the modern implementations have been deemed satisfactory the corresponding legacy code will be removed from the Legacy module. However the code in the Legacy differs somewhat from that of BoneJ1 in the bonej-org repo:

• Legacy code cloned from BoneJ1's mavenization branch, which in turn was cloned from the testing branch. These branches include bug fixes and code improvements not released yet (merged to master) at the time of cloning.
• All dependencies via Maven. Some versions differ, e.g. 3D Viewer.
• Uses java3d from org.scijava which in turn requires Java 7 and JOGL
• Compiled with Java 1.8
• AnalyzeSkeleton_, Skeletonize3D_ and LocalThickness are used via Maven instead of being hard coded in the BoneJ packages.
• Erode_ and Dilate_ called from VIB_ instead of the hard coded BoneJ versions
• Triple Point Angles no longer excepts skeletonised images. It contains the step for skeletonising the input image.
• Packages restructured

The unaltered starting point, the complete Legacy module with all the mavenized functionality from BoneJ1 will be kept in the mavenization branch of this repository.

---

Challenges and future developments

• Duplicate plugins: Due to the way Maven builds the artefacts, some plugins have more than one menu path. For example the Thickness plugin can be found under Plugins>BoneJ>Thickness and Analyze>Local Thickness. These paths still ultimately point to the same implementation, but there may be some differences in user experience.
• Some BoneJ1 features are unavailable in the ImageJ2 API: For example, there’s no equivalent for the ROI manager. Plugins need to written either in the style of ImageJ1 or ImageJ2. You can’t really mix and match the best of both worlds, or write “transitive” versions of the plugins, where only part of the functionality is written in the new way. This is because backwards compatibility in ImageJ2 is very complicated.
• BoneJ2 and macros: ImageJ2 is moving away from the ImageJ macro language. Have to learn one of the scripting languages ImageJ2 supports, and figure out how macros are supposed to work with BoneJ2. Are macros supposed to call Ops?
• Gathering usage data: Apparently ImageJ2 offers a UsageService class, but the community reacted negatively to it. Should BoneJ2 use a modified version of the UsageReporter class from BoneJ1, or utilize UsageService once its issues have been solved?
• Should BoneJ2 have a bug reporting mechanism integrated to ImageJ2? For example, by somehow using the Report a Bug plugin?
• Should the run-time help for BoneJ2 inform how users should cite it or its plugins? (Should be coded as a mechanism in ImageJ2)