Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 15 10:07

    tinevez on TrackMate-7.5.1

    [maven-release-plugin] prepare … (compare)

  • Jan 15 10:07

    tinevez on master

    Bump to next development cycle … Merge branch 'master' of github… Center preview test on config p… and 1 more (compare)

  • Jan 14 16:27
    imagesc-bot commented #207
  • Jan 14 16:18
    phisanti edited #207
  • Jan 14 16:18
    phisanti opened #207
  • Jan 13 16:51

    tinevez on master

    Revert "Remove the logic to che… Don't crash when running global… Use html in JLabelLogger. In c… (compare)

  • Jan 12 19:47
    ctrueden unassigned #17
  • Jan 12 19:34
    ctrueden commented #18
  • Jan 12 19:34

    ctrueden on main

    Switch to JUnit 5 See #18; tha… (compare)

  • Jan 12 19:33
    ctrueden commented #18
  • Jan 12 15:22
    tinevez closed #205
  • Jan 12 15:22
    tinevez commented #205
  • Jan 12 15:02
    wolfgangkeil commented #205
  • Jan 11 22:04
    imagesc-bot commented on 9a9e241
  • Jan 11 22:01

    ctrueden on master

    ReadBufferDataHandle: fix buffe… (compare)

  • Jan 11 19:39

    ctrueden on master

    Bump to next development cycle … (compare)

  • Jan 11 19:39

    ctrueden on TrackMate-7.5.0

    [maven-release-plugin] prepare … (compare)

  • Jan 11 19:35

    ctrueden on master

    (compare)

  • Jan 11 19:35

    ctrueden on TrackMate-7.5.0

    (compare)

  • Jan 10 22:30

    ctrueden on master

    Update README * Add links to n… (compare)

Curtis Rueden
@ctrueden

An instance of the problem with Java's typing policy with arrays, right? This also compiles:

String[] s = {"hello", "world"};
Object[] o = s;
o[0] = new Object();

And throws ArrayStoreException for the same reason. So I don't think the fault is with java.util.Arrays, per se.

Same as how ImgLib2's type hierarchy is right-side up for getters, but upside down for setters, eh?
Stephan Saalfeld
@axtimwalde
nah, the setter/ getter thing is a design flaw that could be fixed by separating the getter and setter interfaces, the array situation is a language decision that cannot be fixed, but is ok to live with
Philipp Hanslovsky
@hanslovsky
That is a little scary. Good to know, thanks for sharing. I figure, the only way for Java to solve this would be to disallow implicit casting (never going to happen, of course). I don't see any other way to have this fail at compile time
Philipp Hanslovsky
@hanslovsky
Not as evil as c++ (at least Arrays.setAll throws an exception at runtime)
int x = ...
if (x = 0) { /* do stuff */ }
Most c++ compiler will display a warning for that (and error on warning is generally a good idea in cpp)
Curtis Rueden
@ctrueden

@hanslovsky wrote:

I don't see any other way to have this fail at compile time

Array types are covariant (can assign from specific to more general element type), but shouldn't be. Have a syntax to distinguish between "read-only" and "write-only" modes (i.e. upper bounded versus lower bounded), where you can assign from more-to-less specific in read mode, and less-to-more specific in write mode.

CharSequence[] words = {"hello", "world"};
Object>[] readonly = words;
Object o = readonly[0]; // allowed -- all elements are subtypes of Object
readonly[0] = new Object(); // compile error -- storage type may be more specific than Object
String<[] writeonly = words;
writeonly[0] = "goodbye"; // allowed -- String is a subtype of CharSequence
String s = writeonly[0]; // compile error -- element might not be a String

Or maybe there is a way to do it with the existing generic syntax with T extends and T super on the element types, I dunno...

Eugene Katrukha
@ekatrukha
Hello everybody. Quick question, there was a class for n-dimentional Bresenham line in net.imglib2.algorithm.region, but it is not there anymore. Can you please help me find where it was moved?
Eugene Katrukha
@ekatrukha
thank you!
Curtis Rueden
@ctrueden
I encountered a bug when upgrading imagej-ops to imglib2-algorithm 0.12.0. @maarzt changed how Gaussian smoothing works (imglib/imglib2-algorithm@c3232dd), so our tubeness op's test now fails. To address it, tomorrow, @gselzer will regenerate our ground truth expected output image. Just a heads up to others that if you have code relying on the previous output, the newest imglib2-algorithm release changes the result.
Jean-Yves Tinevez
@tinevez
Is it the tubeness op I adapted? Do you want me to work on this issue?
Gabriel Selzer
@gselzer
@ctrueden @tinevez fixed.
To push to configurable-threads, I had to generate a PAT. I've never had to do that before, which was strange
Jan Eglinger
@imagejan
@gselzer did you push to the git URL via https instead of ssh?
Gabriel Selzer
@gselzer
@imagejan yup, that was it
Curtis Rueden
@ctrueden
Tangentially: in case others haven't noticed yet, git:// is no longer supported. They seem to be in the process of phasing it out; I've had some repos barf on it now, and others still work.
I think I might have been the only one in the world still using git:// anyway 🤷
Tobias Pietzsch
@tpietzsch
@ctrueden I'm also using it...
good to know
Matthias Arzt
@maarzt
@ctrueden, @gselzer, sorry to here that this change caused trouble to you. The change to the gaussian kernel was made for exactly algorithms like tubeness that calculate derivates of a gaussian blurred image. The hardly cut off gaussian kernel that the algorithm previously used would create some artifacts in the derivates. The kernel now is consistent with the IJ1 gaussian and the result of tubeness filter should improve.
Matthias Arzt
@maarzt

There's another change to the gauss algorithm in imglib2-algorithm version 0.12.1. The new change won't effect any results. But gauss should run faster for small images. And it's now possible to execute Gauss3.gauss(...) single threaded by using the imglib2 Parallelization context:

\\ By default: multi threaded execution
Gauss3.gauss(sigma, source, target);
\\ Execute single threaded using the parallelization context
Parallelization.runSingleThreaded(() -> gauss(sigma, source, target));
\\ Or if really needed you may as well set the ExecutorService or number of tasks
Parallelization.runWithExecutor(executorService, () -> gauss(sigma, source, target));
Parallelization.runWithNumTreads(numThreads, () -> gauss(sigma, source, target));

The multi-threaded LoopBuilder and Parallelization context make it indeed very easy to implement multi-threaded algorithms. Or to update them. This raises an important question:
How should we deal with existing single threaded algorithms in imglib2-algorithm? (Like for example PartialDerivative.gradientForwardDifference
Should we change them to use multi-threading, or should we add multi-threaded methods with a different name?

I'm happy to here your opinions. Here is the related imglib/imglib2-algorithm#83

Curtis Rueden
@ctrueden
@maarzt Awesome, thanks for all your work on this! :+1:
For what to do with existing algorithms: I think it depends on whether multithreading them would change the result.
If you arrive at the same deterministic answer as before, then I vote to definitely switch them over to multithreading.
If the result changes, but is still deterministic, you could add new method sig(s) and deprecate the old one(s).
If the result of multithreading it becomes non-deterministic, that's a problem for Ops and probably others using the algorithm, so we should be careful there.
Jean-Yves Tinevez
@tinevez
Awesome !
Tobias Pietzsch
@tpietzsch
I would also change to multi-threading by default. (or rather using current Parallelization context by default). I would prehaps keep the single-threaded versions under an explicit name (e.g. PartialDerivative.gradientForwardDifferenceSingleThreaded) for things that are possibly run on tiny things where even querying the Parallelization ThreadLocal could be considered too much overhead. These "kernel methods" are perhaps anyway used as building blocks for the multi-threaded versions, and I don't see a big downside to exposing them.
Tobias Pietzsch
@tpietzsch
But multi-threaded by default is good
@axtimwalde @StephanPreibisch opinions?
Mark Kittisopikul
@mkitti
Per discussion in SciJava, could I move BDV Core to use hdf.hdf5lib.H5 in JHDF5 19.04?
Mark Kittisopikul
@mkitti
It's likely to going to have to be an ecosystem wide effort to update, but opening up more HDF5 functionality will important moving forward. Plus I think the hdf.hdf5lib.H5 JHI5 interface from HDF Group should be more stable going forward.
Tobias Pietzsch
@tpietzsch
Hi @mkitti. That discussion belongs in https://gitter.im/bigdataviewer/bigdataviewer-core
But, yes! Please do! that would be very welcome
Gabriel Selzer
@gselzer
@maarzt I've been using your LoopBuilder work in the new incarnation of Ops, and I've noticed that sometimes it will throw an ArrayOutOfBoundsException, but this exception does not seem to be thrown deterministically.
This Op is the one that will sometimes throw the error, as it calls this guy
Here is the error I'm getting, do you know what this might be stemming from?
java.lang.ArrayIndexOutOfBoundsException
    at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
    at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
    at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
    at java.base/java.util.concurrent.ForkJoinTask.getThrowableException(ForkJoinTask.java:603)
    at java.base/java.util.concurrent.ForkJoinTask.getException(ForkJoinTask.java:933)
    at java.base/java.util.concurrent.ForkJoinTask.invokeAll(ForkJoinTask.java:854)
    at net.imglib2@5.11.1/net.imglib2.parallel.ForkJoinExecutorService.invokeAll(ForkJoinExecutorService.java:126)
    at net.imglib2@5.11.1/net.imglib2.parallel.DefaultTaskExecutor.forEachApply(DefaultTaskExecutor.java:121)
    at net.imglib2@5.11.1/net.imglib2.loops.LoopBuilder.runUsingRandomAccesses(LoopBuilder.java:356)
    at net.imglib2@5.11.1/net.imglib2.loops.LoopBuilder.forEachChunk(LoopBuilder.java:199)
    at net.imglib2@5.11.1/net.imglib2.loops.LoopBuilder.forEachPixel(LoopBuilder.java:158)
    at net.imagej.ops2/net.imagej.ops2.map.neighborhood.MapNeighborhoodAllRAI.compute(DefaultMapNeighborhood.java:127)
    at net.imagej.ops2/net.imagej.ops2.map.neighborhood.MapNeighborhoodAllRAI.compute(DefaultMapNeighborhood.java:97)
    at org.scijava.ops.engine/org.scijava.ops.engine.matcher.impl.OpWrappers$Computer3OpWrapper$1GenericTypedComputer3.compute(OpWrappers.java:884)
    at net.imagej.ops2/net.imagej.ops2.filter.mean.DefaultMeanFilter.compute(DefaultMeanFilter.java:73)
    ...
(I figured it was probably an input dimension mismatch, but that doesn't seem to be the case)
Matthias Arzt
@maarzt

Hi @gselzer, the stack trace is somehow incomplete. There should be another part, that starts with: Caused by: java.lang.ArrayIndexOutOfBoundsException:. This other part would contain the stack trace of the exception that occurred first.

It is most likely that the action passed into LoopBuidler.forEachPixel(action) has thrown an ArrayIndexOutOfBoundsException.
Possible reasons could be that something is wrong with the images that is passed to the Op or the OutOfBoundsFactory. I don't know?

I have no clue why the exception is non deterministically. Maybe you could point me to a minimal example if I should help debug the code.

Gabriel Selzer
@gselzer

Hi @gselzer, the stack trace is somehow incomplete. There should be another part, that starts with: Caused by: java.lang.ArrayIndexOutOfBoundsException:. This other part would contain the stack trace of the exception that occurred first.

It is most likely that the action passed into LoopBuidler.forEachPixel(action) has thrown an ArrayIndexOutOfBoundsException.
Possible reasons could be that something is wrong with the images that is passed to the Op or the OutOfBoundsFactory. I don't know?

I have no clue why the exception is non deterministically. Maybe you could point me to a minimal example if I should help debug the code.

Thanks @maarzt

You should see it if you checkout scijava/incubator@367d716 and run this test a couple of times
17 replies
I do remember getting the second ArrayIndexOutOfBoundsException, I just didn't copy it.
I too think that it is possible that there is something wrong with the images, but I didn't look too hard beyond ensuring that the images passed to LoopBuilder are always the same size, even when the Exception is thrown
Eugene Katrukha
@ekatrukha
Hello everybody, quick noob question, if I do something like : IntervalView< FloatType > iVsome = Views.interval( Views.extendPeriodic( someImg ),interval); and then try to change the values of iVsome using Cursor, it will not work out, right? It is a bad bad idea? I should rather copy iVsome to some new Img, correct? Thanks for your help.
7 replies
Eugene Katrukha
@ekatrukha
Happy coming 2022 everybody! This year I finally started heavily using imglib2 (after learnathon 2 years ago) and wanted to congratulate/express my gratitude for creators and mainteiners on this diverse and thoughtful library. Saves so much time. 🙏 My only minor pet-peeve is XYCZT sequence, but what other code does not have an annoying specialty 😝
Jan Eglinger
@imagejan
Isn’t XYCZT rather an ImageJ 1.x specialty? An ImgLib2 Img and RandomAccessibleInterval doesn’t have any axis metadata. That information is only present in ImageJ2’s higher level API such as ImgPlus and Dataset.
Eugene Katrukha
@ekatrukha
You are right, it is, my bad. Then it is nearly perfect :) I am still using ImageJ 1.x as input/output, so struggle with it.
Stephan Saalfeld
@axtimwalde
Thanks and happy new year to you too! May be these methods can help? https://github.com/imglib/imglib2/blob/master/src/main/java/net/imglib2/view/Views.java#L435-L484
1 reply