\n
![\"\"](\"https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F7019029%2F00cc10491c9bec238d6ef91ab0ee35d0%2Fbad%20pixel%20size.jpg?generation=1754083180302155&alt=media\"){kind=tracking}
Hi everyone,
\nWhile auditing the RSNA Intracranial Aneurysm Detection dataset I found a small set of DICOM slices whose in-plane Pixel Spacing differs from the dominant spacing of their series (usually scout/topogram frames saved in the same folder).
\nNote: in many “enhanced” or multi-frame CT objects the true voxel spacing is stored inside the Pixel Measures Sequence (tag 0028,9110) of the Shared/Per-Frame Functional Groups, so a quick header read may miss it. After parsing those nested groups most series are clean—only the files listed below still break consistency.
\nTo help others avoid silent resampling errors, I’m sharing the full list of filenames beneath this post.
\nIf you spot anything I missed—or have a cleaner way to filter scouts—please let me know!
images like …
\n
Hi everyone,
\nWhile auditing the RSNA Intracranial Aneurysm Detection dataset I found a small set of DICOM slices whose in-plane Pixel Spacing differs from the dominant spacing of their series (usually scout/topogram frames saved in the same folder).
\nNote: in many “enhanced” or multi-frame CT objects the true voxel spacing is stored inside the Pixel Measures Sequence (tag 0028,9110) of the Shared/Per-Frame Functional Groups, so a quick header read may miss it. After parsing those nested groups most series are clean—only the files listed below still break consistency.
\nTo help others avoid silent resampling errors, I’m sharing the full list of filenames beneath this post.
\nIf you spot anything I missed—or have a cleaner way to filter scouts—please let me know!
images like …
\n
Thanks for this valuable info. Unfortunately this reflects real world data, so measures like what you are proposing may be necessary.
", "rawMarkdown": "Thanks for this valuable info. Unfortunately this reflects real world data, so measures like what you are proposing may be necessary. ", "votes": 1 }, { "id": 3262596, "postDate": "2025-08-04T00:00:00.187Z", "content": "Your method seems to catch most of the instances (well done, this is useful), but there might be some that slip through the net. Try, for example, SeriesInstanceUID 1.2.826.0.1.3680043.8.498.17677548211553545296698864792051352427, SOPInstanceUID 1.2.826.0.1.3680043.8.498.55677754734899892737758005594096916348.
What is even more disturbing with this example is that it should be the slice containing the aneurysm coordinates (see train_localizers.csv)! I am planning later today to release an initial list of \"wrong coordinates\" for CT scans (either they seem on the right slice, but wrong location; or they are located on the wrong slice). There could be up to 11 such cases, but I need to do a final check before releasing.
The script scans every series folder, records the (Rows × Cols) of each DICOM header without loading pixel data, treats the most frequent matrix size as the series’ reference resolution, and logs any slice whose dimensions differ; the result is a CSV (dim_mismatch.csv) listing 38 out-of-spec instances out of 4,405 series, enabling us to review or drop only the problematic files before NIfTI conversion.
\nhttps://www.kaggle.com/code/antonsibilev/mismatch-resolution-v1
", "rawMarkdown": "The script scans every series folder, records the (Rows × Cols) of each DICOM header without loading pixel data, treats the most frequent matrix size as the series’ reference resolution, and logs any slice whose dimensions differ; the result is a CSV (dim_mismatch.csv) listing 38 out-of-spec instances out of 4,405 series, enabling us to review or drop only the problematic files before NIfTI conversion.\n\nhttps://www.kaggle.com/code/antonsibilev/mismatch-resolution-v1" } ], "comments": [ { "id": 3265694, "author_name": "Evan Calabrese", "author_url": "", "post_date": "2025-08-07T20:38:04.427000", "content": "Thanks for this valuable info. Unfortunately this reflects real world data, so measures like what you are proposing may be necessary.
", "votes": 1, "replies": [] }, { "id": 3262596, "author_name": "Patrick Robitaille", "author_url": "", "post_date": "2025-08-04T00:00:00.187000", "content": "Your method seems to catch most of the instances (well done, this is useful), but there might be some that slip through the net. Try, for example, SeriesInstanceUID 1.2.826.0.1.3680043.8.498.17677548211553545296698864792051352427, SOPInstanceUID 1.2.826.0.1.3680043.8.498.55677754734899892737758005594096916348.
What is even more disturbing with this example is that it should be the slice containing the aneurysm coordinates (see train_localizers.csv)! I am planning later today to release an initial list of \"wrong coordinates\" for CT scans (either they seem on the right slice, but wrong location; or they are located on the wrong slice). There could be up to 11 such cases, but I need to do a final check before releasing.
The script scans every series folder, records the (Rows × Cols) of each DICOM header without loading pixel data, treats the most frequent matrix size as the series’ reference resolution, and logs any slice whose dimensions differ; the result is a CSV (dim_mismatch.csv) listing 38 out-of-spec instances out of 4,405 series, enabling us to review or drop only the problematic files before NIfTI conversion.
\nhttps://www.kaggle.com/code/antonsibilev/mismatch-resolution-v1
", "votes": 0, "replies": [] } ], "raw_markdown_by_id": { "3261643": "Hi everyone,\n\nWhile auditing the RSNA Intracranial Aneurysm Detection dataset I found a small set of DICOM slices whose in-plane Pixel Spacing differs from the dominant spacing of their series (usually scout/topogram frames saved in the same folder).\n\nNote: in many “enhanced” or multi-frame CT objects the true voxel spacing is stored *inside* the Pixel Measures Sequence (tag 0028,9110) of the Shared/Per-Frame Functional Groups, so a quick header read may miss it. After parsing those nested groups most series are clean—only the files listed below still break consistency.\n\nTo help others avoid silent resampling errors, I’m sharing the full list of filenames beneath this post. \nIf you spot anything I missed—or have a cleaner way to filter scouts—please let me know!\n\n\nimages like ...\n \n\n\n", "3265694": "Thanks for this valuable info. Unfortunately this reflects real world data, so measures like what you are proposing may be necessary. ", "3262596": "Your method seems to catch most of the instances (well done, this is useful), but there might be some that slip through the net. Try, for example, SeriesInstanceUID `1.2.826.0.1.3680043.8.498.17677548211553545296698864792051352427`, SOPInstanceUID `1.2.826.0.1.3680043.8.498.55677754734899892737758005594096916348`. \n\nWhat is even more disturbing with this example is that it should be the slice containing the aneurysm coordinates (see `train_localizers.csv`)! I am planning later today to release an initial list of \"wrong coordinates\" for CT scans (either they seem on the right slice, but wrong location; or they are located on the wrong slice). There could be up to 11 such cases, but I need to do a final check before releasing.", "3262557": "The script scans every series folder, records the (Rows × Cols) of each DICOM header without loading pixel data, treats the most frequent matrix size as the series’ reference resolution, and logs any slice whose dimensions differ; the result is a CSV (dim_mismatch.csv) listing 38 out-of-spec instances out of 4,405 series, enabling us to review or drop only the problematic files before NIfTI conversion.\n\nhttps://www.kaggle.com/code/antonsibilev/mismatch-resolution-v1" } }