NOTICE! This is a static HTML version of a legacy ImageJ Trac ticket.

The ImageJ project now uses GitHub Issues for issue tracking.

Please file all new issues there.

Ticket #36 (closed feature: fixed)

Opened 2010-02-24T16:09:59-06:00

Last modified 2012-02-23T11:33:19-06:00

Explore OpenCL option for plugins

Reported by: curtis Owned by: rlentz
Priority: major Milestone: progress-report
Component: Plugin Framework Version:
Severity: non-issue Keywords:
Cc: Blocked By:


One potential issue with using imglib for the ImageJ data model is performance—a generalized, object-oriented approach has bottlenecks due to many method calls compared to efficient processing of raw primitive arrays.

We plan to look into using OpenCL to maximize the performance of common image processing functions. This has been discussed in the thread " Performance" on the ImageJX discussion group. If the updated plugin infrastructure and scripting framework include a way to provide optional OpenCL-based algorithm implementations (probably pixel-type-specific), we may be able to mitigate much of the performance penalty incurred with imglib in common cases.

Change History

comment:1 Changed 2010-02-24T16:11:14-06:00 by curtis

Note that  Endrov provides some support for OpenCL-based image analysis.

comment:2 Changed 2010-02-25T11:29:53-06:00 by rlentz

  • Status changed from new to accepted

comment:3 Changed 2010-06-22T11:15:44-05:00 by rlentz

OpenCL has proven viable as a plugin and seems viable to support imglib.

Work was done to demonstrate NIO backed imglib structures and testing with JavaCL. The frequent brokering of boilerplate functional calls into the native OpenCL system libraries proved to be detrimental to any performance gains. Use of JavaCL was dropped in favor of direct mapping with JNA into native exported 'C' calls.

In conclusion of the the scope of this task, it should be mentioned that several opportunities do exist for ImageJ with regard to the project's focus.

1) OpenCL is viable for accelerating computationally intensive tasks within core ImageJ. To support this, NIO backed arrays should be used for brokering data between computational resources including GPU's. This also will aid in integration with other native software libraries.

2) Future efforts should consider a management layer that aids the user in adopting this technology. The focus should be on managing the amount of boilerplate needed, automatically refactoring existing code, automatic application of algorithmic techniques, and automatic adoption of multiple devices (to include networked resources).

comment:4 Changed 2010-06-22T11:16:12-05:00 by rlentz

  • Status changed from accepted to closed
  • Resolution set to fixed

comment:5 Changed 2012-02-23T11:33:19-06:00 by curtis

  • Type changed from task to story