Ticket #36 (closed feature: fixed)

Opened 9 years ago

Last modified 7 years ago

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 9 years ago by curtis

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

comment:2 Changed 9 years ago by rlentz

  • Status changed from new to accepted

comment:3 Changed 9 years ago 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 9 years ago by rlentz

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

comment:5 Changed 7 years ago by curtis

  • Type changed from task to story
Note: See TracTickets for help on using tickets.