Fiji

Today the ImageJDev team is releasing the fourth beta of ImageJ2, version 2.0.0-beta4. ImageJ 2.0.0-beta4 is a "beta"-quality release, meaning the code is not finished. The design is more stable than before but still subject to change until the final ... [More] 2.0.0 release. It is recommended that people continue to use ImageJ 1.x for critical work. Download from the ImageJ2 development releases page. The ImageJ2 user interface is modeled after ImageJ v1.x as much as possible. However, under the hood, ImageJ2 is a complete redesign of ImageJ. It provides backward compatibility with older versions of ImageJ by bundling the latest v1.x code and translating between "legacy" and "modern" image structures. Contents 1 What's new 1.1 Application level changes 1.2 Architecture changes 1.3 Launcher and Updater changes 1.4 SLIM Plugin 1.5 Tutorials for developers 1.6 Compatibility 2 Known bugs 3 Roadmap and future directions 4 Thanks What's new The improved Duplicate command Development of this release of ImageJ focused heavily on the plugin architecture and various plugin implementations. There were also numerous architecture changes to make ImageJ more flexible, powerful, and backwards compatible. To accommodate this, changes were made to the plugin class hierarchy, the user interface classes, the legacy layer, the updater, the launcher, and in many other areas. Application level changes The Select View, Select Overlays, and Deselect Overlays commands have been added to replace the Select All and Select None commands from ImageJ 1.x. The Capture Screen and Capture Image commands have been implemented. The Duplicate command can subsample an image along any axis. The type changing plugin (Image > Type > ...) respects the color mode of the current display (grayscale, color, composite) which is configurable via the Image > Color > Channels Tool command. The Salt and Pepper plugin now works better with data other than 8-bit. Salt value and pepper value can each be specified. The Process > Math > Equation language has been enhanced to be more powerful. The full capabilities are documented on the ImageJ2/Documentation/Process/Math/Equation page. There is now support for composite overlays (i.e. this works now: Edit > Selection > Make Inverse). Architecture changes We made many changes and improvements to the plugin hierarchy. It is now much more complete and consistent. We have renamed several parts of the plugin hierarchy to improve and clarify the codebase. In particular, runnable plugins are now called commands. The term "command" is familiar to users of ImageJ 1.x, the only difference being that in ImageJ 1.x, a "plugin" can implement multiple "commands"; however, in ImageJ2 each command was already expressed as a separate class, so the distinction has been dropped. The term "plugin" is now a more general one referring to any new piece of functionality added on to ImageJ: every extension point in the codebase is now a subtype of ImageJPlugin. This means that every type of feature you might want to add on top of ImageJ is done as a particular sort of plugin. ImageJ plugins take many forms, but all of them are automatically discovered at runtime in the same way, and accessible via the plugin service. Several tools utilize the JHotDraw library for rendering and user interaction. However, they were coded as non-plugin extension points. We have remedied that, so adding additional JHotDraw-specific functionality is now a matter of writing a JHotDrawAdapter plugin. There is also now a JHotDraw service for managing these adapters, rather than ad hoc embedded logic. In previous releases, there were a fixed number of supported input widgets for harvesting user input with respect to command input values. We have eliminated this restriction, such that it is now possible to create a widget plugin for any input type of a command, beyond those that the core provides (numbers, strings & chars, booleans, files, colors and multiple-choice object selectors). For example, you could create an input widget with a two-headed slider for min/max range of values, a trinary toggle box, a color lookup table editor, or a CAPTCHA challenge to combat spam submissions. Support for multiple UIs has been improved. The UI service now has a better API for managing UIs, launching multiple UIs, etc. And the widget and display frameworks have been improved such that even if multiple UIs are available, input dialogs, widgets and displays will appear in the correct UI's paradigm. There is now a direct API in place for calling commands programmatically in a type-safe fashion. The uploader mechanism is now much better encapsulated and makes it very easy to add components that handle protocols other than ssh and sftp. ImageJ2 exposes functionality in reusable services. New services were added this cycle including the ConsoleService, the RenderingService, the SamplerService, and the ScreenCaptureService. Support for images with 16-bit palettes has been added. These include microscopy images in the Olympus .oif and Leica .lif formats, which may have 16-bit gray or color ramp palettes. When displayed, the 16-bit colors are truncated down to 8 bits per channel. Multiple simultaneous UIs Launcher and Updater changes The Fiji Updater was fully moved to ImageJ. The Fiji Updater is now only a small component which relies on ImageJ's Updater to modify the current installation. Many bug fixes were made with regards to the handling of versioned file names. The Updater now understands that ij.jar and ij-1.47b.jar are really just two different versions of the same component. Many bugs have been fixed with regards to multiple update sites. Of note a rather serious bug was fixed which prevented the moving of files from one update site to another. Many internal changes were made that make ongoing maintenance and automatic regression testing easier. The process by which the Updater updates itself now includes all related files (including the front-end, and not just the core). SLIM Plugin The SLIM Plugin is still available for ImageJ 1.x only but is now of usable beta quality. It will migrate to ImageJ2 for the final ImageJ 2.0.0 release. See the SLIM Plugin web site for details. Tutorials for developers We have begun work on some programming examples for developers. The tutorials are available in the imagej-tutorials project on GitHub. A dataset with a 16-bit LUT Compatibility There have been numerous compatibility improvements and bug fixes. Since beta3 the team has closed over 115 issues and made progress on many more. Some of them include: Improved support for many commands: 3D Project, Clear, Clear Outside, Image Bin, Image Properties, Image Rotate, Selection Cut, Selection Enlarge, Stack Combine, Stack Insert, and Stack To Images. Data translation accuracy improved in the legacy compatibility layer. Image display creation/destruction more closely mirrors ImageJ 1.x behavior. Color support improved when invoking legacy plugins. There is now a set of compatibility options (set in the Edit > Options > Compatibility dialog). Some commands have an ImageJ 1.x compatibility mode setting. Information about this setting can be found on the ImageJ2/Documentation/Edit/Options/Compatibility page. Legacy plugins which produced composite ROIs are supported now. See this report for a high-level list of features completed for the 2.0.0-beta4 release. Known bugs Many legacy ImageJ plugins and macros work; many others do not. There are still many bugs. In particular, there are a few issues specifically regarding 2.0.0-beta4: There is a spurious grayed-out polygon tool on the tool bar, next to the real polygon tool [see #1470]. If you execute many legacy plugins very quickly, there may be bugs relating to timing issues [see #1471]. Due to bugs in the Updater (which have since been fixed), it is not possible to update from a beta3 installation. Please download the 2.0.0-beta4 distribution bundle instead. And the following bugs still remain from previous betas: The data coordinate system is off by one pixel, which causes the pixel probe and drawing tool coordinates to be slightly misaligned [see #716 and #1190]. Image windows sometimes leave space for nonexistent sliders [see #1060]. Image windows don't always load at the optimal scale [see #1472]. A few other minor zoom issues [see #1326]. IJ1 commands that have preview capabilities are not fully functional. In general their final results are correct. Going forward the preview capabilities will be restored by porting them to IJ2's GUI model [see #981]. Lastly, please note that it is still the case on Windows & Linux that you must have Java already installed; ImageJ2 is not bundled with Java, nor will it download it for you. See the list of Open Features for a high-level list of planned features and bugfixes. Roadmap and future directions We make a substantial effort to document the work we are doing, and what needs to be done, to deliver a powerful and full-featured ImageJ2. All tasks are tracked by our Trac issue tracking system, which you can review in several ways: Roadmap - Top level overview of future releases, including progress toward each release Open Features - A high-level list of features slated for each future release All Open Tickets - A complete list of known bugs You can also perform custom queries to further refine the results, if there are particular parts of the development that interest you. Thanks Thanks for your interest in ImageJ2! Please give it a try, and feel free to report any bugs you find! [Less]

Today the ImageJDev team is releasing the fifth beta of ImageJ2, version 2.0.0-beta5. ImageJ 2.0.0-beta5 is a "beta"-quality release, meaning the code is not finished. The design is more stable than before but still subject to change until the final ... [More] 2.0.0 release. It is recommended that people continue to use ImageJ 1.x for critical work. Download from the ImageJ2 development releases page. The ImageJ2 user interface is modeled after ImageJ v1.x as much as possible. However, under the hood, ImageJ2 is a complete redesign of ImageJ. It provides backward compatibility with older versions of ImageJ by bundling the latest v1.x code and translating between "legacy" and "modern" image structures. Contents 1 What's new 1.1 Application level changes 1.2 Architecture changes 1.3 Improved help 1.4 Examples for developers 1.5 Compatibility 1.6 Updater changes 1.7 SLIM Plugin 1.8 Features 2 Known bugs 3 Roadmap and future directions 4 Thanks What's new Development of this release of ImageJ focused on the addition of scripting support. The release was timed to coincide with the ImageJ conference in Luxembourg, to ensure participants have access to a recent, stable codebase. Since the development cycle for this beta was shorter than many of our previous cycles, there are fewer new major features. But we have made substantial progress on some big ticket items (such as multi-step undo and redo) that will be part of the next beta release. Application level changes Written and executed from the Script Editor! New script editor! This is the artist formerly known as the Fiji Script Editor, much refurbished and with a shiny new rewrite of the scripting infrastructure. It even comes with basic support for Maven projects. [commit] There is now a Noise Reduction menu that supports a few noise reduction methods. [code] The Command Finder now has a full set of sortable columns. [#1483] There is now a "Show LUT As Table" command. [commit] The current foreground and background colors are displayed on the toolbar. Creating grayscale images from multichannel data is now easier. Architecture changes Redesigned scripting framework. A scripting language is now a type of plugin, meaning anyone can create and register their own scripting language within ImageJ. [#12] Results tables. They can be declared as outputs of commands, and will be automatically displayed in a new table window. [#1250] Statistics service. The statistics service simplifies the measurement of statistics from a set of data. There is an example (see below) which shows how it can be used. [commit] Improvements to Imglib2 OPS. [#1511] Efficient Collections-based primitive array lists. The Java standard library does not have a performant way to wrap primitive types—such as int and double—in ArrayLists. We now have performant implementations of growable primitive-type arrays in imagej.util.IntArray and friends. These classes were added to support results tables, but their utility goes beyond just results tables. [commit] Better detection of the ImageJ base directory. This fixes a bug when using ImageJ2 from within KNIME. [commit] Better naming of displays. [commit] More consistent display viewer package hierarchies. [commit] Plugin index bugfixes. [commit] Improved help Some command dialogs now have Help buttons that load a wiki page describing the command. Such commands include the Overlay Manager, the ImageJ 1.x Compatibilty Mode options, the Process > Math > Equation command, and the PointSet Demo command. This kind of immediate help via the wiki will be utilized more going forward. Examples for developers We have continued to flesh out example code for developers. In this release there is an example of how to use the new StatisticsService, an example showing how plugin parameters are assigned, and an example in Imglib2 on how to use OPS to combine images. We have also added a new tutorial on creating a custom preprocessor plugin. Compatibility There have been numerous compatibility improvements and bug fixes. Since beta4 the team has closed over 50 issues and made progress on many more. For instance there is improved support for legacy commands such as: Surface Plot, Zoom In, Rename, and To RGB Stack. See the full list of beta 5 changes here. Updater changes There were some Fiji-specific changes; Fiji uses the ImageJ updater now, but does not provide an ImageJ context, hence a few improvements were necessary. robustness improvements (mainly for uploading). when uploading via SSH via a specified proxy fails, the updater tries SSH without a proxy. SLIM Plugin The SLIM Plugin is usable beta quality but still available for ImageJ 1.x only. It will migrate to ImageJ2 by the final ImageJ 2.0.0 release. For this last cycle the emphasis for SLIM Plugin was on fixing bugs and adding features to improve functionality and ease-of-use. See the SLIM Plugin web site for details. Features See this report for a high-level list of features completed for the 2.0.0-beta5 release. Known bugs Many legacy ImageJ plugins and macros work; many others do not. There are still many bugs. In particular, the following bugs still remain from previous betas: There is a spurious grayed-out polygon tool on the tool bar, next to the real polygon tool. #1470 If you execute many legacy plugins very quickly, there may be bugs relating to timing issues. #1471 The data coordinate system is off by one pixel, which causes the pixel probe and drawing tool coordinates to be slightly misaligned. #716 and #1190 Image windows sometimes leave space for nonexistent sliders. #1060 Image windows don't always load at the optimal scale. #1472 A few other minor zoom issues. #1326 IJ1 commands that have preview capabilities are not fully functional. In general their final results are correct. Going forward the preview capabilities will be restored by porting them to IJ2's GUI model. #981 Lastly, please note that it is still the case on Windows & Linux that you must have Java already installed; ImageJ2 is not bundled with Java, nor will it download it for you. See the list of Open Features for a high-level list of planned features and bugfixes. Roadmap and future directions We make a substantial effort to document the work we are doing, and what needs to be done, to deliver a powerful and full-featured ImageJ2. All tasks are tracked by our Trac issue tracking system, which you can review in several ways: Roadmap - Top level overview of future releases, including progress toward each release Open Features - A high-level list of features slated for each future release All Open Tickets - A complete list of known bugs You can also perform custom queries to further refine the results, if there are particular parts of the development that interest you. To more accurately reflect what is left to do, we have recently reestimated ImageJ2's release dates, and scheduled additional betas before the final 2.0.0 release. See the Downloads page for the updated release timeline. Thanks Thanks for your interest in ImageJ2! Please give it a try, and feel free to report any bugs you find! [Less]

We are happy to announce the first stable release version of the ImgLib2 core library! This release was a central goal of the recent hackathon at LOCI in Madison, during the week of October 13 - 17. The ImgLib2 core library is now available on Maven ... [More] Central, and the source code for all ImgLib2 projects is accessible on GitHub. Like the SciJava and ImageJ2 projects, ImgLib2 releases now follow the semantic versioning scheme. Also, the project and git repository structure has changed. The main imglib repository has been split into multiple repositories, named consistently with the artifact names and java package prefixes. Projects are now coupled using non-SNAPSHOT versions, in order to achieve reproducible builds. For further technical details on project structure, see the Architecture page. Before coming out of beta, we have made several last-minute changes to the code: All @Deprecated methods and classes have been removed. All metadata handling (formerly imglib2-meta subproject) is being moved into imagej-common. From ImgLib2 core, the classes AnnotatedSpace, AbstractAnnotatedSpace, and Axis were moved to imagej-common. The current ROI representation was not considered stable enough to be included in a release. The net.imglib2.roi and net.imglib2.labeling packages were moved to the new imglib2-roi subproject which will remain in beta for now. The net.imglib2.multithreading package was moved to imglib2-algorithm and deprecated. We merged work by Albert Cardona and Stephan Preibisch on "fractional" types. ImgLib2 NativeTypes map pixels into primitive arrays, where often the mapping is one-to-one. For example, an UnsignedByteType pixel maps into one byte of a primitive byte[] array. With fractional types this mapping maybe non-integral, for example Unsigned12BitType maps pixels into a long[] array, where each pixel occupies 12/64 longs. Superfluous generic parameters were removed from Projector<A,B> interface which is now only Projector. Projector implementations were fixed accordingly. Several classes were renamed or moved to more suitable places: Extended[Real]RandomAccessibleInterval moved to the net.imglib2.view package. RandomAccessibleOnRealRandomAccessible moved to the net.imglib2.view package. Binning moved to the net.imglib2.util package. The contents of package net.imglib2.collection (KDTree etc.) moved to the net.imglib2 package. net.imglib2.concatenate.Util was renamed to net.imglib2.concatenate.ConcatenateUtils. Bounded moved to the net.imglib2.outofbounds package. The class NearestNeighborInterpolator from package net.imglib2.interpolation.neighborsearch was renamed to NearestNeighborSearchInterpolator (to avoid confusion with the net.imglib2.interpolation.randomaccess.NearestNeighborInterpolator class). The Pair interface moved to the net.imglib2.util package. The net.imglib2.util.Util class was cleaned up: Methods getTypeFromRandomAccess() and getTypeFromRealRandomAccess() were removed. We considered them too dangerous because the RandomAccess may be pointing to invalid position. Unused methods setCoordinateRecursive() and getRecursiveCoordinates() were removed. Some variants of computeLength() and computeDistance() were removed. Use methods distance() and length() from net.imglib2.util.LinAlgHelpers instead. Methods computeMedian(), computeAverage(), etc. were renamed to median(), average(), etc. These unused classes were removed: IterableIntervalSubsetT Triple RealPositionableFloorPositionable RealPositionableRoundPositionable ImgTranslationAdapter Packages net.imglib2.img.constant and net.imglib2.sampler.special were removed (ConstantImg, ConstantRandomAccessible, etc). Similar functionality can now be achieved through the net.imglib2.util.ConstantUtils class and Views. All ImgLib2 subprojects have been adapted to these changes and released (in some cases as new beta versions). One thing still pending is to upload these new ImgLib2 releases to the ImageJ and Fiji update sites, making them available to users of ImageJ and Fiji. This change has been rather involved, since there is a lot of downstream code affected by the API changes. But we expect to make the new ImgLib2 available to users before the end of the calendar year. Stay tuned for further announcements! [Less]

A graph of progress during the hackathon. From Saturday, September 14, 2014 through Friday, September 19, 2014, LOCI in Madison hosted Christian Dietz and Brian Northan, two developers of ImageJ OPS, for an exciting hackathon. Christian Dietz is a ... [More] PhD student in computer science at the University of Konstanz and the lead developer of the KNIME Image Processing project; Brian Northan is a freelance contract research and development engineer specializing in scientific image and signal processing. Contents 1 Overview 2 Accomplishments 3 Progress and future directions 4 Future directions Overview ImageJ OPS is an extensible Java framework for algorithms, particularly image processing algorithms. OPS seeks to be a unifying library for scientific image processing. See the Motivation page on the OPS wiki for details. KNIME is an open source data analytics, reporting and integration platform, which integrates various components for machine learning and data mining through its modular data pipelining concept. The KNIME Image Processing extension, KNIP, provides nodes for working with images, and is built on the ImageJ OPS library. OPS makes it possible to execute the image processing algorithm in many contexts, including from within ImageJ itself, from OMERO, KNIME, CellProfiler and beyond. Accomplishments This hackathon focused on the ImageJ OPS library, adding support for key image processing operations, as well as improving the framework itself. Achievements from the hackathon include: Vastly improved thresholding code (#52) Improvements to the code generation mechanism (#42) Autogeneration of base op interfaces (e1e2d18f) Several miscellaneous design improvements (#36, 6cb8b083) See the SCM history for full details. All thresholding algorithms from ImageJ 1.x have been ported to OPS. Available thresholding methods now include: huang intermodes isodata li maxEntropy maxlikelihood mean minerror minimum moments otsu percentile renyientropy shanbhag triangle yen Progress and future directions We also made great progress on several new lines of development: Type conversion (#47) Kernels (#48) Projection (#51) Conditions (conditions branch) Features and descriptors (feature-service branch) Future directions The OPS development plan and timeline is now codified on GitHub. Major milestones include: A near-term release later this fall: high-priority design issues, features and ops. An intermediate release before next spring: work to complete before coming out of incubation with 1.0.0, but less urgent than near-term items. A stable 1.0.0 release before the end of 2015: first release with a goal of future backwards compatibility according to SemVer. Please direct questions about OPS to the ImageJ mailing list. Thanks to everyone involved for all the hard work, patience and enthusiasm! [Less]

From Saturday, April 27, 2013 through Friday, May 3, 2013, LOCI in Madison hosted Tobias Pietzsch and Stephan Preibisch, two ImgLib2 main developers, for a hackathon. Here is a rough summary of what most people worked on: Stephan Preibisch ... [More] Together with Johannes we removed imglib1 from the imglib git repository, it now lives in legacy-imglib1. It could not go into SPIM_Registration directly due to circular dependencies with the 3d-viewer. I implemented wrappers from imglib1 <-> imglib2 that allow efficient, non-copying wrapping of array and cell images between both libraries. To achieve that imglib1 now depends on imglib2. This allows a gradual modification of source code which should ultimately result in the removal of imglib1. Additionally, new implementations in imglib1-based projects can now be implemented in imglib2. We have been working on a new Type hierarchy that reflects the opposed read and write capabilities for integer/floating point based Types. The repository lives on GitHub. Until now it does not work though as it seems very hard to express it using Java generics. I hope that is not true ... Curtis Rueden I developed a new component to manage extra metadata about N-dimensional images. In particular, it provides a class hierarchy for attaching per-dimension metadata as extensions of the Axis interface. The AnnotatedSpace interface provides a EuclideanSpace extension that manages the Axis list. Work was done on a branch called img-metadata, culminating in d3f8e64. The branch then sat for several months before being merged to master on August 12, 2013. Johannes Schindelin There were a couple of things I worked on (apart from the inevitable Fiji side tracks, in this case mostly the SezPoz class loader issue preventing the uploading part of the uploader to work): Tobias showed me his SPIM viewer which is slated to be in Fiji very soon. Tobias and I had a quick look whether we could easily support wrapping IJ1 VirtualStacks in Imgs and decided: no, there is no easy way. At least not as a small path to ImageJFunctions. We had a lot of discussions revolving about Ops and Expressions and performance. My current thinking is that we need to separate Ops from Expressions: to make developing, understanding and maintaining Ops as easy as possible, we have to separate the concerns better.And it is simply easier for everybody if the Ops do one thing, and one thing only, but that one well: evaluate an operation, working on Type variables. Expressions, however, need to know about temporary variables, input and output variables and about being clever not to copy data around too much. But that's the Expressions' job, not the Ops'. Performance is another issue, completely. Over the course of several experiments, I became convinced that we were wrong to rely on the JIT so much: it is okay for simple things, but for ever so slightly complicated things, we need a precompiler that knows what we really want to do. For example, just the mere fact should have taught us something that stand-alone FloatType instances *must* refer to their *single* float value as a 1-element float array *just so* that the JIT does not do an utterly bad job when we access single values as well as pixel values in an array. As a consequence of the findings regarding performance, I came up with a simple proof-of-concept that things could be made fast by using Javassist, a library for bytecode manipulation. We use this library extensively in ImageJ2 and Fiji already for just-in-time patching of, say, ImageJ1. It was a natural choice to turn to Javassist for trying to optimize ImgLib, too. Mind you, the example I made was very simple: it constructed a class working on ArrayImgs of FloatType directly, without even inspecting any code to know what to do, but instead hard-coding the "+" op. But it showed the way to how we could do things in the future: inspect what the, say, Expression is supposed to do and rewrite it in optimized bytecode. The speed improvement was—as I expected—impressive. A lot of discussion went into the question: "where should that optimization take place?". The major problem is—as so often—that you cannot completely rely on good design to get good performance. You have to have a place where the good design can be overridden by something potentially performant. So something has to give. But what? The way out, as far as I am concerned, is to leverage the scijava-common infrastructure and add an OpService. This will be a lot of work, of course, but it was invaluable to have the discussions and hands-on experiments together with the other guys. When you have such a concentration of programming talent in one room, good things happen! Barry DeZonia The discussions I participated in included: a proposal for a new roi interface where rois are Positionable, Localizable, and IterableInterval<BoolType>. The hope is to have rois you can move through space, bind to an existing interval, and then iterate the interval data directly. a proposed set of new histogram classes that can unify the various existing implementations a new approach to data operations in OPS (via new Expressions design and a new OpsService including Javassist accelerated operations) improved support for axes and calibration in Imglib2 data type hierarchy experiments The new roi discussion led to an attempt to see if the new interface design had any gotcha limitations. To that end I spent much of my time exercising the new interface by implementing it for some of the most general PointSet implementations. The test interface was laid out here as NewPointSet.. I have now created four implementations of this interface that can be found here. So far I have not run into any show stopper gotchas. The new implementations are sometimes slower than the old implementations but that may be addressable with additional attention. I also presented work I had done on a set of histogram classes in Imglib2 that could be used to unify the various histogram implementations currently found there. Suggestions were fielded, some changes were made, and the code has been merged to master. In regards to data type hierarchy experiments I tried to determine the ramifications of supporting BigInteger and BigDecimal data types in Imglib2 for ImageJ2. As part of this work I mocked up a version of the Haskell numeric type hierarchy so that it could inform any future development of data types. It can be found on the types-experiment branch here and here. Now that the hackathon is complete there are additional related tasks to follow up on. They include: Incorporating Mark Hiner's hackathon work (supporting very large image data) into IJ2. Assisting Curtis Rueden with incorporating the imglib2-metadata code into IJ2 Implementing the rest of the existing PointSet classes as NewPointSets. Improving the performance improve of the implementations of the NewPointSet interface Leveraging the new histogram classes throughout Imglib2 Updating IJ2 (and perhaps OPS' functions) to use new Expressions approach in OPS if it stands up to scrutiny Mark Hiner Over the hackathon and this past week I've been working on extending Tobias's CellImg structures with a SCIFIO backing. The goal here is to get ImageJ2 using SCIFIO for it's image IO operations, with the Cell's facilitating caching for huge datasets as needed. This will replace the need for specifying a virtual stack, as the SCIFIO cells will automatically determine optimal tile sizes and load the tiles when requested. This has required work on all three projects: ImgLib2 made the Cell classes more extensible (adding a Cell interface, refactoring some typing to be more general instead of on concrete implementations) SCIFIO Converted ImgSaver and ImgOpener to use the SCIFIO API. Extended the imglib2 cell components with SCIFIO cell classes. Currently, these components create 2D cells using the optimal tile height/width, as determined by the current SCIFIO reader. The cells are cached per-dataset using soft references to determine when cells are disposed. ImageJ2 Updated DefaultIOService and SaveImg to use the updated SCIFIO ImgOpener and ImgSaver. This also means that IJ2 can read/write all the formats currently supported in SCIFIO. Future plans ImgSaver uses the SCIFIO API but is still set up to handle planar imgs. It needs to be updated to use SCIFIO cell imgs. The SCIFIO cell cache is currently read-only because when cells are disposed they aren't written to disk, they're just GC'd. So the cache will be updated to allow writing disposed cells to disk. ImgOpener only opens SCIFIO cell imgs right now. We'll add back the ability to open planar imgs if the dataset size is within appropriate bounds. Also, currently many operations in IJ2 (including just opening a dataset.. but also running plugins like Brightness/contrast) require dataset-wide operations (specifically calculating min/max values and autoscaling). This means that while SCIFIO cells can be used to open huge datasets, it's not practical because the autoscaling takes forever. So we need to decide how to limit the range of these operations (e.g. to the current plane, or to the set of known planes). Limitations These changes don't immediately allow for opening large single planes in IJ2—just large numbers of planes—as each whole plane is always loaded in IJ2. However, I think cells will lay the foundation for supporting large single planes in future IJ2 betas. [Less]

We updated the default skin for imagej.net. In particular, this new skin (Modern) has a white background, which better matches the content of some pages—particularly those containing images with white backgrounds.

We are happy to announce TrackMate version 2.5.0, but aren't we each time? This version brings mainly a complete rewrite of the LAP tracker, that brings major improvement in speed performance and memory usage, as well as several enhancement in the ... [More] UI of TrackScheme. The new LAP tracker We completely rewrote the LAP tracker and this version ships it. It gives (almost exactly) the same results and has the same settings that the former version, but exploits the sparse structure of the cost matrices we typically have in bioimaging to achieve a much better memory usage. Let's quickly review how. The LAP tracking framework proposed by Jaqaman et al.[1] is based on generating a large cost matrix that contains the costs to link all possible spots to another, within physically reasonable bounds. Then a solver finds the links that minimize the total cost. In some cases, when allowing for tracks to merge and split, the cost matrix generated had almost all spots of the model as rows and almost all spots of the model as columns. Even is the vast majority of these costs were infinite (impossible linking, because they are too far apart, not in suitable frames, etc...) they still occupied most of the memory. It gets worst as the cost matrix has to be manipulated to be completed by alternative costs. These heavy movements of large chunks of memory can crash the program and slows it down considerably. The answer is using a data structure that takes advantage of the sparsity of the problem and algorithms that deal with such structure, which is what this version brings. Of course, if this new tracker is optimized for memory usage, it has a cost on raw speed. However, it appears that this cost is not seen in practice. With a 20k spots model (which is not even big), allowing all events, the memory used amounts to 10 GB with the old version. Which is madness. The new version takes 230 MB topx. And there is an added bonus: Normally the sparse version should take more time But in practice it does not; the memory manipulation overhead kills the performance of the old version: it takes 40 s. while the sparse version takes 18 s. And there is a second bonus: The main time is spent creating the cost matrix. But in the sparse version the creation can be multithreaded easily. So with 24 threads (with hyperthreading), the time for tracking goes down to 4s. We have a new version of our tracker which is 10 times faster and takes 40 times less memory for medium-size models. It's probably longer for small models (but you would not feel it anyway), much quicker for medium-size models, and make large models doable. This is cool, but let's be honest, most modern tracking softwares offer this for a long time already. There are tiny differences with the previous version, notably in the way cost thresholds are handled, that makes the new tracker give results that are not exactly the same as the old version. For instance, on a medium-size model, 99.73% of the links created are common to the two trackers. For this reason we did not discard the old version of the tracker, but renamed it with the prefix "old-". You can still find it in TrackMate, and it will be correctly set if you load from an XML file. TrackScheme UI improvement TrackScheme now features a search box and proper row and column headers. Other improvement A new action, called Branch hierarchy analysis features a branch-based analysis of tracks. The output is an ImageJ results table that contains for each branch the number of predecessors, the number of successors and its duration. The results table is clickable and will set the selection to be the clicked branch. ↑ Jaqaman et al., "Robust single-particle tracking in live-cell time-lapse sequences", Nat Methods. 2008 Aug;5(8):695-702. [Less]

After receiving input from the ImageJ community on the collection of anonymous plugin usage data, the ImageJ team is happy to announce a new public release candidate for ImageJ2: version 2.0.0-rc-13. The sole purpose of this release is to remove ... [More] usage statistics collection from the core of ImageJ. This update is available immediately in Fiji through "Help > Update Fiji". Note that even without updating, the usage collection server has been set to reject any upload events, and the data that was collected has been purged. Thank you again to all community members who provided feedback on this issue! [Less]

Today, the ImageJ team is pleased to announce a new public release candidate for ImageJ2: version 2.0.0-rc-11. New features Usage tracking! We can now track and upload (anonymously) use counts at the plugin level, along with information about the ... [More] environment of use (location, operating system, etc...). Although we are taking care not to expose any user data with these statistics, this feature can be disabled via a new Edit > Options > Privacy... setting. Expect great things coming to the usage page! (note: "great things" = statistics graphs) Groovy scripting! The Groovy scripting language is one of the most popular available for the JVM. Hence, ImageJ now has built-in support for Groovy as a scripting option. All images, whether opened with the SCIFIO option enabled or not, should now be automatically populated in @Dataset annotations in scripts and plugins. This will make parameterized scripting much more consistent and useful. See the scripting guide for more information and tutorials. More plugin types! Continuing our dedication to making ImageJ2 a flexible and extensible platform, we converted some lower level utilities to pluggable services: type conversion and preference storage. This won't mean much to users right now, but it gives developers new ways to tap in to the functionality of ImageJ, and plays a key role in extensions like our upcoming MATLAB scripting language! Bug-fixes We resolved a significant memory leak due to images not being closed properly. This was also causing naming errors (e.g., the second time you opened "Data" it would display a title "Data-1" even after closing the first image) and other terrible gotchas. As a consequence, the linkage between ImageJ2 and ImageJ 1.x data structures maintained by the legacy layer is now more robust. We fixed several bugs in SCIFIO; e.g., ImageJ slice labels should now be preserved after saving and reopening in TIFF format. Quite a few other small bug-fixes; for example, the languages shown in the Languages menu of the Script Editor now appear in a consistent and alphabetical order. How to test the release candidate? Use the Help > Update command to update your ImageJ installation. Please send any comments to the ImageJ mailing list. And thank you very much for trying ImageJ2! [Less]

ImageJ2 has a flexible "extensibility framework" for managing plugins and their cousins, modules. Lately we have been making big improvements that are too numerous to mention here. But we wanted to make note of some of the progress that we made ... [More] within the past couple of days. Be warned: it is very technical and will likely only be of interest to other ImageJ2 developers. We now have a fully working way to create plugins with dynamic numbers of input and output parameters, by extending the DynamicPlugin class. DynamicPluginTest shows an example. (Feedback on the code is welcome; use Ctrl+Shift+T in Eclipse to Open Type and jump straight to it. To try it out in the GUI, open a couple of datasets first and then run Plugins > Sandbox > Dynamic Plugin Test. It will produce one output dataset per input, of the specified size squared.) There is now a ModuleService that tracks all known modules (plugins or otherwise). It publishes ModulesChangedEvent (in the case of new modules added, ModulesAddedEvent, and in the case of modules removed, ModulesRemovedEvent) whenever the list of known modules changes. This is similar to the ObjectService's ObjectsUpdatedEvent, so we expanded that to have the same hierarchy (Changed at base, Added and Removed as subtypes). The ObjectService's index was split out into its own class called ObjectIndex, which maintains the objects on every list that is part of its type hierarchy. For example, an object of type Integer would be registered onto the following lists: Integer, Number, Object, Serializable, Comparable. We implemented a subclass of ObjectIndex called SortedObjectIndex which does the same thing, but keeps all the lists sorted. Then we subclassed that as PluginIndex, and used it with the PluginService. So the plugin service now keeps an index of all its plugins including supertype hierarchies, which it didn't before. So for example, you can now ask the plugin service for all RunnablePlugins, and get ImageJPlugins (a subtype) included in that. ModuleService also uses a SortedObjectIndex subclass called ModuleIndex to maintain its list of modules. ModuleService has run methods for executing any Module or ModuleInfo, with or without spawning a new thread, and with or without a specified set of pre- and postprocessors. Similarly, PluginService has run methods for executing any Module or ModuleInfo with its known PreprocessorPlugins and PostprocessorPlugins. These methods are the central way to run a module programmatically. The ShadowMenu, a UI-agnostic menu tree structure, now has each leaf linked to a ModuleInfo. This means that menu entries will now be capable of running scripts and other modules, not just plugins. What's next: Dynamic plugin implementations: We are going to update various core plugins which need the dynamic plugin mechanism, to give it a test drive. Dynamic menus: Update ShadowMenu to listen to ModulesChangedEvent and ModuleUpdatedEvent and change its internal structure accordingly. This will generally entail surgical changes to its structure rather than a full menu rebuild. Update the UI-toolkit-specific menu builders to keep the resultant menu structures (e.g., JMenuBar) linked to the ShadowMenu. When the ShadowMenu publishes events indicating menu items have changed, the actual UI menu needs to automatically update to reflect that as well. Maybe: update ModuleService to maintain a ShadowMenu data structure, which can be obtained for whatever purpose. More module invocation routines: It would be nice to have run methods of ModuleService and PluginService that accept parameters programmatically, either as a list or as a map. Grant's InvokePluginTest shows what we are going for. [Less]