Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Oct 20 16:13
    tinevez closed #27
  • Oct 20 16:13
    tinevez commented #27
  • Oct 20 12:04

    tinevez on master

    Prevent error when the fade tra… (compare)

  • Oct 20 11:42

    tinevez on MaMuT-7.0.2

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

  • Oct 20 11:42

    tinevez on master

    Bump parent pom to pom-scijava … Temporary coupled to TrackMate … Fix compile errors with v7.2.0 … and 1 more (compare)

  • Oct 20 08:12

    tinevez on master

    Change the gamma letter for the… Fix directional change edge fea… (compare)

  • Oct 20 07:03
    tinevez closed #26
  • Oct 20 07:03
    tinevez commented #26
  • Oct 19 12:10
    tinevez closed #23
  • Oct 19 12:10
    tinevez commented #23
  • Oct 19 12:09
    tinevez labeled #27
  • Oct 19 12:09
    tinevez assigned #27
  • Oct 19 12:09
    tinevez opened #27
  • Oct 19 12:08
    tinevez assigned #26
  • Oct 19 12:08
    tinevez labeled #26
  • Oct 19 12:08
    tinevez opened #26
  • Oct 18 21:36

    ctrueden on fix-op-test-files-from-jar

    WIP: Try mapping the stream whe… (compare)

  • Oct 18 13:19
    tinevez closed #197
  • Oct 18 09:10
    tinevez closed #297
  • Oct 18 07:19
    RussiaVk opened #297
Tobias Pietzsch
@tpietzsch
Otherwise it would be null
Maybe it would be also set, if you save the SpimData to a (different) XML file
but that already gets interesting
NicoKiaru
@NicoKiaru
oki doc. Maybe another option is to add an abstract save or resave method to spimdata ? Would that make sense ? The default behaviour would be what you describe. But I'm not familiar with use cases other than the simple ones. I do not want to add a dirty patch which turns out to be annoying.
Tobias Pietzsch
@tpietzsch
I'm not sure how that would play with extensibility
AbstractSpimData and XmlIoAbstractSpimData play together somehow
and then SpimDataMinimal, XmlIoSpimDataMinimal, etc
I wouldn't do it
But potentially you could make a wrapper around a SpimData and a XmlIo that has these methods and keeps the filename
(then we need to make sure, that the default spimdatas in Fiji always are loaded in a way that they have the wrapper)
something like that?
NicoKiaru
@NicoKiaru
yep. Ok. For now I will not touch anything, and keep things the way they are. I'll let the user define the dataset name, and with the Parameter being persistent, it's not complicated : if he wants to resave and erase the previous dataset, he lets the same name, and if he wants to avoid erasing the dataset, he changes the name - another dataset is created.
Not ideal, because this dataset name is not transfered from one Command to another. I'll investigate more your advice when required. Thanks a lot !
Tobias Pietzsch
@tpietzsch
Maybe you can just make a static Map< SpimData, String (with weak keys)
or attach that association to the Context somehow?
Curtis Rueden
@ctrueden
There is a CacheService backed by a weak hash map, into which you can put that stuff.
Tobias Pietzsch
@tpietzsch
👍
NicoKiaru
@NicoKiaru
I realized I have another related issue. Suppose I call BdvFunctions.show(mySpimData);. If I update a viewRegistration in the mySpimData object, can I update what is displayed in the bdv window ? Should I close it and reopen it ? thanks!
Tobias Pietzsch
@tpietzsch
In practice, it is enough to move to a different timepoint and back to make the transforms reload from the mySpimData
But that is more an implementation detail of the current sources
(but pretty reliable)
otherwise: BdvFunctions.show(mySpimData); returns a List<BdvStackSource<?>>
you can use the BdvSource.removeFromBdv() for each of the BdvStackSource and then use BdvFunctions.show(mySpimData, Bdv.options().addTo(...)); to add them again
NicoKiaru
@NicoKiaru
Ok, since I'm working with 2d slice scanners file, there's no (or a single) timepoint. I'll try the other option.
Tobias Pietzsch
@tpietzsch
Depending on whether its a window or just a panel:
the window will probably close when all sources are removed
so maybe BdvFunctions.show(mySpimData, Bdv.options().addTo(...));
before you remove the old sources
NicoKiaru
@NicoKiaru

There is a CacheService backed by a weak hash map, into which you can put that stuff.

I wasn't aware of the CacheService, and I didn't know what a WeakHashMap was. That looks incredibly useful!

Kyle I S Harrington
@kephale
@maarzt labkit is looking fantastic these days. has anything been developed for applying the classifiers trained with labkit in a headless way (e.g., train on my laptop, segment on a cluster)?
oh, Others > Batch segment images, i can find the corresponding code
Christian Tischer
@tischi
@tpietzsch @NicoKiaru would it be feasible and useful to implement a BdvFunctions.show( SourceAndConverter )? I think that would be very useful to, e.g., give users the possibility to use own LUTs for displaying data in the Bdv. Currently, to achieve this, one needs to construct oneself a Source<ARGBType> and then call BdvFunctions.show( Source<ARGBType> ). This works fine in principle, but the actual pixel values in Bdv are then from 0 to 255 and do not reflect the real data anymore, which I think is not ideal.
NicoKiaru
@NicoKiaru
Actually, related to the point @tischi suggest : I try to implement a bigdataviewer- scijava repo, and one problem I came across is the following : when you perform processing, you want to act on the 'real' source, but when you want to display it, you want a 'volatile source' (or a converter (Volatile)ARGBType, as @tischi said). To circumvent this issue, I wanted to use the CacheService with WeakHashMap in order to be always able to retrieve the source and the volatile source (and potentially the RGBified source), one form another. But I don't know if it's a good idea. If you think it is, I'll go for it. If you plan to implement extra stuff in BdvFunctionsor in the new BigDataViewer UI which will make my efforts obsolete very fast, I'd rather not do it.
Philipp Hanslovsky
@hanslovsky
@tischi sounds like a great pull request :smile:
@NicoKiaru In Paintera I keep track of the data and volatile sources. In particular, I implemented an interface DataSource<T, V> extends Source<V> that provides both the data and volatile voxels. (As it extends Source, you could just pass it into a regular BDV if you wanted to)
Also, @tpietzsch is on vacation right now.
Christian Tischer
@tischi

Also, @tpietzsch is on vacation right now.

Maybe I better way until he is back before working on the PR? Because I think we talked about this before and I am not sure what his latest plans were...

Christian Tischer
@tischi

when you perform processing, you want to act on the 'real' source, but when you want to display it, you want a 'volatile source' (or a converter (Volatile)ARGBType

This was partly my point of suggesting to work more with SourceAndConverter objects, because you would have the Source holding the actual data together with the Converter< R, VolatileARGBType > that can be used for rendering. The job of actually applying the Converter to the Source could then be delegated to be done inside Bdv, because outside Bdv it anyway isn't useful?!

However, one limitation with this idea is here: https://forum.image.sc/t/bigdataviewer-blending-modes/28568/8
For my applications, I seem to need to also specify a special VolatileARGBType out-of-bounds value, which is currently not part of the Converter but of the Source....

NicoKiaru
@NicoKiaru
@tischi, ok, if I understand correctly, there's no need to keep an extra volatile source, because you can do everything using the VolatileARGBType, right ?
NicoKiaru
@NicoKiaru
@hanslovsky cool! I fear a bit the fact, that I'm wrapping many times the source (Source -> AffineTransformedSource -> WarpedSource (-> DataSource)). But that looks like a very good solution. (this interface, right ? https://github.com/saalfeldlab/paintera/blob/master/src/main/java/org/janelia/saalfeldlab/paintera/data/DataSource.java). However why is your function getDataSource(int t, int level); returning a RandomAccessibleInterval ? Why not a Source ?
Philipp Hanslovsky
@hanslovsky
Because all the shared meta data (transforms, etc) are stored within a single source, that way.
And I can just query the data or volatile as I need it
NicoKiaru
@NicoKiaru
Ah I see, so you track somewhere else the list of sources which should be transformed in an identical manner ?
Philipp Hanslovsky
@hanslovsky
Each source (and data source) has its own transform in my use case. It's just a matter of accessing data and volatile voxels in a consistent way
NicoKiaru
@NicoKiaru
Ok, I'll have to think about it, thanks for the explanations
Christian Tischer
@tischi
@NicoKiaru I discussed this once with Tobias and I think the conclusion was that one usually only needs Volatile pixels types within the Bdv for rendering, such that you can rotate a volume quickly, even is the data is not yet loaded (i.e. not valid). For any sort of computation one typically wants to have the actual valid data. Thus, I think, one way of seeing the issue is that we would never have to care about Volatile data outside Bdv, but upon saying BdvFuntion.show( source ), Bdv would internally VolatileViews.wrapAsVolatile( ... ) for you. Currently however there are some limitations, e.g. VolatileViews.wrapAsVolatile( ) is only implemented for RandomAccessible and not for a Source and also VolatileViews.wrapAsVolatile( ) does not always work, e.g. if the RAI is internally derived from too complicated Views and Converters. With the help of @hanslovsky I added some functionality to VolatileViews.wrapAsVolatile( ) to make it cover more scenarios, see e.g. https://github.com/tischi/fiji-plugin-bigDataProcessor2/blob/master/src/main/java/de/embl/cba/bdp2/volatiles/VolatileViews.java#L186 but there are still cases where it cannot handle it.
NicoKiaru
@NicoKiaru
cool! Thanks @tischi that's very good to know. Maybe we can work on this Source wrapping in BdvFunctions @tischi ? Would this class be generic enough ? https://github.com/BIOP/bigdataviewer-bioformats/blob/master/src/main/java/ch/epfl/biop/bdv/bioformats/bioformatssource/VolatileBdvSource.java
For now, while waiting for BdvFunctions to wrap a Source into a volatile Source, I think we have to keep the (optional) wrapping in the bigdataviewer-bioformats repo.
NicoKiaru
@NicoKiaru
Something which is not clear to me is the image loader: outside of BdvFunctions, it seems that a SetupLoader which extends an AbstractViewerSetupImgLoader should also provide a Volatile source. As a consequence the source volatile wrapping has to be done internally to the repository anyway.
Christian Tischer
@tischi

it seems that a SetupLoader which extends an AbstractViewerSetupImgLoader should also provide a Volatile source.

This is exactly the kind of stuff I was also just thinking about. To me, right now it seems as if there are two ways to provide Volatile pixels: (a) via the SetupLoader logic and (b) via this kind of logic: https://github.com/tischi/fiji-plugin-bigDataProcessor2/blob/master/src/main/java/de/embl/cba/bdp2/volatiles/VolatileViews.java#L118 where a CachedCellImg can be made to return Volatile pixel values. Honestly, I think I would need a Skype, probably with someone like @tpietzsch or @hanslovsky and a white-board to draw how all these things are connected :-)

Philipp Hanslovsky
@hanslovsky

The SetupLoader existed before the CachedCellImg. I use CachedCellImgs exclusively because it is extremely convenient. There may be benefits of SetupLoader that I am not aware of.

VolatileViews.wrapAsVolatile should be sufficient for any/most standard ImgLib2 native types. It gets a little more tricky when more complex types are being used, e.g. LabelMultisetType in Paintera, or Composite<T> vector-like types.