imagej / imagej-common Goto Github PK

Originally ImageJ About images were specified to be RGB images. Recently this specification was relaxed. There are text files associated with about images that specify how to render the attribution text. One field is the rendering color. For backdrop images that are not RGB this color is no longer respected. We need to determine whether to ditch the color text support or not and update IJ2 as needed. Alternatively we could create the attribution as a color text overlay instead of stamping it into the Dataset. However text overlay code is not really in place yet.

Migrated-From: http://trac.imagej.net/ticket/1954

In IJ1 the ResultsTable API deprecates accessing arbitrary cell values by (col,row). All data access is meant to work by (columnName,row).

Currently IJ2 allows unnamed columns (or even two columns with the same name). We should change the table API to allow them to index via column name rather than column number. And we should put in checks so that setting column headers only allows unique column names (they could default to "1", "2", "3", etc.).

These changes would allow us to simplify the code in ResultsTableHarmonizer and also make it more correct.

Migrated-From: http://trac.imagej.net/ticket/1601

From issue #44, @dietzc writes:

Besides FloodFiller it would also think about moving/replacing Extents, Position, maybe PositionByAxis, ImageGrabber and DrawingTool. ChannelCollection.

Especially Extents and Position are probably unnecessary duplication of constructs already in ImgLib2 core. The others should be moved to subpackages.

When saving an image, there is some view-related metadata that is currently not being recorded. Specifically, knowing the composite mode of an image would be useful, as well as other display properties, such as the current index for each axis.

One way to handle it would be for DatasetService#save to add (key, value) pairs to the ImgPlus's properties, which SCIFIO then preserves. This would work around the fact that SCIFIO knows nothing about ImageJ DatasetViews.

Migrated-From: http://trac.imagej.net/ticket/1081

A difficult problem common to many applications is that of the undo history. Ideally, we would like ImageJ to support multiple undo and redo as efficiently as possible. There are two major kinds of undoable operations:

1. Some operations such as adding a ROI are simple to invert efficiently (just delete it). We can use a command recorder system to keep track of such workflows both backwards and forwards to allow undo and redo.
2. Other operations such as dithering are more destructive, and ImageJ must somehow cache the prior state of the image in order to successfully undo the change.
   As such, support for a hybrid undo history supporting both types of operations may be the way to go.

Migrated-From: http://trac.imagej.net/ticket/13

The ImgLib2 library has type-agnostic support for numerical data processing. As such, it would be great to have numerical types based on Java's BigInteger and BigDecimal, for arbitrary-precision integer- and real-valued numbers, respectively.

Implementing this feature will first require the types to exist within ImgLib2. Then we will need to write additional converter plugins (for the Image > Type menu) as well as ensure that ImageJ2's core numerical commands are well-tested with the new types. Right now, many plugins "cheat" by operating on doubles, which would defeat the purpose of the new types.

Migrated-From: http://trac.imagej.net/ticket/1653

JHotDraw7 has built-in support for rotation of selections. Press space bar to change the mode and the blue grippers become purple, with an extra little circle on top, for rotation.

We should support this too. This will prevent the need for separate tools for things like oval and ellipse.

Migrated-From: http://trac.imagej.net/ticket/1048

When checking if we have a display for a given object, the ConvertService should be used to check if we can convert from the given type to a supported type

If you open the OME 4d series in IJ1 (via either File open command or BF open command) the image is displayed all gray.

If you open the same image in IJ2 using the IJ2 open command it is displays as color channels (red, green, and blue).

Migrated-From: http://trac.imagej.net/ticket/720

In the long run it would be nice to pull numbers out of a Dataset at a given location. At the time this ticket was written there is a method in Dataset called getDoubleValue() that can do this. And it may have made its way into the ProbeTool. However using this method would result in some precision loss if the backing image is of type long. Come up with a way to pull numbers out of Imglib images and/or Datasets that can keep from losing precision.

Migrated-From: http://trac.imagej.net/ticket/389

Currently, ImgPlus wraps an Img, but the same metadata it attaches would be useful to associate with any RandomAccessibleInterval, even if it is not also an IterableInterval. However, exactly how to proceed with this change requires some thought.

This change would enable the ImgSaver to work with non-Img objects such as those produced by Views, which would be very powerful.

Migrated-From: http://trac.imagej.net/ticket/1063

In plain OSGi, bundles define their dependencies as so called imports. A bundle states that it requires another by package name (e.g. import net.imglib2). However, this implies that the package names have to be unique, i.e. a package is not split across several bundles. At the moment the package net.imglib2 is split into imglib2-core and imagej-commons. In our OSGi world this doesn't work. So what are the plans to refactor the packages in imagej-commons?

Thanks!!

Christian

ImageJ1 displays the label as a "subtitle" at the top of the image window (not in the title bar—that would be the name). ImageJ2 will also need a dedicated label property, since it's useful.

We also need slice labels—but see #21 for that.

Now that there is a unit conversion facility in imglib2-meta we should utilize it as possible. For instance we need to finish writing CombinedCalibratedRealInterval such that you can define axes and modify underlying axes by scaling utilizing unit conversion code. And also unit code can be used for pulling data out of interval.

Migrated-From: http://trac.imagej.net/ticket/2004

In IJ1 an ImageStack can get tagged with slice labels (programmatically by plugins or importers). These labels are displayed in the image window label and Image > Stacks > Tools > Remove Slice Labels clears them out.

IJ2 does not handle slice labels at all. Nothing is displayed in the image window label and remove slice labels is unnecessary.

We need to tag each plane with metadata on the IJ2 side and harmonize that info across the legacy layer. Note that restructuring plugins (add/del axis, add/del data, reorder data, etc.) need to maintain this metadata.

Migrated-From: http://trac.imagej.net/ticket/1301

The restructure plugins maintain existing color tables, but the code needs to make some assumptions, because Dataset currently keeps its per-plane color tables in a separate data structure from the ImgPlus itself.

More generally, things like Views cannot properly preserve per-plane metadata since there is no such thing at the moment. (We have per-axis metadata, but not per-plane.)

Ultimately, we probably need something like AnnotatedSpace but for intervals, so that each position of the interval can have some Metadata... although that would be per-pixel metadata if implemented naively. To handle it per-plane in a general way will require further consideration...

Migrated-From: http://trac.imagej.net/ticket/917

If you drag a set of table cell data from a LibreOffice spreadsheet onto the app frame, the data is pasted into a text pane. One of the flavors supported by LibreOffice is text/html and the data is an HTML table. It would be nice if we could see it's a table of values and make a results table window rather than a text window.

Migrated-From: http://trac.imagej.net/ticket/1673

It would be nice if we provided a template class for designing plugins that only work with certain types of Datasets. For instance the user might make a plugin that only works with unsigned byte type data. (This is similar to IJ1's DOES_RGB, DOES_ALL, etc.) We need to provide ways to get the type of a Dataset for checking. If we could make the template class check parameters at init time (and not when run() is called) that would be great. This would simplify plugin developers lives.

However a template class approach may be too limiting in that we really need multiple inheritance to cover the flexibility of our other plugin base class implementations. So maybe instead we provide interfaces and helper methods.

Another possibility is to have all plugins have a precheck() method with current abstract base classes providing empty ones. And plugin developers could provide their own implementation. The precheck would happen after @parameters assignment and maybe after initializers were run but before run() is ever called.

(See also ImgPlusService.)

Migrated-From: http://trac.imagej.net/ticket/1945

When attempting to open an image using the DefaultDatasetService, the following exception is thrown:

java.io.IOException: org.scijava.util.ReflectException: No such class: io.scif.config.SCIFIOConfig;
at net.imagej.DefaultDatasetService.open(DefaultDatasetService.java:256)
at ImageScanner.main(ImageScanner.java:11)

Sample code:

DefaultDatasetService dss = new DefaultDatasetService();
try {
dss.open(filename);
}catch ...

The net.imagej.axis package should be updated to support labeling each sample along an axis. The central use case for this is for channel names, but it would be potentially useful for any dimension.

See also this thread on imagej-devel.

I believed the Table API (e.g., for Results tables) was pretty thorough, but when trying to use it to implement a new IJ2 List Shortcuts command, I discovered that there are no appendRow methods. These would be a nice convenience, rather than having to explicitly call set(String colHeader, int row, Object value) for each cell of the row.

Actually, there are appendRow methods, but none that take the actual row data. So the current ListShortcuts implementation does:

shortcuts.appendRow();
shortcuts.set(hotKeyHeader, row, shortcut.toString());
shortcuts.set(commandHeader, row, info.getTitle());

When what would be nicer would be:

shortcuts.appendRow(shortcut.toString(), info.getTitle());

Of course, while this is more succinct, it also loses the column-safety, assuming columns are in a particular order.

Migrated-From: http://trac.imagej.net/ticket/1646

Currently AWTDisplayController is responsible for creating BufferedImages that are displayed in an ImageCanvas. The call to AWTDisplayController::update() creates a BufferedImage from the Dataset that is 1:1 scale in X & Y. For large Datasets this will be a problem.

Barry and Aivar discussed this some and noted some possible design changes.

We'd like to support the ability of the ImageCanvas to just display a BufferedImage that is made by AWTDisplayController. The ImageCanvas would pan and zoom on the given BufferedImage. The AWTDisplayController could make a BufferedImage from a number of tiles (allowing much less memory use).

After a certain zoom level is reached (1:1) then any zoom within ImageCanvas would just scale and pan on the last BufferedImage it was given. If panning or zooming out would cause a boundary of the current BufferedImage to become visible the ImageCanvas could say "hey, display controller, now I need to see region (x1,y1,x2,y2) of the image". The AWTDisplayController could then recalculate a new BufferedImage that represents that region of the Dataset building from some tiles as needed. ImageCanvas would display the new BufferedImage.

Migrated-From: http://trac.imagej.net/ticket/444

From a post by @dietzc on the ImageJ forum:
ArrayImgs should have a Converter to the native array and then the ops framework can automatically select the most efficient implementation for native-array-friendly operations.

We have some images that would display well when composite channel count != numCHannels. We have a 12 channel image (Day 1 Naked NB positive 1-2007-0055.zvi) which would display well with compos chan count == 3. The existing slider manipulation and display code needs to be updated to support this.

Migrated-From: http://trac.imagej.net/ticket/721

Right now, any Data objects get stored in the ObjectService as long as their reference count (number of things displaying them, essentially) is > 0. And when the ref count hits zero, they are removed from the ObjectService. This is because the ObjectService keeps hard references.

We could:

• Add a feature to the ObjectService to support weak or phantom references. This can eat memory though and delay garbage collection of otherwise-obsolete data.
• Consider making more things extend Data, particularly Table implementations, which would be nice to have a multiple-choice selection for when they are used as inputs.
• Generalize the reference counting thing beyond Data if needed.
• Forget all this reference counting stuff, and enhance the ObjectWidget to look for Display objects in the ObjectService that are currently displaying the needed type—and populate the multiple choices with those objects.

That last option is how I'm currently leaning, without having thought or investigated thoroughly enough to be sure I'm remembering how everything works 100% correctly. Would need to be sure things still work headless, though, if nothing is being displayed.

java.lang.NullPointerException
    at net.imagej.convert.ConvertIntArrayToFinalInterval.convert(ConvertIntArrayToFinalInterval.java:53)
    at org.scijava.convert.AbstractConvertService.convert(AbstractConvertService.java:62)
    at org.scijava.script.ScriptModule.run(ScriptModule.java:196)
    at org.scijava.module.ModuleRunner.run(ModuleRunner.java:167)
    at org.scijava.module.ModuleRunner.call(ModuleRunner.java:126)
    at org.scijava.module.ModuleRunner.call(ModuleRunner.java:65)
    at org.scijava.thread.DefaultThreadService$2.call(DefaultThreadService.java:181)
    at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
    at java.util.concurrent.FutureTask.run(FutureTask.java:138)
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
    at java.lang.Thread.run(Thread.java:695)
java.util.concurrent.ExecutionException: java.lang.NullPointerException
    at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:222)
    at java.util.concurrent.FutureTask.get(FutureTask.java:83)
    at net.imagej.ui.swing.script.TextEditor.evalScript(TextEditor.java:2476)
    at net.imagej.ui.swing.script.TextEditor.access$400(TextEditor.java:158)
    at net.imagej.ui.swing.script.TextEditor$Tab$6.execute(TextEditor.java:1488)
    at net.imagej.ui.swing.script.TextEditor$Executer$1.run(TextEditor.java:1977)
Caused by: java.lang.NullPointerException
    at net.imagej.convert.ConvertIntArrayToFinalInterval.convert(ConvertIntArrayToFinalInterval.java:53)
    at org.scijava.convert.AbstractConvertService.convert(AbstractConvertService.java:62)
    at org.scijava.script.ScriptModule.run(ScriptModule.java:196)
    at org.scijava.module.ModuleRunner.run(ModuleRunner.java:167)
    at org.scijava.module.ModuleRunner.call(ModuleRunner.java:126)
    at org.scijava.module.ModuleRunner.call(ModuleRunner.java:65)
    at org.scijava.thread.DefaultThreadService$2.call(DefaultThreadService.java:181)
    at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
    at java.util.concurrent.FutureTask.run(FutureTask.java:138)
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
    at java.lang.Thread.run(Thread.java:695)

And here's the script that caused it:

# @DatasetService data
# @DisplayService display
# @OpService ops
# @net.imagej.Dataset inputData

from net.imglib2.meta import ImgPlus
from net.imglib2.img.display.imagej import ImageJFunctions

from jarray import array
from ij import IJ

# create a log kernel
logKernel=ops.logKernel(2, 1.0)

# convolve with log kernel
logFiltered=ops.convolve(inputData, logKernel)

# display log filter result
display.createDisplay("log", ImgPlus(logFiltered))

# otsu threshold and display
thresholded = ops.run("otsu", logFiltered)
display.createDisplay("thresholded", ImgPlus(thresholded))

# convert to imagej1 imageplus so we can run analyze particles
impThresholded=ImageJFunctions.wrap(thresholded, "wrapped")

# convert to mask and analyze particles
IJ.run(impThresholded, "Convert to Mask", "")
IJ.run(impThresholded, "Analyze Particles...", "display add")
IJ.run("Close")

@hinerm Can you take a look? On cursory inspection it seems that AbstractConverter accepts null sources in canConvert now (maybe due to my recent changes to ConversionUtils?), but downstream converters are not expecting this and their convert method blows up in that scenario. We'll need to be more consistent about this...

The imglib2-realtransform package is a robust transform-based way of supporting coordinate system transformations, including per-axis transformations but also much more.

We should retire the calibrated portions of the net.imagej.axis package, in favor of using imglib2-realtransform. There is probably code of value in net.imagej.axis that can be retooled in some way, but what we want to avoid is limiting ourselves to only per-axis calibration support, since it is not powerful enough for many use cases.

In theory, the ImageJ2 display model supports multiple datasets in the same display. However, support for it is not exposed in the GUI, and there are surely some architectural problems with the current design. These problems must be resolved, so that we can start using ImageJ2 displays as flexibly as intended.

Blocked-By: #12
See-Also: #23
Migrated-From: http://trac.imagej.net/ticket/579

There are good reasons to support one kind of axis that has its equation defined by a string. I have mocked up a class below. This is not a simple endeavor but would eliminate a lot of (sometimes redundant) concrete CalibratedAxis implementations. See notes in code below for pointers.

package net.imglib2.meta.axis;

import net.imglib2.meta.AxisType;

/**
 * A very general text driven axis class.
 * 
 * @author Barry DeZonia
 */
public class UberAsciiAxis extends VariableAxis {

    // I might be getting carried away but think it would be nice to define axes
    // by equation alone. IJ1 has lots of one off definitions in CurveFitter that
    // have offsets or not or powers or not. I've generalized some of this by
    // always having an offset that can be 0. But really we'd like the flexibility
    // of not needing a new concrete axis class every time someone comes up with a
    // new formula. This class would parse the equation and build an appropriate
    // function that can scale coords as needed. The nice thing here is that the
    // parsed axis can be queried for variables and then a curve fitting algo can
    // determine appropriate variable values. Curtis' idea of the EditAxes plugin
    // directly tweaking the variables of a displayed equation is correct. There
    // remains the trick of determining when an axis is linear. This can be done
    // by testing that an axis.equals(some general linear axis string) as noted
    // below.

    // TODO - bad name: Equation is more general than our 1d case

    private interface Equation {

        // This might be involved to determine but it would be fun to write!
        Equation inverse(); // if doesn't exist we will return a NullEquation

        double eval(double input);

        // TODO - maybe one String method rather than two.

        String generalEquation();

        String particularEquation(); // likely in an abstract class
    }

    // equation string can be things like:
    // y = m*x + b
    // y = 74*x + b
    // y = q*sin(slope*x+19.4)^(33*power)+fred (here only x & y are predefined)
    // constants and vars automatically detected

    private final String equationString;
    private final Equation eqn;
    private final Equation eqnInverse;

    public UberAsciiAxis(AxisType type, String unit, String equationString) {
        super(type, unit);
        this.eqn = parse(equationString);
        this.eqnInverse = eqn.inverse();
        this.equationString = equationString;
    }

    public UberAsciiAxis(AxisType type, String unit, Equation equation) {
        super(type, unit);
        this.eqn = equation;
        this.eqnInverse = eqn.inverse();
        this.equationString = equation.generalEquation(); // or particular?
    }

    @Override
    public double calibratedValue(double rawValue) {
        return eqn.eval(rawValue);
    }

    @Override
    public double rawValue(double calibratedValue) {
        return eqnInverse.eval(calibratedValue);
    }

    @Override
    public String generalEquation() {
        return equationString;
    }

    @Override
    public UberAsciiAxis copy() {
        return new UberAsciiAxis(type(), unit(), equationString);
    }

    @Override
    public boolean equals(Object o) {
        if (!(o instanceof UberAsciiAxis)) return false;
        UberAsciiAxis other = (UberAsciiAxis) o;

        // TODO: do something really cool. compare syntax trees and variables of the
        // two UberAxes. Even trickier: detect when vars of two eqns are the same
        // due to coeffs being 1 or 0. For example y = 1*x + 0 is same as y = x
        // though they would have different syntax trees.

        // TEMP: only equal to self
        return other == this;
    }

    // For generality and reuse elsewhere maybe make parser return multidim
    // equation. We'd need to test that it has a single dim of input to qualify as
    // a valid axis equation

    private Equation parse(String equationString) {
        // TODO
        return new NullEquation();
    }

    // return one of these as an Equation::inverse() when it is not invertible

    private class NullEquation implements Equation {

        @Override
        public double eval(double input) {
            return Double.NaN;
        }

        @Override
        public Equation inverse() {
            return this;
        }

        @Override
        public String generalEquation() {
            return "y = NaN";
        }

        @Override
        public String particularEquation() {
            return "y = NaN";
        }

    }
}

Migrated-From: http://trac.imagej.net/ticket/2012

These two classes should be one thing.

This is one primary goal of the "rich image" work. Relevant related resources are:

• data-model label
• scijava/scijava-common#157
• This news post
• imagej/imagej-common@rich
• imagej/janelia-hackathon-2016

Overlays currently can be serialized and restored via a writeExternal() and readExternal() approach. However this approach requires that the serialized object has a no arg constructor. Currently the Data constructors all require at least 1 argument to the constructor. Until recently we were passing null as an argument safely. But with recent changes to the data type hierarchy this fake no arg approach fails and the test code in TestBinaryMaskOverlay began failing. I have commented out this test for now as we are not sure how we want to handle serialization going forward. We should figure out how we will support serialization of overlays and restore the commented out test,

Migrated-From: http://trac.imagej.net/ticket/1991

Illustrated in this sample python script:

# @OpService ops
# @DisplayService display

blank = ops.createimg(100)

display.createDisplay(blank)

Which causes the following exception:

Caused by: java.lang.ArrayIndexOutOfBoundsException: 1
    at net.imagej.display.DefaultDatasetView.xyPlane(DefaultDatasetView.java:340)
    at net.imagej.display.DefaultDatasetView.autoscale(DefaultDatasetView.java:169)
    at net.imagej.display.DefaultDatasetView.initializeView(DefaultDatasetView.java:515)
    at net.imagej.display.DefaultDatasetView.rebuild(DefaultDatasetView.java:399)
    at net.imagej.display.DefaultImageDisplay.rebuild(DefaultImageDisplay.java:136)
    at net.imagej.display.DefaultImageDisplay.display(DefaultImageDisplay.java:274)
    at org.scijava.display.DefaultDisplayService.createDisplay(DefaultDisplayService.java:221)
    at org.scijava.display.DefaultDisplayService.createDisplay(DefaultDisplayService.java:207)

Which makes sense, since there is no "Y" for a y plane.

Dataset has a ImgPlus<? extends RealType<?>>. This is wrong for multiple reasons:

1. RealType is not general enough. We need to support at least ComplexType as well, if not all Types. See ImageJ Trac ticket #845 for related discussion.
2. ? extends RealType<?> causes many issues with the compiler. We might need to bite the bullet and have Dataset be generically typed. See also #12.

Hi @hinerm @ctrueden,

I started working on some simple Converters from ImgLib2 NumericTypes to native Java types, RandomAccessibleInterval to IterableInterval or RandomAccessibleInterval to ImgView. I ran into some problems/questions:

• Creating converters for ImgLib2 types is something we can solve with code-generation and therefore I suggest to do it in ops.
• I don't actually understand the Converter interface and the AbstractConverter from SciJava:
  • The convert(...) return an Object. Why can't it return what I specified in the generic declaration of the Converterinterface?
  • The abstract implementation requires deep knowledge about it's implementation. In some situations you have to override several canConvert(...) to get the desired behaviour. Also overriding supports(...) seems to have to effect (see e.g. https://github.com/imagej/imagej-common/blob/converter/src/main/java/net/imagej/converters/ConvertLongArrayToFinalInterval.java).
• Converting RandomAccessibleInterval to ImgView requires that we have an heuristic which ImgFactoryor to be more general which RandomAccessibleIntervalFactory (we don't have this concept, yet) is chosen and returned by the ImgView. We started implementing these heuristics in https://github.com/imagej/imagej-ops/tree/img-creators), but of course I can't use them here as imagej-common has no dependency on ops. So should I implement this single Converter in ops then?

Thanks for your help!

Christian

Some of the display classes (AbstractImageDisplay, SwingImageDisplay) listen to data events and update their views. This is sort of backwards and poorly coupled.

Make views listen for data events and change their state appropriately. They should generate view events. Displays should listen for view events and update their state accordingly.

Migrated-From: http://trac.imagej.net/ticket/884

It would be nice if rather than only an index, each position along each dimensional axis could be labeled with a string as well. A very common use case is to have multiple wavelengths labeled with the stain used; e.g., labeling a GFP fluorescence channel as "GFP" or "509nm".

In ImageJ 1.x these are called "slice labels" and you can have one per image plane.

Right now, SCIFIO has some hacks to read and propagate them. But ImgPlus et. al needs to properly support it.

Migrated-From: http://trac.imagej.net/ticket/1567

Create a new 8 slice hyperstack (1 c, 1 t). Run Stack To Images. If you put a print statement in CompositeXYProjector.map() you'll see it is called dozens of times.

Migrated-From: http://trac.imagej.net/ticket/1159

For some axis types, it makes sense to interpolate between values, since they are intended to represent continuous axes. For others, they may be discrete—e.g., if each sample along that axis is a different computed feature. It would be nice if the AxisType interface had isDiscrete and/or isContinuous methods reporting that.

There is a bug in the Table implementation, as illustrated by the following code:

import imagej.data.table.DefaultGenericTable;
import imagej.data.table.GenericTable;

public class TableBug {

    public static void main(final String[] args) throws Exception {
        final String first = "First";
        final String second = "Second";
        final int rowCount = 10;

        final GenericTable table = new DefaultGenericTable();
        table.setRowCount(rowCount);
        table.appendColumn(first);
        table.appendColumn(second);

        for (int row = 0; row < rowCount; row++) {
            table.set(first, row, "1st:" + row);
            table.set(second, row, "2nd:" + row);
        }

        System.out.println(table);
    }

}

It throws the following exception:

Exception in thread "main" java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
    at java.util.ArrayList.RangeCheck(ArrayList.java:547)
    at java.util.ArrayList.set(ArrayList.java:337)
    at imagej.data.table.AbstractTable.set(AbstractTable.java:408)
    at TableBug.main(TableBug.java:18)

But if you move the setRowCount call after the two appendColumn calls, the code works.

Migrated-From: http://trac.imagej.net/ticket/1647

When you launch IJ2 when no ImageJ.cfg file exists (or no memory constraint exists within it) the dialog shows 256 mb. But the actual ram allocated might differ substantially depending upon how IJ2 was launched. Have the dialog default to the currently allocated number of megabytes. Also warn user that memory setting won't apply if they launched IJ2 by some method other than the launcher. We can detect this state via lookup of the property ij.executable that the launcher sets.

Migrated-From: http://trac.imagej.net/ticket/1089

Some tools need a mechanism to iteratively update and redraw images at a rapid rate. E.g., the fitting process in the SLIM Curve plugin is very slow so there is a scheme to refresh the fitted image incrementally so that progress and results may be monitored.

It would be useful to generalize this somehow in the IJ2 framework.

Migrated-From: http://trac.imagej.net/ticket/1748

The following exception can be thrown by the DefaultPrefService when persisting values:

java.lang.NullPointerException
    at java.util.prefs.AbstractPreferences.put(AbstractPreferences.java:241)
    at org.scijava.prefs.DefaultPrefService.put(DefaultPrefService.java:183)
    at org.scijava.module.DefaultModuleService.save(DefaultModuleService.java:280)
    at org.scijava.module.process.SaveInputsPreprocessor.saveValue(SaveInputsPreprocessor.java:74)
    at org.scijava.module.process.SaveInputsPreprocessor.process(SaveInputsPreprocessor.java:65)
    at org.scijava.module.ModuleRunner.preProcess(ModuleRunner.java:104)
    at org.scijava.module.ModuleRunner.run(ModuleRunner.java:156)
    at org.scijava.module.ModuleRunner.call(ModuleRunner.java:126)
    at org.scijava.module.ModuleRunner.call(ModuleRunner.java:65)
    at org.scijava.thread.DefaultThreadService$2.call(DefaultThreadService.java:164)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)

To reproduce, open the SingleInputPreprocessorTest, remove the persist = false attribute from the private T thing parameter of HasASingleInput, and run the tests.

imglib2-meta has a UnitService. We aren't yet using it in IJ2. We should do so. PixelProbe seems an obvious use. Identify others.

Migrated-From: http://trac.imagej.net/ticket/2025

Sequential calls to DefaultDatasetView#autoscale() end up repeatedly computing the overall min and max. It could compute once and use cached results. Also it uses overall min and max rather than channel min and max which may be broken. We should revisit autoscaling.

Migrated-From: http://trac.imagej.net/ticket/1216

There are a number of places in IJ2 where an algorithm assumes the x coordinate of a position array is at index 0 and the y coordinate of a position array is at index 1. Remove this assumption.

Might need to have a Dataset cache the xIndex & yIndex (or more appropriately uIndex & vIndex) and allow them to be queried. One could supply methods somewhere such as:
fillPosition(uAxisIndex, vAxisIndex, uVal , vVal, planePosVals)
getU(position)
getV(position)
getPlanePos(position)

Migrated-From: http://trac.imagej.net/ticket/432

First of all, SaveDataset should be moved to imagej-plugins-commands.

Second, do we even want a SaveDataset? It should really be modified as is to use an appropriately styled File chooser for selecting an output destination, and do all the validation that we are already doing in SaveAsImage... so is SaveAsImage sufficient?

If so we may want to create a legacy menu entry for File > Export > Image... that calls SaveAsImage, if we want to be consistent with File > Import.

The DefaultMinMaxMethod uses a single progress variable that multiple threads increment. However, this operation is not actually thread safe. In tests of a dataset with 1000000 pixels, only ~900000 progress updates were actually being checked.

When progress is tracked in this way, each thread needs its own variable to be incremented.

Currently, a Display consists of a list of DisplayViews, each of which links to a Data object. After talking with a few people about use cases, it seems that this approach is too simplistic, while also being too complex.

For example, if you have a Dataset with a collection of Overlays intended to correspond to that Dataset, it would be nice for the data structures to indicate that they are specifically linked somehow, rather than just implicitly so by being in the same display.

A tree-like hierarchy of data objects would provide more explicit linkage between related objects, as well as easy duplication of the same structures across multiple displays. (TrakEM2 and Endrov both support tree-like hierarchies of data objects.)

Another problem is that we currently have no UI-agnostic mechanism to create DisplayView instances from a given Dataset or Overlay. Many plugins need to return a DatasetView or an OverlayView, but must avoid invoking e.g. "new SwingDatasetView" in code.

Further, for plugins that wish to return more complex data structures (e.g., a Dataset together with some Overlays), it would be nice to have the aforementioned tree structure, so that it can be used by those plugins.

To address these issues, I propose the following changes:

1. Create a third type of DisplayView called a CompositeView that consists of a list of other DisplayViews.
2. Provide a helper/factory that can generically create DatasetViews and OverlayViews.
3. Potentially, for simplicity, change Display to take a single CompositeView.

See also: scijava/scijava-common#157

Migrated-From: http://trac.imagej.net/ticket/660

Open the T1 Head sample. Save to TIFF, then reopen in the ImageJ2 Swing UI. Instead of being set to 3-521 like ImageJ1 does, the range will be set differently. The reason is probably that ImageJ1's default autoscaling is not a naive min-to-max but rather a statistical range computation.

Migrated-From: http://trac.imagej.net/ticket/794

The Extents and Position classes are redundant with ImgLib2 classes. The Position class may be equivalent to a Cursor. We may be able to eliminate them in favor of Intervals.

Migrated-From: http://trac.imagej.net/ticket/1996