-
Notifications
You must be signed in to change notification settings - Fork 7
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
Current state of the BEP (NOT FOR MERGING) #24
base: master
Are you sure you want to change the base?
Conversation
This PR splits the tractography section from the diffusion derivatives document, so that #5 is easier to merge. The new ``05-diffusion-derivatives-tractography.md`` file will remain orphaned, but kept there as a base for the time we tackle tractography. It shouldn't be merged into the derivatives branch until it is ready.
[FIX] Split out tractography
- More clarity of distinction between requisite and optional files in output directory. - Try using 3 spaces rather than 4 in non-code indentation; partly to try to get tables within dot point lists to render correctly, partly to improve editor software syntax highlighting.
- Various small re-wordings. - Slightly more use of hyperlinks. - Short introductions to "parameter terminology" and "data representations" sections. - Be more explicit about normalised vs. non-normalised 3-vectors, so that structure more clusely mimics that of description of spherical coordinate representation. - Rename hyperlink names to "parameter terminology" section to better separate from later "intrinsic / extrinsic model parameters" sections.
Based on suggestion in #5. If all model intrinsic parameters are incorporated into a single file, rather than dropping the "_parameter-<param>" field, instead enforce that parameter name "all" be used.
When introducing the file naming convention, give an example of the "_<model>" field.
Re-arranged descriptions of intrinsic and extrinsic model parameters within the file naming section, and corrected a discordance in one dot point that was using an intrinsic model parameter filename path but discussing extrinsic model parameters.
Provide information on specification of orientation data after the various models and model parameters have been explained.
[ENH] Restructuring of DWI derivatives
[FIX] Formatting conformity to pass CI
Conflicts: src/05-derivatives/05-diffusion-derivatives.md
…actions/actions/checkout-4 Conflicts: .github/workflows/schemacode_ci.yml .github/workflows/validation.yml
* DWI models: Clarify metadata fields relevance * DWI models: Typo fix --------- Co-authored-by: Ariel Rokem <[email protected]>
…ctions/checkout-4 Bump actions/checkout from 3 to 4
Apply US spelling. Addresses current codespell CI failure.
Add "ParameterURL" metadata field
DWI models: Force presence of "param" entity
Removes one more i.e.
Filesystem macros
- FSL bedpostx command fibre orientations stored as spherical coordinates are confirmed to use the "bvec" reference frame. - Enforcing azimuth angle to obey the right hand rule about the zenith axis would necessitate direct modification of image intensities from bedpostx outputs to store. Therefore it would be preferable to instead define the sign of the azimuth angle based on the direction of the second reference axis. Closes #95. Closes #94.
Conflicts: src/derivatives/05-diffusion-derivatives.md
DWI models: Define "bvec" orientation reference
IIUC, we need to resolve this discussion: https://github.com/bids-standard/bids-bep016/pull/104/files#r1605423106, and after that we can convert this to a PR against bids-standard/bids-specification:master. Is that others' understanding as well? Do folks want to weigh in on that terminology discussion? @francopestilli : do you have any thoughts on nomenclature for l/lmax? |
A PR without #71 and with no exemplar data generated via #23 would IMO be laughed off. You can't demand that the community format their data to your decree whilst literally never having done it yourself. Please give me time to generate a BIDS App to generate and save the derivatives currently exemplified in the specification document, so that they can be moved from there to |
Hi @Lestropie, concerning this, I started working on a respective Cheers, Peer |
My comment was on the premise that the converter was being restricted in scope to exclusively conversion of pre-generated model fitting outputs, in which case another tool would be required to run the fitting then the conversion. Been a long break between bursts so certain details will still be a bit fuzzy. If in its current state that tool does both fitting and conversion, then that's the obvious starting point; but as per PeerHerholz/bids_bep16_conv#7 longer term we'll want to think about separation of those two steps. |
This is a replacement of #6 as the BEP is being reinvested in.
The PR is not for merging, but to show the current state of the difference between the BEP and an up-to-date
master
of the BIDS specification.