<div dir="ltr"><div>Hi List<br><br></div><div>After seeing Pawel's e-mails, I also wanted to introduce myself and perhaps become more involved with ImageJ2. <br><br></div><div>Like Pawel I've been exploring the ImageJ2 ecosystem recently (well for over a year actually). I'm coming at it from a developer's point of view. I used to work in the commercial realm until 2011 (Media Cybernetics, mostly on Autoquant). After leaving that I did some unrelated things for a couple of years. I did have a non-compete agreement, but that is long expired so I am thinking about getting back into microscopy.<br>
</div><div><br>I'm interested mainly in high performance applications. A good example of the type of project I'm interested in is GPU Deconvolution. I've seen buzz about a few GPU deconvolution apps recently (I've been able to explore Stephan Preibisch's and Bob Pepin's work on Github). </div>
<div><br>When evaluating a GPU implementation, one would want to understand state-of-the-art CPU implementations. But how does one even determine what is state-of-the-art?? How do you get the algorithms and test them in a consistent fashion? (I recently attended the ISBI Deconvolution Grand Challenge addressing some aspects of this issue). Further, it may not be possible to produce the same results as CPU on a GPU implementation (memory limitations, limited math libraries, etc.). It becomes necessary to run many tests and comparisons. So to evaluate the benefits and trade-offs of GPU deconvolution (or newish algorithms like wavelet approaches) it really becomes important to have access to the older implementations. <br>
</div><div>
<br></div><div>For any new algorithm development, 90% of the problem (in my experience) is understanding and evaluating what has been done before. With open source the great thing is that understanding the past is no longer just a literature search; it also involves getting the algorithms and running them. <br>
</div><div><br>So I see "uber-wrapper" projects (a means to run and test multiple existing implementations under the same framework) being very useful, and I've been developing one for deconvolution with ImageJ2 (<a href="https://github.com/bnorthan/projects" target="_blank">https://github.com/bnorthan/projects</a>). Right now it wraps YacuDecu GPU deconvolution [1], PSF generation in COSMOS [2] and an algorithm from ITK deconvolution. I've also ported a Total Variation implementation from IOCBIOS [3] and non periodic boundary handling from EPFL [4] to imglib2 based implementations (similar design to imglib2 FFTConvolution [5]). These few algorithms barely scratch the surface of what is out there. <br>
<br>As I've gotten multiple algorithms and components wrapped or ported as ImageJ2 commands (or more recently a few ops) it has become simple to run test scripts and to combine components in interesting and useful ways. <br>
<br></div>
<div>I'm not entirely sure how far I will be able to develop this. Since I am using some native components, it could become difficult to maintain and distribute for multiple operating systems. But at the very least I hope to polish it and get it on a personal update site. (Maybe isolating the java only components, possibly snagging the PSF code from Icy[6]). <br>
</div><div><br></div><div>The Github link will be out of date soon as I need to clean and refactor things a bit. As I do this there may be an opportunity to contribute to the Imagej-ops project or Imglib2. One thing I need to do is take inventory of all the little math functions I've written. Where I've re-invented the wheel I need to re-use the proper imagej-ops or imglib2 function instead. If some math functions I have written are not in imagej-ops/imgib I could take a look at implementing them. <br>
<br></div><div>Regards,<br></div><div><br></div><div>Brian<br></div><div><br></div><div>[1] <a href="https://github.com/bobpepin/YacuDecu" target="_blank">https://github.com/bobpepin/YacuDecu</a><br>[2] <a href="http://cirl.memphis.edu/cosmos.php" target="_blank">http://cirl.memphis.edu/cosmos.php</a><br>
[3] <a href="http://code.google.com/p/iocbio/wiki/IOCBioMicroscope" target="_blank">http://code.google.com/p/iocbio/wiki/IOCBioMicroscope</a><br>[4] <a href="http://bigwww.epfl.ch/deconvolution/challenge/index.html?p=documentation/theory/richardsonlucy" target="_blank">http://bigwww.epfl.ch/deconvolution/challenge/index.html?p=documentation/theory/richardsonlucy</a><br>
[5] <a href="https://github.com/imglib/imglib/blob/master/algorithms/gpl/src/main/java/net/imglib2/algorithm/fft2/FFTConvolution.java">https://github.com/imglib/imglib/blob/master/algorithms/gpl/src/main/java/net/imglib2/algorithm/fft2/FFTConvolution.java</a><br>
[6] <a href="http://icy.bioimageanalysis.org/plugin/Widefield_Fluorescence_Microscope_PSF">http://icy.bioimageanalysis.org/plugin/Widefield_Fluorescence_Microscope_PSF</a><br>
</div><div>
<br></div><div><br>
</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, May 13, 2014 at 3: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>
<br>
______________________________<u></u>_________________<br>
ImageJ-devel mailing list<br>
<a href="mailto:ImageJ-devel@imagej.net" target="_blank">ImageJ-devel@imagej.net</a><br>
<a href="http://imagej.net/mailman/listinfo/imagej-devel" target="_blank">http://imagej.net/mailman/<u></u>listinfo/imagej-devel</a><br>
</blockquote></div><br></div>