[Big Warp] Issue with disruption in exported image on Big Warp

Hi, all!
I have been using Big Warp (v5.1.1) plugin on ImageJ to register [a] histology image (H&E; 17415x12049) - moving onto [b] fluorescent image (DAPI; 29416x23120) - target. After picking 7~20 landmarks and then checking fused image before exporting, it looked fairly well

but, once its exported with either linear or nearlest neighbor all give broken warped image as follows. I tried to remove background of moving image and try again but somehow give similar result.

Does anyone (@bogovicj ) might have similar experiences/solution before?
I put images I tried for the testing as following link if it might help to find reasons…
Target image:

Moving image:

Moving image-2 (no bakcground):

Landmark:

1 Like

Hi @jpark27 ,

Welcome to the forum.

I get some weird behavior on the newest Bigwarp (6.1.0), I’ll look into it and let you know (see below). By the way, why did you attach two moving image below? Maybe I’m missing something about what you’re doing.

Thanks for reporting this issue,
John

I get this when exporting Moving.tif to the size and resolution of Target.tif using the landmarks you provided. The upper ~three-quarters of the export look correct, but the bottom part is clearly wrong.

HI, @bogovicj ! Thank you for the reply :slight_smile:

  1. Sorry for confusing you with two moving.tif files. a) Landmark is picked using moving.tif and b) I tested moving2.tif just in caes having no background (e.g., debris of tissue) might help but turn out it still generate mis-registration on bottom part. I even tried with using ~5 landmarks only on inside tissue but still give mis-registration on bottom part likewise you observed. ^^;;

  2. Do you think its possibly inherent problem of provided moving.tif image? (c.f., ndpi image is exported as tif file using QuPath-imageJ).
    original file:
    original-Moving.ndpi - Google Drive

1 Like

@jpark27

Thanks for clarifying what moving2 was for.

At first glance, no, I don’t think it has to do with the image(s) you used, but seems more like a bug. I tried to find a quick work-around for you, but so far havn’t found one. Will need to investigate more carefully later this week. Will keep you posted.

Thanks again,
John

Hi, @bogovicj ! Sorry to bug you again but any chance you found solution to resolve the bug in big warp with test images?

Hi @jpark27 ,

I have ideas about what the bug is, and expect to have it fixed in the next release.

Below are two imagej macros that you can run right now as workarounds.
Just replace the paths with the locations of the images on your computer.

Hope these help for now, and thanks again for reporting this issue,
John

1) export at half (or smaller) resolution

This macro will do it:

moving="/path/to/your/Moving.tif"
landmarks="/path/to/your/Landmarks"
numThreads="4"

run("Big Warp Apply", "landmarks_image_file="+landmarks+" moving_image_file="+moving+" target_space_file=[] resolution=Specified field=[Specified (pixel units)] point=[] x=2.0000 y=2.0000 z=1.0000 x_0=0.0000 y_0=0.0000 z_0=0.0000 x_1=14708 y_1=[11560 ] z_1=0 interpolation=Linear threads="+numThreads);

2) export at full resolution as two pieces

This macro will do it:

moving="/path/to/your/Moving.tif"
landmarks="/path/to/your/Landmarks"
numThreads="4"

run("Big Warp Apply", "landmarks_image_file="+landmarks+" moving_image_file="+moving+" target_space_file=[] resolution=Specified field=[Specified (pixel units)] point=[] x=1.0000 y=1.0000 z=1.0000 x_0=0.0000 y_0=0.0000 z_0=0.0000 x_1=29416 y_1=[11560 ] z_1=0 interpolation=Linear threads="+numThreads);
run("Big Warp Apply", "landmarks_image_file="+landmarks+" moving_image_file="+moving+" target_space_file=[] resolution=Specified field=[Specified (pixel units)] point=[] x=1.0000 y=1.0000 z=1.0000 x_0=0.0000 y_0=11560.0000 z_0=0.0000 x_1=29416 y_1=[11560 ] z_1=0 interpolation=Linear threads="+numThreads);

Hi, @bogovicj! Thank you so much for providing two solutions on given images :slight_smile: I tried both apporach and both 1) half-resol approach 2) splitted full-resol approach working quite well.

(*I noticed subtract 1 on both x_1 and y_1 gives matched pixel resolution to fixed image [29416x23120])

run(“Big Warp Apply”, “landmarks_image_file=”+landmarks+" moving_image_file="+moving+" target_space_file=[] resolution=Specified field=[Specified (pixel units)] point=[] x=2.0000 y=2.0000 z=1.0000 x_0=0.0000 y_0=0.0000 z_0=0.0000 x_1=14707 y_1=[11559 ] z_1=0 interpolation=Linear threads="+numThreads);

However, if you don’t mind asking, I’ve encountered very weird result in re-scaling or combing these bigwarp outputs. (Sorry about this I am still quite new on image processing…so I might doing sth wrong)

To adjust resolution of bigwarp output to fixed image I tried folloiwng,

1-a) re-scale half-resol (big-warp output) by x2

2-a) combine full-resol (big-warp output) vertically through ImageJ - stacks - tools - combine - combine vertically


2-b) combine full-resol (big-warp output) vertically through python PIL package (Image)

All 3 apporaches somehow re-create weird warping again… Do you think somehow there’s inherent (unfixable) issues on bigwarp outputs?

1 Like

Hi @jpark27

Nice catch.

Will have to dig some more to be sure, but I belive this issue is not really bigwarp’s fault, but more a limitation in how imagej (and PIL) store their images. For example, try using imagej to convert your target image to RGB (no bigwarp involved) and I bet you’ll be surprised with the result.

Another work around -
split the channels of your moving image so that they’re 8-bit images instead of RGB.

I predict that the output of bigwarp will be as expected for each individual channel, but that you will observe weird stuff when trying to combine them.

John

1 Like

Hi, @bogovicj ! Very much appreciated with your quick responses.

1.
Omg, yea… when I converted target_image (DAPI) it shows messy footprint and maybe all this time this might have caused the issue?

image

2.
And as you suggested using converted moving image (RGB->8-bit) as bigwarp input finally show no such footprint.


…but re-converting bigwarp output shows the foot print again. ^^;;

Guess for the time-being, I will use either half-resol splitted/registered (RGB) image or 8-bit full-resol one. Thank you so much john for investigating this together.
(Let me know if you find proper way to escape this for future :pray:)

2 Likes

Thanks for trying that experiment :slight_smile: