abria / TeraStitcher

A tool for fast automatic 3D-stitching of teravoxel-sized microscopy images
http://abria.github.io/TeraStitcher/
Other
78 stars 32 forks source link

Reduced intensity at tile boundaries #2

Closed oakdet closed 8 years ago

oakdet commented 9 years ago

Hi Alessandro, First, I must say this is a great work from you guys, thanks. I recently started using Terastitcher for large image sets. If you look at the image below (cropped image), you can see the boundary effect between tiles, i.e. intensity is relatively lower at the stitched junctions. I have seen this before also in some articles.

back detec corr1

What could be the possible reasons and solutions (e.g., percentage of overlap can be tweaked to reduce this, etc.). I have tried normalization on these images but the difference way significant a the boundary. Thanks VK

abria commented 9 years ago

Hi, and thank you for using TeraStitcher!

Unfortunately the boundary effect, which we call "zebrated pattern", is a common issue for different microscopy techniques and our SPIM images too have the same problem. We implemented a very simple method (still experimental) to correct this: see the --restoreSPIM and --restoredir options to be used both in the Align and Merge steps.

This method extracts the illumination map during the Align step and then corrects the tiles using the computed map during the Merge step. More sophisticated methods have been proposed in the literature, but so far we did not spend too much time on this because it does not seem to be an obstacle for effective image analysis.

If this method fails, you might want to better characterise the problem on your images and implement a custom correction method. In this case, you can disable blending between adjacent tiles (automatically done by TeraStitcher) by providing --algorithm="NO_BLEND" in the Merge step (see --algorithm). In this way you will have a more faithful reconstruction of the image in the boundary regions.

Hope that helps!

Cheers, Alessandro

oakdet commented 9 years ago

Hi Alessandro, Thank you very much for the reply. I will try to implement your suggestions. If things come as expected I will post you. Thanks again. Vivek

oakdet commented 8 years ago

Hi Alessandro,

I am facing a problem with stitching process when I am trying to use a down sized volume. I have an original data with 12x19 tiles with 1200 images in each tile folder for whole mouse brain, but when I am trying to use a 6x4 tile with just 50 images for each tile- its showing an error- "cross MIPs: search region is too big with respect to the overlapping region. Overlapping extent should be >2*delay+1 for each of the search region extent along that direction.". FYI I am accordingly generating the xml file and using the standalone with scripts. But interestingly when I am using the GUI mode from Vaa3d its working fine. Do you think its has to do with project displacement? If yes how its calculate by the program using what data parameters? It will will great if you can help with this. Thanks Vivek

abria commented 8 years ago

Vivek,

the problem is due to the relatively small number of slices along Z and occurs in the Align step https://github.com/abria/TeraStitcher/wiki/Step-2:-Align. To estimate misalignments, TeraStitcher looks in a search region whose radius along Y, X and Z axes is specified with --sV, --sH, and --sD command line parameters, respectively. Their default value is 25, which means that the search region will have size 50x50x50 by default. That’s too much since you only have 50 slices. On the Vaa3D-TeraFly, the default value is 20, which is still fine in your case (but would produce an error with 40 or fewer slices).

Then the solution is to provide --sD=20 (link https://github.com/abria/TeraStitcher/wiki/User-Interface#--sdinteger-advanced to parameter description) on your command line during the Align step.

My warning is that if your maximum “expected” misalignment along Z for a pair of adjacent stacks is too close to the number of slices, the stitching result might not be good. In general, it could also be possible that the problem has no solution. That’s because to find a misalignment between two images, there should be some overlap. The smaller the overlap, the more difficult is to find the misalignment. No overlap, no solution.

Hope I helped :-).

Cheers, Alessandro

On 11 Nov 2015, at 17:42, oakdet notifications@github.com wrote:

Hi Alessandro,

I am facing a problem with stitching process when I am trying to use a down sized volume. I have an original data with 12x19 tiles with 1200 images in each tile folder for whole mouse brain, but when I am trying to use a 6x4 tile with just 50 images for each tile- its showing an error- "cross MIPs: search region is too big with respect to the overlapping region. Overlapping extent should be >2*delay+1 for each of the search region extent along that direction.". FYI I am accordingly generating the xml file and using the standalone with scripts. But interestingly when I am using the GUI mode from Vaa3d its working fine. Do you think its has to do with project displacement? If yes how its calculate by the program using what data parameters? It will will great if you can help with this. Thanks Vivek

— Reply to this email directly or view it on GitHub https://github.com/abria/TeraStitcher/issues/2#issuecomment-155838937.

oakdet commented 8 years ago

Hi Alessandro,

Thanks a lot for your another quick response. I highly appreciate. It worked! sD was earlier set to 30, after changing to 20 it worked fine. Yes, I agree with the misalignment problem, I'll keep in mind.

Thanks Vivek

On Wednesday, November 11, 2015, Alessandro Bria notifications@github.com wrote:

Vivek,

the problem is due to the relatively small number of slices along Z and occurs in the Align step < https://github.com/abria/TeraStitcher/wiki/Step-2:-Align>. To estimate misalignments, TeraStitcher looks in a search region whose radius along Y, X and Z axes is specified with --sV, --sH, and --sD command line parameters, respectively. Their default value is 25, which means that the search region will have size 50x50x50 by default. That’s too much since you only have 50 slices. On the Vaa3D-TeraFly, the default value is 20, which is still fine in your case (but would produce an error with 40 or fewer slices).

Then the solution is to provide --sD=20 (link < https://github.com/abria/TeraStitcher/wiki/User-Interface#--sdinteger-advanced> to parameter description) on your command line during the Align step.

My warning is that if your maximum “expected” misalignment along Z for a pair of adjacent stacks is too close to the number of slices, the stitching result might not be good. In general, it could also be possible that the problem has no solution. That’s because to find a misalignment between two images, there should be some overlap. The smaller the overlap, the more difficult is to find the misalignment. No overlap, no solution.

Hope I helped :-).

Cheers, Alessandro

On 11 Nov 2015, at 17:42, oakdet <notifications@github.com javascript:_e(%7B%7D,'cvml','notifications@github.com');> wrote:

Hi Alessandro,

I am facing a problem with stitching process when I am trying to use a down sized volume. I have an original data with 12x19 tiles with 1200 images in each tile folder for whole mouse brain, but when I am trying to use a 6x4 tile with just 50 images for each tile- its showing an error- "cross MIPs: search region is too big with respect to the overlapping region. Overlapping extent should be >2*delay+1 for each of the search region extent along that direction.". FYI I am accordingly generating the xml file and using the standalone with scripts. But interestingly when I am using the GUI mode from Vaa3d its working fine. Do you think its has to do with project displacement? If yes how its calculate by the program using what data parameters? It will will great if you can help with this. Thanks Vivek

— Reply to this email directly or view it on GitHub < https://github.com/abria/TeraStitcher/issues/2#issuecomment-155838937>.

— Reply to this email directly or view it on GitHub https://github.com/abria/TeraStitcher/issues/2#issuecomment-155856582.

Vivek Kumar

oakdet commented 8 years ago

Hey Alessandro,

Sorry, I have another question to disturb you. Its about multi channel stitching, how can we do simultaneously 2-3 channel stitching? When we start with one channel a "mdata.bin, xml_import.xml and exec_sti.exe" files are created but while trying to start for another channel it shows conflict. Is it possible to delete mdata.bin and keep the first stitching going on and move on to second channel (I should have tried this before asking you) or any other solution. I hope I made my point clear.

Thanks Vivek

abria commented 8 years ago

Hi Vivek,

unfortunately I did not completely understand your problem. What is “exec_sti.exe”? TeraStitcher does not create such a file :-).

Anyway, TeraStitcher is currently not able to generate multichannel images (but can read them). We already developed the underlying code, and we will release this feature soon (1-2 months).

Meanwhile, here is a workaround:

TeraConverter (GUI version) is available in Vaa3D (Menu Advanced > Big-Image-Data > TeraConverter). You can download Vaa3D from www.vaa3d.org http://www.vaa3d.org/.

Let me know if you need further assistance.

Best, Alessandro

On 24 Nov 2015, at 15:48, oakdet notifications@github.com wrote:

Hey Alessandro,

Sorry, I have another question to disturb you. Its about multi channel stitching, how can we do simultaneously 2-3 channel stitching? When we start with one channel a "mdata.bin, xml_import.xml and exec_sti.exe" files are created but while trying to start for another channel it shows conflict. Is it possible to delete mdata.bin and keep the first stitching going on and move on to second channel (I should have tried this before asking you) or any other solution. I hope I made my point clear.

Thanks Vivek

— Reply to this email directly or view it on GitHub https://github.com/abria/TeraStitcher/issues/2#issuecomment-159290592.

abria commented 8 years ago

One more comment: steps 1-5 should be run once on the "best" channel (i.e. the one providing most of the information), whereas step 6 should be repeated for all the channels taking in input the same .xml file previously generated at step 5.

oakdet commented 8 years ago

Hi Alessandro,

Thanks a lot for your great help. I got you and I'll try this. I'll give you a bit more detail what we are doing. Just now in the morning here I have to rush for Thanksgiving doorbuster. Happy Thanksgiving! Thanks and enjoy! Vivek On Thursday, November 26, 2015, Alessandro Bria notifications@github.com wrote:

One more comment: steps 1-5 should be run once on the "best" channel (i.e. the one providing the most of the information), whereas step 6 should be repeated for all the channels taking in input the same .xml file previously generated at step 5.

— Reply to this email directly or view it on GitHub https://github.com/abria/TeraStitcher/issues/2#issuecomment-159879008.

Vivek Kumar

oakdet commented 8 years ago

Hi Alessandro, I got the workaround mentioned earlier by you for multi channel. I have started the run for the best channel, do as mentioned by you. As far as exe_stich.exe related file is concerned, actually we are using the standalone version in combination with perl/script which creates the xml file and others based on our acquisition folder and file structure. Anyways I'm going to try as you have mentioned and also with the method we are using, I guess in our case I just need to modify the xml_merging.xml file (to start a new step 6 for another channel) which is created after the first channel/best channel run. This is what I understood from your reply. I will keep you posted. Thanks again. Vivek

abria commented 8 years ago

Vivek,

you don't need to edit the xml_merging.xml file to start a new step 6. Just use the same file and start a new step 6. To select the channel to stitch, use the --imin_channel parameter as indicated in my previous post.

Cheers, Alessandro

Il giorno 30/nov/2015, alle ore 22:10, Vivek kumar notifications@github.com ha scritto:

Hi Alessandro, I got the workaround mentioned earlier by you for multi channel. I have started the run for the best channel, do as mentioned by you. As far as exe_stich.exe related file is concerned, actually we are using the standalone version in combination with perl/script which creates the xml file and others based on our acquisition folder and file structure. Anyways I'm going to try as you have mentioned and also with the method we are using, I guess in our case I just need to modify the xml_merging.xml file (to start a new step 6 for another channel) which is created after the first channel/best channel run. This is what I understood from your reply. I will keep you posted. Thanks again. Vivek

— Reply to this email directly or view it on GitHub.

oakdet commented 7 years ago

Hi Alessandro, I hope you are having a good time! Lately I have been imaging with 25X lens and was trying to stitch the images but with weird output. Just some details: For 10x- I have successfully used following values: pixel size in x-0.585, y-0.585 & displacement pixel count for 10x: -sV=60; sH=60;sD=30. but for 25x I am trying to use- size in x-0.234, y-0.234 and displacement count -sV=30; sH=30;sD=20

Problem its flipping the tiles in vertical axis.

So if look at the image, each tile appears to be vertically flipped 180. Horizontal position of tiles look normal. The ventral side of brain should curve nicely towards lateral side and because of every tile flipping it looks serrated

flipped vertical axis

Please if you can take a look at this.

Thanks a lot. Vivek

oakdet commented 7 years ago

Sorry I forgot to mention that it could also be shifting the whole column of tiles from left to right side and vice versa. I wonder if I have made my point clear.

Thanks Vivek

iannellog commented 7 years ago

As to the flipping problem, you have to specify correctly command line options --ref1, --ref2, --ref3 in the import step. Have a look to the attached file for details. If something is not clear please write again because we are trying to improve the documentation about these issues.

One more observation about the values of command line options --sV, --sH, --sD when pixel size is 0.234 in x-y. Values of these options are in pixels. Hence the region explored by the alignment algorithm in microns is obtained by multiplying the values of these options times the pixel size. Using smaller values of these options when the pixel size decreases means exploring an even smaller area which is likely not you want to do. In other words, values of options --sV, --sH, --sD should be chosen approximately equal to the ratio between account estimated alignment errors and pixel size in microns. Pay attention however that increasing the values of these increases the computational workload of the alignment step, hence they have to be carefully chosen.

Best.

-- Giulio

Reference system documentation (draft).pdf