Initializing BigWarp from two `Source<T>`, `Source` wrapping into a `SpimData` object

Hello,

I managed to write a multiresolution bdv.viewer.Source<T>, which is behaving as I want with a specific file format. Now I’d like to use these sources into BigWarp in order to perform a manual landmark registration.

However I’m stuck at the initialization step with BigWarp :

  • is there a way to start a BigWarp instance with two Source ?
    Looking at BigWarpInit, it looks like it’s not possible. However there is a function that takes two AbstractSpimData as an input. I feel that there should be a simple way to wrap the Sources into AbstractSpimData, but I don’t know how to do it… the class is implementing many interfaces, and I don’t know what to do and how to keep it simple. So:
  • How to easily wrap a Source into an AbstractSpimData class, or anything else that would do the trick ?

Any thoughts ? Thanks!

cc @bogovicj

1 Like

Hi @NicoKiaru,

Short answer. What you need is in the current dev branch.

I think this is what you need, right? I’d like to make it convenient, so let me know if this setup isn’t ideal, much appreciated.

There’s a major release of Bigwarp coming soon, and this will be part of it.
Need some dependencies to be released first though.

John

2 Likes

That’s absolutely perfect! What a great coincidence. Regarding the function arguments, that’s simple and intuitive.

Now I come back to you for another issue… I can display both images and put landmarks. But when I press ‘T’ to see the transformed image, I see a bunch of uncorrelated pixels instead of the transformed image. I don t know where this comes from. I have limited connectivity now, but I ll give more info if you re interested to know where this comes from.
Thanks again @bogovicj!

1 Like

@NicoKiaru,

Ooops, yea forgot about that - that’s the dependency that I’m waiting on.

The fix:
Replace your imglib2-realtransform with the latest snapshot version (2.2.1-SNAPSHOT)

The reason:
A bug is fixed there that addresses problems with multithreading.

John

1 Like

Hmm I tried with your jar but it’s still failing. I’m not sure that I managed to replace it correctly though…

And FYI I already had a 2.2.1-SNAPSHOT dependency. But I’ll wait, no rush.

edit: I looked at your linked JAR, and all the files have been last modified on May the 16th.

oh, weird…are you running bigwarp “standalone” or through Fiji?

Hmm I have a project in progress in intellij - there I’m using bigwarp, by declaring it as a dependency. I build the repo bigwarp_fiji from github and used it as a dependency for my project (I increased the version just to be sure that it was the I built locally).

My local maven repository has the 2.2.1-SNAPSHOT version, and it was indeed the declared dependency in the bigwarp_fiji repo.

My current dependencies are like this:

<dependency>
			<groupId>net.imagej</groupId>
			<artifactId>imagej</artifactId>
		</dependency>

		<!-- Necessary for ImagePlus Generation in BDVSlicesToImgPlus command -->
		<dependency>
			<groupId>net.imagej</groupId>
			<artifactId>imagej-legacy</artifactId>
		</dependency>

		<dependency>
			<groupId>ch.epfl.biop</groupId>
			<artifactId>bigdataviewer_scijava</artifactId>
			<version>0.1.1-SNAPSHOT</version>
		</dependency>

		<dependency>
			<groupId>junit</groupId>
			<artifactId>junit</artifactId>
			<scope>test</scope>
		</dependency>

		<dependency>
			<groupId>net.imglib2</groupId>
			<artifactId>imglib2</artifactId>
		</dependency>

		<dependency>
			<groupId>org.scijava</groupId>
			<artifactId>scijava-common</artifactId>
		</dependency>

		<dependency>
			<groupId>sc.fiji</groupId>
			<artifactId>bigdataviewer-vistools</artifactId>
		</dependency>


		<dependency>
			<groupId>org.scijava</groupId>
			<artifactId>scijava-ui-swing</artifactId>
		</dependency>


		<dependency>
			<groupId>net.imagej</groupId>
			<artifactId>imagej</artifactId>
		</dependency>

		<dependency>
			<groupId>junit</groupId>
			<artifactId>junit</artifactId>
			<scope>test</scope>
		</dependency>

		<dependency>
			<groupId>sc.fiji</groupId>
			<artifactId>bigdataviewer-core</artifactId>
		</dependency>

		<dependency>
			<groupId>sc.fiji</groupId>
			<artifactId>bigdataviewer_fiji</artifactId>
		</dependency>
		<!--
		<dependency>
			<groupId>io.scif</groupId>
			<artifactId>scifio</artifactId>
		</dependency>

		<dependency>
			<groupId>io.scif</groupId>
			<artifactId>scifio-bf-compat</artifactId>
		</dependency>
		-->

		<dependency>
			<groupId>ome</groupId>
			<artifactId>formats-bsd</artifactId>
		</dependency>

		<dependency>
			<groupId>ome</groupId>
			<artifactId>formats-gpl</artifactId>
		</dependency>


		<dependency>
		<groupId>sc.fiji</groupId>
		<artifactId>bigwarp_fiji</artifactId>
		<version>3.1.4-SNAPSHOT</version>
		</dependency>


		<dependency>
			<groupId>net.imglib2</groupId>
			<artifactId>imglib2-realtransform</artifactId>
			<version>2.2.1-SNAPSHOT</version>
		</dependency>

I’ll try to make a minimal example if all my efforts are unsuccessful.

The Source I built is also a bit weird. I’ll check if BigWarp works with some more basic images.

1 Like

Still failing with basic images. Maybe the dependency is not correctly overriden. I’ll investigate.

@bogovicj

The last commit which do not give me errors in the dev branch is:

  • f148d57c67a325e90f4a961200b9c8676530c0a2

The following commit fails:

  • 3c2409130674b57eb92a7b967a7bbe9181ccf0e6 Replace TpsTransformWrapper with imglib2 ThinplateSplineTransform

And I tested this intermediate one :

  • bd8b361f3c46ccacf02b6b7e413f470aa95dd294 > Fail

And the last one:

  • 1942992aee7203dc0697ee3cf94308b56ae5b0f2 Fix viewer transform bugs when exiting landmark mode > Fail

This was tested with simple tif 2D images 8 bit one channel

Though, I have to say, the last one looks a bit better because some chunks of stripes do indeed look correct…

Hope that helps,

Nicolas

Thanks for doing that digging, I’m looking into this now…

Having trouble reproducing.

Would you mind checking out the latest dev branch and trying this test:

Btw, when you say the above commits fail, do you mean that the display is wrong after transformation, right (i.e. not that there is a compile failure, right?)?

Another quick question - why does your pom point to bigwarp_fiji-3.1.4-SNAPSHOT? The latest is 3.1.3-SNAPSHOT, I presume you bumped the version on your local build??

John

Yes, indeed, there are stripes which are right, and stripes which are messy. I’ll make a short video.

Indeed, maybe that’s useless, but I wanted to be sure that I was linking to the local build. Increasing the version was a way to verify…, since the jar only exists locally

Will do and report back.

Thanks for digging. I do not have another computer to see if I get the same result. Last note: on the dev branch, the parent Pom is 23.2.0. Is that normal ?

FYI, I’m on ubuntu 16.04, Java JDK 1.8.0_212.

Nico

1 Like

Makes sense - that’s a good idea I think. :+1:

There you go:

I don’t think it’s a “Source” specific problem. I get this issue even when starting BigWarp with two files as arguments.

One little thing : I had to put some landmarks for your test because I don’t have your landmark file (the file not found error shows up, but I can continue to use it).

1 Like

Ugh, I’m an idiot. The master branch didn’t have the fix yet, but now it does.

You can build imglib2-realtransform-2.2.1-SNAPSHOT from the current master, or grab the build from here .

Sorry about this drama…
John

1 Like

That’s perfect! Thanks for pushing it

Works awesomely well :clap: :clap: .

1 Like