[ImageJ-devel] Future support for units in ImgLib2

Senseney, Justin (NIH/CIT) [E] senseneyj at mail.nih.gov
Sun Apr 1 14:47:19 CDT 2012

Although I've always liked the JScience project, I haven't used it in awhile since I thought it had gone dormant.  Their last major release was in 2007, but their "Coming in 2012" does look promising.  


From: Curtis Rueden [ctrueden at wisc.edu]
Sent: Saturday, March 31, 2012 6:03 PM
To: Stephan Preibisch
Cc: Fiji Developers; ImageJ Developers
Subject: Re: [ImageJ-devel] Future support for units in ImgLib2

Hi Steffi,

the JScience looks like a cool library, maybe we could even add some of their number implementations to our Types ... http://jscience.org/api/org/jscience/mathematics/number/package-summary.html#package_description

I agree, it could be useful in the future for more than just units!


On Thu, Mar 29, 2012 at 8:28 AM, Stephan Preibisch <preibisch at mpi-cbg.de<mailto:preibisch at mpi-cbg.de>> wrote:
Hi Curtis,

the JScience looks like a cool library, maybe we could even add some of their number implementations to our Types ... http://jscience.org/api/org/jscience/mathematics/number/package-summary.html#package_description

Nice greetings,

On Mar 28, 2012, at 15:00 , Curtis Rueden wrote:

Hi everyone,

Just wanted to update y'all on the status of units support in ImgLib2.

It's still something that will be coming later rather than sooner. However, I did inquire in the Unidata community about the UCAR Units Java package, and found out it might be better to use the Units of Measurement API (http://www.unitsofmeasurement.org/), probably the JScience implementation thereof (http://jscience.org/).

See below for details of the conversation, if interested.


---------- Forwarded message ----------
From: Curtis Rueden <ctrueden at wisc.edu<mailto:ctrueden at wisc.edu>>
Date: Wed, Mar 28, 2012 at 1:55 PM
Subject: Re: [netcdf-java] UCAR Units package standalone in Maven
To: Martin Desruisseaux <martin.desruisseaux at geomatys.fr<mailto:martin.desruisseaux at geomatys.fr>>
Cc: netcdf-java at unidata.ucar.edu<mailto:netcdf-java at unidata.ucar.edu>

Hi Martin,

Thanks for the information about the Units of Measurement API!

Regarding adoption of the Java UCAR Units package by the Unidata team, it seemed like a no-brainer to me to split out the dependency and provide it on GitHub, since that seems to be the direction the NetCDF Java team (and Unidata in general) is going. But as there has been no official response for now, the project can sit there in ctrueden/ucar-units indefinitely.

The JScience units implementation appears actively maintained (they even have a Maven repository, woo!), so hopefully that will work for us.


On Tue, Mar 20, 2012 at 5:10 PM, Martin Desruisseaux <martin.desruisseaux at geomatys.fr<mailto:martin.desruisseaux at geomatys.fr>> wrote:
Hello Curtis

I can not tell about the possible usage of ctrueden/ucar-units in the UCAR library. But on the units topic in general, just a few hints: they were various efforts to propose a standalone units package, including standardization efforts that failed (http://jcp.org/en/jsr/detail?id=108 which was inspired by the UCAR units library of that time, http://jcp.org/en/jsr/detail?id=275). The reason for the JSR-275 failure was, among other, an API exposing too much implementation details (I agree with this objection, but this is unfortunate that the JCP procedures didn't gave the opportunity for JSR-275 to apply corrections and make new proposal). Other JSR define units-like API, especially the mobile-related JSR (I forgot the number).

The ex-JSR-275 group extracted a smaller set of interfaces from their standardization effort and published it here:


Those interfaces are implemented by those project:

 - http://www.eclipse.org/uomo/
 - http://jscience.org/ (I think - need to verify if they updated their code)
 - apparently there is a proprietary implementation at BT (British Telephone I guess)

GeoAPI will probably switch their current ex-JSR-275 dependencies to the www.unitsofmeasurement.org<http://www.unitsofmeasurement.org/> interfaces. If the UCAR units library implements those interfaces, that would probably simplify the use of UCAR library with GeoAPI (but this is not essential)...

There is also other units efforts. I forgot the link, but if you are interested to dig in this area, I encourage you to contact Werner Keil (werner.keil at gmail.com<mailto:werner.keil at gmail.com>) who is still doing investigations about a possible (if possible standardized) unit framework.



Le 20/03/12 19:02, Curtis Rueden a écrit :

Hi Steve (& John & everyone!),

I hope you are well! I am writing with a question about your UCAR Units Java package.

In recent years, my work has transitioned to visualization and analysis of biological image data. As part of that effort, my team is developing a new version of the ImageJ image processing program (http://developer.imagej.net/ has details). For some time now we have been planning to use the UCAR Units package to manage units in our data structures.

I noticed that you recently published the C version of UDUNITS on GitHub at:

However, I could not find the Java version available anywhere as a standalone project.

So I wanted to let you know that I created one:

I also restructured things a little to use Maven as the build system.

Is this project something you would be interested in adopting? If so, I would be happy to donate it. I know that the NetCDF Java team is in the process of transitioning to Maven too, so it would be pretty straightforward to split out Units as a separate dependency. This would make it easier for third parties to use the library on its own (I have seen other questions in the Unidata archives about it, so I know I'm not the only one).

What do you think?


netcdf-java mailing list
netcdf-java at unidata.ucar.edu<mailto:netcdf-java at unidata.ucar.edu>
For list information or to unsubscribe, visit: http://www.unidata.ucar.edu/mailing_lists/

ImageJ-devel mailing list
ImageJ-devel at imagej.net<mailto:ImageJ-devel at imagej.net>

More information about the ImageJ-devel mailing list