@tischi the n5 downsampling code is in n5-spark, but you can run it on your machine. Take a look at n5-spark repo, there are scripts for building the shaded jar and running it on a local machine. When you run locally, Spark emulates the cluster environment by using threads, and it comes as a self-contained maven dependency so you don't need to install anything extra. You can also run it in your IDE by supplying the following JVM variable:
-Dspark.master=local[1] that sets the number of threads to use, or -Dspark.master=local[*] for using all cores
An
Or is using
imglib2-roi question: is it possible to sample (random) points on a sphere by taking some GeomMasks.closedSphere(...).xor(GeomMasks.openSphere(…))? And/or to get a full list of points representing the sphere surface by some Bresenham-like algorithm?Or is using
imglib2-roi for this a bad idea, and I should rather take a math function of a sphere and sample points “manually” ?
(I was thinking in the direction of ImgLib2 Example 4a, but taking a sphere surface instead of the full volume…)
I am due to retire this machine, after moving some stuff over to bds.mpi-cbg.de and archiving the rest. Tell me where I can upload your stuff and I can get a tarball of your dir to you
@igorpisarev May I ask couple of questions related to n5-s3?
- Are you using BigDataViewer to view the n5-s3 data?
- Do you have some experience what the optimal block size is for streaming n5-s3 data through the internet into some viewer such as Bdv?
- Is it possible to work with compressed n5-s3 blocks and decompress on the client side? Would this give you a better performance because you need to send less data through the web?
Hi @tischi, for browsing I created N5 Viewer which is a BDV-based plugin that supports AWS and Google cloud: https://github.com/saalfeldlab/n5-viewer
2 - I've only used streaming through cloud platforms for smaller test projects, but I assume that the same guidelines for choosing the block size would apply there, and something like 64x64x64 would be good. I think both S3 and Google Cloud Storage charge not only for the data throughput, but also for the number of I/O requests, so you would probably want to avoid having too many tiny block files.
3 - if you use any N5 compression scheme such as GzipCompression, the blocks are always stored and sent in the compressed form
2 - I've only used streaming through cloud platforms for smaller test projects, but I assume that the same guidelines for choosing the block size would apply there, and something like 64x64x64 would be good. I think both S3 and Google Cloud Storage charge not only for the data throughput, but also for the number of I/O requests, so you would probably want to avoid having too many tiny block files.
3 - if you use any N5 compression scheme such as GzipCompression, the blocks are always stored and sent in the compressed form
@NicoKiaru it should also be super easy to start a BigDataServer locally. See https://imagej.net/BigDataServer
Basically, just download the bigdataviewer.jar
and
java -jar bigdataserver.jar myName myDataset.xml
@NicoKiaru regarding
CacheControl and SharedQueue
CacheControl has only one method: prepareNextFrame()
This is called by BDV whenever the timepoint is changed, the viewer transformation is changed, etc
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
Slightly simplified, it is basically a priority queue for image block requests and a number of threads that service requests from the queue.
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
}