[ImageJ-devel] ImageJ2 development
Curtis Rueden
ctrueden at wisc.edu
Mon May 12 21:20:22 CDT 2014
Hi Pawel,
> I decided to start work on the project by playing around with the
> ImageJ2 interface in some routine tasks I usually do in ImageJ. After
> having done some extensive testing, I just wanted to give you some,
> hopefully constructive, input. I don't want to sound too negative, but
> I really think that June 1st is a bit early to be releasing a
> production version of ImageJ2.
With respect to the ImageJ2 Swing user interface and commands, you are
absolutely right. However, the initial 2.0.0 release of ImageJ2 is going to
continue using the classic ImageJ 1.x user interface by default. The new UI
will still be included (Help > Switch to Modern Mode) but will still be
very much in beta.
See this blog post for details:
http://developer.imagej.net/2014/04/01/imagej-200-stable-release-coming-spring
ImageJ 2.0.0 will be fundamentally the same as ImageJ1, but:
* Will be bundled with the Updater component which supports ImageJ update
sites and automatic update checking.
* Will be bundled with the native ImageJ Launcher with quite a few nice
command line features.
* Will be bundled with the ImageJ Script Editor including support for
several scripting languages.
* Will support parameterized ImageJ modules, including commands and
scripts, so that existing plugins can begin incremental migration toward
this new approach, which is more headless friendly and more interoperable
with tools such as CellProfiler, KNIME and OMERO.
* Will come with an option to use the SCIFIO library when opening image
files (e.g., using File > Open). This will fix ImageJ's TIFF support to be
more robust, and add extensible support for additional file formats without
needing to hack the HandleExtraFileTypes source.
* Will ship with all the new ImageJ2 APIs, but all these components will
still be in beta. We will bring each component out of beta after it has
been thoroughly vetted over time. These components include:
- imagej-common: The ImgLib2-based image data model and core
- imagej-ops: A framework for reusable algorithms; see
http://developer.imagej.net/2014/04/04/announcing-imagej-ops
- imagej-ui-swing: The "pure ImageJ2" Swing user interface
- imagej-plugins-*, scijava-plugins-*: Core plugins for ImageJ2 including
many commands
Note that the Fiji distribution of ImageJ has been shipping of all of these
components, and operating in this way, for years now, and is a well vetted
system. But it is time for these components to be officially available as
part of ImageJ's core, rather than only from a specific
life-sciences-focused ImageJ distribution.
> Please don't take it the wrong way - I am in the process of analysing
> the codebase and I think it is a real software engineering feat.
No offense taken at all; again, it is absolutely true that the ImageJ2 UI
needs more time in the oven. But meanwhile, it has already been over four
years since we launched the ImageJ2 project, and there are several very
mature components that need to get into the hands of users: the Updater,
the Launcher, the Script Editor, parameterized modules, and everything else
that is now part of the "SciJava Common" component (
https://github.com/scijava/scijava-common).
Because ImageJ2 consists of several pieces at various stages of
development, it needs to migrate out of beta piece by piece.
> It shows that there has been really serious thought put into
> architerctural design. However, at this point, and I am saying that as
> a daily ImageJ user, the architectural brilliance is not showing on
> the surface.
I am glad you like the design. And I agree that much more needs to be done
in terms of leveraging that design for the benefit of end users. This is an
area where your contributions could be really beneficial.
> I am going to submit some bug reports in a few days, but basically the
> interface is highly unpredictable and in many ways incompatible with
> ImageJ1.
Indeed. Please note that there are many bugs about such problems already
logged in the ImageJ Trac: http://trac.imagej.net/. We are actively in the
process of migrating away from the Trac system though, with individual
tickets being moved to GitHub Issues of the most relevant repository.
Unfortunately, since we are in the middle of that migration, it may be
difficult to verify whether an issue has already been filed for any
particular concern. When in doubt, file away and we can close any duplicate
issues accordingly.
> Let me just point to a few basic things before I submit detailed bug
> reports:
>
> 1. The brightness/contrast dialog sometimes sticks around when you
> open a new image and close the old one - you end up with multiple
> brightness/contrast dialogs and a single image. Moreover, I've had the
> dialog stay open even after I closed the application.
The IJ2 version of B&C has been the subject of frequent debate. In short,
it needs a lot more work. See http://trac.imagej.net/ticket/1100 and all
its blocking tickets (those listed in "Blocked by").
> 2. The color picker behavior is hectic and I couldn't figure out how
> and why it randomly changes color. Especially in 16-bit per channel
> images it is totally unpredictable.
>
> 3. With 48-bit 16-bit per channel composite images the drawing command
> with the white color selected basically draws random grey colors.
IJ2's current approach to foreground and background "colors" differs from
IJ1. And there are likely bugs, too.
* http://trac.imagej.net/ticket/965
* http://trac.imagej.net/ticket/1292
> 4. The interface is extremely slow to the point of being unusable for
> things like looking through time-course stacks or stacks of
> medium-sized multicolor images.
That is not a problem we have noticed, unless image planes become very
large. How large are your image planes? >2Kx2K?
> 5. Shape selection keeps old selections after you make a new one,
> which is inconsistent with ImageJ1 behavior and quite maddening for
> someone who is used to it.
Yes. We will probably need an option for it, because for many new users, it
is maddening to have one ROI disappear when creating another. But the main
reason IJ2's UI works that way right now is technical: it currently uses
the JHotDraw library which works that way by default.
> 6. Missing magic wand and text tool functionality.
https://github.com/imagej/imagej-plugins-tools/issues/8
https://github.com/imagej/imagej-plugins-tools/issues/9
> 7. Missing custom toolbars.
Known, but no explicit issue for it yet. Low priority, given all the other
things the Swing UI needs first. Note that IJ2 is not intrinsically limited
to 8 tools like ImageJ1 is, so it is less urgent to support customization.
All available tools will be present in the bar by default.
> 8. In multicolor images there seems to be no way of adjusting
> brightness/contrast of each channel individually.
Hmm, you're right. This might be a relatively new bug.
> 9. LIF format import doesn't work - it doesn't present the usual
> BioFormats dialog and instead just imports the first image in the
> series with some random channel separation.
LIF format does not work with vanilla ImageJ1 either. It is handled by the
Bio-Formats plugin. We do not ship Bio-Formats with ImageJ2 because: A)
ImageJ2 is BSD-2 licensed, and the Bio-Formats proprietary file format
readers have an incompatible GPL license; and B) ImageJ2 is supposed to be
a "discipline-agnostic" piece of software, while Bio-Formats is focused on
life sciences file formats.
However, LIF should work if you download Fiji, choose Help > Switch to
Modern Mode, and then File > Open your LIF file. This is thanks to the
SCIFIO Bio-Formats compatibility component (
https://github.com/scifio/scifio-bf-compat) which is bundled with Fiji.
Alternately, you can install Bio-Formats by turning on the Fiji and/or
Bio-Formats update sites shown in ImageJ2's Help > Update "Manage Update
Sites" dialog.
> This is just a sample, but there is a bunch more. My prediction is
> that the users will not migrate to the new version if you ship it as
> is. They frankly need a reason to migrate and ImageJ2 is not offering
> them any.
Agreed; "regular users" should not be switching to the new interface yet.
There are too many bugs and not enough advantages.
That is why decided to keep the ImageJ2 releases using the 1.x interface,
for the time being. This keeps 100% backwards compatibility while also
providing many advantages:
* the ImageJ Updater
* the Script Editor
* user-facing improvements made possible by our ImageJ 1.x patching
mechanism, such as File > Open using the SCIFIO library to read TIFFs and
other formats more robustly
* new developer-facing APIs (esp.,parameterized modules)
There are downsides though:
* IJ1 UI is limited to XYZCT (though we may later patch in support for
additional dimensions)
* IJ1 UI cannot handle tiled huge image planes (a feature planned for the
IJ2 UI)
* Lack of separation of concerns; IJ1 UI is fundamentally tied to the IJ1
data model
* Further reading: http://dev.imagej.net/rationale,
http://dev.imagej.net/proposal
> Right now ImageJ1 is a mature platform with few bugs and a plethora of
> mostly seamlessly working plugins.
In many ways. But due to ImageJ1's protracted incremental development, its
API how grown organically far beyond its original design goals, so it now
contains a plethora of limitations and edge cases.
> The biggest gripe most users have with ImageJ1 is its antiquated UI
With that insight in mind, we recently decided to allow the ImageJ2 Swing
UI to begin diverging much more from the ImageJ 1.x design. It will be nice
to take more liberties and create something that behaves in way more
standardized with other modern applications. See Icy for inspiration (
http://icy.bioimageanalysis.org/).
> and I would wait with the release of the final version until you (we?)
> (1) have ironed out all the bugs and inconsistencies,
>From experience, that goal will never occur. The ImageJ2 design
fundamentally cannot be 100% consistent with ImageJ 1.x. Not even ImageJ
1.x is 100% consistent with previous versions of ImageJ 1.x. And no
software of this magnitude is bug-free, either.
> (2) have good end-user documentation so they know how to do things the
> new way,
Indeed, we had a whole milestone dedicated to documentation in our original
release plan:
http://trac.imagej.net/milestone/imagej2-b11-docs
> and (3) have provided users with at least one "killer" feature that
> they have longed for.
Many such "killer" feature ideas were discussed on the ImageJX list when
ImageJ2 was first launched:
* https://groups.google.com/d/msg/imagejx/gz7cgytSRuA/emlJLp8o7XYJ
* https://groups.google.com/d/msg/imagejx/_yaczl4UWK4/_w6dCnGcJ1QJ
* https://groups.google.com/d/msg/imagejx/lD4s32M5als/HZiEA02LhXsJ
* https://groups.google.com/d/msg/imagejx/ox2ooizORA4/scMd4P0cRZAJ
* https://groups.google.com/d/msg/imagejx/F3gWc_Ndz_U/UTKiut-HuQMJ
* https://groups.google.com/d/msg/imagejx/79rryiWqFno/Ne--gMjkSX8J
* https://groups.google.com/d/msg/imagejx/pL6ipxHkAk8/26u5MF41YGsJ
There are many others in the issue tracker:
* Coherent I/O (complete): http://trac.imagej.net/ticket/9
* Separation of concerns (complete): http://trac.imagej.net/ticket/10
* Better plugin framework (complete): http://trac.imagej.net/ticket/11
* Better scripting (complete): http://trac.imagej.net/ticket/12
* Better event handling (complete): http://trac.imagej.net/ticket/14
* N-dimensional images (complete): http://trac.imagej.net/ticket/17
* Very large image data (complete): http://trac.imagej.net/ticket/20
* CellProfiler interoperability (complete):
http://trac.imagej.net/ticket/1002
* KNIME interoperability (complete): http://trac.imagej.net/ticket/1004
* OMERO interoperability: http://trac.imagej.net/ticket/1003
* Very large image planes: http://trac.imagej.net/ticket/19
* Better undo/redo: http://trac.imagej.net/ticket/13
* Coordinate systems: http://trac.imagej.net/ticket/40
* Metadata: http://trac.imagej.net/ticket/8
I know a lot of those are in some sense architectural, but many of them
have huge impact for users, too. Happy to elaborate on any specific aspects
of these.
> I think there is one thing that can be done in terms of point (3) that
> will make many users happy is a "pin" button in each image
> window/dialog. If the "pin" is activated then the window/dialog will
> be brought to the foreground every time the user brings any other
> "pinned" window or the main imagej bar to the foreground. This solves
> the perrenial usability problem of ImageJ1 where if you have multiple
> images open, you have to hunt for the right image, then hunt for the
> brightness/contrast dialog, then hunt for the channels dialog in the
> taskbar/dock.
Note that there are shortcuts for many of ImageJ's windows, which reduce
the need to hunt through the taskbar. E.g.: Shift+C for the B&C window,
Shift+Z for channels, Enter for the main ImageJ window.
> I don't think this should be a difficult feature to implement and I
> can try to do that, but I will need time to plow through the codebase
> and take it all in.
This feature could also be implemented for the ImageJ 1.x UI, which would
get it into the hands of users more immediately. And you could easily
distribute it via an ImageJ update site; see
http://wiki.imagej.net/Update_Sites.
> I hope that my comments will help with the development. I am hoping to
> contribute to the actual work soon.
Development of the core ImageJ system is a substantially different endeavor
from feature ideas like better window management, analysis plugins, etc.
The question is: which sort of project are you more interested in working
on?
> Please let me know your thoughts. Also, I thought that I might want to
> send these comments to you personally rather than to the ImageJ-devel
> list, since I don't want to step on anyones toes. I imagine there is
> more to your decision to ship on June 1st than just software
> excellence - things like funding, publications, etc. Please feel free
> to forward my letter to the imagej-devel list if you think this will
> be constructive.
Thanks. As I said before, the imagej-devel list is the best place to
discuss these matters. ImageJ is an open source project, and as such is
best discussed in public to keep the community informed of the current
development directions, invite feedback and constructive criticism from
interested parties, etc.
Regards,
Curtis
On Mon, May 12, 2014 at 3:57 PM, Pawel Niewiadomski <
pawelthebiologist at gmail.com> wrote:
> Hi Curtis,
>
> I decided to start work on the project by playing around with the ImageJ2
> interface in some routine tasks I usually do in ImageJ. After having done
> some extensive testing, I just wanted to give you some, hopefully
> constructive, input. I don't want to sound too negative, but I really think
> that June 1st is a bit early to be releasing a production version of
> ImageJ2. Please don't take it the wrong way - I am in the process of
> analysing the codebase and I think it is a real software engineering feat.
> It shows that there has been really serious thought put into architerctural
> design. However, at this point, and I am saying that as a daily ImageJ
> user, the architectural brilliance is not showing on the surface. I am
> going to submit some bug reports in a few days, but basically the interface
> is highly unpredictable and in many ways incompatible with ImageJ1. Let me
> just point to a few basic things before I submit detailed bug reports:
> 1. The brightness/contrast dialog sometimes sticks around when you open a
> new image and close the old one - you end up with multiple
> brightness/contrast dialogs and a single image. Moreover, I've had the
> dialog stay open even after I closed the application.
> 2. The color picker behavior is hectic and I couldn't figure out how and
> why it randomly changes color. Especially in 16-bit per channel images it
> is totally unpredictable.
> 3. With 48-bit 16-bit per channel composite images the drawing command
> with the white color selected basically draws random grey colors.
> 4. The interface is extremely slow to the point of being unusable for
> things like looking through time-course stacks or stacks of medium-sized
> multicolor images.
> 5. Shape selection keeps old selections after you make a new one, which is
> inconsistent with ImageJ1 behavior and quite maddening for someone who is
> used to it.
> 6. Missing magic wand and text tool functionality.
> 7. Missing custom toolbars.
> 8. In multicolor images there seems to be no way of adjusting
> brightness/contrast of each channel individually.
> 9. LIF format import doesn't work - it doesn't present the usual
> BioFormats dialog and instead just imports the first image in the series
> with some random channel separation.
> This is just a sample, but there is a bunch more. My prediction is that
> the users will not migrate to the new version if you ship it as is. They
> frankly need a reason to migrate and ImageJ2 is not offering them any.
> Right now ImageJ1 is a mature platform with few bugs and a plethora of
> mostly seamlessly working plugins. The biggest gripe most users have with
> ImageJ1 is its antiquated UI and I would wait with the release of the final
> version until you (we?) (1) have ironed out all the bugs and
> inconsistencies, (2) have good end-user documentation so they know how to
> do things the new way, and (3) have provided users with at least one
> "killer" feature that they have longed for. I think there is one thing that
> can be done in terms of point (3) that will make many users happy is a
> "pin" button in each image window/dialog. If the "pin" is activated then
> the window/dialog will be brought to the foreground every time the user
> brings any other "pinned" window or the main imagej bar to the foreground.
> This solves the perrenial usability problem of ImageJ1 where if you have
> multiple images open, you have to hunt for the right image, then hunt for
> the brightness/contrast dialog, then hunt for the channels dialog in the
> taskbar/dock. I don't think this should be a difficult feature to implement
> and I can try to do that, but I will need time to plow through the codebase
> and take it all in. I hope that my comments will help with the development.
> I am hoping to contribute to the actual work soon. Please let me know your
> thoughts. Also, I thought that I might want to send these comments to you
> personally rather than to the ImageJ-devel list, since I don't want to step
> on anyones toes. I imagine there is more to your decision to ship on June
> 1st than just software excellence - things like funding, publications, etc.
> Please feel free to forward my letter to the imagej-devel list if you think
> this will be constructive.
>
> Best regards,
> Pawel
>
>
> On 2014-05-06 11:17 PM, Curtis Rueden wrote:
>
>> Hi Pawel,
>>
>> > I am really glad you are open to collaboration. Like you said, there
>> > is definitely a learning curve, so I will try to get acquainted with
>> > the current codebase and drop in on #imagejdev for questions.
>>
>> Sounds good.
>>
>> > I am happy to work on documentation while I am getting up to speed
>> > with the code.
>>
>> Great, that would be really helpful.
>>
>> > Most of my itches are actually GUI-related, but from what I've
>> > gathered you are not planning to initially change the GUI much from
>> > what it was in 1.x for compatibility reasons. Maybe once I understand
>> > the code structure a little better, I can help with work on the Swing,
>> > AWT, or RCP GUIs for the later releases. I'll be keeping in touch.
>>
>> Right, there are two very different modes: the ImageJ 1.x user
>> interface, and the ImageJ 2.x Swing UI. The latter is (at the moment)
>> designed to function much like the former, although we will probably
>> diverge more from ImageJ 1.x's design in the future.
>>
>> To facilitate total backwards compatibility, as well as to accommodate
>> Wayne Rasband's continued development of ImageJ 1.x, we are now opting
>> to release ImageJ 2.0.0 running with the 1.x UI by default. You can
>> still switch to the ImageJ2 UI using Help > Switch to Modern Mode, but
>> it has more limitations compatibility-wise.
>>
>> I would encourage you to discuss your UI ideas and requirements on
>> imagej-devel or in the #imagejdev IRC channel (i.e., somewhere public).
>> That way we can stay on the same page about what things are possible and
>> warranted within each user interface.
>>
>> I look forward to hearing more from you!
>>
>> Regards,
>> Curtis
>>
>>
>> On Tue, May 6, 2014 at 3:35 PM, Pawel Niewiadomski
>> <pawelthebiologist at gmail.com <mailto:pawelthebiologist at gmail.com>> wrote:
>>
>> Hi Curtis,
>>
>> I am really glad you are open to collaboration. Like you said, there
>> is definitely a learning curve, so I will try to get acquainted with
>> the current codebase and drop in on #imagejdev for questions. I am
>> happy to work on documentation while I am getting up to speed with
>> the code. Most of my itches are actually GUI-related, but from what
>> I've gathered you are not planning to initially change the GUI much
>> from what it was in 1.x for compatibility reasons. Maybe once I
>> understand the code structure a little better, I can help with work
>> on the Swing, AWT, or RCP GUIs for the later releases. I'll be
>> keeping in touch.
>>
>> Regards,
>> Pawel
>>
>>
>> On 2014-05-06 6:29 PM, Curtis Rueden wrote:
>>
>> Hi Pawel,
>>
>> Thanks very much for your interest in the ImageJ project! I'm
>> CCing the
>> imagej-devel mailing list, since that is the best place to discuss
>> ImageJ2 core development.
>>
>> > ImageJ is one of my all-time favorite pieces of software and
>> I would
>> > like to contribute to its development. I have a decent
>> knowledge of
>> > Java, but I haven't really worked on an open source project
>> before. I
>> > saw that the list of contributors on the ImageJ github page
>> is pretty
>> > limited and so I am wondering if you generally like outside
>> people
>> > contributing to the codebase or whether you prefer to keep
>> it within
>> > the core development team.
>>
>> One of the major goals of ImageJ2 is to support a more
>> community-oriented group of developers. Requests like yours are
>> surprisingly rare because most people do not have a lot of free
>> time to
>> contribute to projects like ImageJ. But your help would
>> definitely be
>> most welcome.
>>
>> > If you welcome new devs, what features/bugfixes do you think
>> are most
>> > critical at the moment?
>>
>> I would encourage you to first "scratch your own itches" [1].
>> You can
>> get started right away: fork the relevant project(s) from
>> https://github.com/imagej and https://github.com/scijava, push
>> changes
>> to topic branches, and file pull requests [2]. (And if you need an
>> introduction to Git: https://try.github.io/).
>>
>> If you really don't have any itches and just want to fix bugs,
>> that's a
>> bit trickier at the moment, since you would need to become more
>> acquainted with the ImageJ2 project structure -- and it is still
>> in beta
>> and documentation is scarce in many places.
>>
>> It might make the most sense for you to jump into the ImageJ
>> chat room
>> (#imagejdev) on IRC freenode during U.S. business hours and chat
>> with us
>> at more length. One way you could start helping the project
>> right away
>> would be transform any information you learn there into wiki
>> pages on
>> the ImageJ wiki (http://wiki.imagej.net/).
>>
>> We are gearing up for an initial release of ImageJ 2.0.0 (finally
>> leaving beta!) on June 1, so your timing is hectic, but also
>> really
>> fantastic to help improve the project documentation and learn the
>> system, so that you can embark on more involved coding endeavors.
>>
>> Regards,
>> Curtis
>>
>> [1]
>> https://gettingreal.37signals.__com/ch02_Whats_Your_Problem.__php
>> <https://gettingreal.37signals.com/ch02_Whats_Your_Problem.php>
>> [2] https://help.github.com/__articles/using-pull-requests
>>
>> <https://help.github.com/articles/using-pull-requests>
>>
>>
>>
>> On Wed, Apr 30, 2014 at 12:36 PM, Pawel Niewiadomski
>> <pawelthebiologist at gmail.com
>> <mailto:pawelthebiologist at gmail.com>
>> <mailto:pawelthebiologist at __gmail.com
>>
>> <mailto:pawelthebiologist at gmail.com>>> wrote:
>>
>> Hi Curtis,
>>
>> I am a postdoc in molecular biology, who has recently
>> started to
>> seriously work on improving my coding skills. ImageJ is one
>> of my
>> all-time favorite pieces of software and I would like to
>> contribute
>> to its development. I have a decent knowledge of Java, but
>> I haven't
>> really worked on an open source project before. I saw that
>> the list
>> of contributors on the ImageJ github page is pretty limited
>> and so I
>> am wondering if you generally like outside people
>> contributing to
>> the codebase or whether you prefer to keep it within the core
>> development team. If you welcome new devs, what
>> features/bugfixes do
>> you think are most critical at the moment?
>>
>> Thanks,
>> Pawel
>>
>> --
>> Paweł Niewiadomski
>> e-mail: pawelthebiologist at gmail.com
>> <mailto:pawelthebiologist at gmail.com>
>> <mailto:pawelthebiologist at __gmail.com
>>
>> <mailto:pawelthebiologist at gmail.com>>
>> website: www.pawelthebiologist.com
>> <http://www.pawelthebiologist.com>
>> <http://www.pawelthebiologist.__com
>>
>> <http://www.pawelthebiologist.com>>
>>
>>
>>
>> --
>> Paweł Niewiadomski
>> e-mail: pawelthebiologist at gmail.com <mailto:pawelthebiologist@
>> gmail.com>
>> website: www.pawelthebiologist.com <http://www.pawelthebiologist.com>
>>
>>
>>
> --
> Paweł Niewiadomski
> e-mail: pawelthebiologist at gmail.com
> website: www.pawelthebiologist.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20140512/4cbe1d7c/attachment-0001.html>
More information about the ImageJ-devel
mailing list