Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Aug 22 17:44
    ctrueden commented #205
  • Aug 16 17:34
    acardona opened #231
  • Aug 07 13:48
    chalkie666 opened #230
  • Aug 02 13:33
    tinevez labeled #107
  • Aug 02 13:33
    tinevez labeled #107
  • Aug 02 13:32
    tinevez opened #107
  • Aug 02 13:30
    tinevez commented #106
  • Aug 02 13:29
    tinevez synchronize #106
  • Aug 02 13:29

    tinevez on serialize-feature-model2

    Avoid feature name inflation wh… Update the MaMuT exporter examp… (compare)

  • Jul 18 11:57
    tpietzsch commented #106
  • Jul 18 11:44
    tinevez commented #106
  • Jul 18 11:41
    tpietzsch commented #106
  • Jul 18 11:32
    tinevez commented #106
  • Jul 18 11:31
    tpietzsch commented #106
  • Jul 18 11:20
    tpietzsch synchronize #106
  • Jul 18 11:20

    tpietzsch on serialize-feature-model2

    formatting Demonstrate that feature names … Add TODO and 2 more (compare)

  • Jul 10 13:08
    tinevez closed #104
  • Jul 10 13:08
    tinevez commented #104
  • Jul 10 13:08
    tinevez opened #106
  • Jul 10 10:56

    tinevez on serialize-feature-model2

    Fix weird compile error with Op… Make some static methods of MaM… JUnit test for the TrackMate im… and 5 more (compare)

Florian Jug
@fjug
It might be very helpful if the MM2 guys use CV… in that case we would get immediate feedback from many users in case CV breaks on some platforms...
Ulrik Günther
@skalarproduktraum
we could - in the meantime - do a bit more sophisticated automated testing… though i have no idea how we could check for graphical output in travis or so
or actually i do… we could query the texture we render to and write that to a file
oh and for the record, the clearvolume plugin currently freezes for me, also on el cap
Florian Jug
@fjug
@skalarproduktraum ok, lets chat about that in CV/CV or tomorrow at MPI. I strongly suggest we find a fix fast so that Nico is not stopping his work on MM2+CV...
Ulrik Günther
@skalarproduktraum
yip
all in for that
i just wanted to mention the issue as @tinevez mentioned a similar one above with the fiji 3d viewer
Florian Jug
@fjug
nod
Michael Doube
@mdoube
BoneJ uses a bunch of stuff in the 3D Viewer's API (e.g. Marching Cubes mesh creation), and also heavily uses it for e.g. particle visualisation. A roadmap for migrating client code would be helpful if considering ditching 3D Viewer.
Jean-Yves Tinevez
@tinevez
Hi @mdoube yes ditching is probably not such a great idea. I also forgot that TrakEM2 depends on 3D viewer as well for some of its functionality. We will disable a large part of Fiji if we remove 3D viewer.
Michael Doube
@mdoube
@tinevez one way to find out how used it is would be to remove the 3D Viewer resource from your IDE and see what chaos ensues...
Curtis Rueden
@ctrueden
@tinevez Ah crap, I forgot about TrakEM2 when I created the 3D update site. I didn't update its class references. I failed to grep for usages of Java 3D in trakem2 and bdv orgs.
@mdoube That would work, but only if you first imported all the projects, and then snapshot coupled them using the dev profiles.
Kyle I S Harrington
@kephale
i use marching cubes a bit too, but is there really a great reason other than the development history for it staying in 3D viewer?
Curtis Rueden
@ctrueden
You guys, you guys! Marching cubes is in ImageJ Ops already, thanks to the efforts of @tibuch.
Kyle I S Harrington
@kephale
OH! @ctrueden @tibuch, my heros yet again
Michael Doube
@mdoube
@ctrueden that's exactly the kind of info we need to migrate our code: @rimadoma could you make a 'todo' to look in to what would be required for BoneJ to stop using 3D Viewer while maintaining functionality?
Curtis Rueden
@ctrueden
@mdoube In general, ImageJ Ops is the future of all the image processing algorithms. If you need an image processing algorithm and it's not already in ops, let's discuss the best way forward!
Michael Doube
@mdoube
This message was deleted
@ctrueden but that implies that things like LocalThickness - an algorithm that measures 3D geoemtry like much of BoneJ - should be in the net.imagej.ops.geom.geom3d namespace rather than sc.fiji, as we were discussing somewhere else. A clear policy document on this point would be very helpful for contributors.
Curtis Rueden
@ctrueden
@mdoube It should move there, yes, after it is actually implemented in the Ops framework. Which right now it isn't. Agreed about the value of a policy doc.
I would strongly advise @rimadoma to learn the Ops framework. Note though that moving plugins to Ops entails a nearly complete rewrite. I suppose that is a major goal of BoneJ2, right?
Michael Doube
@mdoube
@ctrueden you got it - BoneJ is getting rewritten for ImageJ2. Our main concern at this stage is whether there will be a performance hit, and how to mitigate that.
Ignacio Arganda-Carreras
@iarganda
@ctrueden I'm testing your version of the 3D viewer using java 1.7 and java3D 1.6. For now the transparency problem with isosurfaces remains (at least on my Ubuntu machine). I have a question for you: do I need to do anything new to import javax.vecmath classes from a script? Both the Script Editor and the Beanshell Interpreter have stopped finding those classes.
Curtis Rueden
@ctrueden
@iarganda The package prefix changed. It is now (temporarily) org.scijava.vecmath.
It will become org.jogamp.vecmath in the future.
Kyle I S Harrington
@kephale
@ctrueden but might there be some interest in debating where the contents of that package end up in the future, especially with respect to the 2-4D Vector*f classes?
Ignacio Arganda-Carreras
@iarganda
Thanks @ctrueden !
Richard Domander
@rimadoma
I guess you have realized that Fiji has an infinite acronym? ;)
i.e. Fiji -> Fiji is just ImageJ -> Fiji is just ImageJ is just ImageJ...
Jan Eglinger
@imagejan
@rimadoma yes, I guess that was its intention. It's been on the wikipedia list of recursive acronyms for a while:
https://en.wikipedia.org/wiki/Recursive_acronym
Curtis Rueden
@ctrueden
@kephale Not really our decision unless we want to permanently fork. We csn participate in community discussion if you have a case for different package/class names for Java 3D 1.7's vecmath. I will send you the JogAmp forum thread link when I get to the office.
Regarding extending the Apache Commons Math and/or vecmath types: I favor composition over inheritance. I.e.: adapters to and from ImgLib's chosen vector class (es).
Kyle I S Harrington
@kephale
@ctrueden Okey. Composition is certainly the lisp strategy anyway, so I'm happier with it. I'm just focusing on these specific data structures for rendering speeds.
Anywho, I'll poke at at some tests before the hackathon and be persuasive with numbers instead of words ; )
Curtis Rueden
@ctrueden
@kephale Here is the JogAmp forum thread.
Kyle I S Harrington
@kephale
@ctrueden ooo a new maintainer finally!!
Pariksheet Nanda
@omsai
@ctrueden I see you are the current maintainer for the Cell Counter plugin. I have an incomplete patch omsai/Cell_Counter@80d77c8 to add a scrollbar to the cell counter list (one of our users has 30+ cell types and without scrollbars the plugin window grows beyond her screen size). But the problem is I need to change line 449 in the change set; the scrollbars need to be set to the actual window size. I can't think where in the code to set the scroll window size, as it relies on the widgets being drawn (the Eclipse debugger reports widget widths and heights as being 0 while in initGUI()).
Curtis Rueden
@ctrueden
@omsai Are you sure you need to use Cell Counter, instead of ImageJ's built-in multi-point tool? It supports multiple marker types now, doesn't it?
Curtis Rueden
@ctrueden
@omsai Try upgrading to the latest daily build, and double clicking the multi-point tool. It supports up to 100 counter types now.
Curtis Rueden
@ctrueden
@omsai I really hope the updated multi-point tool works for your user, because updating the Cell Counter UI is a PITA. I spent ~30 minutes messing with it, but GridBagLayout is horrible. If we really have to fix it, I recommend redoing the UI with a different layout manager.
Pariksheet Nanda
@omsai
Cheers, @ctrueden. I imagine the user would be happier with the multi-point tool, because having Cell Counter open did not allow switching to non-point ROIs (e.g. lines). To be honest I'm not all that familiar with Cell Counter (today was the first I heard of it). I'm playing with it now. Will try and stop by the user's lab tomorrow to understand their use case and workflow better. Thanks for the tip about the layout manager! Looks like BorderLayout might be more appropriate which I can look into if the user wants to continue with Cell Counter.
Curtis Rueden
@ctrueden
@omsai Cool, let me know how it goes. For layout managers, I prefer MiGLayout. It generally works as you expect (as much as any layout manager does/can, anyway).
Pariksheet Nanda
@omsai
@ctrueden nice! I was actually leaning towards MiGLayout from it's efficient API in the documentation, and see we have 3.7.4 bundled in FIJI. I'm going to meet the user in another 3 hours.
Nico Stuurman
@nicost
@ctrueden Hope you can help! I am trying to build a bridge between Micro-Manager 2.0 and ClearVolume such that a ClearVolume renderer can be opened on a MM dataset. Making nice progress (http://valelab.ucsf.edu/~nstuurman/CV-MM-Desktop.png), but run into the strange problem that the code works fine when it is run under NetBeans, but not as a stand-alone. It seems to boil down to a class-loader issue and the exception occurs after bridj tries to register it’s own Callback type and after registering com.nativelibs4java.opencl.library.IOpenCLLibrary$clSetEventCallback_arg1_callback. Strangely, things are fine with the ClearVolume plugin under Fiji (which goes through the same sequence of calls). Is there a difference between class loading in Fiji and vanilla ImageJ1? Lots more details in the ClearVolume room here on gitter.
Ulrik Günther
@skalarproduktraum
@ctrueden: with MM2 bolted on top of fiji, it actually works … some classloader issue?
Curtis Rueden
@ctrueden
@nicost @skalarproduktraum There is a huge difference between ImageJ2 and ImageJ1 when it comes to class loading, yes.
Specifically: all ij.* classes are runtime patched in IJ2.