Template used for the Subject*_ImageNetTraining.h5 file

[huawei-xu]

Thank you very much for your assistance.
I have two questions about the dataset.
Could you let me konw which specific template is used for the Subject*_ImageNetTraining.h5 file?
I have tried some common templates (MNI152NLin2009cAsym and MNI152NLin6Asym) but found mismatches, so I want to confirm the exact one.
Also, I noticed there are two coordinate systems in the metadata: XYZ and IJK. Do they actually correspond to the same template and the same space, just represented differently?

[micchu]

Dear @huawei-xu,

Thank you for your question.

Could you let me konw which specific template is used for the Subject*_ImageNetTraining.h5 file?

Regarding Subject*_ImageNetTraining.h5, the data are in each subject's native T1w space. They were not normalized to a standard template such as MNI152NLin2009cAsym or MNI152NLin6Asym. Therefore, these files are not provided in MNI space.
For the BData datasets released by the Kamitani Lab on Figshare, the default space is each subject's native T1w space unless otherwise noted.

Also, I noticed there are two coordinate systems in the metadata: XYZ and IJK. Do they actually correspond to the same template and the same space, just represented differently?

As for the metadata, XYZ and IJK do not refer to different templates or different spaces. They describe the same native-space data in two different ways.
XYZ represents continuous coordinates in millimeters in the subject's native image space, whereas IJK represents voxel indices in the corresponding preprocessed BOLD NIfTI volume, with the origin at the corner of the volume.

I hope this clarifies the issue. Please let us know if anything remains unclear.
Best regards,

[PeerHerholz]

Hello @micchu,

do you think it might be helpful to update the naming pattern of the data to be more BIDS-like?
For example, it could be something akin to sub-01_task-ObjectDecoding_space-T1w_desc-ImageNetTraining.h5. I think figshare also supports dataset versioning, ie the prior version could remain for legacy purposes. However, I of course understands if this won't add any benefits.

[micchu]

Thank you, @PeerHerholz,

I agree that using a more BIDS-like naming scheme would be beneficial for future datasets and new repositories.

For the current Figshare release, however, I am hesitant to rename already published files, because the existing GitHub code and documentation assume the current filenames, and changing them could create inconsistencies for users and downstream workflows.

So for the current dataset, I think it would be more important to improve the Figshare metadata/description, for example by explicitly stating that these data are in each subject’s native T1w space, not normalized to MNI, and by documenting the preprocessing provenance such as the fMRIPrep version.

For future releases, I would be happy to consider a more BIDS-like naming scheme from the outset.

Best regards,

[micchu]

@PeerHerholz san,

Just to clarify one point: my main concern is not the BIDS-like naming itself, but changing the filenames in the current release.

Even if figshare versioning preserves the legacy version, renaming only the latest release would still create a mismatch between the current Figshare files and the existing GitHub code/documentation, which are based on the current filenames. From a user and maintenance perspective, that could make the dataset harder to follow.

So, if we decide to provide a BIDS-like version, I think it would be better to do so as an additional dataset or a separate release, while also improving the metadata/provenance of the current dataset.

[huawei-xu]

Thank you very much for your reply. So the template file for the Subject*_ImageNetTraining.h5 is the Subject*_SpaceTemplate in the dataset folder 7387130, which can be downloaded from Figshare, Am I understanding this correctly? But when I apply the IJK voxel coordinates to the template, the results appear to be inconsistent.

img = np.zeros(template_bold_1.shape)

for voxel_idx in range(data_location_ijk.shape[1]):

    i = data_location_ijk[0,voxel_idx]
    j = data_location_ijk[1,voxel_idx]
    k = data_location_ijk[2,voxel_idx]

    img[int(i),int(j),int(k)] = data[0,voxel_idx]

img = nib.Nifti1Image(img, template_bold_1.affine)

plotting.view_img(img, template_bold_1, symmetric_cmap=False, cmap="hot", title="Subject5-ROI_V1")

However, it seems to give a reasonable alignment when I flip the J coordinate, although I am not entirely sure if this is the correct approach.

img = np.zeros(template_bold_1.shape)

for voxel_idx in range(data_location_ijk.shape[1]):

    i = data_location_ijk[0,voxel_idx]
    j = data_location_ijk[1,voxel_idx]
    k = data_location_ijk[2,voxel_idx]

    img[int(i),int(-j),int(k)] = data[0,voxel_idx]

img = nib.Nifti1Image(img, template_bold_1.affine)

plotting.view_img(img, template_bold_1, symmetric_cmap=False, cmap="hot", title="Subject5-ROI_V1")

I also converted IJK coordinates to XYZ using the affine from this template, but the resulting XYZ coordinates do not match the XYZ in the Subject*_ImageNetTraining.h5. This makes me wonder if I am using the wrong template.

By the way, I noticed an issue with some files on OpenNeuro. In the sourcedata folder, files can be downloaded successfully,
but they appear as 0 KB after downloading (e.g., most subjects except subject 5).

[PeerHerholz]

Hello @micchu,

Just to clarify one point: my main concern is not the BIDS-like naming itself, but changing the filenames in the current release.

Even if figshare versioning preserves the legacy version, renaming only the latest release would still create a mismatch between the current Figshare files and the existing GitHub code/documentation, which are based on the current filenames. From a user and maintenance perspective, that could make the dataset harder to follow.

So, if we decide to provide a BIDS-like version, I think it would be better to do so as an additional dataset or a separate release, while also improving the metadata/provenance of the current dataset.

Yes, you're absolutely right. The two aspects are dependent on one another and should be updated respectively. Please just let me know if I can be of any help regarding this.

[PeerHerholz]

Hello @huawei-xu,

I'm not too familiar with the dataset and thus my two cents shouldn't be too heavily trusted as @micchu and other lab members are way more knowledgeable.

Re IJK: yes, I would also assume that the axis of the j coordinate is flipped. This could be due to different conventions used for the h5 data and template data or using the "wrong" template for visualization.

Re XYZ and affine: similar to above, things depend on the template and subject data space. If they are not from the same subject and modality, for example t1w and bold, then applying only the affine won't work as another transform between these spaces is needed. You could try plotting the h5 and template data next to each other/overlay them or maybe compare their shape?

[micchu]

Dear @huawei-xu and @PeerHerholz,

Thank you very much for your careful investigation and thoughtful comments. We also appreciate @PeerHerholz's helpful point that the apparent mismatch could in part reflect the use of a template different from the one corresponding to Subject*_ImageNetTraining.h5. This was an important point.

1. In the current Figshare repository, Subject*.h5, Subject*_SpaceTemplate.nii, and Subject*_T1wAligned.nii are files associated with the older SPM-based processing workflow and were released essentially as they were used at the time of the original publication. In contrast, Subject*_ImageNetTraining.h5 was generated from data preprocessed with fMRIPrep. In other words, these files are not based on the same preprocessing/template space. We apologize that this dependency was not clearly stated in the metadata and dataset description. This is our oversight, and we will revise the metadata and descriptions as soon as possible.

2. Because the underlying template spaces are different, Subject*_SpaceTemplate.nii should not be expected to match Subject*_ImageNetTraining.h5 exactly. In addition, Subject*_SpaceTemplate.nii has an LAS orientation, whereas the image space associated with Subject*_ImageNetTraining.h5 follows an LPS-oriented convention. This likely explains why flipping the j axis can make the result look more consistent. However, this does not mean that flipping j is the correct solution. Since the underlying template spaces are different, simple j-axis flipping cannot fully recover the correct alignment. The fact that the occipital brain region is still not fully covered after flipping, as shown in the second attached image, is consistent with this interpretation.

3. We can also provide the template file corresponding to Subject*_ImageNetTraining.h5 if needed. That said, because the .h5 file contains both IJK voxel coordinates and XYZ millimeter coordinates for corresponding voxels, it should in principle be possible to reconstruct the voxel-to-world affine transformation directly from those coordinate pairs. Still, providing the reference template would make visualization and validation much easier, so we would be happy to add it to Figshare if that would be helpful.

4. Regarding the OpenNeuro files that appear as 0 KB after download, this may be related to a known OpenNeuro-side download issue in which files with nonzero size are downloaded as empty files. For example, OpenNeuro issue #3816 describes a similar symptom. Our case is not necessarily identical, since it involves a different dataset and multiple files, but the symptom appears similar.
   As a workaround, you could consider downloading via AWS S3. OpenNeuro snapshots are synchronized to a public S3 bucket, and downloading via:

aws s3 sync --no-sign-request s3://openneuro.org/ds001246 ds001246-download/

accesses that S3 copy directly. In our case, this workaround succeeded. Therefore, the 0 KB issue may be related to the standard OpenNeuro download path rather than the underlying stored files themselves.
It is also possible to restrict the download to a smaller subset, for example a specific prefix such as sourcedata/sub-01/anat:

aws s3 sync --no-sign-request \
  s3://openneuro.org/ds001246/sourcedata/sub-01/anat \
  ds001246-download/sourcedata/sub-01/anat

Thank you again for pointing this out.

Best regargs,

[huawei-xu]

Dear @micchu and @PeerHerholz,

Thank you both for your detailed and prompt responses. They have answered all my questions. Please do consider adding the corresponding template file to Figshare—this dataset is really interesting, and including the proper template will make it much more complete and usable.

Best regards

[micchu]

Dear @huawei-xu,

Thank you for your request. We have added the space template files corresponding to the fMRIPrep-processed data to Figshare.
https://doi.org/10.6084/m9.figshare.7387130.v7

The added file names are Subject*_fMRIPrepSpaceTemplate.nii. I hope this helps.

Best regards,