IndexError: string index out of range in dcm2niix2bids.py about bidscoin HOT 6 CLOSED

Indeed, I test with the default template, in which part is specified as a list (which defines/translates into a dropdown menu in the bidseditor). I now made a catch for this (i.e. when part is not specified as a list) when loading the bidsmap.

Another note You're checking there the ImageType DICOM field (0008, 0008) but the BIDS specification says, that this value corresponds to (0008,9208) which is ComplexImageComponent, which I can't find in my DICOM file.

Sure I use ImageType as an attribute to identify (discriminate) acquired DICOM scans (datatypes), but that has nothing to do with the Complex Image Component Attribute you are talking about. The latter is supposed to store the part mag/phase/real/imag info, but I also don't see anyting in our DICOM headers. Hence I'm not using it to populate part

have you considered using pull requests to fix issues? It seems to me that there are fixes of multiple things at once on the master branch. PRs would greatly help with isolating the fixes and testing them.

The way I work is as follows. When I'm working on a bug or feature that is not too complex and that I'm sure I want to land in master, then I develop it straight in master, otherwise I create a feature branch. I use PRs only to merge contributions from other people. I see the advantages of doing more of my development in feature/bugfix branches (but it sometimes also makes life more complicated due to potential merge conflicts), but I don't see what the benefit would be using PR's for my own branches as opposed to merging them directly with master? Sure, there is CI on github, but I locally use tox to get the same functionality (but way faster)

from bidscoin.

Thanks for reporting this. You are using bidscoin in a way that I didn't intend, which is a very good thing as it makes me fix the code to be more robust and flexible :-)

from bidscoin.

Another note You're checking there the ImageType DICOM field (0008, 0008) but the BIDS specification says, that this value corresponds to (0008,9208) which is ComplexImageComponent, which I can't find in my DICOM file.

Sure I use ImageType as an attribute to identify (discriminate) acquired DICOM scans (datatypes), but that has nothing to do with the Complex Image Component Attribute you are talking about. The latter is supposed to store the part mag/phase/real/imag info, but I also don't see anyting in our DICOM headers. Hence I'm not using it to populate part

The comment in the code says

So I assumed that you're trying to set this value. Therefore the comment about the DICOM field.

from bidscoin.

have you considered using pull requests to fix issues? It seems to me that there are fixes of multiple things at once on the master branch. PRs would greatly help with isolating the fixes and testing them.

The way I work is as follows. When I'm working on a bug or feature that is not too complex and that I'm sure I want to land in master, then I develop it straight in master, otherwise I create a feature branch. I use PRs only to merge contributions from other people. I see the advantages of doing more of my development in feature/bugfix branches (but it sometimes also makes life more complicated due to potential merge conflicts), but I don't see what the benefit would be using PR's for my own branches as opposed to merging them directly with master? Sure, there is CI on github, but I locally use tox to get the same functionality (but way faster)

I've just noticed that you reference the issue ids in your commits, which will help me now.

In this context, a PR would group the commits relevant to resolving a specific issue, which then helps in identifying commits or simply a branch to test, before it is merged to master, especially when multiple issues are resolved in parallel. PRs also give a nice summarized view of the changes over all commits for a specific issue, which in my experience helps to focus 😃

from bidscoin.

I can't reproduce this problem anymore on the master branch.

from bidscoin.

Sure I use ImageType as an attribute to identify (discriminate) acquired DICOM scans (datatypes), but that has nothing to do with the Complex Image Component Attribute you are talking about. The latter is supposed to store the part mag/phase/real/imag info, but I also don't see anything in our DICOM headers. Hence I'm not using it to populate part

The comment in the code says

bidscoin/bidscoin/plugins/dcm2niix2bids.py

Line 171 in 2a0dd3a

# Try to automagically set the {part: phase/imag/real} (should work for Siemens data)

So I assumed that you're trying to set this value. Therefore the comment about the DICOM field.

Ah sure, there I'm trying to guess the image type before the bidsmap is fed to the bidseditor. In the BIDS specification they mean something else when they talk about ImageType, as you noted. I wasn't sure what you were trying to say, but I suppose we are on the same line of thought here

from bidscoin.