<div dir="ltr">Hi Pawel,<div><br></div><div><div><div>> I decided to start work on the project by playing around with the</div><div>> ImageJ2 interface in some routine tasks I usually do in ImageJ. After</div><div>> having done some extensive testing, I just wanted to give you some,</div>
<div>> hopefully constructive, input. I don't want to sound too negative, but</div><div>> I really think that June 1st is a bit early to be releasing a</div><div>> production version of ImageJ2.</div></div><div>
<br></div><div>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.</div>
<div><br></div><div>See this blog post for details:</div><div><a href="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</a></div>
<div><br></div><div>ImageJ 2.0.0 will be fundamentally the same as ImageJ1, but:</div><div><br></div><div>* Will be bundled with the Updater component which supports ImageJ update sites and automatic update checking.</div>
<div><br></div><div>* Will be bundled with the native ImageJ Launcher with quite a few nice command line features.</div><div><br></div><div>* Will be bundled with the ImageJ Script Editor including support for several scripting languages.</div>
<div><br></div><div>* 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.</div>
<div><br></div><div><div>* 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.</div>
<div><br></div></div><div>* 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:</div>
<div> - imagej-common: The ImgLib2-based image data model and core</div><div> - imagej-ops: A framework for reusable algorithms; see <a href="http://developer.imagej.net/2014/04/04/announcing-imagej-ops">http://developer.imagej.net/2014/04/04/announcing-imagej-ops</a><br>
</div><div><div> - imagej-ui-swing: The "pure ImageJ2" Swing user interface</div><div> - imagej-plugins-*, scijava-plugins-*: Core plugins for ImageJ2 including many commands</div></div><div><br></div><div>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.</div>
<div><br></div><div><div>> Please don't take it the wrong way - I am in the process of analysing</div><div>> the codebase and I think it is a real software engineering feat.</div></div></div><div><br></div><div>
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 (<a href="https://github.com/scijava/scijava-common">https://github.com/scijava/scijava-common</a>).</div>
<div><br></div><div>Because ImageJ2 consists of several pieces at various stages of development, it needs to migrate out of beta piece by piece.</div><div><br></div><div><div><div>> It shows that there has been really serious thought put into</div>
<div>> architerctural design. However, at this point, and I am saying that as</div><div>> a daily ImageJ user, the architectural brilliance is not showing on</div><div>> the surface.</div></div></div><div><br></div>
<div>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.</div><div>
<br></div><div><div><div>> I am going to submit some bug reports in a few days, but basically the</div><div>> interface is highly unpredictable and in many ways incompatible with</div><div>> ImageJ1.</div><div><br>
</div></div></div><div>Indeed. Please note that there are many bugs about such problems already logged in the ImageJ Trac: <a href="http://trac.imagej.net/">http://trac.imagej.net/</a>. 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.</div>
<div><br></div><div><div>> Let me just point to a few basic things before I submit detailed bug</div><div>> reports:</div><div>></div><div>> 1. The brightness/contrast dialog sometimes sticks around when you</div>
<div>> open a new image and close the old one - you end up with multiple</div><div>> brightness/contrast dialogs and a single image. Moreover, I've had the</div><div>> dialog stay open even after I closed the application.</div>
</div><div><br></div><div>The IJ2 version of B&C has been the subject of frequent debate. In short, it needs a lot more work. See <a href="http://trac.imagej.net/ticket/1100">http://trac.imagej.net/ticket/1100</a> and all its blocking tickets (those listed in "Blocked by").</div>
<div><br></div><div><div>> 2. The color picker behavior is hectic and I couldn't figure out how</div><div>> and why it randomly changes color. Especially in 16-bit per channel</div><div>> images it is totally unpredictable.</div>
<div>></div><div><div>> 3. With 48-bit 16-bit per channel composite images the drawing command</div><div>> with the white color selected basically draws random grey colors.</div></div><div><br></div><div>IJ2's current approach to foreground and background "colors" differs from IJ1. And there are likely bugs, too.</div>
<div>* <a href="http://trac.imagej.net/ticket/965">http://trac.imagej.net/ticket/965</a></div><div>* <a href="http://trac.imagej.net/ticket/1292">http://trac.imagej.net/ticket/1292</a></div><div><br></div><div>> 4. The interface is extremely slow to the point of being unusable for</div>
<div>> things like looking through time-course stacks or stacks of</div><div>> medium-sized multicolor images.</div><div><br></div><div>That is not a problem we have noticed, unless image planes become very large. How large are your image planes? >2Kx2K?</div>
<div><br></div><div>> 5. Shape selection keeps old selections after you make a new one,</div><div>> which is inconsistent with ImageJ1 behavior and quite maddening for</div><div>> someone who is used to it.</div>
<div><br></div><div>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.</div>
<div><br></div><div>> 6. Missing magic wand and text tool functionality.</div><div><br></div><div><a href="https://github.com/imagej/imagej-plugins-tools/issues/8">https://github.com/imagej/imagej-plugins-tools/issues/8</a><br>
</div><div><a href="https://github.com/imagej/imagej-plugins-tools/issues/9">https://github.com/imagej/imagej-plugins-tools/issues/9</a><br></div><div><br></div><div>> 7. Missing custom toolbars.</div><div><br></div><div>
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.</div>
<div><br></div><div>> 8. In multicolor images there seems to be no way of adjusting</div><div>> brightness/contrast of each channel individually.</div><div><br></div><div>Hmm, you're right. This might be a relatively new bug.</div>
<div><br></div><div>> 9. LIF format import doesn't work - it doesn't present the usual</div><div>> BioFormats dialog and instead just imports the first image in the</div><div>> series with some random channel separation.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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 (<a href="https://github.com/scifio/scifio-bf-compat">https://github.com/scifio/scifio-bf-compat</a>) which is bundled with Fiji.</div>
<div><br></div><div>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.</div><div><br></div><div>
> This is just a sample, but there is a bunch more. My prediction is</div><div>> that the users will not migrate to the new version if you ship it as</div><div>> is. They frankly need a reason to migrate and ImageJ2 is not offering</div>
<div>> them any.</div><div><br></div><div>Agreed; "regular users" should not be switching to the new interface yet. There are too many bugs and not enough advantages.</div><div><br></div><div>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:</div>
<div> * the ImageJ Updater</div><div> * the Script Editor</div><div> * 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<br>
</div><div><div> * new developer-facing APIs (esp.,parameterized modules)<br></div><div><br></div></div><div>There are downsides though:</div><div> * IJ1 UI is limited to XYZCT (though we may later patch in support for additional dimensions)</div>
<div> * IJ1 UI cannot handle tiled huge image planes (a feature planned for the IJ2 UI)</div><div> * Lack of separation of concerns; IJ1 UI is fundamentally tied to the IJ1 data model</div><div> * Further reading: <a href="http://dev.imagej.net/rationale">http://dev.imagej.net/rationale</a>, <a href="http://dev.imagej.net/proposal">http://dev.imagej.net/proposal</a></div>
<div><br></div><div>> Right now ImageJ1 is a mature platform with few bugs and a plethora of</div><div>> mostly seamlessly working plugins.</div><div><br></div><div>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.</div>
<div><br></div><div>> The biggest gripe most users have with ImageJ1 is its antiquated UI</div><div><br></div><div>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 (<a href="http://icy.bioimageanalysis.org/">http://icy.bioimageanalysis.org/</a>).</div>
<div><br></div><div>> and I would wait with the release of the final version until you (we?)</div><div>> (1) have ironed out all the bugs and inconsistencies,</div><div><br></div><div>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.</div>
<div> </div><div>> (2) have good end-user documentation so they know how to do things the</div><div>> new way,</div><div><br></div><div>Indeed, we had a whole milestone dedicated to documentation in our original release plan:</div>
<div><a href="http://trac.imagej.net/milestone/imagej2-b11-docs">http://trac.imagej.net/milestone/imagej2-b11-docs</a></div><div><br></div><div>> and (3) have provided users with at least one "killer" feature that</div>
<div>> they have longed for.</div><div><br></div><div>Many such "killer" feature ideas were discussed on the ImageJX list when ImageJ2 was first launched:</div><div>* <a href="https://groups.google.com/d/msg/imagejx/gz7cgytSRuA/emlJLp8o7XYJ">https://groups.google.com/d/msg/imagejx/gz7cgytSRuA/emlJLp8o7XYJ</a></div>
<div>* <a href="https://groups.google.com/d/msg/imagejx/_yaczl4UWK4/_w6dCnGcJ1QJ">https://groups.google.com/d/msg/imagejx/_yaczl4UWK4/_w6dCnGcJ1QJ</a></div><div>* <a href="https://groups.google.com/d/msg/imagejx/lD4s32M5als/HZiEA02LhXsJ">https://groups.google.com/d/msg/imagejx/lD4s32M5als/HZiEA02LhXsJ</a></div>
<div>* <a href="https://groups.google.com/d/msg/imagejx/ox2ooizORA4/scMd4P0cRZAJ">https://groups.google.com/d/msg/imagejx/ox2ooizORA4/scMd4P0cRZAJ</a></div><div>* <a href="https://groups.google.com/d/msg/imagejx/F3gWc_Ndz_U/UTKiut-HuQMJ">https://groups.google.com/d/msg/imagejx/F3gWc_Ndz_U/UTKiut-HuQMJ</a></div>
<div>* <a href="https://groups.google.com/d/msg/imagejx/79rryiWqFno/Ne--gMjkSX8J">https://groups.google.com/d/msg/imagejx/79rryiWqFno/Ne--gMjkSX8J</a></div><div>* <a href="https://groups.google.com/d/msg/imagejx/pL6ipxHkAk8/26u5MF41YGsJ">https://groups.google.com/d/msg/imagejx/pL6ipxHkAk8/26u5MF41YGsJ</a></div>
<div><br></div><div>There are many others in the issue tracker:</div><div>* Coherent I/O (complete): <a href="http://trac.imagej.net/ticket/9">http://trac.imagej.net/ticket/9</a></div><div>* Separation of concerns (complete): <a href="http://trac.imagej.net/ticket/10">http://trac.imagej.net/ticket/10</a></div>
<div>* Better plugin framework (complete): <a href="http://trac.imagej.net/ticket/11">http://trac.imagej.net/ticket/11</a></div><div>* Better scripting (complete): <a href="http://trac.imagej.net/ticket/12">http://trac.imagej.net/ticket/12</a></div>
<div>* Better event handling (complete): <a href="http://trac.imagej.net/ticket/14">http://trac.imagej.net/ticket/14</a></div><div>* N-dimensional images (complete): <a href="http://trac.imagej.net/ticket/17">http://trac.imagej.net/ticket/17</a></div>
<div>* Very large image data (complete): <a href="http://trac.imagej.net/ticket/20">http://trac.imagej.net/ticket/20</a></div><div>* CellProfiler interoperability (complete): <a href="http://trac.imagej.net/ticket/1002">http://trac.imagej.net/ticket/1002</a></div>
<div>* KNIME interoperability (complete): <a href="http://trac.imagej.net/ticket/1004">http://trac.imagej.net/ticket/1004</a></div><div>* OMERO interoperability: <a href="http://trac.imagej.net/ticket/1003">http://trac.imagej.net/ticket/1003</a></div>
<div>* Very large image planes: <a href="http://trac.imagej.net/ticket/19">http://trac.imagej.net/ticket/19</a></div><div>* Better undo/redo: <a href="http://trac.imagej.net/ticket/13">http://trac.imagej.net/ticket/13</a></div>
<div>* Coordinate systems: <a href="http://trac.imagej.net/ticket/40">http://trac.imagej.net/ticket/40</a></div><div>* Metadata: <a href="http://trac.imagej.net/ticket/8">http://trac.imagej.net/ticket/8</a></div><div><br>
</div><div>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.</div><div><br></div><div>> I think there is one thing that can be done in terms of point (3) that</div>
<div>> will make many users happy is a "pin" button in each image</div><div>> window/dialog. If the "pin" is activated then the window/dialog will</div><div>> be brought to the foreground every time the user brings any other</div>
<div>> "pinned" window or the main imagej bar to the foreground. This solves</div><div>> the perrenial usability problem of ImageJ1 where if you have multiple</div><div>> images open, you have to hunt for the right image, then hunt for the</div>
<div>> brightness/contrast dialog, then hunt for the channels dialog in the</div><div>> taskbar/dock.</div><div><br></div><div>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.</div>
<div><br></div><div>> I don't think this should be a difficult feature to implement and I</div><div>> can try to do that, but I will need time to plow through the codebase</div><div>> and take it all in. </div>
<div><br></div><div>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 <a href="http://wiki.imagej.net/Update_Sites">http://wiki.imagej.net/Update_Sites</a>.</div>
<div><br></div><div>> I hope that my comments will help with the development. I am hoping to</div><div>> contribute to the actual work soon.</div><div><br></div><div>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?</div>
<div><br></div><div>> Please let me know your thoughts. Also, I thought that I might want to</div><div>> send these comments to you personally rather than to the ImageJ-devel</div><div>> list, since I don't want to step on anyones toes. I imagine there is</div>
<div>> more to your decision to ship on June 1st than just software</div><div>> excellence - things like funding, publications, etc. Please feel free</div><div>> to forward my letter to the imagej-devel list if you think this will</div>
<div>> be constructive.</div></div><div><br></div><div>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.</div>
<div><br></div><div>Regards,</div><div>Curtis</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, May 12, 2014 at 3:57 PM, 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>
I decided to start work on the project by playing around with the ImageJ2 interface in some routine tasks I usually do in ImageJ. After having done some extensive testing, I just wanted to give you some, hopefully constructive, input. I don't want to sound too negative, but I really think that June 1st is a bit early to be releasing a production version of ImageJ2. Please don't take it the wrong way - I am in the process of analysing the codebase and I think it is a real software engineering feat. It shows that there has been really serious thought put into architerctural design. However, at this point, and I am saying that as a daily ImageJ user, the architectural brilliance is not showing on the surface. I am going to submit some bug reports in a few days, but basically the interface is highly unpredictable and in many ways incompatible with ImageJ1. Let me just point to a few basic things before I submit detailed bug reports:<br>
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.<br>
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.<br>
3. With 48-bit 16-bit per channel composite images the drawing command with the white color selected basically draws random grey colors.<br>
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.<br>
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.<br>
6. Missing magic wand and text tool functionality.<br>
7. Missing custom toolbars.<br>
8. In multicolor images there seems to be no way of adjusting brightness/contrast of each channel individually.<br>
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.<br>
This is just a sample, but there is a bunch more. My prediction is that the users will not migrate to the new version if you ship it as is. They frankly need a reason to migrate and ImageJ2 is not offering them any. Right now ImageJ1 is a mature platform with few bugs and a plethora of mostly seamlessly working plugins. The biggest gripe most users have with ImageJ1 is its antiquated UI and I would wait with the release of the final version until you (we?) (1) have ironed out all the bugs and inconsistencies, (2) have good end-user documentation so they know how to do things the new way, and (3) have provided users with at least one "killer" feature that they have longed for. I think there is one thing that can be done in terms of point (3) that will make many users happy is a "pin" button in each image window/dialog. If the "pin" is activated then the window/dialog will be brought to the foreground every time the user brings any other "pinned" window or the main imagej bar to the foreground. This solves the perrenial usability problem of ImageJ1 where if you have multiple images open, you have to hunt for the right image, then hunt for the brightness/contrast dialog, then hunt for the channels dialog in the taskbar/dock. I don't think this should be a difficult feature to implement and I can try to do that, but I will need time to plow through the codebase and take it all in. I hope that my comments will help with the development. I am hoping to contribute to the actual work soon. Please let me know your thoughts. Also, I thought that I might want to send these comments to you personally rather than to the ImageJ-devel list, since I don't want to step on anyones toes. I imagine there is more to your decision to ship on June 1st than just software excellence - things like funding, publications, etc. Please feel free to forward my letter to the imagej-devel list if you think this will be constructive.<br>
<br>
Best regards,<br>
Pawel<div class=""><br>
<br>
On 2014-05-06 11:17 PM, Curtis Rueden wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Pawel,<br>
<br><div><div class="h5">
> I am really glad you are open to collaboration. Like you said, there<br>
> is definitely a learning curve, so I will try to get acquainted with<br>
> the current codebase and drop in on #imagejdev for questions.<br>
<br>
Sounds good.<br>
<br>
> I am happy to work on documentation while I am getting up to speed<br>
> with the code.<br>
<br>
Great, that would be really helpful.<br>
<br>
> Most of my itches are actually GUI-related, but from what I've<br>
> gathered you are not planning to initially change the GUI much from<br>
> what it was in 1.x for compatibility reasons. Maybe once I understand<br>
> the code structure a little better, I can help with work on the Swing,<br>
> AWT, or RCP GUIs for the later releases. I'll be keeping in touch.<br>
<br>
Right, there are two very different modes: the ImageJ 1.x user<br>
interface, and the ImageJ 2.x Swing UI. The latter is (at the moment)<br>
designed to function much like the former, although we will probably<br>
diverge more from ImageJ 1.x's design in the future.<br>
<br>
To facilitate total backwards compatibility, as well as to accommodate<br>
Wayne Rasband's continued development of ImageJ 1.x, we are now opting<br>
to release ImageJ 2.0.0 running with the 1.x UI by default. You can<br>
still switch to the ImageJ2 UI using Help > Switch to Modern Mode, but<br>
it has more limitations compatibility-wise.<br>
<br>
I would encourage you to discuss your UI ideas and requirements on<br>
imagej-devel or in the #imagejdev IRC channel (i.e., somewhere public).<br>
That way we can stay on the same page about what things are possible and<br>
warranted within each user interface.<br>
<br>
I look forward to hearing more from you!<br>
<br>
Regards,<br>
Curtis<br>
<br>
<br>
On Tue, May 6, 2014 at 3:35 PM, Pawel Niewiadomski<br></div></div><div class="">
<<a href="mailto:pawelthebiologist@gmail.com" target="_blank">pawelthebiologist@gmail.com</a> <mailto:<a href="mailto:pawelthebiologist@gmail.com" target="_blank">pawelthebiologist@<u></u>gmail.com</a>>> wrote:<br>
<br>
Hi Curtis,<br>
<br></div><div><div class="h5">
I am really glad you are open to collaboration. Like you said, there<br>
is definitely a learning curve, so I will try to get acquainted with<br>
the current codebase and drop in on #imagejdev for questions. I am<br>
happy to work on documentation while I am getting up to speed with<br>
the code. Most of my itches are actually GUI-related, but from what<br>
I've gathered you are not planning to initially change the GUI much<br>
from what it was in 1.x for compatibility reasons. Maybe once I<br>
understand the code structure a little better, I can help with work<br>
on the Swing, AWT, or RCP GUIs for the later releases. I'll be<br>
keeping in touch.<br>
<br>
Regards,<br>
Pawel<br>
<br>
<br>
On 2014-05-06 6:29 PM, Curtis Rueden wrote:<br>
<br>
Hi Pawel,<br>
<br>
Thanks very much for your interest in the ImageJ project! I'm<br>
CCing the<br>
imagej-devel mailing list, since that is the best place to discuss<br>
ImageJ2 core development.<br>
<br>
> ImageJ is one of my all-time favorite pieces of software and<br>
I would<br>
> like to contribute to its development. I have a decent<br>
knowledge of<br>
> Java, but I haven't really worked on an open source project<br>
before. I<br>
> saw that the list of contributors on the ImageJ github page<br>
is pretty<br>
> limited and so I am wondering if you generally like outside<br>
people<br>
> contributing to the codebase or whether you prefer to keep<br>
it within<br>
> the core development team.<br>
<br>
One of the major goals of ImageJ2 is to support a more<br>
community-oriented group of developers. Requests like yours are<br>
surprisingly rare because most people do not have a lot of free<br>
time to<br>
contribute to projects like ImageJ. But your help would<br>
definitely be<br>
most welcome.<br>
<br>
> If you welcome new devs, what features/bugfixes do you think<br>
are most<br>
> critical at the moment?<br>
<br>
I would encourage you to first "scratch your own itches" [1].<br>
You can<br>
get started right away: fork the relevant project(s) from<br>
<a href="https://github.com/imagej" target="_blank">https://github.com/imagej</a> and <a href="https://github.com/scijava" target="_blank">https://github.com/scijava</a>, push<br>
changes<br>
to topic branches, and file pull requests [2]. (And if you need an<br>
introduction to Git: <a href="https://try.github.io/" target="_blank">https://try.github.io/</a>).<br>
<br>
If you really don't have any itches and just want to fix bugs,<br>
that's a<br>
bit trickier at the moment, since you would need to become more<br>
acquainted with the ImageJ2 project structure -- and it is still<br>
in beta<br>
and documentation is scarce in many places.<br>
<br>
It might make the most sense for you to jump into the ImageJ<br>
chat room<br>
(#imagejdev) on IRC freenode during U.S. business hours and chat<br>
with us<br>
at more length. One way you could start helping the project<br>
right away<br>
would be transform any information you learn there into wiki<br>
pages on<br>
the ImageJ wiki (<a href="http://wiki.imagej.net/" target="_blank">http://wiki.imagej.net/</a>).<br>
<br>
We are gearing up for an initial release of ImageJ 2.0.0 (finally<br>
leaving beta!) on June 1, so your timing is hectic, but also really<br>
fantastic to help improve the project documentation and learn the<br>
system, so that you can embark on more involved coding endeavors.<br>
<br>
Regards,<br>
Curtis<br>
<br>
[1]<br></div></div>
<a href="https://gettingreal.37signals." target="_blank">https://gettingreal.37signals.</a><u></u>__com/ch02_Whats_Your_Problem.<u></u>__php <<a href="https://gettingreal.37signals.com/ch02_Whats_Your_Problem.php" target="_blank">https://gettingreal.<u></u>37signals.com/ch02_Whats_Your_<u></u>Problem.php</a>><br>
[2] <a href="https://help.github.com/__articles/using-pull-requests" target="_blank">https://help.github.com/__<u></u>articles/using-pull-requests</a><div class=""><br>
<<a href="https://help.github.com/articles/using-pull-requests" target="_blank">https://help.github.com/<u></u>articles/using-pull-requests</a>><br>
<br>
<br>
<br>
On Wed, Apr 30, 2014 at 12:36 PM, Pawel Niewiadomski<br>
<<a href="mailto:pawelthebiologist@gmail.com" target="_blank">pawelthebiologist@gmail.com</a><br>
<mailto:<a href="mailto:pawelthebiologist@gmail.com" target="_blank">pawelthebiologist@<u></u>gmail.com</a>><br></div>
<mailto:<a href="mailto:pawelthebiologist@" target="_blank">pawelthebiologist@</a>__<a href="http://gmail.com" target="_blank">gm<u></u>ail.com</a><div><div class="h5"><br>
<mailto:<a href="mailto:pawelthebiologist@gmail.com" target="_blank">pawelthebiologist@<u></u>gmail.com</a>>>> wrote:<br>
<br>
Hi Curtis,<br>
<br>
I am a postdoc in molecular biology, who has recently<br>
started to<br>
seriously work on improving my coding skills. ImageJ is one<br>
of my<br>
all-time favorite pieces of software and I would like to<br>
contribute<br>
to its development. I have a decent knowledge of Java, but<br>
I haven't<br>
really worked on an open source project before. I saw that<br>
the list<br>
of contributors on the ImageJ github page is pretty limited<br>
and so I<br>
am wondering if you generally like outside people<br>
contributing to<br>
the codebase or whether you prefer to keep it within the core<br>
development team. If you welcome new devs, what<br>
features/bugfixes do<br>
you think are most critical at the moment?<br>
<br>
Thanks,<br>
Pawel<br>
<br>
--<br>
Paweł Niewiadomski<br>
e-mail: <a href="mailto:pawelthebiologist@gmail.com" target="_blank">pawelthebiologist@gmail.com</a><br>
<mailto:<a href="mailto:pawelthebiologist@gmail.com" target="_blank">pawelthebiologist@<u></u>gmail.com</a>><br></div></div>
<mailto:<a href="mailto:pawelthebiologist@" target="_blank">pawelthebiologist@</a>__<a href="http://gmail.com" target="_blank">gm<u></u>ail.com</a><div class=""><br>
<mailto:<a href="mailto:pawelthebiologist@gmail.com" target="_blank">pawelthebiologist@<u></u>gmail.com</a>>><br>
website: <a href="http://www.pawelthebiologist.com" target="_blank">www.pawelthebiologist.com</a><br>
<<a href="http://www.pawelthebiologist.com" target="_blank">http://www.pawelthebiologist.<u></u>com</a>><br></div>
<<a href="http://www.pawelthebiologist." target="_blank">http://www.pawelthebiologist.</a><u></u>__com<div class=""><br>
<<a href="http://www.pawelthebiologist.com" target="_blank">http://www.pawelthebiologist.<u></u>com</a>>><br>
<br>
<br>
<br>
--<br>
Paweł Niewiadomski<br>
e-mail: <a href="mailto:pawelthebiologist@gmail.com" target="_blank">pawelthebiologist@gmail.com</a> <mailto:<a href="mailto:pawelthebiologist@gmail.com" target="_blank">pawelthebiologist@<u></u>gmail.com</a>><br>
website: <a href="http://www.pawelthebiologist.com" target="_blank">www.pawelthebiologist.com</a> <<a href="http://www.pawelthebiologist.com" target="_blank">http://www.pawelthebiologist.<u></u>com</a>><br>
<br>
<br>
</div></blockquote><div class="HOEnZb"><div class="h5">
<br>
-- <br>
Paweł Niewiadomski<br>
e-mail: <a href="mailto:pawelthebiologist@gmail.com" target="_blank">pawelthebiologist@gmail.com</a><br>
website: <a href="http://www.pawelthebiologist.com" target="_blank">www.pawelthebiologist.com</a><br>
</div></div></blockquote></div><br></div>