-
Notifications
You must be signed in to change notification settings - Fork 42
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
Is it possible to use different --align-channel for different cycles? #165
Comments
I understand the problem! The command line interface doesn't support this but the internal Python code does. You could write a short custom script to call the Python API directly and choose separate channel numbers for each cycle. If you could provide a sample ashlar command line that you use, I can convert that to a Python script where you can customize the channel numbers per cycle. |
Thank you for creating this great tool and thank you for continuous support.
|
I have similar question regarding --output-channels argument so decided to piggyback in this thread. Is it possibly to specify to output different channels per cycle? or even easier to specify channels that should be omitted from some of the cycles (for example if we dont have 4 antibodies in one of the cycles we often run the same acquisition protocol which generates one of the channels as intermediate background, it simplifies the setup, keeps all the channels in order and give us a little bit of QC window for signal quenching between actual antibodies) but for final stack image file for analysis it would be nice to have an option to remove this "empty" channels if possible. |
hello @ciszew, did you figure out how to use different channel numbers, I am in a similar situation as you were. |
This currently cannot be achieved using the ashlar script/command. For a more complex configuration @ciszew described, I think constructing a configuration file will be needed. Channel used for alignment is set when instantiating |
Hi @josenimo |
Thank you both, @Yu-AnChen I will try again to take a closer look at this file, I believe I can manage to understand it with my poor python, but right now I am under a lot of pressure to present some results soon :`). Thank you for the help. @ciszew this is what I would have done have every channel start at 0, or image empty. However this was our first run at CYCIF and they always imaged DAPI last, and cycles have different number of channels. My current hack is the following, read the image in python with
Any ideas and feedback are very welcome! |
@josenimo thanks for elaborating on your use case. I added a branch on my fork that allows passing Not sure if you are running ashlar within mcmicro pipeline, if so you likely will need to build a custom docker container. Otherwise I would pull the code from the branch and pip install it in editable mode git clone https://github.com/labsyspharm/ashlar.git
cd ashlar
git remote add yu-anchen https://github.com/yu-anchen/ashlar.git
git fetch yu-anchen
git checkout -b last-channel yu-anchen/last-channel
# install in editable mode
pip install -e . Hopefully, with this you don't have to re-write the files. On you two other concerns
|
Dear @Yu-AnChen , thank you for your time, explanation, and sharing your ashlar fork. I have run into another issue with ashlar and I will try to explain, erring on the side of oversharing some details, thank you for bearing with me, I have learnt lots in the past few weeks. Context: Preprocessing: Right now I have 4 stacks, one for each cycle. I tried your ashlar fork unsuccessfully, see stack_trace below:
I checked the dimensions of the four files, with I first tried transposing all of them to xyc using
I don't understand what array too large means I did run ashlar on bigger images, so I thought ASHLAR uses yxc instead of cyx, based of Issue 104 and Issue 95. So I then transposed cycle one to yxc, (without channel reorder, and without pixel slicing) and tried running ashlar_yuanchen again, still an error:
When I tried slicing the pixels for the yxc arrays I keep running out of RAM:
Right now I am trying to recreate the background subtraction preprocessing again for cycle1, assuming something is off. but the output is still (c,y,x). Regarding my previous concerns:
If there is any simple way to slice my ome.tif files and keep the metadata ? (Right now I just know how to use skimage.io) |
Apologies I think we are deviating from the topic of the thread. Maybe we could talk about the bg subtraction issues on image.sc. On the ashlar side, based on what you've described, I would run ashlar on all the scans collected (w/ both Ab stains and bg-only), assuming your imager provides access to the raw FOVs. After running ashlar, it outputs a single file that contains all the channels, and the bg subtraction module uses that as input to generate the bg-subtracted image. |
I agree, |
Try this in a notebook, worked for me, in my case I have 0 overlap between tiles in this set:
|
I have another, more complicated question. Cycle 0, I don't have dapi but I have a Protein A stain Would I have to create a 0+1 and then align to the dapi channel? Problem is, I need to split the image in at least two (to then mosaic again since Ashlar doesn't do pre-stiched images)? I've done a fake mosaic before with Ashlar, that wouldn't be the biggest problem. |
In some of our experiments we have different number of channels for some of the cycles. This results in mismatched numbering in the order of the channels, for example:
cycle 1 has DAPI only -> DAPI channel=0
cycle 2 has 4 colors with DAPI as last channel -> DAPI channel=3
cycle 3 has 5 colors with DAPI as last channel-> DAPI channel=4
...more cycles like cycle 2 and 3
when setting up ashlar run we specify align channel option, in above scenario if selecting channel 0 for alignment some of the cycles (small number 0-2 cycles out of 15 cycles in recent experiment) have a large shift in alignment in range of hundreds to few thousands um. Image for this cycle appears cut or shifted by large distance.
Im guessing this is due to the different channels being used for alignment for different cycles (in above example channel 0 is DAPI for cycle 1 and Cy7 for cycle 2 and 3). If my assumption is correct is there a way to specify different alignment channels for different cycles (in example above 0, 3, 4 to use DAPI signal each time).
I tested alignment of selected matching cycles with the same true DAPI channel and i didnt get the large shift described above.
When searching for some answerers i noticed that issue #153 has similar large shift mentioned, possibly its related?
The text was updated successfully, but these errors were encountered: