Warn about coarse input voxel size and clarify resolution requirements - #28
Open
karl-koschutnig wants to merge 1 commit into
Open
Warn about coarse input voxel size and clarify resolution requirements#28karl-koschutnig wants to merge 1 commit into
karl-koschutnig wants to merge 1 commit into
Conversation
Segmentations at ~1 mm rather than the ~0.33 mm this method is designed for fail checkSurface with "Surface contains holes", which sends users toward manual editing even though the segmentation is usually fine. The mask filters are parameterised in voxels, not mm, so their physical strength scales with the input voxel size. - Warn at startup when the input voxel edge length exceeds a threshold, and for --lut freesurfer additionally point out the .FSvoxelSpace. variant, which is the common way to hit this. - Add the voxel size to the "Surface contains holes" message when the input is coarse, so the error itself suggests checking the resolution before editing the segmentation. - Log when --upsample is a no-op, which it silently is for isotropic input, since reaching for it is the natural response to the error. - Document the two FreeSurfer output files and the resolution dependency in the tutorial and documentation. Refs Deep-MI#25
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Addresses items 1–3 from #25, per @m-reuter's "you can attempt a fix for the other items in a PR". The
--upsample/--make-isotropicrenaming is deliberately not included here, since you mentioned that is under internal discussion — the only change to that flag is a log line (see below).What this changes
The mask filters are parameterised in voxels rather than mm, so their physical strength scales with input voxel size. At ~1 mm the hippocampal ribbon is only ~2 voxels thick and default filtering erodes through it, producing "Surface contains holes" — which then sends users toward manual editing, even though the segmentation is usually fine and it is the resolution that is wrong.
voxel_size_threshold = 0.4mm incfg/config.py, set just above the native 0.33333 mm so correct input never trips it). For--lut freesurferit additionally names the.FSvoxelSpace.variant, which is the usual way to hit this.checkSurfacemessage — when the input is coarse, the "holes" error now says so and suggests checking for a higher-resolution segmentation before editing. When the input is not coarse, the message is unchanged, so genuine segmentation defects still get the original advice.TUTORIAL.md(mandatory arguments) andDOCUMENTATION.md(supported segmentations), and the "Holes in the surface" troubleshooting section now lists input resolution as the first thing to check.--upsampleno-op is now logged. It is silently a no-op for isotropic input (everymin(vxsz)/vxsz[i]ratio is 1, so the affine is unchanged). Reaching for--upsampleis the natural response to the holes error, so the silence is misleading. This is only a log line — no behaviour or naming change.The voxel size is read once in
_check_paramsand stashed onparams.internal, socheckSurfacedoes not have to re-read the image (by that pointparams.FILENAMEhas been reassigned several times).Two decisions I would like your call on
a) Should the FreeSurfer case be a hard error rather than a warning? You suggested "we know that the .333mm file should exist and so we can even stop if we do not get that file passed". I have implemented it as a warning for now, because erroring would break any existing workflow that knowingly runs coarser data, and would want an override flag. Happy to switch it to an error if you prefer — it is a small change. Note I keyed the check off the actual voxel size rather than the filename, so it still works for renamed or copied files.
b) How should this behave for ASHS? As written, the warning fires for any coarse input, so ASHS users will see it on essentially every run — anisotropic voxels are normal there, and the docs already recommend
--upsamplefor them. I left it un-special-cased rather than guess: the input genuinely is coarse and it is only a warning. If you would rather suppress it (or reword it) for the ASHS LUTs, that is a one-line condition onparams.LUTand I am happy to add it. You mentioned you were unsure whether ASHS outputs use the anisotropic input resolution — if you can confirm, I can tune the wording accordingly.Test plan
Tested against a FreeSurfer 8.2 longitudinal cohort, running the pipeline in the Docker image with the modified package mounted in:
.FSvoxelSpace.input,--lut freesurfer— both startup warnings fire, and the holes error carries the new resolution hint.Hipsta finished without errors., all three QC PNGs written. No regression.--upsample— logsThe image already has isotropic voxels of 1.000 mm, so upsampling ... leaves it unchanged.ruff check .andcodespellpass.Sample output for the first case: