[ImageJ-devel] ImageJ2 development
Pawel Niewiadomski
pawelthebiologist at gmail.com
Tue May 13 15:38:54 CDT 2014
Hi Curtis,
Thanks again for taking the time to comprehensively reply to my
sometimes ill-informed concerns and questions. I hope I can start
contributing to the project soon!
Regards,
Pawel
On 2014-05-13 10:16 PM, Curtis Rueden wrote:
> Hi Pawel,
>
> > 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.
>
> The vision of the ImageJ2 project has substantially evolved since its
> 2009 inception.
>
> The main takeaway is that "ImageJ2" is actually several different
> components. Documenting these components clearly but succinctly is
> certainly a challenge.
>
> > 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.
>
> OK, thanks. I suggest these resources for how to write a good bug report:
> * http://stackoverflow.com/help/how-to-ask
> * http://whathaveyoutried.com/
>
> > 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.
>
> 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.
>
> > > * Will support parameterized ImageJ modules
> >
> > Sounds good - I need to look into it more closely.
>
> https://github.com/imagej/imagej-tutorials/tree/master/simple-commands/src/main/java
>
> > I've been using FiJi for quite some time now, so I didn't see the
> > "newness" of the features.
>
> Fiji (small J, BTW) incubated several of the features now being slated
> for ImageJ 2.0.0:
> * http://developer.imagej.net/2012/11/19/road-fiji-2
> * http://developer.imagej.net/2014/03/27/imagej2-and-fiji-recent-milestones
>
> > 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.
>
> 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.
>
> > 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.
>
> 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.
>
> > OK. It would be nice if the toolbar were easily customizable by the
> > user the way the old style custom toolbars were.
>
> Customization of toolbars is planned but will come later.
>
> > 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.
>
> The IJ2 toolbar is already dockable, so can be made to float. Try
> grabbing the grippers on the left and dragging.
>
> And we will definitely not need to use an RCP framework for the
> customization.
>
> > 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.
>
> 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.
>
> 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.
>
> > 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.
>
> Sure. That is a gray area though, since it is subjective depending on
> the user. But I agree with the sentiment.
>
> > > * Better undo/redo: http://trac.imagej.net/ticket/13
> >
> > Absolutely a killer feature, but I am guessing difficult to implement
> > in a plugin-based framework.
>
> Difficult but doable. We just never quite had time to work on it
> intensively, yet. The ticket explains what needs to be done.
>
> > Most annoyingly, the ImageJ toolbar disappears (is there a shortcut to
> > bring it to foreground???)
>
> Yes, like I said: Enter.
>
> > > This feature could also be implemented for the ImageJ 1.x UI,
> >
> > Sounds good. I'll give it a stab.
>
> Awesome, definitely keep us posted on your progress!
>
> > 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.
>
> 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.
>
> 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.
>
> Regards,
> Curtis
>
>
> On Tue, May 13, 2014 at 2:41 AM, Pawel Niewiadomski
> <pawelthebiologist at gmail.com <mailto:pawelthebiologist at gmail.com>> wrote:
>
> Hi Curtis,
>
> Thanks for your comprehensive reply.
>
>
> 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.
>
>
> 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.
>
>
> See this blog post for details:
> http://developer.imagej.net/__2014/04/01/imagej-200-stable-__release-coming-spring
> <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.
>
>
> OK
>
>
> * Will be bundled with the native ImageJ Launcher with quite a
> few nice
> command line features.
>
>
> 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.
>
>
>
> * Will be bundled with the ImageJ Script Editor including
> support for
> several scripting languages.
>
>
> 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.
>
>
> * 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.
>
>
> Sounds good - I need to look into it more closely.
>
>
> * 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.
>
>
> OK.
>
>
> * 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
> <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
>
>
> OK
>
>
> 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.
>
>
> Sounds good. I've been using FiJi for quite some time now, so I
> didn't see the "newness" of the features.
>
>
>
> > 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
> <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
> <http://trac.imagej.net/ticket/1100>
> and all its blocking tickets (those listed in "Blocked by").
>
>
> OK
>
>
> > 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/965>
> * http://trac.imagej.net/ticket/__1292
> <http://trac.imagej.net/ticket/1292>
>
>
> OK
>
>
> > 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?
>
>
> 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.
>
>
> > 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.
>
>
> OK
>
>
> > 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/8>
> https://github.com/imagej/__imagej-plugins-tools/issues/9
> <https://github.com/imagej/imagej-plugins-tools/issues/9>
>
>
> OK
>
>
> > 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.
>
>
> OK. It would be nice if the toolbar were easily customizable by the user
> 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.
>
>
> > 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.
>
>
> That's an absolutely essential feature for any microscopy work. I'll
> submit the bug report.
>
>
> > 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.
>
>
> OK. Understood.
>
>
> 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
> <https://github.com/scifio/scifio-bf-compat>) which is bundled
> with Fiji.
>
>
> 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.
>
>
> 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)
>
>
> Sounds good.
>
>
>
> 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
>
>
> 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.
>
>
> * Further reading: http://dev.imagej.net/__rationale
> <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/
> <http://icy.bioimageanalysis.org/>).
>
>
> I agree
>
>
>
> > 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.
>
>
> 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.
>
>
> > (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
> <http://trac.imagej.net/milestone/imagej2-b11-docs>
>
>
> OK.
>
>
> > 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/gz7cgytSRuA/emlJLp8o7XYJ>
> *
> https://groups.google.com/d/__msg/imagejx/_yaczl4UWK4/___w6dCnGcJ1QJ
> <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/lD4s32M5als/HZiEA02LhXsJ>
> *
> https://groups.google.com/d/__msg/imagejx/ox2ooizORA4/__scMd4P0cRZAJ
> <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/F3gWc_Ndz_U/UTKiut-HuQMJ>
> *
> https://groups.google.com/d/__msg/imagejx/79rryiWqFno/Ne--__gMjkSX8J
> <https://groups.google.com/d/msg/imagejx/79rryiWqFno/Ne--gMjkSX8J>
> *
> https://groups.google.com/d/__msg/imagejx/pL6ipxHkAk8/__26u5MF41YGsJ
> <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
> <http://trac.imagej.net/ticket/9>
> * Separation of concerns (complete):
> http://trac.imagej.net/ticket/__10
> <http://trac.imagej.net/ticket/10>
> * Better plugin framework (complete):
> http://trac.imagej.net/ticket/__11
> <http://trac.imagej.net/ticket/11>
> * Better scripting (complete):
> http://trac.imagej.net/ticket/__12
> <http://trac.imagej.net/ticket/12>
> * Better event handling (complete):
> http://trac.imagej.net/ticket/__14
> <http://trac.imagej.net/ticket/14>
> * N-dimensional images (complete):
> http://trac.imagej.net/ticket/__17
> <http://trac.imagej.net/ticket/17>
> * Very large image data (complete):
> http://trac.imagej.net/ticket/__20
> <http://trac.imagej.net/ticket/20>
> * CellProfiler interoperability (complete):
> http://trac.imagej.net/ticket/__1002
> <http://trac.imagej.net/ticket/1002>
> * KNIME interoperability (complete):
> http://trac.imagej.net/ticket/__1004
> <http://trac.imagej.net/ticket/1004>
> * OMERO interoperability: http://trac.imagej.net/ticket/__1003
> <http://trac.imagej.net/ticket/1003>
> * Very large image planes: http://trac.imagej.net/ticket/__19
> <http://trac.imagej.net/ticket/19>
> * Better undo/redo: http://trac.imagej.net/ticket/__13
> <http://trac.imagej.net/ticket/13>
>
>
> Absolutely a killer feature, but I am guessing difficult to
> implement in a plugin-based framework.
>
>
> * Coordinate systems: http://trac.imagej.net/ticket/__40
> <http://trac.imagej.net/ticket/40>
> * Metadata: http://trac.imagej.net/ticket/__8
> <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.
>
>
> 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/__PowerPoint/Word) or analyze the data
> (Excel/R/Statistica). Right now I spend half my time fishing for the
> right image/dialog/button.
>
>
>
> > 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
> <http://wiki.imagej.net/Update_Sites>.
>
>
> Sounds good. I'll give it a stab.
>
>
>
> > 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?
>
>
> 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.
>
>
>
> > 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.
>
>
> Got it.
>
>
> Regards,
> Curtis
>
>
> Regards,
>
> Pawel
>
> --
> Paweł Niewiadomski
> e-mail: pawelthebiologist at gmail.com <mailto:pawelthebiologist at gmail.com>
> website: www.pawelthebiologist.com <http://www.pawelthebiologist.com>
>
>
--
Paweł Niewiadomski
e-mail: pawelthebiologist at gmail.com
website: www.pawelthebiologist.com
More information about the ImageJ-devel
mailing list