It is a hint to the asynchronous loading infrastructure in the background: Data that might be enqueued for loading is not immediately needed anymore, and new requests should be prioritized. For example when moving to timepoint 2, then image tiles that were required to render timepoint 1 and are still enqueued for loading can be discarded (or bumped to a lower priority)
In general nothing bad happens if this hint is simply ignored.
SharedQueue is a CacheControl
Several VolatileImages can share the same
SharedQueue (hence the name)
The idea is that block requests from these images (which might be visible at the same time) are sorted into the same priority queue and serviced by the same loader threads. (instead of having a group of threads for each image that fight for resources and are basically prioritized the same)
Ok, thanks @tpietzsch this makes a lot of sense! So let's say I need to open hundreds ( ~200) of sources at the same time. Currently I create a
SharedQueue(1) for each source. I assume it's probably more efficient to create a single SharedQueue(x), indeed shared for all sources ? What value of x would be appropriate ? Should x be equal to the number of cpu cores ? Also, would it diminish the risk of getting a Java Heap Space issue ?
Yes, a single
SharedQueue would be better, however, 200 sources could become inefficient? If that is the case, I would implement an intermediate cached source that combines the 200 sources (you can do this with a simple Converter over a Composite). But that means that you would lose the sliders and stuff...
I guess there is: PositionableIterableRegion; but is there a utility function similar to
Regions.iterable(RAI<B>) to retrieve those?
@imagejan The javadoc for that class says "We put interfaces
RandomAccessibleInterval<BooleanType>, IterableRegion<BooleanType>, PositionableIterableRegion<BooleanType> into this sequence such that the Regions methods that "add capabilities" (being iterable, positionable) can have appropriate result types."
This suggests to me that @tpietzsch intended for there to be more
Regions methods exposing it. But I don't see them.
In this case though, we just want a
LocalizableIterableRegion. Not Positionable. Right? I think the latter is more complex.
IterableRegion does have a localizingCursor method.
That is: the
IterableRegion (similar to RAI and II) does not have a position. But it can give you accessors that do.
Note that
IterableRegion<T extends BooleanType<T>> extends IterableInterval<Void>. So... the cursor() method returns Cursor<Void>. So that you can iterate the positions, but you can't access sample values because there is nothing to access (the backing region is just true at those spots, always).
Let's see...
Right now, you do:
RealMaskRealInterval myMask = ...;
RandomAccessible<T> myImage = ...;
IterableInterval<T> myMaskedImage = Regions.sample(myMask, myImage);
Cursor<T> c = myMaskedImage.localizingCursor();
long[] pos = new long[c.numDimensions()];
while (c.hasNext()) {
T value = c.next();
c.localize(pos);
// and now we do something with the position and sample value
}
However, there are some limitations:
myMaskhas to be aRealMaskRealInterval, not aRealMask. This is unfortunate. We could add aRegions.sample(RealMask, RandomAccessibleInterval)that creates aRealMaskRealIntervalmatching the bounds of the given RAI. I think?- This
myMaskedImagecannot be used withLoopBuilderbecauseLoopBuilderonly supports RAI images, not II images. So we have to use this clunkier cursor code, rather than a nice lambda.¯\_(ツ)_/¯
Do you agree with (1) that we could have a better utility method here?
Because I think the most common thing is that you have a
RealMask (not necessarily a RealMaskRealInterval) and a RAI and you want to combine them.
Hm, so far I've only seen examples of this in discrete space, i.e. going via
RandomAccessible and IntervalView, see imagej-roi-course
It makes sense as its own project during the learnathons... but then why not follow up by migrating shared useful materials out of learnathon space and into the official tutorials repo?
Unfortunately, they have been a hodge-podge of git repositories. Which ends up being fine during the event, and really tough afterward to see what's been presented.
@NicoKiaru I have the following workflow:
- I open a XML/H5 (that contains only a single
Source) and view it in BDV. - In BDV I change its
AffineTransformusing the manual transform UI of BDV - Now I would like to save a new
*.xmlfile that looks exactly as the original one that I opened, but I want a new<affine>...</affine>content, reflecting the additional transform that I manually added in BDV.
Do you know how to do this most efficiently? Do I have to construct a new SpimData object from the TransformedSource and then use XmlIoSpimData.save()? If so, would you have code already to construct SpimData from a single Source and the path to the corresponding .h5 file? Or are there other ways to save such an .xml file?
Hi Christian, you can use this
spimData.getViewRegistrations().getViewRegistration(timePoint,iViewSetup).preconcatenateTransform(myAffineTransform); or spimData.getViewRegistrations().getViewRegistration(timePoint,iViewSetup).concatenateTransform(myAffineTransform);, with myAffineTransform being the transform retrieved from the TransformedSource. Then you can resave the dataset. FYI, I also found a trick to update the spimData when it's shown in the bdv (thanks to reflection to access a private method see https://github.com/BIOP/bigdataviewer_scijava/blob/master/src/main/java/ch/epfl/biop/bdv/scijava/command/spimdata/UpdateSpimDataDisplay.java)