<div dir="ltr"><div>Hi Pawel,</div><div><br></div><div>> I was actually under the impression that ImageJ2 IS the modern</div><div>> interface and that it would be the default for the 2.0.0 release.</div><div><br></div>
<div>The vision of the ImageJ2 project has substantially evolved since its 2009 inception.</div><div><br></div><div>The main takeaway is that "ImageJ2" is actually several different components. Documenting these components clearly but succinctly is certainly a challenge.</div>
<div><br></div><div>> The imagej-win32.exe doesn't work in the build from about a week ago</div><div>> on my machine (Just the basic command that launches the GUI). I'll</div><div>> submit a bug report.</div>
<div><br></div><div>OK, thanks. I suggest these resources for how to write a good bug report:</div><div>* <a href="http://stackoverflow.com/help/how-to-ask">http://stackoverflow.com/help/how-to-ask</a></div><div>* <a href="http://whathaveyoutried.com/">http://whathaveyoutried.com/</a></div>
<div><br></div><div>> I am guessing it's the same as the FiJi script editor? In that case</div><div>> the legacy UI should have a menu option File->New->Script, like FiJi</div>
<div>> does. In addition, the plugins->new->plugin throws some sort of</div><div>> exception on first use, again I'll submit a bug report.</div><div><br></div><div>The Fiji Script Editor came first. Then it was ported to the ImageJ2 Script Editor, which at the moment is a separate codebase. We are on the cusp of updating Fiji to use the IJ2 Script Editor, and retiring the old Fiji codebase. But we cannot do it until the IJ2 Script Editor has all the features that the current Fiji Script Editor has. It is a goal for the June release.</div>
<div><br></div><div>> > * Will support parameterized ImageJ modules </div>
<div>></div><div>> Sounds good - I need to look into it more closely.</div><div><br></div><div><a href="https://github.com/imagej/imagej-tutorials/tree/master/simple-commands/src/main/java">https://github.com/imagej/imagej-tutorials/tree/master/simple-commands/src/main/java</a><br>
</div><div><br></div><div>> I've been using FiJi for quite some time now, so I didn't see the</div>
<div>> "newness" of the features.</div><div><br></div><div>Fiji (small J, BTW) incubated several of the features now being slated for ImageJ 2.0.0:</div><div>* <a href="http://developer.imagej.net/2012/11/19/road-fiji-2">http://developer.imagej.net/2012/11/19/road-fiji-2</a></div>
<div>* <a href="http://developer.imagej.net/2014/03/27/imagej2-and-fiji-recent-milestones">http://developer.imagej.net/2014/03/27/imagej2-and-fiji-recent-milestones</a><br></div><div><br></div><div>> It does work, but not with File->Open. It doesn't present the right</div>
<div>> dialog for file import. You can go to File->Import->Bio-Formats. When</div>
<div>> you go to file-open (even in modern mode in FiJi), it just imports the</div><div>> first image of the bundle with each channel on a separate plane</div><div>> instead of creating a composite. It doesn't offer you the choices the</div>
<div>> way Bio-Formats does.</div><div><br></div><div>The "big honkin' dialog" of Bio-Formats is indeed specific to Bio-Formats. File > Open in ImageJ2 will not use the Bio-Formats dialogs. After all, that dialog was built using an IJ1 GenericDialog, which ImageJ2 eschews. Eventually we will have some "advanced options" which will be very similar to (some of) those options of the BF dialog, but we have not implemented that yet.</div>
<div><br></div><div>> These are not large images (1kx1k/48-bit/10 z-planes), but mind you, I</div><div>> am not using the latest hardware. However, I think many of ImageJ</div>
<div>> users will not be on modern hardware, and my computer can run</div><div>> Photoshop CS4 with ease, which is an indication that it is not a piece</div><div>> of junk, either.</div><div><br></div><div>Browsing images of that size is supposed to be smooth. Maybe it is a CPU issue as you say. In the long term, we are planning to overhaul IJ2's display mechanism which should substantially help improve performance.</div>
<div><br></div><div>> OK. It would be nice if the toolbar were easily customizable by the</div><div>> user the way the old style custom toolbars were.</div><div><br></div><div>Customization of toolbars is planned but will come later.<br>
</div><div><br></div><div>> Also, having custom floating/docking toolbars would be nice. I am</div>
<div>> thinking photoshop/illustrator here, or at least Office <2003. I don't</div><div>> think you necessarily need to implement an RCP-style interface to have</div><div>> those.</div><div><br></div><div>
The IJ2 toolbar is already dockable, so can be made to float. Try grabbing the grippers on the left and dragging.</div><div><br></div><div>And we will definitely not need to use an RCP framework for the customization.</div>
<div><br></div><div>> I think that and the fact that FiJi already has many of these features</div><div>> is why I was convinced that ImageJ2 is the modern interface. The data</div><div>> model limitation is a serious one, because people cannot just migrate</div>
<div>> their plugins in one fell swoop. Rather, they have to first play with</div><div>> the new APIs, then start working on the data model conversion, etc.</div><div><br></div><div>The new data model will be available in ImageJ 2.0.0, but still in beta -- meaning anyone who converts their plugins at this point might need to tweak their code again in the future as the API continues to evolve before final release.</div>
<div><br></div><div>But the parameterized module framework is out of beta and we will do our best to ensure backwards compatibility. So the recommended next step for migration of plugins would be to first switch the plugin to an ImageJ2 command using parameterized inputs and outputs, but with ImageJ1 data structures (e.g., ImagePlus). Then switch to ImageJ2 data structures later... unless the plugin really needs an IJ2-only feature immediately.</div>
<div><br></div><div>> Yes. I may have overstated that goal. It would be a more realistic</div>
<div>> goal to have it bug-free enough that it is not super-annoying to the</div><div>> casual user.</div><div><br></div><div>Sure. That is a gray area though, since it is subjective depending on the user. But I agree with the sentiment.</div>
<div><br></div><div>> > * Better undo/redo: <a href="http://trac.imagej.net/ticket/13" target="_blank">http://trac.imagej.net/ticket/13</a></div>
<div>></div><div>> Absolutely a killer feature, but I am guessing difficult to implement</div><div>> in a plugin-based framework.</div><div><br></div><div>Difficult but doable. We just never quite had time to work on it intensively, yet. The ticket explains what needs to be done.</div>
<div><br></div><div>> Most annoyingly, the ImageJ toolbar disappears (is there a shortcut to</div>
<div>> bring it to foreground???)</div><div><br></div><div>Yes, like I said: Enter.</div><div><br></div><div>> > This feature could also be implemented for the ImageJ 1.x UI,</div><div>></div><div>> Sounds good. I'll give it a stab.</div>
<div><br></div><div>Awesome, definitely keep us posted on your progress!</div><div><br></div><div>> I think I will be interested in features development more than the</div><div>> core, but that may change as I get more familiar with the core.</div>
<div><br></div><div>That is understandable, and certainly very reasonable given ImageJ's extensible plugin mechanism. The core is "good enough" for a great variety of things. I think it takes a certain architectural obsession to want to work on ImageJ2 itself, which is one reason there are so few external contributors.</div>
<div><br></div><div>Then, the best way for you to improve ImageJ, and give back to the ImageJ community, will be to create your own personal update site and start adding useful plugins to it, which work in the ImageJ 1.x UI. That said, you could still be an early adopter of the parameterized ImageJ2 command mechanism and other ImageJ2-only features, which would be really nice for a number of reasons.</div>
<div><br></div><div>Regards,</div><div>Curtis</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, May 13, 2014 at 2:41 AM, Pawel Niewiadomski <span dir="ltr"><<a href="mailto:pawelthebiologist@gmail.com" target="_blank">pawelthebiologist@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Curtis,<br>
<br>
Thanks for your comprehensive reply.<div class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Pawel,<br>
<br>
> I decided to start work on the project by playing around with the<br>
> ImageJ2 interface in some routine tasks I usually do in ImageJ. After<br>
> having done some extensive testing, I just wanted to give you some,<br>
> hopefully constructive, input. I don't want to sound too negative, but<br>
> I really think that June 1st is a bit early to be releasing a<br>
> production version of ImageJ2.<br>
<br>
With respect to the ImageJ2 Swing user interface and commands, you are<br>
absolutely right. However, the initial 2.0.0 release of ImageJ2 is going<br>
to continue using the classic ImageJ 1.x user interface by default. The<br>
new UI will still be included (Help > Switch to Modern Mode) but will<br>
still be very much in beta.<br>
<br>
</blockquote>
<br></div>
I was actually under the impression that ImageJ2 IS the modern interface and that it would be the default for the 2.0.0 release. I must have not found the relevant blog/discussion posts. My bad.<div class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
See this blog post for details:<br>
<a href="http://developer.imagej.net/2014/04/01/imagej-200-stable-release-coming-spring" target="_blank">http://developer.imagej.net/<u></u>2014/04/01/imagej-200-stable-<u></u>release-coming-spring</a><br>
<br>
ImageJ 2.0.0 will be fundamentally the same as ImageJ1, but:<br>
<br>
* Will be bundled with the Updater component which supports ImageJ<br>
update sites and automatic update checking.<br>
<br>
</blockquote>
<br></div>
OK<div class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Will be bundled with the native ImageJ Launcher with quite a few nice<br>
command line features.<br>
</blockquote>
<br></div>
The imagej-win32.exe doesn't work in the build from about a week ago on my machine (Just the basic command that launches the GUI). I'll submit a bug report.<div class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
* Will be bundled with the ImageJ Script Editor including support for<br>
several scripting languages.<br>
<br>
</blockquote>
<br></div>
I am guessing it's the same as the FiJi script editor? In that case the legacy UI should have a menu option File->New->Script, like FiJi does. In addition, the plugins->new->plugin throws some sort of exception on first use, again I'll submit a bug report.<div class="">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Will support parameterized ImageJ modules, including commands and<br>
scripts, so that existing plugins can begin incremental migration toward<br>
this new approach, which is more headless friendly and more<br>
interoperable with tools such as CellProfiler, KNIME and OMERO.<br>
<br>
</blockquote>
<br></div>
Sounds good - I need to look into it more closely.<div class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Will come with an option to use the SCIFIO library when opening image<br>
files (e.g., using File > Open). This will fix ImageJ's TIFF support to<br>
be more robust, and add extensible support for additional file formats<br>
without needing to hack the HandleExtraFileTypes source.<br>
<br>
</blockquote>
<br></div>
OK.<div class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Will ship with all the new ImageJ2 APIs, but all these components will<br>
still be in beta. We will bring each component out of beta after it has<br>
been thoroughly vetted over time. These components include:<br>
- imagej-common: The ImgLib2-based image data model and core<br>
- imagej-ops: A framework for reusable algorithms; see<br>
<a href="http://developer.imagej.net/2014/04/04/announcing-imagej-ops" target="_blank">http://developer.imagej.net/<u></u>2014/04/04/announcing-imagej-<u></u>ops</a><br>
- imagej-ui-swing: The "pure ImageJ2" Swing user interface<br>
- imagej-plugins-*, scijava-plugins-*: Core plugins for ImageJ2<br>
including many commands<br>
<br>
</blockquote>
<br></div>
OK<div class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Note that the Fiji distribution of ImageJ has been shipping of all of<br>
these components, and operating in this way, for years now, and is a<br>
well vetted system. But it is time for these components to be officially<br>
available as part of ImageJ's core, rather than only from a specific<br>
life-sciences-focused ImageJ distribution.<br>
</blockquote>
<br></div>
Sounds good. I've been using FiJi for quite some time now, so I didn't see the "newness" of the features.<div><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> Please don't take it the wrong way - I am in the process of analysing<br>
> the codebase and I think it is a real software engineering feat.<br>
<br>
No offense taken at all; again, it is absolutely true that the ImageJ2<br>
UI needs more time in the oven. But meanwhile, it has already been over<br>
four years since we launched the ImageJ2 project, and there are several<br>
very mature components that need to get into the hands of users: the<br>
Updater, the Launcher, the Script Editor, parameterized modules, and<br>
everything else that is now part of the "SciJava Common" component<br>
(<a href="https://github.com/scijava/scijava-common" target="_blank">https://github.com/scijava/<u></u>scijava-common</a>).<br>
<br>
Because ImageJ2 consists of several pieces at various stages of<br>
development, it needs to migrate out of beta piece by piece.<br>
<br>
> It shows that there has been really serious thought put into<br>
> architerctural design. However, at this point, and I am saying that as<br>
> a daily ImageJ user, the architectural brilliance is not showing on<br>
> the surface.<br>
<br>
I am glad you like the design. And I agree that much more needs to be<br>
done in terms of leveraging that design for the benefit of end users.<br>
This is an area where your contributions could be really beneficial.<br>
<br>
> I am going to submit some bug reports in a few days, but basically the<br>
> interface is highly unpredictable and in many ways incompatible with<br>
> ImageJ1.<br>
<br>
Indeed. Please note that there are many bugs about such problems already<br>
logged in the ImageJ Trac: <a href="http://trac.imagej.net/" target="_blank">http://trac.imagej.net/</a>. We are actively in<br>
the process of migrating away from the Trac system though, with<br>
individual tickets being moved to GitHub Issues of the most relevant<br>
repository. Unfortunately, since we are in the middle of that migration,<br>
it may be difficult to verify whether an issue has already been filed<br>
for any particular concern. When in doubt, file away and we can close<br>
any duplicate issues accordingly.<br>
<br>
> Let me just point to a few basic things before I submit detailed bug<br>
> reports:<br>
><br>
> 1. The brightness/contrast dialog sometimes sticks around when you<br>
> open a new image and close the old one - you end up with multiple<br>
> brightness/contrast dialogs and a single image. Moreover, I've had the<br>
> dialog stay open even after I closed the application.<br>
<br>
The IJ2 version of B&C has been the subject of frequent debate. In<br>
short, it needs a lot more work. See <a href="http://trac.imagej.net/ticket/1100" target="_blank">http://trac.imagej.net/ticket/<u></u>1100</a><br>
and all its blocking tickets (those listed in "Blocked by").<br>
<br>
</blockquote>
<br></div></div>
OK<div class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> 2. The color picker behavior is hectic and I couldn't figure out how<br>
> and why it randomly changes color. Especially in 16-bit per channel<br>
> images it is totally unpredictable.<br>
><br>
> 3. With 48-bit 16-bit per channel composite images the drawing command<br>
> with the white color selected basically draws random grey colors.<br>
<br>
IJ2's current approach to foreground and background "colors" differs<br>
from IJ1. And there are likely bugs, too.<br>
* <a href="http://trac.imagej.net/ticket/965" target="_blank">http://trac.imagej.net/ticket/<u></u>965</a><br>
* <a href="http://trac.imagej.net/ticket/1292" target="_blank">http://trac.imagej.net/ticket/<u></u>1292</a><br>
<br>
</blockquote>
<br></div>
OK<div class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> 4. The interface is extremely slow to the point of being unusable for<br>
> things like looking through time-course stacks or stacks of<br>
> medium-sized multicolor images.<br>
<br>
That is not a problem we have noticed, unless image planes become very<br>
large. How large are your image planes? >2Kx2K?<br>
<br>
</blockquote>
<br></div>
These are not large images (1kx1k/48-bit/10 z-planes), but mind you, I am not using the latest hardware. However, I think many of ImageJ users will not be on modern hardware, and my computer can run Photoshop CS4 with ease, which is an indication that it is not a piece of junk, either.<div class="">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> 5. Shape selection keeps old selections after you make a new one,<br>
> which is inconsistent with ImageJ1 behavior and quite maddening for<br>
> someone who is used to it.<br>
<br>
Yes. We will probably need an option for it, because for many new users,<br>
it is maddening to have one ROI disappear when creating another. But the<br>
main reason IJ2's UI works that way right now is technical: it currently<br>
uses the JHotDraw library which works that way by default.<br>
<br>
</blockquote>
<br></div>
OK<div class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> 6. Missing magic wand and text tool functionality.<br>
<br>
<a href="https://github.com/imagej/imagej-plugins-tools/issues/8" target="_blank">https://github.com/imagej/<u></u>imagej-plugins-tools/issues/8</a><br>
<a href="https://github.com/imagej/imagej-plugins-tools/issues/9" target="_blank">https://github.com/imagej/<u></u>imagej-plugins-tools/issues/9</a><br>
<br>
</blockquote>
<br></div>
OK<div class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> 7. Missing custom toolbars.<br>
<br>
Known, but no explicit issue for it yet. Low priority, given all the<br>
other things the Swing UI needs first. Note that IJ2 is not<br>
intrinsically limited to 8 tools like ImageJ1 is, so it is less urgent<br>
to support customization. All available tools will be present in the bar<br>
by default.<br>
<br>
</blockquote>
<br></div>
OK. It would be nice if the toolbar were easily customizable by the user<br>
the way the old style custom toolbars were. Also, having custom floating/docking toolbars would be nice. I am thinking photoshop/illustrator here, or at least Office <2003. I don't think you necessarily need to implement an RCP-style interface to have those.<div class="">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> 8. In multicolor images there seems to be no way of adjusting<br>
> brightness/contrast of each channel individually.<br>
<br>
Hmm, you're right. This might be a relatively new bug.<br>
<br>
</blockquote>
<br></div>
That's an absolutely essential feature for any microscopy work. I'll submit the bug report.<div class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> 9. LIF format import doesn't work - it doesn't present the usual<br>
> BioFormats dialog and instead just imports the first image in the<br>
> series with some random channel separation.<br>
<br>
LIF format does not work with vanilla ImageJ1 either. It is handled by<br>
the Bio-Formats plugin. We do not ship Bio-Formats with ImageJ2 because:<br>
A) ImageJ2 is BSD-2 licensed, and the Bio-Formats proprietary file<br>
format readers have an incompatible GPL license; and B) ImageJ2 is<br>
supposed to be a "discipline-agnostic" piece of software, while<br>
Bio-Formats is focused on life sciences file formats.<br>
<br>
</blockquote>
<br></div>
OK. Understood.<div class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
However, LIF should work if you download Fiji, choose Help > Switch to<br>
Modern Mode, and then File > Open your LIF file. This is thanks to the<br>
SCIFIO Bio-Formats compatibility component<br>
(<a href="https://github.com/scifio/scifio-bf-compat" target="_blank">https://github.com/scifio/<u></u>scifio-bf-compat</a>) which is bundled with Fiji.<br>
<br>
</blockquote>
<br></div>
It does work, but not with File->Open. It doesn't present the right dialog for file import. You can go to File->Import->Bio-Formats. When you go to file-open (even in modern mode in FiJi), it just imports the first image of the bundle with each channel on a separate plane instead of creating a composite. It doesn't offer you the choices the way Bio-Formats does.<div class="">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Alternately, you can install Bio-Formats by turning on the Fiji and/or<br>
Bio-Formats update sites shown in ImageJ2's Help > Update "Manage Update<br>
Sites" dialog.<br>
<br>
> This is just a sample, but there is a bunch more. My prediction is<br>
> that the users will not migrate to the new version if you ship it as<br>
> is. They frankly need a reason to migrate and ImageJ2 is not offering<br>
> them any.<br>
<br>
Agreed; "regular users" should not be switching to the new interface<br>
yet. There are too many bugs and not enough advantages.<br>
<br>
That is why decided to keep the ImageJ2 releases using the 1.x<br>
interface, for the time being. This keeps 100% backwards compatibility<br>
while also providing many advantages:<br>
* the ImageJ Updater<br>
* the Script Editor<br>
* user-facing improvements made possible by our ImageJ 1.x patching<br>
mechanism, such as File > Open using the SCIFIO library to read TIFFs<br>
and other formats more robustly<br>
* new developer-facing APIs (esp.,parameterized modules)<br>
</blockquote>
<br></div>
Sounds good.<div class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
There are downsides though:<br>
* IJ1 UI is limited to XYZCT (though we may later patch in support<br>
for additional dimensions)<br>
* IJ1 UI cannot handle tiled huge image planes (a feature planned for<br>
the IJ2 UI)<br>
* Lack of separation of concerns; IJ1 UI is fundamentally tied to the<br>
IJ1 data model<br>
</blockquote>
<br></div>
I think that and the fact that FiJi already has many of these features is why I was convinced that ImageJ2 is the modern interface. The data model limitation is a serious one, because people cannot just migrate their plugins in one fell swoop. Rather, they have to first play with the new APIs, then start working on the data model conversion, etc.<div class="">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Further reading: <a href="http://dev.imagej.net/rationale" target="_blank">http://dev.imagej.net/<u></u>rationale</a>,<br>
<a href="http://dev.imagej.net/proposal" target="_blank">http://dev.imagej.net/proposal</a><br>
<br>
> Right now ImageJ1 is a mature platform with few bugs and a plethora of<br>
> mostly seamlessly working plugins.<br>
<br>
In many ways. But due to ImageJ1's protracted incremental development,<br>
its API how grown organically far beyond its original design goals, so<br>
it now contains a plethora of limitations and edge cases.<br>
<br>
> The biggest gripe most users have with ImageJ1 is its antiquated UI<br>
<br>
With that insight in mind, we recently decided to allow the ImageJ2<br>
Swing UI to begin diverging much more from the ImageJ 1.x design. It<br>
will be nice to take more liberties and create something that behaves in<br>
way more standardized with other modern applications. See Icy for<br>
inspiration (<a href="http://icy.bioimageanalysis.org/" target="_blank">http://icy.bioimageanalysis.<u></u>org/</a>).<br>
</blockquote>
<br></div>
I agree<div class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> and I would wait with the release of the final version until you (we?)<br>
> (1) have ironed out all the bugs and inconsistencies,<br>
<br>
From experience, that goal will never occur. The ImageJ2 design<br>
fundamentally cannot be 100% consistent with ImageJ 1.x. Not even ImageJ<br>
1.x is 100% consistent with previous versions of ImageJ 1.x. And no<br>
software of this magnitude is bug-free, either.<br>
</blockquote>
<br></div>
Yes. I may have overstated that goal. It would be a more realistic goal to have it bug-free enough that it is not super-annoying to the casual user.<div class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> (2) have good end-user documentation so they know how to do things the<br>
> new way,<br>
<br>
Indeed, we had a whole milestone dedicated to documentation in our<br>
original release plan:<br>
<a href="http://trac.imagej.net/milestone/imagej2-b11-docs" target="_blank">http://trac.imagej.net/<u></u>milestone/imagej2-b11-docs</a><br>
<br>
</blockquote>
<br></div>
OK.<div><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> and (3) have provided users with at least one "killer" feature that<br>
> they have longed for.<br>
<br>
Many such "killer" feature ideas were discussed on the ImageJX list when<br>
ImageJ2 was first launched:<br>
* <a href="https://groups.google.com/d/msg/imagejx/gz7cgytSRuA/emlJLp8o7XYJ" target="_blank">https://groups.google.com/d/<u></u>msg/imagejx/gz7cgytSRuA/<u></u>emlJLp8o7XYJ</a><br>
* <a href="https://groups.google.com/d/msg/imagejx/_yaczl4UWK4/_w6dCnGcJ1QJ" target="_blank">https://groups.google.com/d/<u></u>msg/imagejx/_yaczl4UWK4/_<u></u>w6dCnGcJ1QJ</a><br>
* <a href="https://groups.google.com/d/msg/imagejx/lD4s32M5als/HZiEA02LhXsJ" target="_blank">https://groups.google.com/d/<u></u>msg/imagejx/lD4s32M5als/<u></u>HZiEA02LhXsJ</a><br>
* <a href="https://groups.google.com/d/msg/imagejx/ox2ooizORA4/scMd4P0cRZAJ" target="_blank">https://groups.google.com/d/<u></u>msg/imagejx/ox2ooizORA4/<u></u>scMd4P0cRZAJ</a><br>
* <a href="https://groups.google.com/d/msg/imagejx/F3gWc_Ndz_U/UTKiut-HuQMJ" target="_blank">https://groups.google.com/d/<u></u>msg/imagejx/F3gWc_Ndz_U/<u></u>UTKiut-HuQMJ</a><br>
* <a href="https://groups.google.com/d/msg/imagejx/79rryiWqFno/Ne--gMjkSX8J" target="_blank">https://groups.google.com/d/<u></u>msg/imagejx/79rryiWqFno/Ne--<u></u>gMjkSX8J</a><br>
* <a href="https://groups.google.com/d/msg/imagejx/pL6ipxHkAk8/26u5MF41YGsJ" target="_blank">https://groups.google.com/d/<u></u>msg/imagejx/pL6ipxHkAk8/<u></u>26u5MF41YGsJ</a><br>
<br>
There are many others in the issue tracker:<br>
* Coherent I/O (complete): <a href="http://trac.imagej.net/ticket/9" target="_blank">http://trac.imagej.net/ticket/<u></u>9</a><br>
* Separation of concerns (complete): <a href="http://trac.imagej.net/ticket/10" target="_blank">http://trac.imagej.net/ticket/<u></u>10</a><br>
* Better plugin framework (complete): <a href="http://trac.imagej.net/ticket/11" target="_blank">http://trac.imagej.net/ticket/<u></u>11</a><br>
* Better scripting (complete): <a href="http://trac.imagej.net/ticket/12" target="_blank">http://trac.imagej.net/ticket/<u></u>12</a><br>
* Better event handling (complete): <a href="http://trac.imagej.net/ticket/14" target="_blank">http://trac.imagej.net/ticket/<u></u>14</a><br>
* N-dimensional images (complete): <a href="http://trac.imagej.net/ticket/17" target="_blank">http://trac.imagej.net/ticket/<u></u>17</a><br>
* Very large image data (complete): <a href="http://trac.imagej.net/ticket/20" target="_blank">http://trac.imagej.net/ticket/<u></u>20</a><br>
* CellProfiler interoperability (complete):<br>
<a href="http://trac.imagej.net/ticket/1002" target="_blank">http://trac.imagej.net/ticket/<u></u>1002</a><br>
* KNIME interoperability (complete): <a href="http://trac.imagej.net/ticket/1004" target="_blank">http://trac.imagej.net/ticket/<u></u>1004</a><br>
* OMERO interoperability: <a href="http://trac.imagej.net/ticket/1003" target="_blank">http://trac.imagej.net/ticket/<u></u>1003</a><br>
* Very large image planes: <a href="http://trac.imagej.net/ticket/19" target="_blank">http://trac.imagej.net/ticket/<u></u>19</a><br>
* Better undo/redo: <a href="http://trac.imagej.net/ticket/13" target="_blank">http://trac.imagej.net/ticket/<u></u>13</a><br>
</blockquote>
<br></div></div>
Absolutely a killer feature, but I am guessing difficult to implement in a plugin-based framework.<div class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Coordinate systems: <a href="http://trac.imagej.net/ticket/40" target="_blank">http://trac.imagej.net/ticket/<u></u>40</a><br>
* Metadata: <a href="http://trac.imagej.net/ticket/8" target="_blank">http://trac.imagej.net/ticket/<u></u>8</a><br>
<br>
I know a lot of those are in some sense architectural, but many of them<br>
have huge impact for users, too. Happy to elaborate on any specific<br>
aspects of these.<br>
<br>
> I think there is one thing that can be done in terms of point (3) that<br>
> will make many users happy is a "pin" button in each image<br>
> window/dialog. If the "pin" is activated then the window/dialog will<br>
> be brought to the foreground every time the user brings any other<br>
> "pinned" window or the main imagej bar to the foreground. This solves<br>
> the perrenial usability problem of ImageJ1 where if you have multiple<br>
> images open, you have to hunt for the right image, then hunt for the<br>
> brightness/contrast dialog, then hunt for the channels dialog in the<br>
> taskbar/dock.<br>
<br>
Note that there are shortcuts for many of ImageJ's windows, which reduce<br>
the need to hunt through the taskbar. E.g.: Shift+C for the B&C window,<br>
Shift+Z for channels, Enter for the main ImageJ window.<br>
</blockquote>
<br></div>
Yes, I've been using those shortcuts, but it is still annoying to have to find the image, and then press shift-Z and shift-C every time you switch back and forth between applications. Most annoyingly, the ImageJ toolbar disappears (is there a shortcut to bring it to foreground???) unless you set it always on top, which in turn makes it get in the way of other applications. What many users do is switch back and forth between ImageJ and other apps that allow them to put figures together (Illustrator/Photoshop/<u></u>PowerPoint/Word) or analyze the data (Excel/R/Statistica). Right now I spend half my time fishing for the right image/dialog/button.<div class="">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> I don't think this should be a difficult feature to implement and I<br>
> can try to do that, but I will need time to plow through the codebase<br>
> and take it all in.<br>
<br>
This feature could also be implemented for the ImageJ 1.x UI, which<br>
would get it into the hands of users more immediately. And you could<br>
easily distribute it via an ImageJ update site; see<br>
<a href="http://wiki.imagej.net/Update_Sites" target="_blank">http://wiki.imagej.net/Update_<u></u>Sites</a>.<br>
</blockquote>
<br></div>
Sounds good. I'll give it a stab.<div class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> I hope that my comments will help with the development. I am hoping to<br>
> contribute to the actual work soon.<br>
<br>
Development of the core ImageJ system is a substantially different<br>
endeavor from feature ideas like better window management, analysis<br>
plugins, etc. The question is: which sort of project are you more<br>
interested in working on?<br>
</blockquote>
<br></div>
I think I will be interested in features development more than the core, but that may change as I get more familiar with the core.<div class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> Please let me know your thoughts. Also, I thought that I might want to<br>
> send these comments to you personally rather than to the ImageJ-devel<br>
> list, since I don't want to step on anyones toes. I imagine there is<br>
> more to your decision to ship on June 1st than just software<br>
> excellence - things like funding, publications, etc. Please feel free<br>
> to forward my letter to the imagej-devel list if you think this will<br>
> be constructive.<br>
<br>
Thanks. As I said before, the imagej-devel list is the best place to<br>
discuss these matters. ImageJ is an open source project, and as such is<br>
best discussed in public to keep the community informed of the current<br>
development directions, invite feedback and constructive criticism from<br>
interested parties, etc.<br>
</blockquote>
<br></div>
Got it.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Regards,<br>
Curtis<br>
<br>
</blockquote>
<br>
Regards,<div class=""><br>
Pawel<br>
<br>
-- <br>
Paweł Niewiadomski<br>
e-mail: <a href="mailto:pawelthebiologist@gmail.com" target="_blank">pawelthebiologist@gmail.com</a><br></div>
website: <a href="http://www.pawelthebiologist.com" target="_blank">www.pawelthebiologist.com</a><br>
</blockquote></div><br></div>