Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Firefox] Loading module from "...schema.json" was blocked because of a disallowed MIME type ("application/json"). #2087

Closed
suxpert opened this issue Aug 16, 2024 · 8 comments
Labels

Comments

@suxpert
Copy link

suxpert commented Aug 16, 2024

I was trying validate a BIDS dataset under Linux (where only firefox browser is avalable, so other browsers are not tested), and the latest validator complained a lot, which most of the error and warnings do not exist if I use the legacy validator.

Then I opened the web console, there are error messages like this:

Loading module from “https://bids-specification.readthedocs.io/en/latest/schema.json” was blocked because of a disallowed MIME type (“application/json”).
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://bids-specification.readthedocs.io/en/latest/schema.json. (Reason: CORS request did not succeed). Status code: (null).
Module source URI is not allowed in this document: “https://bids-specification.readthedocs.io/en/latest/schema.json”.
TypeError: error loading dynamically imported module: https://bids-specification.readthedocs.io/en/latest/schema.json
Warning, could not load schema from https://bids-specification.readthedocs.io/en/latest/schema.json, falling back to internal version

I'm not sure that warnings and errors are caused by such issue or not, but since there are messages showing:

warning: UNKNOWN_BIDS_VERSION

The BIDSVersion field of 'dataset_description.json' does not match a known release. The BIDS Schema used for validation may be out of date.

  • /dataset_description.json

I guess it is the internal version of the schema caused those warnings and errors. No matter what, the schema be blocked issue should not exist, right?

@effigies
Copy link
Collaborator

which most of the error and warnings do not exist if I use the legacy validator.

This is expected. While we are working on dealing with some false positives, there are significant portions of the specification that the legacy validator did not systematically validate.

Loading module from “https://bids-specification.readthedocs.io/en/latest/schema.json” was blocked because of a disallowed MIME type (“application/json”).
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://bids-specification.readthedocs.io/en/latest/schema.json. (Reason: CORS request did not succeed). Status code: (null).
Module source URI is not allowed in this document: “https://bids-specification.readthedocs.io/en/latest/schema.json”.
TypeError: error loading dynamically imported module: https://bids-specification.readthedocs.io/en/latest/schema.json
Warning, could not load schema from https://bids-specification.readthedocs.io/en/latest/schema.json, falling back to internal version

The web validator cannot retrieve unreleased updates to the schema, while the command-line validator can. This warning is not really intended for web users, but wasn't suppressed for them, either. All this means is that the web validator will use the schema that was available at the time that it was published.

warning: UNKNOWN_BIDS_VERSION

This should be resolved in the development version of the validator. If you're still seeing it there, you may have a malformed BIDS version. The known values can be found https://github.com/bids-standard/bids-specification/blob/master/src/schema/meta/versions.yaml. I mostly see it when a dataset has version "v1.X.X", instead of just "1.X.X".

@suxpert
Copy link
Author

suxpert commented Aug 19, 2024

The BIDS version in dataset_description.json is 1.2.1, which seems nothing strange.
I tried changing this number to 1.9.0 and got the exact same result with this warning:

warning: UNKNOWN_BIDS_VERSION

BTW, there are lots of other warning and errors shown, e.g.,:

  • ERROR: EXTENSION_MISMATCH
    Extension used by file does not match allowed extensions for its suffix
  • WARNING: NIFTI_DIMENSION
    NIfTI file's header field for dimension information is blank or too short.
  • WARNING: NIFTI_PIXDIM
    NIfTI file's header field for pixel dimension information is empty or too short.
  • WARNING: SIDECAR_KEY_RECOMMENDED
    A data file's JSON sidecar is missing a key listed as recommended.
  • ERROR: REPETITION_TIME_MISMATCH
    Repetition time did not match between the scan's header and the associated JSON metadata file.

These warnings and errors do not exist if I run with the legacy validator.
To be clear, the RepetitionTime in the sidecar is exactly the same as pixdim4 of the NifTi file (1.400000 in my case, which is of cause not empty),
the EXTENSION_MISMATCH file ChangeLog is already added in .bidsignore (This file is generated and contains private information, so is not directly named as Changes, as required by BIDS).

@effigies
Copy link
Collaborator

Please see #2081 and #2091 for most of these. I believe the repetitiontime issue is the only outstanding one.

@suxpert
Copy link
Author

suxpert commented Aug 20, 2024

This means that either dim[0] == 0 or min(dim[1:dim[0]]) <= 0. If that's not the case, that's a bug.

For my case, here are two example files that has been listed under NIFTI_DIMENSION and NIFTI_PIXDIM. (Actually it lists all NifTi files in my dataset, which only contains 4 subjects, each with ~380M, that is too small to be considered as a large dataset)

$ fslhd bids/sub-0151/anat/sub-0151_acq-highres_run-01_T1w | grep 'dim'
dim0            3
dim1            192
dim2            256
dim3            256
dim4            1
dim5            1
dim6            1
dim7            1
pixdim0         1.000000
pixdim1         1.000000
pixdim2         0.937500
pixdim3         0.937500
pixdim4         2.300000
pixdim5         0.000000
pixdim6         0.000000
pixdim7         0.000000
phase_dim       1
freq_dim        2
slice_dim       3
$ fslhd bids/sub-0151/func/sub-0151_task-rest_run-01_bold | grep 'dim'
dim0            4
dim1            116
dim2            96
dim3            66
dim4            200
dim5            1
dim6            1
dim7            1
pixdim0         -1.000000
pixdim1         1.458330
pixdim2         1.458330
pixdim3         1.500000
pixdim4         1.500000
pixdim5         0.000000
pixdim6         0.000000
pixdim7         0.000000
phase_dim       1
freq_dim        2
slice_dim       3

The only "issue" I can see from these NifTi files might be that the functional image have pixdim0=-1, but this is very common (e.g. see here).

dataset_description.json be

{
	"Name":	"test dataset",
	"BIDSVersion":	"1.2.1",
	"License":	"Unknown",
	"Authors":	["XXX", "XXX"],
	"Acknowledgements":	"add any acknowledgement here."
}

and the output of BIDS-Validator be like this:
BIDS Validator.pdf

PS. I've tested the same dataset under Edge (under windows 11), the result is the same as in Firefox, so this issue is not related to Firefox or Linux.

@effigies
Copy link
Collaborator

I believe your issues should be addressed with the next release.

@suxpert
Copy link
Author

suxpert commented Aug 20, 2024

For RepetitionTime, I meet it in another dataset which is a little bit larger than previous mentioned one (~700M per subject).
From the dataset, I have:

$ grep 'RepetitionTime' bids7/sub-*/func/*_bold.json
bids7/sub-0151/func/sub-0151_task-rest_run-01_bold.json:  "RepetitionTime": 1.4,
bids7/sub-0151/func/sub-0151_task-rest_run-02_bold.json:  "RepetitionTime": 1.4,
bids7/sub-0156/func/sub-0156_task-rest_run-01_bold.json:  "RepetitionTime": 1.4,
bids7/sub-0156/func/sub-0156_task-rest_run-02_bold.json:  "RepetitionTime": 1.4,
bids7/sub-0342/func/sub-0342_task-rest_run-01_bold.json:  "RepetitionTime": 1.4,
bids7/sub-0342/func/sub-0342_task-rest_run-02_bold.json:  "RepetitionTime": 1.4,
bids7/sub-0358/func/sub-0358_task-rest_run-01_bold.json:  "RepetitionTime": 1.4,
bids7/sub-0358/func/sub-0358_task-rest_run-02_bold.json:  "RepetitionTime": 1.4,

and

$ for ii in bids7/sub-*/func/*_bold.nii.gz; do echo -ne "$ii\t"; fslhd $ii | grep 'pixdim4'; done
bids7/sub-0151/func/sub-0151_task-rest_run-01_bold.nii.gz       pixdim4         1.400000
bids7/sub-0151/func/sub-0151_task-rest_run-02_bold.nii.gz       pixdim4         1.400000
bids7/sub-0156/func/sub-0156_task-rest_run-01_bold.nii.gz       pixdim4         1.400000
bids7/sub-0156/func/sub-0156_task-rest_run-02_bold.nii.gz       pixdim4         1.400000
bids7/sub-0342/func/sub-0342_task-rest_run-01_bold.nii.gz       pixdim4         1.400000
bids7/sub-0342/func/sub-0342_task-rest_run-02_bold.nii.gz       pixdim4         1.400000
bids7/sub-0358/func/sub-0358_task-rest_run-01_bold.nii.gz       pixdim4         1.400000
bids7/sub-0358/func/sub-0358_task-rest_run-02_bold.nii.gz       pixdim4         1.400000

For this dataset, I got the RepetitionTime mismatch issue:
BIDS-Validator-7.pdf

This issue do not exist for the previous dataset, where TR=1.5. So is it an IEEE 754 issue? Since in IEEE 754, 1.5 is precisely 1.5, but 1.4 is not.

@suxpert
Copy link
Author

suxpert commented Aug 22, 2024

One more question:

ERROR: SLICE_TIMING_AND_DURATION_MUTUALLY_EXCLUSIVE

'SliceTiming' is defined for this file. Neither 'DelayTime' nor 'AcquisitionDuration' may be defined in addition.

For functional images, slice_timing defines the relative acquisition time of each slice of a volume, and AcquisitionDuration stands for the total acquisition time of N volumes, Why are they exclusive?

@effigies
Copy link
Collaborator

Ugh, it looks like BIDS has an inconsistent definition of AcquisitionDuration. Our definition says it's the duration of the acquisition of a volume, but then points to DICOM 0018,9073 (duration of a series) as reference. And it looks like it's been that way the entire time the term has been in the spec, so dcm2niix is taking the DICOM correspondence at its word. I think we need to relax the AcquisitionDuration field and introduce FrameAcqusitionDuration 0018,9220, which matches our text description and original intent.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants