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

Q: multiple channels in idr-download #2936

Closed
sunyi000 opened this issue Mar 25, 2020 · 5 comments
Closed

Q: multiple channels in idr-download #2936

sunyi000 opened this issue Mar 25, 2020 · 5 comments

Comments

@sunyi000
Copy link
Contributor

Hi,

just asking if it's possible for this tool here

https://github.com/galaxyproject/tools-iuc/tree/master/tools/idr_download

to allow multiple channel inputs?

for example, If upload an imageids file contains images across multiple channels, can we specify a comma separated channel list as input to the $channel parameter?

Thanks very much

@beatrizserrano
Copy link
Member

As far as I know, the IDR API provides the function getTile, for just one plane. I can't think of a use case why one would want to get multiple channels and save just one image; for me, either one takes the whole image or just the channel that is going to be analysed.

@sunyi000
Copy link
Contributor Author

for example, for secretion plate/screen (sorry I'm not sure about the name)
the input will be one imageID file contains 1 id per line.. some of them from 'dapi' channel, some of them from 'nucleus-dapi' channel..what would be the best way to download everything in one run?
currently I guess I will need to run twice with the same imageid file but different 'channel' name?

thx

@beatrizserrano
Copy link
Member

Ah, I see. That's an issue with the metadata associated with the images: the same channel is labelled differently (dapi, nucleus-dapi) for some images within the same dataset. I'm not sure whether that issue should be fixed by the tool... in part because we know about this case, but there might be many others. I think that the metadata issues should have been addressed upstream. But again, there are probably other cases that are out of our hands. In the worst-case scenario, the user that is aware of the problem can run the tool twice with the two different labels.

@bgruening
Copy link
Member

In the worst-case scenario, the user that is aware of the problem can run the tool twice with the two different labels.

I don't see anything wrong here. In a second step you could also merge then both collections into one. Those issues should also reported upstream?

@sunyi000 sunyi000 closed this as completed Oct 7, 2020
@sunyi000
Copy link
Contributor Author

sunyi000 commented Oct 7, 2020

closed

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

3 participants