Nihon Kohden V2.0 support

Abierto
  • ¿Algo no está bien?
#14,502 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
48/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
python
Área
data

Línea de trabajo

Start with mne-io/nihon/nihon.py and trace how read_raw_nihon chooses the legacy parser; the issue identifies the uint32 at offset 0x3EE as a format discriminator. Reproduce with an EEG-1200A high-density file and compare channel count and duration against the expected results. Done means the reader handles the extended block chain correctly or raises NotImplementedError instead of silently returning incorrect data.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

BUG
Description of the problem

Currently, mne-python's nihon kohden file reader read_raw_nihon silently mis-parses high-density EEG-1200A files. These have an extended block layout on disk.

#13448 enabled the EEG-1200A V01.00 device string in mne-io/nihon/nihon.py but no parser for the file layout exists. The data is stored in an extended block chain. The current low-density parsing path reads the legacy data block, whose channel-count byte usually for just channel.

The result: mne.io.read_raw_nihon() accepts these files and returns a one-channel Raw object with the wrong duration. No warning or error.

How the layout differs (verified against real files)
  • A uint32 at file offset 0x3EE is 0 on every V1 file inspected, and
    points to an extended-block chain on every EEG-1200A high-density file
    inspected. It is a reliable discriminator; the device string is not (the
    same string also appears on files that must keep the V1 path).
Proposed fixes, two options:
  1. safety - raise NotImplementedError when we detect the extend-block chain format.
  2. Add extended block support. I have a working fix which is about 100 lines long which has been tested on real files. These are compared with NK's own EDF export files and are bit-for-bit matches. (This also covers a silent scaling bug which I will submit separately.) I will also submit a document with my current understanding of the file format if that is desired.
additions to mne-testing-data

I have prepared a few small file examples of the extended block format which have no patient data in them. I would be able to submit them for including in the mne-python test data. These files also caught a couple of bugs in the version 1 format parsing path.

Steps to reproduce
create a `EEG-1200A V01.00` file on an NK acquisition machne. with this amplifier. call name the stem of the file name XXXX. So have {"XXXX.eeg", "XXXX.21e", "XXXX.log", "XXXX.pnt"


import mne
raw = mne.io.read_raw_nihon("XXXX.eeg", preload=False)
print(raw.info["nchan"], raw.n_times)   # 1 channel, wrong length; no error
Link to data

Here is a link to three small studies data files on google drive

Expected results

I will put the outputs of expected results here with the test files as the generic result using the example above is not meaningful.

Actual results

ditto

Additional information

This is being tested on ubuntu 22.04, 24.01 and mac OS 27

Lenguaje dominante
Python
Estrellas
3.6k
Forks
1.6k
Merge medio
1 d 18 h
PR fusionados (30 d)
71

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de mne-tools/mne-python

Todos los issues de mne-tools/mne-python

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.