-
Notifications
You must be signed in to change notification settings - Fork 16
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
ome-tiff issue #197
Comments
Your commands look right to me. I suspect that the TIFF shape is not compatible with steinbock (expected dimension order: CYX, optionally with additional dimensions of size 1 at the beginning/end). This would for example be the case if the CODEX-generated TIFFs are channels-last instead of channels-first. Unfortunately, the steinbock logging for this particular problem is currently broken, which is why the error message is so uninformative. Sorry about that. @Milad4849: Could you maybe investigate this further/help out @paulrbuckley-kcl? And what's your opinion on adding a PS @paulrbuckley-kcl: Really nice to see that you are using steinbock with Singularity! |
Thanks for getting back to me. Yes that makes sense. I've exported in two different ways (imagej format which i assume is CYX) and all appears to be working but will keep you updated. Also yes it works very cleanly using singularity! bit of a lifesaver to be honest! |
@jwindhager, sure I will look into this together with #199, adding channel last makes sense to me, will update you on this. |
Hi,
I am running 'steinbock preprocess external images' on a CODEX-generated .ome.tiff, which has been exported from QuPath. When converting to 'steinbock file format' I receive the following warning and nothing is processed:
I noticed there is a recent bug, so I am using the most recent version of the docker image - 0.16.1 - the below code is used to run this in singularity:
steinbock="singularity run -B /X/$FOLDER:/data --env STEINBOCK_MASK_DTYPE=uint32 docker://ghcr.io/bodenmillergroup/steinbock:0.16.1
where $FOLDER has been defined previously. then the following code is generates the issue:
$steinbock preprocess external images --img /data/external --imgout /data/images --infoout /data/images/images.csv
I assume its something simple like I have not received the updated code given the recent bug? But not entirely sure. Any help would be really appreciated
Thanks
Paul
The text was updated successfully, but these errors were encountered: