[ImageJ-devel] What's left to do for ImgLib2

Wed Oct 29 18:34:33 CDT 2014

Ok, just looking at the code of ApplyManualThresholdTest, I have a hunch of whats going wrong.
The test uses
		final Img<BitType> out = bitmap();

I bet that for the new BitType from the Fractions branch nobody considered the possibility that two cursors might simultaneously write to bits of the same underlying long value.

One solution would be to use locks to synchronize all accesses to the underlying long[] array (this is for BitType, Unsigned12BitType, etc).
However, I fear that this will slow down things considerably.

Is anyone familiar enough with the Java Memory Model to provide an educated guess as to whether a lock-free approach would be feasible?
By lock-free I mean setting the value and then checking whether the value is actually what was expected (and if not, retry).
I’m cc’ing Albert and the imagej-devel and fiji-devel lists to increase the probability that someone might actually know…

best regards,
Tobias

On 30 Oct 2014, at 00:18, Tobias Pietzsch <pietzsch at mpi-cbg.de> wrote:

> Hi Curtis,
> 
> I’m trying to look at it, however I get the following maven error:
> 
> pietzsch at tomancak-mac-17:~/workspace/imagej-ops (imglib2-release)$ mvn -U clean install
> [INFO] Scanning for projects...
> Downloading: http://maven.imagej.net/content/groups/public/net/imagej/pom-imagej/3.2/pom-imagej-3.2.pom
> Downloading: http://repo.maven.apache.org/maven2/net/imagej/pom-imagej/3.2/pom-imagej-3.2.pom
> [ERROR] The build could not read 1 project -> [Help 1]
> [ERROR]
> [ERROR]   The project net.imagej:imagej-ops:0.6.0-SNAPSHOT (/Users/pietzsch/workspace/imagej-ops/pom.xml) has 1 error
> [ERROR]     Non-resolvable parent POM: Could not find artifact net.imagej:pom-imagej:pom:3.2 in imagej.public (http://maven.imagej.net/content/groups/public) and 'parent.relativePath' points at no local POM @ line 5, column 10 -> [Help 2]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please read the following articles:
> [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
> [ERROR] [Help 2] http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableModelException
> 
> How can I fix this?
> 
> best regards,
> Tobias
> 
> On 29 Oct 2014, at 23:37, Curtis Rueden <ctrueden at wisc.edu> wrote:
> 
>> Hi Tobi & all,
>> 
>> [Added Christian to CC, since this mail is mostly about OPS]
>> 
>> Still left to do:
>> 
>> 1) Check out the imglib2-release branch of imglib2-tests and fix the compile errors.
>> 2) Check out the imglib2-release branch of imglib2-script and fix the compile errors.
>> 3) Check out the imglib2-release branch of imagej-ops and figure out why tests fail now.
>> 
>> I spent some hours working on imagej-ops this afternoon. With the latest imglib2 master branch, there is only one remaining test failure. (I guess Tobi's bug-fix fixed the other test failure...)
>> 
>> The problem is really deep, though: the ParallelMapI2I uses multiple cursors simultaneously to iterate over ArrayImgs, and it seems there is a race condition that causes the ApplyManualThresholdTest to intermittently fail.
>> 
>> I have to head out for the day, but if anyone else wants to take a crack at it, I added a WIP to the topic branch that illustrates the issue. Setting a breakpoint on the "WTF" line will stop the code if/when the problem occurs.
>> 
>> https://github.com/imagej/imagej-ops/commit/86f8452f77680dafbff747a86ffca2be4a993b37#diff-da607cd95c8ebd526929f7ea15a1da91R117
>> 
>> On my machine, the problem seems to occur ~40% of the time, depending on the location and quantity of print statements.
>> 
>> Regards,
>> Curtis
>> 
>> 
>> On Mon, Oct 27, 2014 at 11:37 AM, Curtis Rueden <ctrueden at wisc.edu> wrote:
>> Hi Tobi,
>> 
>> > I fixed the remaining errors.
>> 
>> Thanks!
>> 
>> > Curtis, maybe we can do this via Skype tomorrow (i.e. Monday)?
>> 
>> I am available every day from ~9:30am - 4:30pm. I am available via GChat (ctrueden at gmail.com), IRC (#imagejdev and #fiji-devel on freenode) and Skype (curtis_rueden).
>> 
>> > I’ll continue working on these tomorrow.
>> 
>> Thanks again! I'll work on documentation today, then.
>> 
>> Regards,
>> Curtis
>> 
>> On Sun, Oct 26, 2014 at 6:51 PM, Tobias Pietzsch <pietzsch at mpi-cbg.de> wrote:
>> Hi,
>> 
>> On 25 Oct 2014, at 01:02, Curtis Rueden <ctrueden at wisc.edu> wrote:
>> 
>>> Tobias asked if there is anything others could do to help, so here is a list (in my opinion of priority order):
>>> 
>>> 1) Check out the imglib2-release branch of imglib2-tutorials and fix the compile errors.
>> 
>> I fixed the remaining errors.
>> To run these examples I had to do two additional things (not committed because they shouldn’t be required soon)
>> 
>> 1.) I had to add an empty class net.imglib2.img.basictypeaccess.array.BitArray to make scifio able to open the images.
>> This is because at some point scifio does an “instanceof BitArray” check and BitArray isn’t there anymore. These checks should be removed for next scifio version.
>> 
>> 2.) I had to make a SNAPSHOT dependency on imglib2-core because in the current release there is a bug which I fixed in this commit https://github.com/imglib/imglib2/commit/fc0d3ebcd9256e60961180952c0383c47e63d111
>> So already it is time to release imglib2-core 2.0.2
>> It would be absolutely fantastic if you could walk me through how to do that. Curtis, maybe we can do this via Skype tomorrow (i.e. Monday)?
>> 
>>> 2) Check out the imglib2-release branch of imglib2-tests and fix the compile errors.
>>> 3) Check out the imglib2-release branch of imglib2-script and fix the compile errors.
>>> 4) Check out the imglib2-release branch of imagej-ops and figure out why tests fail now.
>> 
>> 
>> I’ll continue working on these tomorrow.
>> 
>> all the best,
>> Tobias
>> 
>> On 25 Oct 2014, at 01:02, Curtis Rueden <ctrueden at wisc.edu> wrote:
>> 
>>> Hi guys,
>>> 
>>> Here is a status update on the ImgLib2 release.
>>> 
>>> The following components are released:
>>> 
>>> * imglib2 2.0.1
>>> * imglib2-algorithm 0.1.0
>>> * imglib2-algorithm-fft 0.1.0
>>> * imglib2-algorithm-gpl 0.1.0
>>> * imglib2-ij 2.0.0-beta-27
>>> * imglib2-realtransform 2.0.0-beta-27
>>> * imagej-common 0.10.0
>>> 
>>> The following components are not done yet:
>>> 
>>> * imglib2-script 0.1.0
>>> * imglib2-tests
>>> * imglib2-tutorials
>>> 
>>> (Note that for tests and tutorials, it is just a matter of updating the master branch, since we will never cut Maven release of those.)
>>> 
>>> * imagej-ops 0.6.0
>>> * imagej-plugins-commands 0.3.0
>>> * imagej-ui-swing 0.8.0
>>> * scifio 0.17.0
>>> * scifio-ome-xml 0.10.0
>>> 
>>> And probably others that will become obvious as we proceed further along.
>>> 
>>> You can glean much of this same information from the following URL:
>>>     http://status.imagej.net/
>>> 
>>> Tobias asked if there is anything others could do to help, so here is a list (in my opinion of priority order):
>>> 
>>> 1) Check out the imglib2-release branch of imglib2-tutorials and fix the compile errors.
>>> 2) Check out the imglib2-release branch of imglib2-tests and fix the compile errors.
>>> 3) Check out the imglib2-release branch of imglib2-script and fix the compile errors.
>>> 4) Check out the imglib2-release branch of imagej-ops and figure out why tests fail now.
>>> 
>>> Any help any of you can contribute toward the above goals would be greatly appreciated! I'll be back on the case on Monday. (I would not worry about the Git history, Tobi -- just fix the errors on each branch.)
>>> 
>>> Regards,
>>> Curtis
>>> 
>>> P.S. Thorough docs on the component structure, development best practices, and related stuff will be coming soon to a http://imagej.net/Architecture near you.
>>> 
>> 
>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20141030/175cdfa0/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20141030/175cdfa0/attachment-0001.pgp>