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

Cannot work out file type of "sub-barcelona01_T1w.nii.gz" #78

Open
claragiroux opened this issue Apr 9, 2021 · 13 comments
Open

Cannot work out file type of "sub-barcelona01_T1w.nii.gz" #78

claragiroux opened this issue Apr 9, 2021 · 13 comments

Comments

@claragiroux
Copy link

I downloaded the images for a few subjects using :
git annex get /sub-oxfordFmrib01/ sub-unf01/ sub-tokyoSkyra01/ sub-stanford01/ sub-milan01/ sub-geneva01/ sub-barcelona01/ sub-hamburg01/ sub-strasbourg01/ sub-tehranS01/ (There is no output when calling this, I'm not sure if it's normal)

However, I'm having trouble using the images. Whenever I try to open them with FSLeyes or to process them with sct_run_batch it says that it cannot work out file type of "sub-barcelona01_T1w.nii.gz"

Here is one of the logs:
err.process_data_sub-barcelona01.log

@jcohenadad
Copy link
Member

Hi,
I suspect you only downloaded the symlinks, not the actual data, what is the output of:

ls -la sub-barcelona01_T1w.nii.gz

If the file name is only ~100Bytes then it confirms you did not download the data.

Next question is: if you followed the doc, you should have downloaded the data-- adding @kousu in the thread

@claragiroux
Copy link
Author

The file size in only 106 Bytes, so it clearly did not download the data! I get this output:

clara@DESKTOP-8DII8HA:~/data-multi-subject/sub-barcelona01/anat$ ls -la sub-barcelona01_T1w.nii.gz
-rw-r--r-- 1 clara clara 106 Apr  8 12:30 sub-barcelona01_T1w.nii.gz

@jcohenadad
Copy link
Member

jcohenadad commented Apr 12, 2021

first thing i notice is that:

git annex get /sub-oxfordFmrib01/

Putting a "/" before the folder name means, in UNIX convention, that you are fetching the root "/", which is wrong. For local folder, you should write "./" (or nothing at all)

@jcohenadad
Copy link
Member

@alexfoias and/or @kousu can you pls help @claragiroux -- thanks

@kousu
Copy link
Contributor

kousu commented Apr 12, 2021

Good eye @jcohenadad, that's definitely one problem. But the other folders didn't start with '/' so they should have been downloaded I think. There definitely should have been some output.

Hi @claragiroux. I can tell you're using WSL from the logs. Is it possible you're using Ubuntu-18.04? The docs I wrote here are a bit thin, they just say " install git-annex at version 8.", which is easy to miss, but that implies that you need at least Ubuntu 20.04. There are much more detailed install instructions in another repo, particularly this part

Check that git-annex version reports version 8 or higher! It should look like:

$ git annex version
git-annex version: 8.20210310-ga343ea76c8

Can you try that?

Also, can you run

uname -a

and

cat /etc/os-release

and copy the results out? Thanks!

@claragiroux
Copy link
Author

Putting a "/" before the folder name means, in UNIX convention, that you are fetching the root "/", which is wrong. For local folder, you should write "./" (or nothing at all)

Thanks! I definitely missed that typo!

I can see that I have git-annex version 6.20180227 with Ubuntu 18.04.

Here are the results for the commands you asked @kousu :

clara@DESKTOP-8DII8HA:~/data-multi-subject$ uname -a
Linux DESKTOP-8DII8HA 4.4.0-19041-Microsoft #488-Microsoft Mon Sep 01 13:43:00 PST 2020 x86_64 x86_64 x86_64 GNU/Linux
clara@DESKTOP-8DII8HA:~/data-multi-subject$ cat /etc/os-release
NAME="Ubuntu"
VERSION="18.04.5 LTS (Bionic Beaver)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 18.04.5 LTS"
VERSION_ID="18.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=bionic
UBUNTU_CODENAME=bionic

@jcohenadad
Copy link
Member

@kousu it is not the first time (and thus not the last time) that users fail to verify their git-annex version. I suggest to slightly modify the doc, to make it an explicit and isolated step, e.g.:

STEP X: Install git-annex version 8.

⚠️ ‎ Make sure you have version by running: git annex version

The output should show something like this:

git-annex version: 8.XXX

If it is not the case, you will not be able to download the data.

note: i wrote this fast-- this should be "polished"

@kousu
Copy link
Contributor

kousu commented Apr 12, 2021

git-annex 6 is really really old. Debian and therefore Ubuntu spread packages the way journals spread knowledge unfortunately. Are you able to install the more recent version? You should just be able to click https://www.microsoft.com/store/apps/9n6svws3rx71 to get it.

I know that means you'll have to reinstall SCT and everything else. Do you think it would be a lot of work for you?

@claragiroux
Copy link
Author

claragiroux commented Apr 12, 2021

Thanks so much for the help! I have access to an old Mac, so I'll download the data on it, this way it will be much faster than installing a new version of Ubuntu!

@jcohenadad
Copy link
Member

@kousu many researchers have Ubuntu 18.04. Isn't there an "easy" way to get git-annex v8 on this distro?

@kousu
Copy link
Contributor

kousu commented Apr 12, 2021

The easy way is sudo do-release-upgrade. Ubuntu 18.04 is three years old now and they're going to have problems with more than just us if they keep using it.

The workaround is conda install -y -c conda-forge git-annex && ln -s PATH/TO/CONDA/bin/git-annex ~/.local/bin/. But that's definitely a workaround.

@kousu
Copy link
Contributor

kousu commented Apr 12, 2021

@jcohenadad
Copy link
Member

jcohenadad commented Apr 13, 2021

The workaround is conda install -y -c conda-forge git-annex && ln -s PATH/TO/CONDA/bin/git-annex ~/.local/bin/. But that's definitely a workaround.

great, thank you. Just for the context: many academic labs have their servers "stuck" to old distros because:

  • the ITs are not updating them fast enough;
  • researchers prefer to stay on the same distros because they are afraid changing the distros will change analysis results (which prove to be true for some analyses).

so it if far from uncommon to encounter SCT users who simply cannot upgrade the distros they are working on; the conda workaround will definitely prove useful.

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