Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Curtis Rueden
    @ctrueden
    I'm not saying you should definitely do it that way right now. It might be more trouble than it is worth.
    Hadrien Mary
    @hadim
    I like trouble :-)
    Curtis Rueden
    @ctrueden
    Hehe.
    Hadrien Mary
    @hadim
    I didn't find how to get the ImageDisplay from a Dataset ?
    Should I iterate over idService.getImageDisplays() and test for each ImageDisplay ?
    Curtis Rueden
    @ctrueden
    Where are these Dataset objects coming from...?
    I guess I should read your code.
    But not tonight—I need to sleep now, sorry. :-/
    Hadrien Mary
    @hadim
    @Parameter(type = ItemIO.INPUT)
    private Dataset dataset;
    Curtis Rueden
    @ctrueden
    You can just change it to ImageDisplay ;-)
    Hadrien Mary
    @hadim
    yeah that's fine
    ok
    Curtis Rueden
    @ctrueden
    ImageDisplayService has a getActiveDataset which gives that back from the ImageDisplay.
    Hadrien Mary
    @hadim
    I would have prefer a method that specify the dataset but that's fine I'll do with getActiveDataset
    Curtis Rueden
    @ctrueden
    Well, it is possible for a Dataset to be present in multiple displays.
    And to have different overlays in each.
    Now, in the ImageJ 1.x UI that can't happen, really.
    Hadrien Mary
    @hadim
    Hum ok
    Curtis Rueden
    @ctrueden
    But the current data model allows it.
    Think of Dataset as the block of pixels, whereas a display is how you're visualizing it.
    So, Dataset has no position right now.
    Because again: two different displays could be showing it in two different places.
    In reality, there are multiple different sorts of ROIs and overlays... some might be important from the acquisition somehow, whereas others might be specified after the fact by the user—to measure a particular area, or to represent a particular segmentation, etc.
    Hadrien Mary
    @hadim
    Ok I understand
    Curtis Rueden
    @ctrueden
    So, perhaps some kinds of ROIs are saved in the original files on disk. But others, no.
    Anyway, I think if your plugin needs to know which overlay(s)/ROIs are part of the view, it needs to ask for an ImageDisplay instead of a Dataset. That is "more correct" here.
    OK, and now I am really turning in for the night. Otherwise when my kids bounce into my room at 6am I will struggle. :-) Good night @hadim!
    Hadrien Mary
    @hadim
    ahah
    Good night. Thanks.
    Hadrien Mary
    @hadim
    @ctrueden I released a version with the Method 3: Double push to master from http://imagej.net/Development_Lifecycle. It seems to be deprecated but I did it anyway since I couldn't do the other method. Let me know which method is currently used for deployment.
    Richard Domander
    @rimadoma
    I recently bumped my pom-imagej to 15.5.0, I guess something has changed since I don't need to declare runtime dependencies on JOGL anymore :smile:
    Thanks for that
    @ctrueden That mvn dependency:analyze trick you showed here yesterday became in handy. Cheers!
    Curtis Rueden
    @ctrueden
    @rimadoma :beers: !
    @hadim Double push is OK! Someday we will find a cleaner way but it works fine for now.
    Hadrien Mary
    @hadim
    @ctrueden ok. So at this point I have nothing more to do to deploy the plugin in Fiji ? It will be automatic ?
    Curtis Rueden
    @ctrueden
    Nothing for you to do. I will upload the release today if you want. It also needs to be added to fiji/fiji as a runtime dependency. After a new pom-fiji is released.
    Hadrien Mary
    @hadim
    Ok
    ChrisWeisiger
    @ChrisWeisiger
    @ctrueden I got a bug report from Nico for µManager, stating that it doesn't look very good on Windows 10 with high-DPI displays ( micro-manager/micro-manager#256 ).
    Evidently changing the launcher (ImageJ.exe) to be the current ImageJ launcher fixes the problem.
    Do you know what the actual change was?
    I'm pretty sure the fix on our end is to just change the launcher we use, but it'd be nice to know what happened.
    It may be something that was fixed accidentally as a side-effect of other changes, since we are a fair bit behind...so I don't necessarily expect that you will know the answer. Feel free to say so. :)
    Mark Hiner
    @hinerm
    @ChrisWeisiger we've made a few changes to the launcher this year. We fixed some bugs in Java 8 detection, so the first thing I might check is the Java version ImageJ is actually using in each case...
    ChrisWeisiger
    @ChrisWeisiger
    It's still 1.6 for us. We ship our own JRE.
    We want to update to Java 8, but we are (and have been for months) on the cusp of pushing out a new major version, and that's too risky of a change to do right now.
    Is there a specific file I should look at in your repository that will track the changes to the launcher?
    Mark Hiner
    @hinerm
    @ChrisWeisiger the native code is all in this directory
    ChrisWeisiger
    @ChrisWeisiger
    Great, thanks.
    Hm, nothing obvious in the past few months is related to this. Oh well.