Hmm, I could also maybe make
reifiedType the Type of the Op with type variables substituted, but that could cause confusion and could be a pain to determine that type. Also might be difficult if the Op is multiple Types or is some Type implementing one of our base types (like if we had a StatsOp that implemented Function)
Cannot seem to think of a simple solution
N0 = getTitle(); //N means name
imageToSelectString1 = substring(N0, indexOf(N0,"Position"), lastIndexOf(N0," "+number+" "));
imageToSelectString1 = substring(N0, indexOf(N0,"Position"), lastIndexOf(N0," "+number+" "));
this does not work
@frauzufall I recall us talking the other day about the behavior of computer ops, regarding preallocated output containers if they have preexisting data in them. Here is a relevant thread about that.
No, mostly because we need to define behavior for when the noise addition goes outside of the type range (and we don't know happens since the behavior across RealTypes is not consistent). I wrote about it in #554 , if you want a better explanation (when you have the time, of course)
We should probably just document the behavior for now.
If we want to do it completely properly, we would need to abstract all the math into interfaces...
E.g.
UnsignedLongType.
while queue has more units of work:
workUnit = queue.remove()
for each pixel in constant-size block at workUnit.offset:
noiseValue = workUnit.rng.next()
pixel += noiseValue
3) Main thread waits for all child threads to terminate
Extra credit: instead of:
noiseValue = workUnit.rng.next()You could do:
noiseValue = distroFunction.apply(workUnit.rng.next())
Where
distroFunction is the noise function!
@ctrueden I must have forgotten in the midst of all of the stuff we have talked about, what is the Ops threading strategy?
There isn't really a "current strategy", as you probably noticed.
That was what I assumed @ctrueden, so I spent a bit of time looking at
LoopBuilder yesterday
It seems nice as far as per-pixel operations go, however there are two things that would be nice for Ops that we cannot do:
(At least as far as I could tell with the small amount of time I spent with it)
- It only works on
RAIs, whereas scijava-ops cannot work onRAIs. Of course, ImageJ-Ops can work onRAIs, and we can convertIIs toRAIs, not sure how slow that operation is - It would be nice if
Chunks had a bit more metadata (such as where they were in the image). This information is needed for our deterministic noise adders
Although, imglib/imglib2#279 is kind of cool, and should fix my second issue listed above.
@gselzer Great, yes, please discuss in the imglib2 channel. Yes for (2): you can indeed localize within LoopBuilder loops, using that approach. For (1): "scijava-ops cannot work on
RAIs"—you mean that we do not want scijava-ops to have a dependency on imglib2, right? So yeah, we should discuss with the ImgLib2 team whether to migrate the parallelization framework upstream of imglib2 into some very lightweight scijava-utils or scijava-parallelization thing.
Actually, @ctrueden, I am not sure that the PR I linked above is enough for what we need. We need to generate a MersenneTwister for every
Chunk, but we do not have access to the Interval that the Chunk is operating on. This means we cannot use the min of the Interval to deterministically generate a seed