poldrack / openfmri Goto Github PK

View Code? Open in Web Editor NEW

53.0 53.0 25.0 28.98 MB

code related to the OpenFMRI project

Home Page: http://www.openfmri.org

License: Other

Python 4.99% Shell 95.00% Makefile 0.01% HTML 0.01%

openfmri's People

Contributors

Stargazers

Watchers

openfmri's Issues

ds000030 - why is it gone?

I believe that files for ds 30 were there before, so we could populate http://datasets.datalad.org/openfmri/ds000030/ (you can browse it more sensibly in http://datasets.datalad.org/webtest/?dir=/openfmri/ds000030 atm) . But now https://openfmri.org/dataset/ds000030/ says "The dataset UCLA Consortium for Neuropsychiatric Phenomics LA5c Study with accession number ds000030 has been submitted and is currently being prepared to be published."

ds000017 - are (unversioned, 1.0.0) models consistent with 1.1.0 release?

https://openfmri.org/dataset/ds000017/ carries http://openfmri.s3.amazonaws.com/tarballs/ds017A_models.tgz for 1.0.0 release but no tarballs for models for 1.1.0

I guess the answer to the Q is: not exactly since 1.1.0 has orientation information fixed and models tarballs do carry .nii.gz ...
So shouldn't the models be regenerated as well?

ds000172 - dataset_description.json contains "un-braking space" (c2 a0) characters after lastnames

which breaks stock json modules in python

AttributeError: 'C' object has no attribute 'projname' when running run_mcflirt.py

'C' object in 'launch_qsub.py' do not have the parameters of 'projname', 'hold' and 'directory'. Is there some actions other than the process introduced at https://openfmri.org/data-processing-stream/ to be done?

Website Meta Data Export

It would be awesome if the website had:

meta data export
database summary statistics
search feature!

The interface is really pretty, and colors are just right :)

"new" ds000030 -- meta data tarball with a long structure of leading directories

(git)smaug:/mnt/datasets/datalad/crawl/openfmri/ds000030[incoming]git
$> tar -tzvf ds000030_R1.0.1_metadata.tgz | head
drwxrwxr-x suyashdb/G-802037 0 2016-09-23 16:38 home1/04275/suyashdb/ds000030_R1.0.1_metadata/
drwxrwxr-x suyashdb/G-802037 0 2016-09-23 16:38 home1/04275/suyashdb/ds000030_R1.0.1_metadata/work/
drwxr-xr-x suyashdb/G-802037 0 2016-09-23 16:37 home1/04275/suyashdb/ds000030_R1.0.1_metadata/derivatives/
drwxr-xr-x suyashdb/G-802037 0 2016-09-23 16:37 home1/04275/suyashdb/ds000030_R1.0.1_metadata/derivatives/parameter_plots/
-rw-r--r-- suyashdb/G-802037 806167 2016-09-23 16:37 home1/04275/suyashdb/ds000030_R1.0.1_metadata/derivatives/parameter_plots/MR_Scan_Parameters.tsv
drwxrwxr-x suyashdb/G-802037      0 2016-09-23 16:37 home1/04275/suyashdb/ds000030_R1.0.1_metadata/derivatives/sub-10159/
drwxrwxr-x suyashdb/G-802037      0 2016-09-23 16:37 home1/04275/suyashdb/ds000030_R1.0.1_metadata/derivatives/sub-10159/logs/
drwxrwxr-x suyashdb/G-802037      0 2016-09-23 16:37 home1/04275/suyashdb/ds000030_R1.0.1_metadata/derivatives/physio_plots/
drwxrwxr-x suyashdb/G-802037      0 2016-09-23 16:37 home1/04275/suyashdb/ds000030_R1.0.1_metadata/derivatives/physio_plots/sub-10440/

api: revisions aren't sorted

which I think would be better to sort them so folks wouldn't even rely on sorting "null" and semantic versions

https://openfmri.org/dataset/api/ds000009/:

    "revision_set": [
        {
            "revision_number": "1.1.0",
            "notes": "Update orientation information in NIFTI headers for better left/right determination",
            "date_set": "2016-02-21"
        },
        {
            "revision_number": "1.0.0",
            "notes": "Initial Release",
            "date_set": "2014-02-03"
        },
        {
            "revision_number": "2.0.0",
            "notes": "Dataset has been re-created and organized in BIDS format.",
            "date_set": "2016-03-25"

minor inconsistencies in BIDS version specifications in datasets

$> grep -i BIDS */*json | f3 | sort | uniq -c 
      3 "1.0.0-rc2",
      2 "1.0.0-rc3",
     18 "1.0.0rc3",
      1 "1.0.0-rc4",
      4 "1.0.0rc4",
      1 "1.0.0rc4",

with a dash before rc or without? ;)

ds 117 - only some subjects (4, 6) have estimated models

just wanted to let you know, feel free to close if that is "by design" ;) you can see that by file sizes

-r--r--r-- 1 yoh datalad  8480302301 Sep 16 23:42 ds117_R0.1.1_sub001_raw.tgz
-r--r--r-- 1 yoh datalad  9262748190 Sep 16 23:24 ds117_R0.1.1_sub002_raw.tgz
-r--r--r-- 1 yoh datalad  9299125353 Sep 16 23:24 ds117_R0.1.1_sub003_raw.tgz
-r-------- 1 yoh datalad 12946014892 Sep 16 15:58 ds117_R0.1.1_sub004_raw.tgz
-r--r--r-- 1 yoh datalad  9350705518 Sep 16 23:24 ds117_R0.1.1_sub005_raw.tgz
-r-------- 1 yoh datalad 11383891459 Sep 16 15:58 ds117_R0.1.1_sub006_raw.tgz
-r--r--r-- 1 yoh datalad  9348995697 Sep 16 23:24 ds117_R0.1.1_sub007_raw.tgz
-r--r--r-- 1 yoh datalad  9275672063 Sep 16 23:24 ds117_R0.1.1_sub008_raw.tgz
-r--r--r-- 1 yoh datalad  9191338927 Sep 16 23:24 ds117_R0.1.1_sub009_raw.tgz
-r--r--r-- 1 yoh datalad  9321784372 Sep 16 23:24 ds117_R0.1.1_sub010_raw.tgz
-r--r--r-- 1 yoh datalad  9437240462 Sep 16 23:24 ds117_R0.1.1_sub011_raw.tgz
-r--r--r-- 1 yoh datalad  9332917165 Sep 16 23:40 ds117_R0.1.1_sub012_raw.tgz
-r--r--r-- 1 yoh datalad  9224599183 Sep 16 23:40 ds117_R0.1.1_sub013_raw.tgz
-r--r--r-- 1 yoh datalad  9376072164 Sep 16 23:40 ds117_R0.1.1_sub014_raw.tgz
-r--r--r-- 1 yoh datalad  9224710368 Sep 16 23:40 ds117_R0.1.1_sub015_raw.tgz
-r--r--r-- 1 yoh datalad  9283255397 Sep 16 23:41 ds117_R0.1.1_sub016_raw.tgz
-r--r--r-- 1 yoh datalad  9282335553 Sep 16 23:41 ds117_R0.1.1_sub017_raw.tgz
-r--r--r-- 1 yoh datalad  9268148156 Sep 16 23:41 ds117_R0.1.1_sub018_raw.tgz
-r--r--r-- 1 yoh datalad  8544704037 Sep 16 23:57 ds117_R0.1.1_sub019_raw.tgz

ds000201 -- missing , after a name in dataset_description.json

thought it was again utf8 stricking back but it is just a banal missing comma (after Peter's name). since @vsoch liked my screen shots so much, here it is:

please come up with "overlay" versioning scheme (e.g. in ds 201)

https://openfmri.org/dataset/ds000201/
release 1.0.1 is a bugfix release and a new tarball was provided for "Metadata, demographics, survey, questionnaire, eye tracking, and non-imaging data (387 MB)". But the other tarballs were not uploaded for release 1.0.1, which is somewhat logical since they didn't change.

My concern is how could I (well, software) decide to have a next version to be an overlay (i.e. take old files and only replace updated ones) or a new release which might indeed have some similarly named tarballs removed. I see possible e.g. releases changing the last component (e.g. here from .0 to .1) are such overlay releases and I should assume that whatever tarball was present for previous one, is still present or replaced in the current one
Not sure if I have coded for such logic already, and not sure if there would be no glitches (eg. in some datasets some even minor inconsistency in filename could introduce "difficulties", e.g. hypothetically having "ds201_R1.0.0_dwi.tar" and "ds201_R1.0.1_dwis.tar")

But it would be nice to come up with some consistent and "standard" convention (should also be explained somewhere on the website)

Where is the code for the live OpenFMRI website (frontend, backend..)?

Do those scripts represent the current incarnation of OpenFMRI? Feels like there are some pieces missing here :)

/cc: @chrisfilo

Potential issue with con_real generation in 1st level FSF

mk_level1_fsf.py contains this bit in the part that generates custom contrasts.

            for evt in range(nevs):
                if contrasts[c][evt]!=0:
                    outfile.write('set fmri(con_real%d.%d) %s\n'%(contrastctr,con_real_ctr,contrasts[c][evt]))
                    outfile.write('set fmri(con_real%d.%d) 0\n'%(contrastctr,con_real_ctr+1))
                    con_real_ctr+=2

                else:
                    outfile.write('set fmri(con_real%d.%d) 0\n'%(contrastctr,evt+1))

I am not sure whether I fully grok it, but isn't it necessary to increment the con_real_ctr regardless of whether a particular contrast vector element is zero? Otherwise it seems to mess of the con_real specification with duplicate IDs. Moreover, why does it need this special case at all? It should be safe to write out the con_real pair even when the value is zero.

Sorry if this is a false alarm.

poldrack / openfmri Goto Github PK

openfmri's People

Contributors

Stargazers

Watchers

Forkers

openfmri's Issues

Recommend Projects

Recommend Topics

Recommend Org