Clarification on TUAR MCC preprocessing for LUNA fine-tuning

[Manhbui1208]

Hi authors,

Thank you for releasing the BioFoundation/LUNA codebase. I am trying to reproduce the LUNA fine-tuning results on the TUAR dataset and would like to clarify the expected preprocessing and configuration for the TUAR multiclass setting.

In the paper/OpenReview discussion, TUAR seems to be described as a multiclass single-label task, where each segment is assigned one artifact label from five classes. My understanding is that this corresponds to:

• classification_type=mcc
• model.num_classes=5
• each sample label y should be a scalar class index, e.g. one of the five artifact types.

However, when I follow the current preprocessing script for TUAR, the available modes appear to be:

• Binary
• MultiBinary
• MultiLabel

When I preprocess TUAR with:

python make_datasets/process_raw_eeg.py tuar \
  --root_dir /path/to/TUAR/edf \
  --output_dir /path/to/processed_eeg \
  --mode MultiLabel

the generated .pkl files contain labels with shape (22,), for example:

X shape: (22, 1280)
y: [3 3 0 0 3 3 0 0 0 0 0 0 0 0 3 3 0 0 3 3 0 0]
y shape: (22,)

This looks like a channel-wise multiclass/multi-output setting, where each channel receives one label from {0, 1, 2, 3, 4, 5}. So this seems closer to classification_type=mmc rather than standard segment-level mcc.

When I try to run the LUNA fine-tuning script under the MCC assumption:

python -u run_train.py +experiment=LUNA_finetune model=LUNA_base \
  pretrained_safetensors_path=/path/to/checkpoints/LUNA/Base/LUNA_base.safetensors \
  classification_type=mcc \
  model.num_classes=5 \
  data_module.train.hdf5_file=$DATA_PATH/TUAR_data/train.h5 \
  data_module.val.hdf5_file=$DATA_PATH/TUAR_data/val.h5 \
  data_module.test.hdf5_file=$DATA_PATH/TUAR_data/test.h5 \
  io.base_output_path=$CHECKPOINT_DIR \
  trainer.devices=1 \
  gpus=1 \
  batch_size=32 \
  trainer.max_epochs=1

I get the following error during data loading:

File "BioFoundation/datasets/tuh_dataset.py", line 84, in __getitem__
    y = int(grp["y"][sample_idx])
TypeError: only length-1 arrays can be converted to Python scalars

This makes sense because the current TUH_Dataset loader expects a scalar y, while the preprocessed TUAR MultiLabel data has a vector label per segment.

Could you please clarify the intended pipeline for reproducing the TUAR MCC results reported in the LUNA paper?

Specifically:

Which process_raw_eeg.py --mode should be used for the TUAR multiclass single-label setting?
Is there a separate preprocessing script or dataset conversion step that produces scalar 5-class labels for TUAR MCC?
For the MCC setting, are clean/background windows removed, or is background included as an additional class?
Should the TUAR MCC label space be five classes only, e.g. CHEW/ELEC/EYEM/MUSC/SHIV, or six classes including background?
What are the exact recommended fine-tuning overrides for LUNA on TUAR MCC, especially classification_type and model.num_classes?

Thank you very much for your help. I may have missed something in the preprocessing instructions, so I would appreciate any clarification on the expected TUAR data format for the paper’s MCC setting.

[Manhbui1208]

Additional context on TUSL preprocessing:

I also noticed a related issue when trying to reproduce the TUSL setting. The paper describes TUSL as a 4-class classification task. In the current preprocessing script, TUSL labels are generated by initializing the whole recording with label 0, then filling annotated intervals from the CSV with bckg/seiz/slow labels.

However, because TUSL annotations appear to correspond to specific 10-second annotated samples within a longer EDF recording, slicing the full EDF into non-overlapping 5-second windows produces a very large number of default label-0 windows. In my processed TUSL HDF5 files, I observed the following label distribution:

TRAIN
0: 16336 / 16819 = 97.13%
1:   158 / 16819 = 0.94%
2:   168 / 16819 = 1.00%
3:   157 / 16819 = 0.93%

VAL
0: 1228 / 1287 = 95.42%

TEST
0: 1667 / 1725 = 96.64%

With this distribution, LUNA fine-tuning seems to collapse to predicting class 0, with validation macro metrics stuck around 0.25 for accuracy/recall.

Could you please clarify the intended TUSL preprocessing protocol used for the reported LUNA results?

Specifically:

Is class 0 intended to represent all outside-annotation / unlabeled 5-second windows?
Did you keep all outside-annotation windows, or did you sample/downsample them?
Should TUSL samples be generated only from the annotated 10-second intervals, splitting each interval into two non-overlapping 5-second segments?
If the reported setting is 4-class classification, what exactly does class 0 correspond to?
Were class weights or a balanced sampler used during TUSL fine-tuning?

I may be misunderstanding the intended TUSL pipeline, so any clarification on the exact preprocessing used for the paper would be very helpful.

[Thoriri]

Hi @Manhbui1208 — thanks for the detailed report and for digging into the preprocessing. For some reason the MCC part was missing in the codebase, I made a small change such that it's there now. Here's the intended setup for both tasks.
TUAR — multiclass single-label (MCC)
The single-label multiclass setting is produced by the MultiClass mode of process_raw_eeg.py (available on the latest main):

python make_datasets/process_raw_eeg.py tuar \
  --root_dir /path/to/TUAR/edf \
  --output_dir /path/to/processed_eeg \
  --mode MultiClass

MultiClass assigns one scalar label per 5-second segment, so it loads directly with TUH_Dataset. The TypeError you saw comes from --mode MultiLabel data: those are per-channel label vectors, i.e. the channel-wise MMC setting (classification_type=mmc), not MCC. The mode ↔ task mapping is:

--mode	classification_type
Binary	bc
MultiBinary	mc
MultiLabel	mmc
MultiClass	mcc
The MCC label space is 6 classes: 0 = background, 1–5 = chew / elec / eyem / musc / shiv. Background/clean segments are kept as class 0; segments containing more than one distinct artifact type are dropped to keep the task single-label.
Recommended LUNA fine-tuning overrides:

classification_type=mcc model.num_classes=6

The TUAR artifact-classification formulation is described in more detail in the FEMBA paper (https://arxiv.org/abs/2502.06438).
TUSL
TUSL is a 4-class task with label space {0, 1, 2, 3}: 0 = background/normal (the default for any 5-second window not covered by an annotation interval), and 1/2/3 = bckg/seiz/slow taken from the CSV annotations (majority label within the window). The full recording is sliced into non-overlapping 5-second windows, and all windows are retained, so the label distribution reflects the underlying corpus, where annotated events are sparse relative to full recordings. The released configuration uses standard cross-entropy; if you'd like to counter the imbalance, adding class weights or a weighted sampler on your side might help, but yes this dataset is very imbalanced!
Hope that helps, let me know if anything's still unclear!

[Manhbui1208]

Hi @Thoriri

Thank you for making this clear as it helps a lot. I have now tested the TUAR setup with --mode MultiClass as you suggested, and the label format now matches the fine-tuning stage correctly with classification_type=mcc and model.num_classes=6.

However, the performance I obtained is still not very good, so I did a quick check of the label distribution after preprocessing. Here is what I got:

[train] total = 48467
  class 0:    26297  (54.26%)
  class 1:      610  (1.26%)
  class 2:     3698  (7.63%)
  class 3:     9807  (20.23%)
  class 4:     8019  (16.55%)
  class 5:       36  (0.07%)

[val] total = 5607
  class 0:     3225  (57.52%)
  class 2:      336  (5.99%)
  class 3:     1090  (19.44%)
  class 4:      956  (17.05%)

[test] total = 6216
  class 0:     3425  (55.10%)
  class 1:       23  (0.37%)
  class 2:      530  (8.53%)
  class 3:      966  (15.54%)
  class 4:     1272  (20.46%)

I noticed that class 1 is missing from the validation split, and class 5 is missing from both validation and test. I was wondering whether this is simply the expected imbalance of TUAR in the MCC setup, or whether it may be caused by the current random EDF-level split without a fixed seed/stratification.

For this setup, would you recommend handling it with class weights or a weighted sampler during fine-tuning (same as TUSL), or would it be better to create a stratified sample-level split after preprocessing to make sure all classes appear in train/val/test?

Thanks again for your help!