Closed AlbertDominguez closed 3 months ago
Great, thanks for reporting this @AlbertDominguez ... could you please share the cmd-line/ImageJ macro call that you used?
In general, Java/ImageJ uses XYZ order ... but at least the same pixel origins as Python (there is a 0.5,0.5,1 xyz offset to Matlab compared to Java/Python)
Hi, I found the bug ... a mix-up of array indices. And with a block size of 1 it will go into an infinite loop since it needs an overlap of 2 pixels. https://github.com/PreibischLab/RS-FISH/commit/5370293f55ad0cf738655d24e69535a197f3bf11
Great catch, thanks so much @AlbertDominguez
And I also uploaded it to the Fiji update site if you'd like to check that it works now .... thanks @AlbertDominguez
I've just tried it, and it works as expected!
Thanks a lot @StephanPreibisch :)
Hi! First, thanks for developing this great method!
When running benchmarks on 2D (YX) data with an ImageJ macro from the command line, I found the execution to completely stall without any warning. After some time (and seeing that the multithreaded version works very nicely on 3D data), I realised it has to do with the block sizes values.
Basically, the following two combinations do not work and cause the execution to stall and sometimes throw an OOM:
However, this one does work:
So basically, for 2D data, the program stalls without any warning if the sizes on
Z
orX
are too small (<=2
). Is this intended?What confused me a bit is that I would have expected the dimensions to be XY/YX, not XZ/ZX (but to that end I have little to None experience with ImageJ, so might be my bad). In any case, it might be nice to add either a warning/Exception if there are inconsistencies with the array/input blocks.