imglib / imglib2 Goto Github PK

It would be nice to have an ImgLib2 Img container that wraps a java.awt.BufferedImage.

See also the discussion thread on fiji-devel.

Hey all,

I found what look like minor bugs in some test code. The initialization of the matrix in LanczosExample and OpenAndDisplayAffineTransformedScreenImage seem wrong.

final double[][] matrix = new double[][]{
{ 0.5, 0, 0, imgPlus.dimension( 0 ) * 0.25 },
{ 0, 0.5 * imgPlus.axis( 1 ).calibration() / imgPlus.axis( 0 ).calibration(), 0, imgPlus.dimension( 1 ) * 0.25 },
{ 0, 0, 0.5 * imgPlus.axis( 0 ).calibration() / imgPlus.axis( 0 ).calibration(), 0 }
};

Note that row 2 of the matrix uses a ratio between axis 0 and axis 1. And that row 3 uses a ratio between axis 0 and itself!

I'm really not sure what was intended here but can someone take a look? Thanks.

I noticed there is no facility in ArrayImgs to create a BitImg. I guess this is because of the data storage that prevents the boolean[] array to be wrapped. But what about this static utility below?

        /**
        * Creates an  {@link ArrayImg}<{@link BitType}, {@link BitArray}>, by <b>copying</b>
        * the content of the specified boolean array into the new image.
        * <p>
        * This static utility
        * is therefore somewhat different from the other ones in this class, for the content
        * of the specified array is <b>copied</b>, not re-used. This is to accommodate the
        * specificity of the {@link BitArray} storage.
        *
        * @param array  the array to use as content, will be copied.
        * @param dim  the dimension of the desired {@link ArrayImg}. Must be coherent with
        * the size of the specified array.
        * @return  a new  {@link ArrayImg}<{@link BitType}, {@link BitArray}>
        */
       final static public ArrayImg< BitType, BitArray > bits( final boolean[] array, final long... dim )
       {
               final BitArray access = new BitArray( array.length );
               for (int i = 0; i < array.length; i++) {
                       access.setValue(i, array[i]);
               }
               final ArrayImg< BitType, BitArray > img = new ArrayImg< BitType, BitArray >( access, dim, 1 );
               final BitType t = new BitType( img );
               img.setLinkedType( t );
               return img;
       }

Hello all!

I noticed several issues with UnsignedLongType.

1. getMaxValue( ) is 0xffffffffL and it should be 0xffffffffffffffffL (this value cannot be represented in java as an unsigned value)
   • Maybe we could do something similar to what is done in Unsigned128BitType?
2. compare( ) doesn't work for negative values
   • Can't compare unsigned longs larger than 2⁶³ - 1
   • Since there is no larger primitive than long, it uses long
     • this is also inconsistent with how the other unsigned types implement compare
3. get( ) returns a long
   • Calling get( ) on an UnsignedLongType can then return a negative value, if it was constructed with a negative
   • Maybe it should return a BigInteger as to return unsigned longs larger than 2⁶³ - 1
   • Inconsistent with other unsigned types which return the next larger primitive (which can't be done here)

I think one possible way to fix some of these issues would be to utilize BigInteger similar as to what is done in Unsigned128BitType. However, I am not certain if this is the best way to solve these issues.

Please let me know your thoughts on this, or if anything I said was unclear.

Currently the ImgOpener tool only allows data to be opened from a String or IFormatReader. While it is possible to implement entirely new LocationServices to read files from another file-system, it would be easier for some projects to enable creating a reader directly from a IRandomAccess or InputStream and a string indicating the filename (for selecting types). Particularly when creating a library which uses ImgLib2 to read and process images, it is quite heavy to write a new custom LocationServices when reading is the only needed ability.

Hello!

I noticed an inconsistency with the Unsigned128BitType variable constructor and how it handles a negative input, when compared with the other unsigned types. The other unsigned types all just mask the input, but Unsigned128BitType masks the individual bytes and then shifts them.

For example:
UnsignedIntType i = new UnsignedIntType(-279);
This will create an UnsignedIntType with the value 4294967017.

Unsigned128BitType b = new Unsigned128BitType(BigInteger.valueOf(-279L));
But this will create an Unsigned128BitType with the value 65257. Whereas, if it masked like the other unsigned types it would create an Unsigned128BitType with the approximate value 3.4028236e38.

So, would it be beneficial to have Unsigned128BitType mask negative values the same way the other unsigned types do? Or is the current method preferred?

Please let me know your thoughts on this, and thank you in advance for your input.

Hi all,

we would like to draw your attention to a probably well-known issue regarding the implementation of general algorithms. And by now we feel the urge to discuss it (you too, hopefully):

The issues we want to address are:

• there are a couple of, more or less, redundant implementations of algorithms (AbstractRegionGrowing, ConnectedComponentAnalysis, Morphological operations, ...) of varying quality (honestly, our implementations in the ops-packages are certainly not the best among them)
• many implementations use different concepts and are part of different frameworks (e.g. Operations, Algorithms or nothing) what complicates, and some time limits, their use and compatibility

As a first starting point, we propose the following:

• we introduce a "imglib2-algorithms-sandbox" where one can put code which he wants to make visible/usable to others but didn't have time for a super-clean implementation yet, they can also be removed without being marked as deprecated. We think this package is important because many of these algorithms can be good starting point for more sophisticated implementations.
• we should agree on one package (e.g. imglib2-ops) what should facilitate the interfaces definitions and usage (e.g. concatenation of algorithms, applying pixel-wise operation assignments on images or rois, etc.) of algorithms in general. addtionally this package may also contain very basic operation like add substract etc)
• algorithm live in another package, e.g. imglib2-algorithms and have to comply with certain conventions that need to be elaborated and algorithms can only be added via pull-requests.

The conventions for stable algorithms in imglib2-algorithms can be something like this:

• no other algorithm doing the same should exist (if yes, this algorithm should be extended instead of adding a similar one)
• each algorithm must inherit from the same interface such that it can be embedded e.g. in the operation framework and should follow a certain coding convention (e.g. the obligation to provide static accessor methods, like in Gauss3)
• the implementation should comply with a set of fixed coding guidelines (e.g. avoid the use of Img itself instead use IterableInterval or RandomAccessibleIntervals etc, whenever possible, use Views to create Iterables over RandomAccessibles, Formatting conventions etc..)
• Multi-threaded algorithms must provide a method which takes an ExecutorService, which is e.g. important for application which maintain their own ThreadPool.
• ...

let's start this discussion!

Martin & Christian

Update: Added GoogleDoc document
https://docs.google.com/document/d/1vENBDKboBWf9q29LHNtY0aizPY6mUw0pa0-q99JsscQ/edit#

To: @LeeKamentsky @MichaelZinsmaier @Squareys @angrauma @StephanPreibisch @axtimwalde @tpietzsch @tinevez @ctrueden @dscho @bdezonia @hinerm @hornm

I would like to use the FFT code in Imglib2 in some IJ2 plugins. As they stand they exist in algorithms-gpl and thus can't be used. They use the Mines Java Toolkit.

I checked the Mines Java Toolkit and it is licensed under the CPL. Maybe it was GPL at one time but no longer. I contacted the author and he says we can use the jar in any BSD project. We cannot modify/distribute the source of Mines as anything but CPL.

This sounds to me like there is no reason for the various Mines derived FFT classes to live in algorithms-gpl (when instead it could possibly move to plain algorithms project).

Does the person who decided to put it in algorithms-gpl want to weigh in here? Or anyone else with an opinion?

I'm getting the following error when I try to do SubpexelEdgelDetection.getEdges() on a 16-bit pgm file.

java.lang.ArrayIndexOutOfBoundsException: 1230082
at net.imglib2.img.basictypeaccess.array.ShortArray.getValue (ShortArray.java:65)
net.imglib2.type.numeric.integer.GenericShortType.getValue (GenericShortType.java:91)
net.imglib2.type.numeric.integer.GenericShortType.set (GenericShortType.java:152)
net.imglib2.type.numeric.integer.GenericShortType.set (GenericShortType.java:52)
net.imglib2.algorithm.gradient.PartialDerivative.gradientCentralDifference (PartialDerivative.java:114)
net.imglib2.algorithm.edge.SubpixelEdgelDetection.getEdgels (SubpixelEdgelDetection.java:107)
mdg.cv$eval11043.invoke (form-init5205819632875051878.clj:1)
clojure.lang.Compiler.eval (Compiler.java:6619)

A test image can be found here:
https://gist.github.com/paulrd/8042194#file-2013-11-05-11-49-49_mca000_65-3-pgm

I'm using:
java version "1.7.0_25"
OpenJDK Runtime Environment (IcedTea 2.3.12) (7u25-2.3.12-4ubuntu3)
OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode)

I'm using the latest git versions of scifio and imglib2.

Metadata Interface name is misleading as extends ImageMetadata (which is actually more specific). We could rename Metadata to ImgPlusMetadata.

Additionally introduce "GeneralMetadata" which serves as a simple marker interface for the metadata e.g. a Labeling and a ImgPlus share.

Currently all the axes implementations are derived from a base equation, whether linear or not.

We should also support the case where the calibrated values are simply explicitly enumerated.

It's not clear what the intended limitations of IterableInterval are.. e.g., can there be gaps in the range of values covered by the interval?

It would be nice if the intended use here was documented.

In the Fiji site Getting Started, there is code that includes the package net.imglib2.img.display.imagej.ImageJFunctions. However, I have downloaded the zip file and cannot find the package in my src/main/java. Is there any way to fix this?
Thank you

I have tried to call the cursor method of an imgPlus object (taken from this file):
https://gist.github.com/paulrd/8042194#file-2013-11-05-11-49-49_mca000_65-3-pgm
and I get the following error:

java.lang.ArrayIndexOutOfBoundsException: -1
at net.imglib2.img.basictypeaccess.array.FloatArray.getValue (FloatArray.java:69)
net.imglib2.type.numeric.real.FloatType.get (FloatType.java:109)
net.imglib2.type.numeric.real.FloatType.getRealDouble (FloatType.java:115)
net.imglib2.type.numeric.real.AbstractRealType.toString (AbstractRealType.java:115)
net.imglib2.img.array.ArrayCursor.toString (ArrayCursor.java:117)

Maybe I'm using this wrong? I can work around this by first creating a IterableRandomAccessibleInterval:

Views.iterable(Views.interval(i, Intervals.expand(i, -1)).cursor()

This error occurs for ArrayImg < FloatType > and ArrayImg< UnsignedShortType >.

See below. If this is a bug, the desired behaviour would be, that the converter isn't called on out of bounds values in this situation (as our out-of-bounds strategy defines the value in this case).

@Test
public void testExtendedConvertedImg() {

    RandomAccessibleInterval<BitType> converted = Converters.convert(
            (RandomAccessibleInterval<ByteType>) ArrayImgs.bytes(100, 100),
            new Converter<ByteType, BitType>() {

                @Override
                public void convert(ByteType input, BitType output) {
                    output.setReal(input.get());
                }
            }, new BitType());

    IntervalView<BitType> extendBorder = Views.interval(Views.extendBorder(converted), converted);

    RandomAccess<BitType> randomAccess = extendBorder.randomAccess();
    randomAccess.setPosition(new long[] { -10, -10 });
    randomAccess.get().get();
}

The ArrayDataAccess class has significant overlap with the SciJava-Common PrimitiveArray class.

If we're willing to depend more heavily on SJC, it would be beneficial to consolidate these two interfaces, to limit repetition of concepts.

Specifically, they could use the Handler pattern or similar so that you can ask for the best Projector for a given sort of image.

It is a little more complicated than that because you are optimizing the projector not just for the type of image, but for the sort of projection you want to do. As pointed out by @dietzc it is very reminiscent of ImageJ OPS.

Hi @tpietzsch

After some discussion we would like to make some updates to how ImgFactory can be used, with respect to generic parameters and Types as method arguments.

Option 1:

• Add a constructor that takes a Type instance to ImgFactory.
• Add create method signatures that do not take a Type instance (since they would have it)
• Deprecate old create signatures and non-Type constructors.

Option 2:

• Copy and paste ImgFactory to a new package
• Remove generic parameter from the NewImgFactory class
• Add generic parameters to the create methods themselves.

Either of these options should meet our goals, and they do not need to be mutually exclusive. I'm happy to do the implementation, but wanted to run these by you first to see if you have a preference, or any suggestions/concerns/etc...

Let me know. Thanks!

In places like IntervalIndexer which use primitive arrays, it would be nice to consolidate their use with classes like PrimitiveArray or ArrayDataAccess. However, for the PrimitiveArray class there will be an autoboxing cost.

So we should run performance benchmarks to see what kind of hit it would take if autoboxing was allowed, as it wold significantly simplify the code for something like #51.

I have been using RealIntervals for some test code. I was looking at AbstractRealInterval and have a question about two of the constructors.

The AbstractRealInterval(RealInterval other) constructor seems to incorrectly initialize min and max to 0's rather than the min and max of the other interval.

The AbstractRealInterval(double[] dimensions) constructor subtracts one from each dimension when setting min and max. This makes sense for an long[] dimension input but not for a double[] input. It has the paradoxical result that creating a real dim of width 5 reports realMin as 0 and realMax as 4 and an effective width of 4.

Can someone (Steffi you wrote this I think) review these and comment? Thanks.

see: https://github.com/imagej/imglib/tree/subinterval-cursor

In October we (Tobias, Johannes, Martin and me) started to introduce optimized iterations of views. In special cases (e.g. any 0-1-plane of a 3-d RandomAccessibleInterval), the iteration over such a view can be optimized e.g. by using the standard cursor of the underlying container with some offset. Actually, each container (Array, Planar, NTree, etc) has to decide whether or not a view over a certain interval can be iterated faster than with a wrapper using RandomAccess.

The View part of the implementation was already done by Tobias and is used in KNIME since Octobre. ArrayImgs already offer fast cursors. PlanarImgs / NtreeImgs etc. need to be implemented (see branch).

This is really useful, as you get a huge speed-up e.g. if you process any n-dimensional image plane-wise.

In ImgLib1, there is support for NIO-backed primitive arrays in the mpicbg.imglib.container.basictypecontainer.array package, specifically the NIO* classes. This was never translated to ImgLib2. It would be nice to do so, since NIO-backed arrays have a few advantages, including allocation outside the heap, arrays larger than 2GB, and shared memory with native applications.

Hi,

we are currently working on ColorTables for Labelings and therefore reviewed some of the existing code of the ColorTables.

We found something where we are not sure whether this is correct or not: ImgPlus implements ImageMetadata which somehow maintains a ColorTable. ImgPlus can be of any type T (not restricted, especially not to RealType), but the ColorTable Interface assumes, that we always map a double value to a color (see e.g. public int lookupARGB(double min, double max, double value)).

We therefore thought about somehow generalizing the current ColorTable interface.

public interface ColorTable{
public int getColorValue(X x); // you get back the color
public int getComponentCount(); // how many "channels" do we have (e.g. RGB, RGBA);
}

This implies that we have to type ImageMetadata. Anyway, this assures, that ImgPlus and ImageMetadata have the same type and therefore a valid mapping of X -> Color is guaranteed. Additionally, we could reuse this interface for arbitrary type ColorTables (e.g. LabelingType -> Color, which is not a "ColorRange" implementation anymore, but a HashMap Implementation).

Any comment before we start refactoring?

Cheers,

Christian

Hello everybody!

I just stumbled over https://github.com/imglib/imglib2/blob/master/src/main/java/net/imglib2/AbstractInterval.java#L243 throwing an ArrayIndexOutOfBoundsException, because I passed a d >= n.

In my oppinion, .dimension() should return 1, just as AbstractImg does: https://github.com/imglib/imglib2/blob/master/src/main/java/net/imglib2/img/AbstractImg.java#L115

To make behaviour of IterableInterval consistent for this use case, I suggest changing the one or the other and documenting the behaviour in the Dimensions interface.

If you agree, I could do this change myself.

Greetings,
Squareys

i need a code of some heuristics algorithms like PSO ,GA, ACO,DEA
as resource allocation at the cloudlet level that allocate cloudlet to different VMS
in datacenterbroker .
please i need to know how to implement this algorithm in java code
if anyone have any code of these algorithms please send to me to implement a new one like it
thanks in advance

In OPS the Erode and Dilate operations should be symmetric. But Dilate now requires a generic typing. Even though the underlying code never seems to use the IterableInterval bits of the declaration. Can someone review? I think these two classes should be nearly identical.

In some cases it would be nice to have an n-dimensional Img/View which wraps a set of m < n dimensional Imgs.

Example NtreeImg:
The higher the dimensionality of your NtreeImg, the slower it gets as in an iteration step it needs to check in any dimension. If I know that I access the Img/View plane-wise and my Img is let's say three dimensional, I could convert it to an Img/View based on several two-dimensional NtreeImgs which can be iterated faster. The idea is actually analogous to a PlanarImg.

The CalibratedRealInterval class of imglib2-meta provides a RealInterval with one CalibratedAxis per dimension. With this information, it is possible to transform on demand from the source coordinate system into a target one. We just need a CalibratedViews static utility class, similar to regular Views, which provides an easy means of doing so.

@tpietzsch, we discussed you working on this eventually at our hackathon last April. But we still weren't quite far enough along on the CalibratedRealInterval work. I think that work is now ready to go, though, such that a CalibratedViews would become possible. @dietzc would also very much take advantage of this work in the KNIP project. Is it something you would have time to work on in the next six months? No worries if not; @dietzc and I will find some other way of getting it implemented. But since you are the Views guy we thought perhaps it make the most sense for you to take a crack at it.

We were wondering if we could integrate some functionality of "our" ImgOpener, which you find in the branch knip_deployment and which is basically a modified version of the ImgOpener available in the master.

The ImgOpener in the branch knip_deployment allows one to read in only parts of the image, e.g. only the x-y-plane in the t-th point of time, depending on a user selection, in contrast to reading in all of the image and cropping it afterwards.

I think we need to refactor the ImgOpener anyway after the changes of the Metadata structure/definitions, maybe we could merge ideas then?

It would be nice for ImgOpener to be able to open more than files. URLs would be nice. Other streams too?

The Mines Java Toolkit is licensed under the CPL. This license is incompatible with the GPL—that is, you cannot release GPL software with dependencies on a CPL component. From the GPL web site:

[The CPL] is a free software license. Unfortunately, its weak copyleft and choice of law clause make it incompatible with the GNU GPL.

In ImgLib2, the imglib2-algorithms package is licensed as BSD-2, and depends on Mines JTK. The imglib2-algorithms-gpl component is licensed as GPL and depends on imglib2-algorithms. In particular, FFTConvolution depends on FFTMethods which uses the Mines Java Toolkit. This situation is not legal.

The most ideal solution to this problem would be to eliminate all dependencies on Mines JTK, to avoid this conundrum in the future. But barring that, we could isolate all Mines-dependent code into its own subcomponent of imglib2-algorithms, perhaps imglib2-algorithms-fft.

@StephanPreibisch, what is your preference?

The firstElement method is typically used to determine data type. However, determining the first element requires reading part of the dataset from disk, which could be a costly operation.

Instead, why don't we make a getType method, and then just cache a Class<T> reference?

Would it be possible to Serialize an Img? I don't necessarily mean making Img implement Serializable.

A more direct question might be: is it possible to get a reference to an Img's type access? For instance, if I have an ArrayImg, I'd like to be able to get a reference to the IntArray that backs it. I could Serialize the access (if it is Serializable), and reconstitute the Img from that.

The ImgIOUtils class currently caches HTTP downloads of images in a temporary file which is deleted upon JVM exit. Better would be to cache permanently in the ~/.imglib2 folder. In this way, we can avoid having any large binary files committed to the git repository.

Hi all,

I'm wondering if we could be a bit more efficient here:

https://github.com/imglib/imglib2/blob/master/src/main/java/net/imglib2/view/RandomAccessibleIntervalCursor.java#L104

We don't really need l.

• l * index is always negative if index is negative
• l * dimensions[ 0 ] = index, right?

Or am I missing something?

Cheers and a nice weekend,

Christian

Find places that are using all the other histogram implementations and make them use Histogram1d and HistogramNd.

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

It would be nice to be able to have an object which is Iterable but not necessarily an Interval or RealInterval. So far we have been using Java's Iterable class, but we want to extend it to support the cursor() method to return a Cursor (in the case of Iterable) or RealCursor (in the case of RealIterable).

The original thinking for not having a non-Interval Iterable was that there are always a finite number of elements in the iteration and hence ultimately there are min and max bounds for the Interval from those. But that is questionable: Java's Iterable actually does not enforce there being a limit to the iteration (i.e., there is no size() method). Of course, Java's Iterable was intended for use with the Collections framework, and all Collections have an int size(), but ImgLib2 does not use Collection directly. (Some types define a size() but it is typically a long, for example.) Of course, if your Iterable isn't actually finite, there are other serious problems: a naive iteration loop over all elements will never terminate—in practice, ImgLib2 has an implicit assumption that all Iterables have a finite number of elements.

Hello!

I noticed that certain Unsigned types in net.imglib2.type.numeric.integer clamp (i.e. if a number is negative set to zero, etc.) for values that are out of range for the particular type (i.e UnsignedIntType, UnsignedByteType, etc.), while others mask values that are out of range (i.e. Unsigned12BitType, Unsigned4BitType, etc.). Should all these types be consistent in their out of range behaviors, and if so which method should be used?

Thank you in advance for your responses and please let me know if any of that isn't clear!

I have found the unit test RealSumTest.java fails on testAdd() when run under Java 8 (1.8.0_25 and 1.8.0_40). I believe Java 8 is not officially supported by ImgLib2 but I though perhaps forewarned is forearmed.

After some digging I found the RealSum::add() function appears to expose a bug in Java 8. (at least on my OS-X 10.9.4 / MacBook Retina)

The code at present is as follows:

    /**
     * Add an element to the sum. All intermediate sums are updated and the
     * capacity is increased on demand.
     *
     * @param a the summand to be added
     */
    final public void add(final double a) {
        int i = 0;
        double s = a;
        try {
            while (flags[i]) {
                flags[i] = false;
                s += sums[i];
                sums[i] = 0.0;
                ++i;
            }
            flags[i] = true;
            sums[i] = s;
            return;
        } catch (final IndexOutOfBoundsException e) {
            expand(s);
        }
    }

The problem seems to be that the value of s is corrupted by the time the IndexOutOfBoundsException is caught. This can be shown with the following code:

    final public void addIllustrateBug(final double a) {
        int i = 0;
        double s = a;
        try {
            while (flags[i]) {
                flags[i] = false;
                s += sums[i];
                sums[i] = 0.0;
                ++i;
                if (i >= flags.length) {
                    System.out.printf("about to go bust with %g%n", s);
                }
            }
            flags[i] = true;
            sums[i] = s;
            return;
        } catch (final IndexOutOfBoundsException e) {
            System.out.printf("expanding with %g%n", s);
            expand(s);
        }
    }

If and when this happens seems to be unpredictable but I enclose output from my log here:

about to go bust with 2.00000
expanding with 2.00000
expand(2.00000)
about to go bust with 4.00000
expanding with 4.00000
expand(4.00000)
about to go bust with 8.00000
expanding with 8.00000
expand(8.00000)
about to go bust with 16.0000
expanding with 16.0000
expand(16.0000)
about to go bust with 32.0000
expanding with 32.0000
expand(32.0000)
about to go bust with 64.0000
expanding with 64.0000
expand(64.0000)
about to go bust with 128.000
expanding with 128.000
expand(128.000)
about to go bust with 256.000
expanding with 256.000
expand(256.000)
about to go bust with 512.000
expanding with 512.000
expand(512.000)
about to go bust with 1024.00
expanding with 1024.00
expand(1024.00)
about to go bust with 2048.00
expanding with 1.47358e-61
expand(1.47358e-61)
about to go bust with 2048.00
expanding with 1.47358e-61
expand(1.47358e-61)
.
.
.

As you can see, things go pear-shaped at "about to go bust with 2048.00"!

Rewriting add() to explicitly test for out of bounds restores peace, harmony and wellbeing (although I do not know how this hits performance).

    final public void addFixed(final double a) {
        int i = 0;
        double s = a;
        while (flags[i]) {
            flags[i] = false;
            s += sums[i];
            sums[i] = 0.0;
            ++i;
            if (i >= flags.length) {
                System.out.printf("about to go bust with %g%n", s);
                expand(s);
                break;
            }
        }
        flags[i] = true;
        sums[i] = s;
        return;
    }

Some of the ImgLib2 Examples fail under Java 8; Example6c (the one that uses FFT to find the position of a sub image in a larger image). I wonder if some of the examples could be wrapped up in JUnit tests to check that they were always delivering the goods?

I would like to define an interface in the type hierarchy called FloatingType. Its signature would look like this:

public interface FloatingType(T extends FloatingType(T)) extends ComplexType(T)

It would gather the floating point ops in one place like this:

void sqrt(T result);
void pow(T p, T result);
void log(T result);
void exp(T result);
void sin(T result); // and cos and tan
void sinh(T result) // and cosh and tanh
void asin(T result) // and acos and atan
void asinh(T result) // and acosh and atanh

And it would be implemented by ComplexDoubleType, ComplexFloatType, FloatType, and DoubleType. The implementations for these methods already exist in OPS so its a minor port.

I haven't investigated this thoroughly but think it makes sense.

Do we want to have a PeriodicalInterpolatorFactory so that scaling images can be more consistent using different interpolation methods?

Hi @axtimwalde and @tpietzsch,

I'm wondering why

final FinalInterval resInterval = new FinalInterval(new long[] { 100,
    100, 5 });

final Img<BitType> any = new ArrayImgFactory<BitType>().create(
    new long[] { 100, 100, 1 }, new BitType());

final Scale scale = new Scale(1, 1, 5);

final RealRandomAccessible<BitType> interpolated = Views.interpolate(
    Views.extendMirrorSingle(any),
    new NLinearInterpolatorFactory<BitType>());

final AffineRealRandomAccessible<BitType, AffineGet> scaled = RealViews
    .affineReal(interpolated, scale);

final RandomAccessibleOnRealRandomAccessible<BitType> rastered = Views
    .raster(scaled);

final IntervalView<BitType> view = Views
    .interval(rastered, resInterval);

final Cursor<BitType> cursor = Views.iterable(view).cursor();
while (cursor.hasNext()) {
  cursor.next();
}

fails with an ArrayIndexOutOfBoundsException in the cursor.next() method. Am I doing something wrong?

Thanks,

Christian

The Axes enum currently contains axes that may be specific to consuming code (e.g. SCIFIO and Bio-Formats).

Also, while it does have a spatial flag, whether or not an axis is spatial is hard-coded... and "spatial" is not necessarily the best classification of axes.

So this enum can be made more general by having useful flags (e.g. "planar" for the axes that compose a single plane, and "channel" for different acquisition wavelengths, with remaining axes defining the number of complete planes in the dataset). These flags should be configurable per-axis.

Then we could potentially remove unnecessary axes entries from imglib.. or at the least, consumers like SCIFIO should define their own axes (e.g. defining which axes are spatial, channel, etc...).

Hi all,

I work togehter with Christian and Martin on the KNIME Image Processing Plugin. We wanted to use something similar to the net.imglib2.display.XYProjector to render images for our views, however the current implementation was a bit too restricted for our use cases.

Therefore we implemented a few new classes that might be interesting for you as well.
The implementation can be found at net.imglib2.display.projectors in branch knip or projectors.

We use these projctors since august last year as basis for the Knime Image Processing Image Views and I thought posting it here would be a good way to make the classes visible for interested developers.

a short description from an earlier e-mail

The code is organized as follows:

• Projector2D: is similar to the XYProjector but it supports also the selection of other dimensions (the code is not active because it requires the class Subsetviews from ops, that is not part of the projectors branch)
• DimProjector2D: is similar to the CompositeProjector however instead of providing multiple Converters the idea is to provide a single converter with access to multiple values from the "projected" third dimension. This gives the converter more flexibility with respect to the composition of single conversion results.
• specializedProjectors: contains some 2DProjectors that allow fast (normalized) extraction of 2D greyscale datasets from certain storage strategies (Planar/Array)
• screenimages: contains classes that convert Byte/Short ArrayImages into Java Images similar to the implementation of net.imglib2.display.ARGBScreenImage

I'm looking forward for your comments

Regards Michael

FinalDimensions.dimensions(long [] dims) is supposed to copy its internal dimensions into the supplied array but the code for it is the following:

public void dimensions( final long[] dims )
{
    for ( int d = 0; d < dims.length; ++d )
        this.dimensions[ d ] = dims[ d ];
}

Wrong direction, right?

Hi @tpietzsch,

there used to be some classes like ConstantRandomAccessible or ConstantRandomAccess. They have been removed during the Madison Oct. Hackathon. Is there any replacement for those useful classes or an nice and easy way to get something similar?

Thanks,

Christian

Hello all!

@dietzc and me tried to clean-up the branch "subinterval-cursor" whose changes now appear in "si-cursor-clean", hopefully without changes unrelated to the subinterval cursors.

SubInterval Cursors are optimized cursors for certain intervals, e.g. given an N-D ArrayImg one can create an optimized cursor for subintervals over an arbitrary XY plane. We started working on this on the Konstanz Hackathon 2012 with @tpietzsch.

I also did benchmarking, which gave some surprising results. You may view them here:

http://pastebin.com/KDzq4Hfy

The most amazing fact is that the optimized cursors of PlanarImg and ArrayImg are about 100 times faster than the RandomAccessibleIntervalCursor!

Sadly especially the PlanarImg optimized cursor gets screwed over by JIT pretty bad when used after iterating over an ArrayImg first. As to be seen in the benchmark above, the optimized cursor is then suddenly slower than the RandomAccessibleIntervalCursor.

Also, the "optimized" LocalizingCursors are always slower than the "non optimized" ones. We haven't really found out why yet.

@tpietzsch:
I suggest you have a look at the code and benchmark and decide over which parts you want to merge, maybe find the reason for the slowness of the LocalizingCursors.

Greetings,
Jonathan

I have created an ArrayImg using the ArrayImgFactory. The ArrayImg was created, it isn't null but when I call .randomAccess() a NullPointerException is thrown. Below I have added a simple class with a main method which reproduces this error.

import net.imglib2.img.array.ArrayImg;
import net.imglib2.img.array.ArrayImgFactory;
import net.imglib2.img.basictypeaccess.array.ByteArray;
import net.imglib2.type.NativeType;
import net.imglib2.type.numeric.RealType;

public class Error {

    public static <T extends RealType<T> & NativeType<T>> void main(
            String[] args) {

        // create an ArrayImg using the ArrayImgFactory
        ArrayImg<T, ByteArray> arrayImg = new ArrayImgFactory<T>()
                .createByteInstance(new long[] { 50, 50 }, 1);

        // arrayImg isn't null
        System.out.println("ArrayImg isn't null: "+(arrayImg != null));

        // NullPointerException is thrown here
        arrayImg.randomAccess();
    }

}

The output on my system is:

ArrayImg isn't null: true
Exception in thread "main" java.lang.NullPointerException
    at net.imglib2.img.array.ArrayRandomAccess.<init>(ArrayRandomAccess.java:84)
    at net.imglib2.img.array.ArrayImg.randomAccess(ArrayImg.java:109)
    at Error.main(Error.java:20)

Hi all,

With the introduction of histogram1d our own (much simpler) histogram implementation becomes obsolete. Therefore
we want to migrate the ops that rely on it to histogram1d and remove OpsHistogram.

However as histogram1d is currently in the project imglib-algorithms and Ops has no dependency towards algorithms this is
not possible.

I would therefore suggest to move the histogram package either to ops or to core. Core might be the better solution?

Looking forward for your thoughts

Michael

Recently it has come to my attention that there is a misunderstanding on how to find the most negative double or float value. The correct form for this is -Double.MAX_VALUE or -Float.MAX_VALUE as appropriate (which are very large negative numbers). It is NOT Double.MIN_VALUE or Float.MIN_VALUE (which are very small positive numbers).

Looking through the Imglib (versions 1.x and 2.x) code base it appears that in some cases we have this distinction confused. Below is a list of files that use Double.MIN_VALUE or Float.MIN_VALUE.

Code is likely wrong (in both imglib1 and imglib2)

CompositeRegionOfInterest
PolygonRegionOfInterest (at least the getRealExtrema() use and maybe others)

Code is likely fine

FloatType
DoubleType
InverseDistanceWeightingInterpolator
ImagePlusAdapter test
HyperSliceImgPlusTest

Unknown whether code is right or wrong

PdeUtil