Unable to load data with mne.io.read_raw_kit()

💬 Support & Discussions
1

Hi all! I’m very unfamiliar with MEG data in general, but am trying to use the MNE package to load in some data collected several years ago (in 2013). From what I can tell, the data is in KIT format, such that I have several .sqd files (plus an .hsp and .elp file) for each subject.

To start, I tried to use the function mne.io.read_raw_kit(data_fn) to read it in.

When doing so, the first error I got was UnsupportedKITFormat: SQD file format V2R001 is not officially supported. Set allow_unknown_format=True to load it anyways. This is probably unsurprising, given how old the data is.

But when changing that allow_unknown_format flag to True, I get a different error that is much less informative. Here’s the full trace:

Extracting SQD Parameters from data/meg/R0487/R0487_MEGBound_Block1_5.16.13.sqd...
Creating Raw.info structure...
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-15-979032905ed0> in <module>
----> 1 mne.io.read_raw_kit(input_fname = data_fn, allow_unknown_format=True)

~/opt/anaconda3/lib/python3.8/site-packages/mne/io/kit/kit.py in read_raw_kit(input_fname, mrk, elp, hsp, stim, slope, stimthresh, preload, stim_code, allow_unknown_format, standardize_names, verbose)
    914     coordinates should be in units of meters.
    915     """
--> 916     return RawKIT(input_fname=input_fname, mrk=mrk, elp=elp, hsp=hsp,
    917                   stim=stim, slope=slope, stimthresh=stimthresh,
    918                   preload=preload, stim_code=stim_code,

<decorator-gen-254> in __init__(self, input_fname, mrk, elp, hsp, stim, slope, stimthresh, preload, stim_code, allow_unknown_format, standardize_names, verbose)

~/opt/anaconda3/lib/python3.8/site-packages/mne/io/kit/kit.py in __init__(self, input_fname, mrk, elp, hsp, stim, slope, stimthresh, preload, stim_code, allow_unknown_format, standardize_names, verbose)
    132         self.preload = False
    133         logger.info('Creating Raw.info structure...')
--> 134         info, kit_info = get_kit_info(
    135             input_fname, allow_unknown_format, standardize_names)
    136         kit_info['slope'] = slope

<decorator-gen-257> in get_kit_info(rawfile, allow_unknown_format, standardize_names, verbose)

~/opt/anaconda3/lib/python3.8/site-packages/mne/io/kit/kit.py in get_kit_info(rawfile, allow_unknown_format, standardize_names, verbose)
    514             if allow_unknown_format:
    515                 unsupported_format = True
--> 516                 warn("Force loading KIT format %s", version_string)
    517             else:
    518                 raise UnsupportedKITFormat(

~/opt/anaconda3/lib/python3.8/site-packages/mne/utils/_logging.py in warn(message, category, module, ignore_namespaces)
    363         # because we move out of the MNE stack, so warnings won't properly
    364         # recognize the module name (and our warnings.simplefilter will fail)
--> 365         warnings.warn_explicit(
    366             message, category, fname, lineno, module,
    367             globals().get('__warningregistry__', {}))

TypeError: 'str' object is not callable

Any insight into what’s going on?

For reference, my MNE version is 0.24.0, and I’m running this on MacOS Big Sur 11.6.

2

where was the data collected?

can you share a file so we can investigate?

A

3

The data was collected at NYU. Here’s a link to a file.

Thanks for your help!

1 Like
4

I got a bit curious and gave it a go.
If you remove the warning, issued when allow_unknown_format is set to True (which should work); you then get another error further down the road when reading the data…

Documentation for allow_unknown_format is:

allow_unknown_format : bool
        Force reading old data that is not officially supported. Alternatively,
        read and re-save the data with the KIT MEG Laboratory application.

Does this alternative work for you?

For the warning, I’ve fixed it in this PR: Fix warning in KIT reader by mscheltienne · Pull Request #10018 · mne-tools/mne-python · GitHub

5

For your information, the next error is the only one remaining; it basically can not read the dtype of the data from the file. If I set it to e.g. dtype('int32') (just a guess) with np.dtype('<i4'), I can read the file.

6

Thanks so much, Mathieu! I pulled the newest version of the package after that fix was implemented, and now don’t hit that error anymore.

Would you mind clarifying that second change for me as well? e.g., how exactly should the code you pasted be modified to change the dtype?

7

I never worked with KIT before; but when I load your file, adc_allocated is equal to 0.
When adc_allocated is set to 0, sqd['dtype'] = np.dtype(f'<i{adc_allocated // 8}') fails because np.dtype('<i0') is not recognized as a valid dtype.

Examples of valid dtype would be:

  • adc_allocated=8 → np.dtype('<i1') → dtype('int8')
  • adc_allocated=16 → np.dtype('<i2') → dtype('int16')
  • adc_allocated=32 → np.dtype('<i4') → dtype('int32')

I doubt MEG data was saved as int8, and I am already surprised the KIT reader reads it as integers.
Maybe it’s not the type of the data, but of a different variable used in the KIT system, I have actually no idea. But the point is, I don’t know what it should be, 8, 16 or 32?

So one ‘hot’ fix would be to hard-code this to e.g. 32 as I did to load your file. To do so, you could clone the newest version from the GitHub repository, and navigate to mne.io.kit.kit.py line 571-572; and either hard-code adc_allocated to 32; or replace sqd['dtype'] = np.dtype(f'<i{adc_allocated // 8}') with sqd['dtype'] = np.dtype('<i4').
Then you can install in your venv this ‘fix’ version with e.g. python setup.py install. You could also install it in develop mode with python setup.py develop which would allow for further changes to the code-base (folder in which you clone the repository) to be included immediately in your venv.

Disclaimer: I don’t know enough about KIT, about whatever this dtype is referring to. I do not offer any guarantee about this ‘fix’. It is after all an old unsupported format.

8

Got it, thank you! I’m really just messing with this data as an initial learning experience, so this fix should be good enough for now. :slight_smile: