Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Are these stitching results correct? #28

Closed
zikai1 opened this issue Mar 23, 2023 · 5 comments
Closed

Are these stitching results correct? #28

zikai1 opened this issue Mar 23, 2023 · 5 comments

Comments

@zikai1
Copy link

zikai1 commented Mar 23, 2023

Hi Russel Torres,
The following image is a 2D stitching result following the asap-modules https://asap-modules.readthedocs.io/en/latest/index.html.
1679491249389
The metadata I test is 21617_R1_166_T5_15_20201231140731_20201231140731 provided by you. Followings are visualization error maps with a html format:

1679491354556
1278ff883ad54f41a2203b3f9c3e137
23d33b5804cf8859b5af08835bcd0ce

Are these stitching results correct? Why do they look like undergoing a spatial rotation? In addition, I also test some EM tiles sampled by ourselves, the 2D stitching results are also rotated by some degree. How do I solve the above problem?

Thanks in advance, Russel Torres. Thank you!

Best and sincere wishes,
MY

@zikai1
Copy link
Author

zikai1 commented Mar 23, 2023

The following presents some of my 2D stitching results:
575ae6fe2c0a1fb20328e1a37df5ad9
861b19f0e3a0847a250c22bcf1e4673

Hi Russel Torres, it seems that the stitching is correct, but the visualization is errornous. Do I need to set or tune parameters? Which parameter should I set?

Thank you again.

@RussTorres
Copy link
Collaborator

Hello,

My initial reaction to this is that the montage may be under-regularized and optimizing by producing a sheared representation of the tiles. As the optimal regularization parameter lambda is dependent on a number of factors (principally the number and weight of point correspondences), you likely need to change this. One sanity check on what a minimally deformed montage should ideally look like is to solve for a TranslationModel, which should produce a translation-only montage that looks like optimal stage coordinates.

This translation model is what the solve is regularized against using the "translation_factor" variable (which describes the relation of the translation to the higher order transformation in the solve), so tweaking the value of that or lambda will vary how deformed your montage can be in service of bringing correspondences closer together.

In the elife paper we described a method of exploring the tradeoff of some of these parameters. I am not sure if this figure made it in (was originally supposed to be a supplement), but it describes some of the effects of regularization on the section rendering. note that the "individual tile" part of this is actually describing the corner overlap of multiple tiles, hence why you see a seam.

image

I have raised AllenInstitute/asap-modules#250 describing the addition of automated parameter search to the main repos.

If you believe this is a rendering error, however, it would be good to understand why -- can you share some example tilespecs (in json form) so it's possible to visualize the stitching result?

Thanks,
Russel

@zikai1
Copy link
Author

zikai1 commented Mar 27, 2023

Hi @RussTorres
Thanks for your timely response. Thank you.

I will change the following parameters in solve.py to re-stitch the tiles:
69234a7af7745201846ff7c2d291731
Since I used the default parameters to solve the tilespecs before.

The tilespecs produced by me can be downloaded from https://drive.google.com/file/d/1L7sROWEliXa5nLOPj7KerjBA2zjFLSS-/view?usp=share_link
These tilespecs were from your shared file 21617_R1_166_T5_15_20201231140731_20201231140731 and they constitute a section, i.e., z=0.

Thank you to further provide the file regarding the automated parameter searching. I am looking forward to seeing that. Thank you.

Best and sincere wishes,
MY

@zikai1
Copy link
Author

zikai1 commented Mar 27, 2023

Hi RussTorres,

After change the regularization parameter in solve.py to the following:

"regularization": {
        "default_lambda": 1.0e7,#1.0e3 in default
        "translation_factor": 1.0e-2#1.0e-5 in default
    },

I attain resonable 2D stitching results with images from 21617_R1_166_T5_15_20201231140731_20201231140731. However, when I use the same set of parameters in my own images, the stitching result is
bdf5c4422df3d0f9fb6e21b5a363568
Then I further increase regularization and it produces
1 0_2
and
1 0_1
It seems that the regularization effect is too heavy. I further tune several sets of parameters but the results seem unchanged.

The tiles I used indeed have about 50% overlappings as indicated by the red and green lines:
1 0_1

In each section, there are 9 tiles as shown up. Besides, the other parameters used in solve.py is in the default format, as shown below:
21c2e7488353d7c0fb6b67d14b35904

Hi RussTorres, could you help me stitch the above 9 tiles? You can easily download them from https://drive.google.com/drive/folders/19Wg4sVyw3v9-2z_b9LjCbzjVOTvAjdj-?usp=share_link
and then I will know where my settings are incorrect and how to set them.

Thank for your help, Dr. RussTorres.

Thanks,
MY

@zikai1
Copy link
Author

zikai1 commented Apr 3, 2023

Hi Dr. Russ Torres,
Based on your suggestions, I have stitched tiles together. Thank you very much!

The key changes I did were increasing the values of "regularization" in solve.py file and relocated my images to make it customize the metadata.json file you provided.

@zikai1 zikai1 closed this as completed Apr 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants