Hi everyone,
Recently there has been a large amount of discussion about ImageJ
development. This dialogue has been great, but in a few cases similar points
have been sprinkled across several different threads. I have filtered
through the recent threads of interest (within the past 2-3 months) and have
identified a few key topics. To better organize the discussion, I am
creating new threads, one per topic, and sending each to the appropriate
mailing list:
* ImageJ for discussion in which non-programmers have expressed
substantial interest
* ImageJX for highly technical discussion regarding software engineering
(technologies, source code, etc.)
The threads I am sending to the ImageJ users list are:
*1. Backwards compatibility* – What does "near 100% backwards compatibility"
mean? And is it a reasonable, warranted goal?
*2. ImageJ project structure* – What are ImageJ, Fiji, ImageJX and
ImageJDev, and how are they related? What about project forks? How can
people contribute?
*3. ImageJDev.org web site* – What is the role of the imagejdev.org web
site? How can we improve it?
*4. ImageJ mailing lists* – There are an increasing number of ImageJ-related
mailing lists. Are they all useful and necessary? Do we need any additional
lists?
*5. Scripting languages and API* – Some people want ImageJ to support
several different scripting languages based on a common underlying API,
while others argue for a single, easy to learn macro language. What the pros
and cons of each approach?
And the threads for ImageJX (
http://groups.google.com/group/imagejx):*6. Image data types* – Images are typically represented with a "data type"
such as 8-bit unsigned integer, 32-bit floating point, etc. How can we allow
developers to write image processing routines without worrying about data
types? And what is the best way to generically support new data types (e.g.,
complex numbers)? Scala @specialized tags?
*7. Coordinate systems* – Image data in some scientific domains (e.g.,
astronomy) can have domain sets more complex than evenly spaced rectangular
grids. Should we work to support these sorts of data?
*8. Separation of concerns (MVC, AWT/Swing/etc.)* – Can we fully decouple
the ImageJ user interface from its data structures? Why do we want to?
*9. Plugins infrastructure* – Multiple proposals have been presented for
enhancing the plugin model—e.g., allowing for explicit declaration of input
and output types to more easily chain plugins into a workflow. Some have
even suggested eliminating the idea of "plugins" entirely (as opposed to
scripts/macros). Various frameworks also exist to facilitate data processing
workflows (e.g., KNIME and Cell Profiler)—what can we learn from them, and
does it make sense to integrate? OSGi?
*10. Performance* – How can we improve ImageJ's algorithmic performance?
Language translation? Performance packs? OpenCL?
*
*
Please reply on whichever threads are of interest to you. I will be on
holiday for the rest of the year, but will be back before January 7th, and
will try to chime in as time allows. Hopefully this great dialogue will
continue as we all refine the roadmap for ImageJ over the next few weeks and
months!
Happy holidays,
Curtis
Locked
