Curtis Rueden edited this page Apr 23, 2018 · 6 revisions
Clone this wiki locally

SLIM Curve projects

SLIM-Curve-related code is currently split into several repositories, at least two of which will be merged (see issues #11, #13).


  • Main project C code
  • Standalone executable wrapper for the library
    • depends on iniparser; embeds source code
    • See issue #15
  • Code to call SLIM Curve from MATLAB
    • See issue #14
  • Java code for calling SLIM Curve via JNI (formerly JNA)

The slim-curve repository houses the main C library of curve fitting algorithms. The goal is for common mathematical routines to live fully in C, and be shared between TRI2 and the ImageJ plugin. While we have made an effort to achieve that ideal, there is still some algorithmic development going on in TRI2, which hasn't yet "trickled down" to SLIM Curve. But we can move code from TRI2 to SLIM Curve on an "as needed" basis if users request a particular feature of TRI2 within the ImageJ SLIM Curve plugin.


  • Code for testing SLIM Curve-java
  • Has both manual tests and unit tests
  • To merge into slim-curve/slim-curve; see issue #13


  • Curve fitting Java library; supports multiple different fitting libraries, one of which being SLIM Curve (via JNA; not using slim-curve-java currently)
  • To be eliminated; see issue #19

The idea of the curve-fitter project was that it made the fitting algorithms pluggable. So you could use SLIM Curve, but alternately could use a pure-Java routine such as the LMA library that SLIM Plotter uses. Our current thinking is to eliminate this layer, instead relying completely on SLIM Curve as the fitting code we rely upon. Reasoning: there is a burden to maintaining this extra "fitter-agnostic" layer, in that it instills an increased level of inflexibility to the API. I.e.: every time a new feature is added to SLIM Curve, the curve-fitter library must be updated to expose API corresponding to that new feature; and then none of the other fitter implementations (e.g., LMA) necessarily provide that feature so then you're throwing UnsupportedOperationException or graying out UI controls and so on. It's more work for very little benefit. So in the long term, we plan to phase out the curve-fitter component completely.



  • "Time Resolved Imaging" application for Windows, developed at the Gray Institute
  • Much of SLIM Curve's code was derived from work originally done as part of TRI2
  • See also Paul Barber software and the TRI2 website

Some eventual future goals:

  • Proper headless batch processing
  • Eliminate dependency on LabWindows
    • Would facilitate open sourcing the code
    • Would facilitate support for non-Windows platforms
  • Would be nice to have continuous integration, perhaps on the ImageJ Jenkins
  • Could mirror the SVN repository to a Git repository painlessly, using Jenkins

Related software


  • LOCI's old SLIM Plotter program
  • We may migrate features from SLIM Plotter into the SLIM Curve plugin for ImageJ in the future


  • Maven plugin for building native C code using Maven

There will probably be improvements needed to the NAR plugin (which is responsible for compiling native code using Maven) to fully support the SLIM Curve codebase. We need these NAR archives for use as dependencies for Java projects, but we also want to compile the shared libraries themselves as painlessly as possible, for consumption by other native code. So we'll have to make sure both our use cases are fulfilled.


The SciJava Native Lib Loader library unpacks and loads native libraries out of JAR/NAR files. Native code doesn't need it, but the ImageJ SLIM Curve plugin uses it to access SLIM Curve.