labsyspharm / ashlar

ASHLAR: Alignment by Simultaneous Harmonization of Layer/Adjacency Registration
https://labsyspharm.github.io/ashlar/
MIT License
129 stars 42 forks source link

Output Image Appears Granular/Pixellated After Stitching with ASHLAR #228

Open cqqa0623 opened 5 days ago

cqqa0623 commented 5 days ago

I am experiencing an issue with the output images generated by ASHLAR. The stitched images appear to be overly granular or pixelated, which significantly impacts the visual quality and usability for analysis. This granular effect is not present in the original input images.

![Uploading image.png…]()

cqqa0623 commented 5 days ago
Snipaste_2024-11-21_14-37-45
jmuhlich commented 5 days ago

Could you upload a representative TIFF of the original data and the ashlar output, rather than a screenshot? I don't think I can figure out what's going on from this screenshot alone. You can crop out a small region so the file is only a few megabytes, or I can give you a link to our large file transfer service if you want to share the entire thing (up to 50 GB).

cqqa0623 commented 2 days ago

Dear jmuhlich,

Thank you for your prompt response and sincere help. I have uploaded the following files for your reference via the following link: https://we.tl/t-XwQkazAzUm

  1. The original CyCIF images from 5 cycles (W0001F0031T0001_IF1-5).
  2. The output generated by using the ASHLAR algorithm to merge these 5 images (merged_F0031_optimized.ome.tiff).
  3. A test where I used only one image from the 5 cycles to merge, but the output still exhibits graininess (F1.ome.tiff and F1merged.ome.tiff).

Below is the environment of my Anaconda ASHLAR setup:

packages in environment at D:\Anaconda\envs\ashlar_env_38:

#

Name Version Build Channel

ansicon 1.89.0 pypi_0 pypi asciitree 0.3.3 pypi_0 pypi ashlar 1.18.0 pypi_0 pypi blessed 1.20.0 pypi_0 pypi ca-certificates 2024.9.24 haa95532_0 contourpy 1.1.1 pypi_0 pypi cycler 0.12.1 pypi_0 pypi fasteners 0.19 pypi_0 pypi fonttools 4.54.1 pypi_0 pypi freetype 2.12.1 ha860e81_0 imageio 2.35.1 pypi_0 pypi importlib-resources 6.4.5 pypi_0 pypi jinxed 1.3.0 pypi_0 pypi joblib 1.4.2 pypi_0 pypi jpeg 9e h827c3e9_3 kiwisolver 1.4.7 pypi_0 pypi lcms2 2.12 h83e58a3_0 lerc 3.0 hd77b12b_0 libdeflate 1.17 h2bbff1b_1 libffi 3.4.4 hd77b12b_1 libpng 1.6.39 h8cc25b3_0 libtiff 4.5.1 hd77b12b_0 libwebp-base 1.3.2 h3d04722_1 lz4-c 1.9.4 h2bbff1b_1 matplotlib 3.7.5 pypi_0 pypi networkx 3.1 pypi_0 pypi numcodecs 0.12.1 pypi_0 pypi numpy 1.24.4 pypi_0 pypi openjpeg 2.5.2 hae555c5_0 openssl 3.0.15 h827c3e9_0 packaging 24.1 pypi_0 pypi pillow 10.4.0 py38h827c3e9_0 pip 24.2 py38haa95532_0 pyjnius 1.6.1 pypi_0 pypi pyparsing 3.1.4 pypi_0 pypi python 3.8.20 h8205438_0 python-dateutil 2.9.0.post0 pypi_0 pypi pywavelets 1.4.1 pypi_0 pypi scikit-image 0.19.3 pypi_0 pypi scikit-learn 1.3.2 pypi_0 pypi scipy 1.10.1 pypi_0 pypi setuptools 75.1.0 py38haa95532_0 six 1.16.0 pypi_0 pypi sqlite 3.45.3 h2bbff1b_0 threadpoolctl 3.5.0 pypi_0 pypi tifffile 2023.7.10 pypi_0 pypi vc 14.40 h2eaa2aa_1 vs2015_runtime 14.40.33807 h98bb1dd_1 wcwidth 0.2.13 pypi_0 pypi wheel 0.44.0 py38haa95532_0 xz 5.4.6 h8cc25b3_1 zarr 2.16.1 pypi_0 pypi zipp 3.20.2 pypi_0 pypi zlib 1.2.13 h8cc25b3_1 zstd 1.5.6 h8880b57_0

Additionally, the metadata from my microscope output is as follows: <icm:ImagingResult xmlns:icm="http://www.yokogawa.co.jp/LSC/ICMSchema/1.0" icm:StructVersion="2.0"> <icm:FileInformation icm:Name="ImagingResult.xml" icm:Version="1.0" icm:CreateTime="2024-01-31T08:43:06.7128566+01:00" icm:CreateUser="CQ1" icm:LastUpdateTime="2024-01-31T09:48:45.2712585+01:00" icm:LastUpdateUser="CQ1"/> <icm:ResultInfo icm:BeginTime="2024-01-31T08:43:06.330756+01:00" icm:EndTime="2024-01-31T09:48:44.6701544+01:00" icm:Result="Completed">

MeasurementProtocol.xml
jmuhlich commented 2 days ago

Thank you. I found a bug in Ashlar's TIFF file handling with certain types of images (big-endian pixel data). I will fix this bug and let you know when there is a new version of Ashlar for you to try. If you want to preview what a correct result will look like, you can use this command line which will use an undocumented alternate TIFF reader that doesn't have this bug:

ashlar "fileseries|.|pattern=W0001F0031T{series}_IF1.tif|overlap=0.1|width=1|height=1" "fileseries|.|pattern=W0001F0031T{series}_IF2.tif|overlap=0.1|width=1|height=1" "fileseries|.|pattern=W0001F0031T{series}_IF3.tif|overlap=0.1|width=1|height=1" "fileseries|.|pattern=W0001F0031T{series}_IF4.tif|overlap=0.1|width=1|height=1" "fileseries|.|pattern=W0001F0031T{series}_IF5.tif|overlap=0.1|width=1|height=1" -c 2

(Note you should specify -c 2 to align on the DNA channel, as the default is to align on channel 0 which is not DNA here)

One question I have about your data: Do you really only have a single field of view per cycle, or are you imaging multiple fields of view in each cycle to cover the whole sample?

jmuhlich commented 1 day ago

Never mind the ashlar command above, I have fixed the issue and released ashlar 1.19.0 with the fix. Please install 1.19.0 version and try again. Again remember to use -c 2.

I'd still like to know whether you are stitching tiles within each cycle, or just registering a single tile across cycles!

cqqa0623 commented 1 day ago

Thank you so much for your quick response and for your work on the new release. I have tried ashlar 1.19.0, and I successfully merged the images this time without the graininess issue.

Our images represent different cycles of the same slice, taken from approximately the same field of view. However, each field has slight displacements and does not completely overlap.

You’ve been incredibly kind and helpful, and your work is of great significance to the progress of our research. We truly appreciate your support and dedication.

Thank you again! jmuhlich