search

BayraktarLab / opt_flow_reg

Optical flow based registration for fluorescence microscopy images
Apache License 2.0
3 stars 1 forks source link

Data format input #1

Closed sebgoti closed 2 years ago

sebgoti commented 3 years ago

Hi, would it be possible to get some additional documentation regarding the data format in which the images need to be stored? From the basic example it seems like both reference image and altered images must be stored as a single stack.

BioinfoTongLI commented 3 years ago

Hello, @sebgoti. This code is currently a step inside a pipeline. So the input of this registration should be the output of https://github.com/BayraktarLab/feature_reg. Hopefully this helps. Best, Tong

sebgoti commented 3 years ago

Hi @BioinfoTongLI , thank you very much for your reply. I was wondering if there was some reason behind the choice of using OME TIFF as the input format?

BioinfoTongLI commented 3 years ago

Hi @sebgoti , np! I would say it's simply because it is almost THE most open microscopy image file format. As I briefly mentioned, we run pipelines as Sanger. So having an community-widely-used open file format is crucial for long-term support/code maintenance. Hope this answers your question. Best, Tong

sebgoti commented 2 years ago

Hi @BioinfoTongLI, thanks for your response and apologies for the late reply. I guess my question was tailored towards knowing if the data format was a requirement for the OpticalFlow algorithm from OpenCV that you are using. I have been facing some issues when applying it to non-stacked images. Do you happen to know/have any demo with this functions?

BioinfoTongLI commented 2 years ago

Oh sorry. I see the problem. I may have an idea about it. But @VasylVaskivskyi who is the developer of this algorithm will be able to elaborate more. As far as I can tell, different cycles that need to be aligned are identified using channel names (c01 DAPI, c02 DAPI, c03 DAPI etc) embedded within OME.tiff. So yea, you wil have issues with non-stacked images. @VasylVaskivskyi How difficult will it be to take different file formats ? We may want to use ome.zarr as input in the future as well.

VasylVaskivskyi commented 2 years ago

Hi @sebgoti, having OME-TIFF as input format is not a requirement for the algorithm that does the alignment, it is just the way that we use data in the lab. We developed a pipeline and this method is a part of it. Image tiles -> Stitching -> Crude linear registration -> Fine non-linear registration. This method is intended to align multicycle imaging experiments, and it expects some metadata to be able to match channels across cycles (e.g. DAPI in cycle one to DAPI in cycle two), that's why we need OME metadata. It is primarily used to align already stitched images. Do you want to use it to register image series? Why you don't want to use stacks or OME-TIFFs?

sebgoti commented 2 years ago

Hi @VasylVaskivskyi, thanks for joining the discussion. At the moment I am decoding ISS samples with an in-house module that wraps around StarFISH, so rather than using external packages for different steps my aim is to add implementations to our current pipeline so we can have everything in the same place. We have an anchor image and then do a global linear registration of every cycle (using only DAPI). Though we already have good results I would like to know to what degree are local deformations affecting our analysis.

An objective is to store our data using OME-ZARR but we are still sorting out the details regarding metadata specification (for a deeper discussion see https://github.com/ome/ngff). Until then the data will be stored in TIFF. For these reasons I do not want to use stacks for the time being and am trying to implement the OpticalFlow algorithms directly in our workflow (step where I am stuck). I thought to ask you in case you had some implementation of the OpticalFlow algorithms without using stacked data.

VasylVaskivskyi commented 2 years ago

Since your images are still in TIFF format you should test if our packages work for you before committing to redevelopment. You can make a small test dataset and check if this kind registration works for you at all.

  1. Prepare OME-TIFF stacks, where each stack contains channels from one cycle. The OME metadata must contain at least channel names. If you don't have any meta, but know which image is what channel, you can use this script to bundle those images into stacks https://github.com/VasylVaskivskyi/bundle See cycle_map.yaml on how to specify information for bundling script. Running this command will give you one file for each cycle: python bundle.py -m cycle_map.yaml -o output_dir -p separate

  2. Then run feature based registration: https://github.com/BayraktarLab/feature_reg python reg.py -i "/path/to/image1/img1.tif" "/path/to/image2/img2.tif" -o "/path/to/output/directory" -r 0 -c "DAPI" -n 3

  3. Then use out.tif from feature_reg and run opt_flow_reg on it: https://github.com/BayraktarLab/opt_flow_reg python opt_flow_reg.py -i "/path/to/iamge/stack/out.tif" -c "DAPI" -o /path/to/output/dir/ -n 3

VasylVaskivskyi commented 2 years ago

Hey @sebgoti, are you still interested in this issue or should we close it?

sebgoti commented 2 years ago

Hi @VasylVaskivskyi, you can close it now, thank you very much :)