\n
![\"\"](\"https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F113660%2Fc6cf5a384430989475a5ff0854eb2e6c%2FSelection_217.png?generation=1722251983892946&alt=media\")
\n
\n
https://www.kaggle.com/code/hengck23/2d-to-3d-projection-for-dicom
\nI suspect some of the dicom tags maybe wrong or \"not consisient\"?
\n(e.g. ImageOrientationPatient, ImageOrientationPatient, SpacingBetweenSlices,SliceThickness).
I followed the website \"https://blog.redbrickai.com/blog-posts/introduction-to-dicom-coordinate\" to make
\naffine transformation to convert between x,y,z(instance num) from label.csv to the world coordinate X,Y,Z.
first, i verify my code is correct. i.e. for the same view (e.g. axial t2) i can project 2d x,y,z to 3d X,Y,Z and backproject from 3d to 2d again.
now across different view. e.g. i project from 2d to 3d for axial t2 view, then i backproject X,Y,Z to the 2 sagittal t1/t2 views. they refer to different image points (by visualisation. x-oord is same, by y-oord is different)
i alread check the following
\nnote: error only occurs for few patient. most of then are correct.
example or error?
\n
did you face the same issues?
\nwhat goes wrong?
\n
\n
https://www.kaggle.com/code/hengck23/2d-to-3d-projection-for-dicom
\nI suspect some of the dicom tags maybe wrong or \"not consisient\"?
\n(e.g. ImageOrientationPatient, ImageOrientationPatient, SpacingBetweenSlices,SliceThickness).
I followed the website \"https://blog.redbrickai.com/blog-posts/introduction-to-dicom-coordinate\" to make
\naffine transformation to convert between x,y,z(instance num) from label.csv to the world coordinate X,Y,Z.
first, i verify my code is correct. i.e. for the same view (e.g. axial t2) i can project 2d x,y,z to 3d X,Y,Z and backproject from 3d to 2d again.
now across different view. e.g. i project from 2d to 3d for axial t2 view, then i backproject X,Y,Z to the 2 sagittal t1/t2 views. they refer to different image points (by visualisation. x-oord is same, by y-oord is different)
i alread check the following
\nnote: error only occurs for few patient. most of then are correct.
example or error?
\n
did you face the same issues?
\nwhat goes wrong?
how the axial slices look like!!!
\ni cluster the slices by ImageOrientationPatient
\neach color means one cluster
\nblack circles are ImagePositionPatient
note the overlap! so be careful if you sort by ImagePositionPatient only!
\n![\"\"](\"https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F113660%2Fa66f697521d6468c4050e02363b27695%2FSelection_229.png?generation=1722310713463185&alt=media\")
For those with combined spine level in one cluster:
\nit make more sense to:
more examples
\n![\"\"](\"https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F113660%2F904dcc09584c78b5975a62e2df5b3b17%2FSelection_245.png?generation=1722345235283130&alt=media\")
so it is called oblique slice (what you mean by angle). that was a nice one to verify.
", "rawMarkdown": "so it is called oblique slice (what you mean by angle). that was a nice one to verify.", "votes": 3 }, { "id": 2941521, "postDate": "2024-07-31T04:18:25.200Z", "content": "Regarding series like 1359869694 you have shown above, having some tolerance, say atol=1e-5 with np.allclose, while grouping ImageOrientationPatient will help in closing the gap. With this tolerance, the maximum number of groups I have seen is around 8.
thanks! you can also try culser by distance of IPP points using dbscan
", "rawMarkdown": "thanks! you can also try culser by distance of IPP points using dbscan", "votes": 1 }, { "id": 2943932, "postDate": "2024-08-02T02:43:45.940Z", "rawMarkdown": "", "isDeleted": true } ] }, { "id": 2946741, "postDate": "2024-08-04T16:09:03.283Z", "content": "Hi, These graphs looks interesting, is the code available to generate them??
", "rawMarkdown": "Hi, These graphs looks interesting, is the code available to generate them??" } ] }, { "id": 2949954, "postDate": "2024-08-07T05:12:58.170Z", "content": "after working for a week, my results …
\npublic notebook: https://www.kaggle.com/code/hengck23/ver-1-demo-workflow-2-stage-approach/edit
these are fully automatic!!!
\ntrain on 1100 selected study ids
\nvalidate on about 300
![\"\"](\"https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F113660%2F79b840bd965ec03ea42644459b43df89%2FSelection_277.png?generation=1723007421681360&alt=media\")
development time is longer than expected because of the inconsistency and errors in the dicom data.
\nyes there are errors !!! some label coordinate are not correct.
how it looks like if you just stacked up axial slices and take a cross section.
\n![\"\"](\"https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F113660%2F1b28fcbe5f6b4b84b4ef7b3baf772c0e%2FSelection_295.png?generation=1723140618843750&alt=media\")
normal, we can use open source dicom viewer to inspect the dicom dir. e.g.
\n![\"\"](\"https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F113660%2Fad9473e4c5bf3f0b1e9e30c678d3bfff%2FPeek%202024-07-30%2023-38.gif?generation=1722354025055897&alt=media\")
however, all my viewers failed for kaggle dataset.
\nI suspect kaggle dataset is not using standard dicom format?
anyone can recommend an opensource viewer for kaggle dataset that work like the above?
", "rawMarkdown": "normal, we can use open source dicom viewer to inspect the dicom dir. e.g.\n\n\nhowever, all my viewers failed for kaggle dataset. \nI suspect kaggle dataset is not using standard dicom format?\n\nanyone can recommend an opensource viewer for kaggle dataset that work like the above?", "votes": 4 }, { "id": 2940026, "postDate": "2024-07-29T17:49:39.793Z", "content": "I have tried this approach you mentioned in the notebook https://blog.redbrickai.com/blog-posts/introduction-to-dicom-coordinate.
\nThe problem with that, that it does not do better job for axials than simple IPP sorting suggested by ipan.
\nWhat you gotta look for is how all instances numbers matches with reversed or direct order of your sorting algorithm. The dot product (mentioned by you in redbrick blogpost) and slicenumber are the worse.
check my code.
\nyou have to split the axial slices into similar orientation IOP first, then apply the sorting using the normal vector to each cluster
if you did that, it automatically split into L1/l2, L2/L3 …. for some training study id.
\n![\"\"](\"https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F113660%2F2d05c61755c736a3e4421713d4d6038c%2FSelection_218.png?generation=1722291568629158&alt=media\")
![\"\"](\"https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F113660%2F1798f71170e93ba2e58f562b698389ee%2FSelection_219.png?generation=1722291586002689&alt=media\")
in other cases, axial slices are split into L1/LN, LN/LM (e.g. L1/L3 and L4/S1)
\nI think the axial slicing at done at an angle
\n![\"\"](\"https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F113660%2Fc8a260f87241422051533d971c5c1fcd%2FSelection_220.png?generation=1722291838991030&alt=media\")
google for:
\nmri lumbar spine planning/protocol/ positioning
also, the orientation IOP. contains information and can be used as input to neural net.
\nbut the data given include MRI + slices made by radiradiologist (which embed additional knowledge and prediction by the radiologist)
", "rawMarkdown": "check my code.\nyou have to split the axial slices into similar orientation IOP first, then apply the sorting using the normal vector to each cluster\n\nif you did that, it automatically split into L1/l2, L2/L3 .... for some training study id.\n\n\n\n\n\nin other cases, axial slices are split into L1/LN, LN/LM (e.g. L1/L3 and L4/S1)\n\nI think the axial slicing at done at an angle\n\n\n\ngoogle for:\nmri lumbar spine planning/protocol/ positioning\n\nalso, the orientation IOP. contains information and can be used as input to neural net.\n\n---\n\n#this is actually data leak! ideally, we want the AI model to look at the whole volume (from L1 to S5) and identify the disc level (and make the slicing) by itself.\n\nbut the data given include MRI + slices made by radiradiologist (which embed additional knowledge and prediction by the radiologist) ", "votes": 2, "replies": [ { "id": 2940450, "postDate": "2024-07-30T05:28:31.530Z", "content": "I want to add that if we do this grouping into similar orientation IOP, for some studies there would be a group above and below L1 to L5 (6 - 8 group cases).
\nAlso, in most of these 5 group cases, the last group (L5 to S1) would be large covering, say, the entire sacrum bone.
", "rawMarkdown": "I want to add that if we do this grouping into similar orientation IOP, for some studies there would be a group above and below L1 to L5 (6 - 8 group cases).\n\nAlso, in most of these 5 group cases, the last group (L5 to S1) would be large covering, say, the entire sacrum bone." }, { "id": 2940464, "postDate": "2024-07-30T05:42:08.087Z", "content": "it doesn't matter if the covering is large.
\nthe most important thing is that each group has only one level.
if that is so, then the solution would be like
\nhttps://www.kaggle.com/competitions/rsna-2022-cervical-spine-fracture-detection/discussion/362643
![\"https://github.com/darraghdog/RSNA22/blob/main/figs/study.gif\"](\"https://github.com/darraghdog/RSNA22/blob/main/figs/study.gif\")
also see the video:
\nhttps://www.youtube.com/watch?v=f-QA5MLN16Q
I had my own implementation for this stuff, and same observation as yours for this study id.
\nThe 2D -> 3D -> 2D projection results seem not to be correct visually: C5 is not aligned between two Sagittal view, and the disc level of left_foraminal_narrowing (LF) label and canal_stenosis (C) label seem to be not well aligned enough.
![\"\"](\"https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F10254700%2F243c9e2771e09d23914c7c59c6914ab6%2Fdownload.png?generation=1722260172259376&alt=media\")
![\"\"](\"https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F10254700%2F147d1fad0bfee7dbaf47e5a408aead50%2Fdownload2.png?generation=1722260184410191&alt=media\")
Description:
\nSagittal or Axial), but is 2D -> 3D -> 2D projected from different series_idLF -> left_foraminal_narrowing, C -> canal_stenosis1, 2, 3, 4, 5 -> L1_L2, L2_L3, L3_L4, L4_L5, L5_S1Maybe the reasons ?
\n3D->2Dprojection is not as expected.thanks for the confirmation.
\ninitially i am thinking of cross-view attention with common world coord as position embedding.
\nI need to see what is this inconsistency rate of the data and decide if i need to change my plan.
correct way to sort … (hint : please simplify this)
\n![\"\"](\"https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F113660%2F7bbef896379fceeda6f0b2318a038bba%2FSelection_248.png?generation=1722377079980919&alt=media\")
now you need college maths: equation of plane, normal distance of 3d point to plane.
\ni wonder if chatgpt is smart enough to give me the code
there is yet another shortcut. simply collect all the IPP (image patient position) points. join them up by connecting to the nearest neighbours.
\ninstead of using IPP, for each axial plane detect the center point of the lumbar spine. Use this point for connection.
", "rawMarkdown": "correct way to sort ... (hint : please simplify this)\n\n\nnow you need college maths: equation of plane, normal distance of 3d point to plane.\ni wonder if chatgpt is smart enough to give me the code \n\n---\n\nthere is yet another shortcut. simply collect all the IPP (image patient position) points. join them up by connecting to the nearest neighbours.\n\ninstead of using IPP, for each axial plane detect the center point of the lumbar spine. Use this point for connection.", "votes": 2, "replies": [ { "id": 2943790, "postDate": "2024-08-01T21:18:58.093Z", "content": "after detection points in sagittal, how to find nearest slice in axial
\n![\"\"](\"https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F113660%2F74b7053202a1e434c1a763000ce101fb%2FSelection_253.png?generation=1722547119948744&alt=media\")
\ncheck new code at:
\nhttps://www.kaggle.com/code/hengck23/place-holder-demo-workflow-2-stage-approach
@hengck23, your approach is ok, and you are also right I think, because when I used my approach the whole images where grouped into l4/l5 and l5/s1 but didn't classify into the rest.
\nAccuracy of approach (99%)
", "rawMarkdown": "@hengck23, your approach is ok, and you are also right I think, because when I used my approach the whole images where grouped into l4/l5 and l5/s1 but didn't classify into the rest.\n\nAccuracy of approach (99%)" }, { "id": 2939670, "postDate": "2024-07-29T12:10:49.203Z", "content": "According to https://www.kaggle.com/code/abhinavsuri/anatomy-image-visualization-overview-rsna-raids when diagnosed the professionals look principally different parts on different MRI:
\nSagittal T1: \"The spinal cord has spinal nerves that exit the spinal canal through openings called foramina.\"
\nAxial T2: \"…the spinal cord in the subarticular zone (this compression can be best visualized in the axial plane).
\nSagittal T2: \"Canal stenosis is impingement on the spinal canal (where the spinal cord travels).\"
\nThey're close and related but don't espect a perfect match between MRI and diagnoses.
\nEDIT: And I've seen Axial to Sagittal correspondence repressentations before, why we espect a perfect fit between volumes? May be Axial starts and ends before or after the correspondig Sagittal slices. I mean, each MRI stacked refers to the same volume (chest), but why perfectly fitted?
", "rawMarkdown": "According to https://www.kaggle.com/code/abhinavsuri/anatomy-image-visualization-overview-rsna-raids when diagnosed the professionals look principally different parts on different MRI:\n\nSagittal T1: \"The spinal cord has spinal nerves that exit the spinal canal through openings called foramina.\"\n\nAxial T2: \"...the spinal cord in the subarticular zone (this compression can be best visualized in the axial plane).\n\nSagittal T2: \"Canal stenosis is impingement on the spinal canal (where the spinal cord travels).\"\n\nThey're close and related but don't espect a perfect match between MRI and diagnoses.\n\nEDIT: And I've seen Axial to Sagittal correspondence repressentations before, why we espect a perfect fit between volumes? May be Axial starts and ends before or after the correspondig Sagittal slices. I mean, each MRI stacked refers to the same volume (chest), but why perfectly fitted?", "replies": [ { "id": 2939704, "postDate": "2024-07-29T12:35:12.893Z", "content": "no. the label csv tells the point location (e.g. L4/L5). so we know where the point should be in other view.
\nthe only explanation I can offer is that if the dicom tags are correct, the patient may have shifted, the world origin has shifted or the MRIs are taken on different days.
", "rawMarkdown": "no. the label csv tells the point location (e.g. L4/L5). so we know where the point should be in other view.\n\nthe only explanation I can offer is that if the dicom tags are correct, the patient may have shifted, the world origin has shifted or the MRIs are taken on different days.", "votes": 1, "replies": [ { "id": 2939720, "postDate": "2024-07-29T12:57:57.240Z", "content": "So just to understand. Axial point location says L4/L5. You marked L4/L5 in Sagittal T1. And then why L3/L4 in Sagittal T2? Is that the anotation on coor_df for Sagittal T2 L4/L5?
", "rawMarkdown": "So just to understand. Axial point location says L4/L5. You marked L4/L5 in Sagittal T1. And then why L3/L4 in Sagittal T2? Is that the anotation on coor_df for Sagittal T2 L4/L5?" }, { "id": 2939759, "postDate": "2024-07-29T13:35:26.970Z", "content": "not i mark. these are computed from their dicom tag. that is why i suspect sagittal t2 dicom tag could be wrong
", "rawMarkdown": "not i mark. these are computed from their dicom tag. that is why i suspect sagittal t2 dicom tag could be wrong", "votes": 4 }, { "id": 2939766, "postDate": "2024-07-29T13:41:23.063Z", "content": "Oh. The metadata in them. I see. Thanks.
", "rawMarkdown": "Oh. The metadata in them. I see. Thanks.", "votes": 1 } ] } ] }, { "id": 2940095, "postDate": "2024-07-29T18:45:07.977Z", "rawMarkdown": "", "isDeleted": true } ], "comments": [ { "id": 2940378, "author_name": "hengck23", "author_url": "", "post_date": "2024-07-30T03:24:06.650000", "content": "how the axial slices look like!!!
\ni cluster the slices by ImageOrientationPatient
\neach color means one cluster
\nblack circles are ImagePositionPatient
note the overlap! so be careful if you sort by ImagePositionPatient only!
\n
For those with combined spine level in one cluster:
\nit make more sense to:
more examples
\n
so it is called oblique slice (what you mean by angle). that was a nice one to verify.
", "votes": 3, "replies": [] }, { "id": 2941521, "author_name": "coderRKJ", "author_url": "", "post_date": "2024-07-31T04:18:25.200000", "content": "Regarding series like 1359869694 you have shown above, having some tolerance, say atol=1e-5 with np.allclose, while grouping ImageOrientationPatient will help in closing the gap. With this tolerance, the maximum number of groups I have seen is around 8.
thanks! you can also try culser by distance of IPP points using dbscan
", "votes": 1, "replies": [] }, { "id": 2943932, "author_name": "", "author_url": "", "post_date": "2024-08-02T02:43:45.940000", "content": "", "votes": 0, "replies": [] } ] }, { "id": 2946741, "author_name": "Gowri Shankar Penugonda", "author_url": "", "post_date": "2024-08-04T16:09:03.283000", "content": "Hi, These graphs looks interesting, is the code available to generate them??
", "votes": 0, "replies": [] } ] }, { "id": 2949954, "author_name": "hengck23", "author_url": "", "post_date": "2024-08-07T05:12:58.170000", "content": "after working for a week, my results …
\npublic notebook: https://www.kaggle.com/code/hengck23/ver-1-demo-workflow-2-stage-approach/edit
these are fully automatic!!!
\ntrain on 1100 selected study ids
\nvalidate on about 300
development time is longer than expected because of the inconsistency and errors in the dicom data.
\nyes there are errors !!! some label coordinate are not correct.
how it looks like if you just stacked up axial slices and take a cross section.
\n
normal, we can use open source dicom viewer to inspect the dicom dir. e.g.
\n
however, all my viewers failed for kaggle dataset.
\nI suspect kaggle dataset is not using standard dicom format?
anyone can recommend an opensource viewer for kaggle dataset that work like the above?
", "votes": 4, "replies": [] }, { "id": 2940026, "author_name": "SSS", "author_url": "", "post_date": "2024-07-29T17:49:39.793000", "content": "I have tried this approach you mentioned in the notebook https://blog.redbrickai.com/blog-posts/introduction-to-dicom-coordinate.
\nThe problem with that, that it does not do better job for axials than simple IPP sorting suggested by ipan.
\nWhat you gotta look for is how all instances numbers matches with reversed or direct order of your sorting algorithm. The dot product (mentioned by you in redbrick blogpost) and slicenumber are the worse.
check my code.
\nyou have to split the axial slices into similar orientation IOP first, then apply the sorting using the normal vector to each cluster
if you did that, it automatically split into L1/l2, L2/L3 …. for some training study id.
\n
in other cases, axial slices are split into L1/LN, LN/LM (e.g. L1/L3 and L4/S1)
\nI think the axial slicing at done at an angle
\n
google for:
\nmri lumbar spine planning/protocol/ positioning
also, the orientation IOP. contains information and can be used as input to neural net.
\nbut the data given include MRI + slices made by radiradiologist (which embed additional knowledge and prediction by the radiologist)
", "votes": 2, "replies": [ { "id": 2940450, "author_name": "coderRKJ", "author_url": "", "post_date": "2024-07-30T05:28:31.530000", "content": "I want to add that if we do this grouping into similar orientation IOP, for some studies there would be a group above and below L1 to L5 (6 - 8 group cases).
\nAlso, in most of these 5 group cases, the last group (L5 to S1) would be large covering, say, the entire sacrum bone.
", "votes": 0, "replies": [] }, { "id": 2940464, "author_name": "hengck23", "author_url": "", "post_date": "2024-07-30T05:42:08.087000", "content": "it doesn't matter if the covering is large.
\nthe most important thing is that each group has only one level.
if that is so, then the solution would be like
\nhttps://www.kaggle.com/competitions/rsna-2022-cervical-spine-fracture-detection/discussion/362643
also see the video:
\nhttps://www.youtube.com/watch?v=f-QA5MLN16Q
I had my own implementation for this stuff, and same observation as yours for this study id.
\nThe 2D -> 3D -> 2D projection results seem not to be correct visually: C5 is not aligned between two Sagittal view, and the disc level of left_foraminal_narrowing (LF) label and canal_stenosis (C) label seem to be not well aligned enough.
Description:
\nSagittal or Axial), but is 2D -> 3D -> 2D projected from different series_idLF -> left_foraminal_narrowing, C -> canal_stenosis1, 2, 3, 4, 5 -> L1_L2, L2_L3, L3_L4, L4_L5, L5_S1Maybe the reasons ?
\n3D->2Dprojection is not as expected.thanks for the confirmation.
\ninitially i am thinking of cross-view attention with common world coord as position embedding.
\nI need to see what is this inconsistency rate of the data and decide if i need to change my plan.
correct way to sort … (hint : please simplify this)
\n
now you need college maths: equation of plane, normal distance of 3d point to plane.
\ni wonder if chatgpt is smart enough to give me the code
there is yet another shortcut. simply collect all the IPP (image patient position) points. join them up by connecting to the nearest neighbours.
\ninstead of using IPP, for each axial plane detect the center point of the lumbar spine. Use this point for connection.
", "votes": 2, "replies": [ { "id": 2943790, "author_name": "hengck23", "author_url": "", "post_date": "2024-08-01T21:18:58.093000", "content": "after detection points in sagittal, how to find nearest slice in axial
\n
\ncheck new code at:
\nhttps://www.kaggle.com/code/hengck23/place-holder-demo-workflow-2-stage-approach
@hengck23, your approach is ok, and you are also right I think, because when I used my approach the whole images where grouped into l4/l5 and l5/s1 but didn't classify into the rest.
\nAccuracy of approach (99%)
", "votes": 0, "replies": [] }, { "id": 2939670, "author_name": "Ángel Jacinto Sánchez Ruiz", "author_url": "", "post_date": "2024-07-29T12:10:49.203000", "content": "According to https://www.kaggle.com/code/abhinavsuri/anatomy-image-visualization-overview-rsna-raids when diagnosed the professionals look principally different parts on different MRI:
\nSagittal T1: \"The spinal cord has spinal nerves that exit the spinal canal through openings called foramina.\"
\nAxial T2: \"…the spinal cord in the subarticular zone (this compression can be best visualized in the axial plane).
\nSagittal T2: \"Canal stenosis is impingement on the spinal canal (where the spinal cord travels).\"
\nThey're close and related but don't espect a perfect match between MRI and diagnoses.
\nEDIT: And I've seen Axial to Sagittal correspondence repressentations before, why we espect a perfect fit between volumes? May be Axial starts and ends before or after the correspondig Sagittal slices. I mean, each MRI stacked refers to the same volume (chest), but why perfectly fitted?
", "votes": 0, "replies": [ { "id": 2939704, "author_name": "hengck23", "author_url": "", "post_date": "2024-07-29T12:35:12.893000", "content": "no. the label csv tells the point location (e.g. L4/L5). so we know where the point should be in other view.
\nthe only explanation I can offer is that if the dicom tags are correct, the patient may have shifted, the world origin has shifted or the MRIs are taken on different days.
", "votes": 1, "replies": [ { "id": 2939720, "author_name": "Ángel Jacinto Sánchez Ruiz", "author_url": "", "post_date": "2024-07-29T12:57:57.240000", "content": "So just to understand. Axial point location says L4/L5. You marked L4/L5 in Sagittal T1. And then why L3/L4 in Sagittal T2? Is that the anotation on coor_df for Sagittal T2 L4/L5?
", "votes": 0, "replies": [] }, { "id": 2939759, "author_name": "hengck23", "author_url": "", "post_date": "2024-07-29T13:35:26.970000", "content": "not i mark. these are computed from their dicom tag. that is why i suspect sagittal t2 dicom tag could be wrong
", "votes": 4, "replies": [] }, { "id": 2939766, "author_name": "Ángel Jacinto Sánchez Ruiz", "author_url": "", "post_date": "2024-07-29T13:41:23.063000", "content": "Oh. The metadata in them. I see. Thanks.
", "votes": 1, "replies": [] } ] } ] }, { "id": 2940095, "author_name": "", "author_url": "", "post_date": "2024-07-29T18:45:07.977000", "content": "", "votes": 0, "replies": [] } ], "raw_markdown_by_id": { "2939628": "~~i am prepaing a notebook and example data to illustrate my observation.~~\n~~please wait for a wait.~~\n~~but i want to make a post first.~~\n\n#notebook link:\nhttps://www.kaggle.com/code/hengck23/2d-to-3d-projection-for-dicom\n\n\n---\n\nI suspect some of the dicom tags maybe wrong or \"not consisient\"?\n(e.g. ImageOrientationPatient, ImageOrientationPatient, SpacingBetweenSlices,SliceThickness).\n\nI followed the website \"https://blog.redbrickai.com/blog-posts/introduction-to-dicom-coordinate\" to make\naffine transformation to convert between x,y,z(instance num) from label.csv to the world coordinate X,Y,Z.\n\n- first, i verify my code is correct. i.e. for the same view (e.g. axial t2) i can project 2d x,y,z to 3d X,Y,Z and backproject from 3d to 2d again.\n\n- now across different view. e.g. i project from 2d to 3d for axial t2 view, then i backproject X,Y,Z to the 2 sagittal t1/t2 views. they refer to different image points (by visualisation. x-oord is same, by y-oord is different)\n\n- i alread check the following\n - 0-indexing for array, 1-indexing for instance num\n - out-of-bound check. axial and sagittal volume only partially overap each other.\n\n- note: error only occurs for few patient. most of then are correct.\n\nexample or error?\n\n\n---\n\ndid you face the same issues?\nwhat goes wrong?", "2940378": "how the axial slices look like!!!\n\ni cluster the slices by ImageOrientationPatient\neach color means one cluster \nblack circles are ImagePositionPatient\n\nnote the overlap! so be careful if you sort by ImagePositionPatient only!\n\n\n\n----\n\nFor those with combined spine level in one cluster:\nit make more sense to:\n\n1. train a model on input = sagittal \n2. pooling by axial slice (e.g. sum by slanted line or other fancy method)\n3. predict = classifier(pool), 5 class of L1/L2, L2/L3 ... L5/S1.", "2949954": "after working for a week, my results ... \npublic notebook: https://www.kaggle.com/code/hengck23/ver-1-demo-workflow-2-stage-approach/edit\n\n---\n\nthese are fully automatic!!! \ntrain on 1100 selected study ids \nvalidate on about 300 \n\n\n\ndevelopment time is longer than expected because of the inconsistency and errors in the dicom data.\nyes there are errors !!! some label coordinate are not correct.", "2941025": "normal, we can use open source dicom viewer to inspect the dicom dir. e.g.\n\n\nhowever, all my viewers failed for kaggle dataset. \nI suspect kaggle dataset is not using standard dicom format?\n\nanyone can recommend an opensource viewer for kaggle dataset that work like the above?", "2940026": "I have tried this approach you mentioned in the notebook https://blog.redbrickai.com/blog-posts/introduction-to-dicom-coordinate.\nThe problem with that, that it does not do better job for axials than simple IPP sorting suggested by ipan. \nWhat you gotta look for is how all instances numbers matches with reversed or direct order of your sorting algorithm. The dot product (mentioned by you in redbrick blogpost) and slicenumber are the worse. ", "2939768": "I had my own implementation for this stuff, and same observation as yours for this study id.\nThe 2D -> 3D -> 2D projection results seem not to be correct visually: C5 is not aligned between two Sagittal view, and the disc level of `left_foraminal_narrowing (LF)` label and `canal_stenosis (C)` label seem to be not well aligned enough.\n\n\n\n\n\n\n**Description**:\n- Green: Image (Instance) coordinate label\n- Yellow: Coordinate label from same view (either `Sagittal` or `Axial`), but is `2D -> 3D -> 2D` projected from different `series_id`\n- `LF` -> `left_foraminal_narrowing`, `C` -> `canal_stenosis`\n- Level: `1`, `2`, `3`, `4`, `5` -> `L1_L2`, `L2_L3`, `L3_L4`, `L4_L5`, `L5_S1`\n\n**Maybe the reasons ?**\n- Non-negligible differences in image acquisition time, so the Reference Coordinate System (RCS) is no longer shared between views\n- Patient moving while scanning ?\n- The RCS is not ideal. If patient is not well positioned (as standard) on the machine, or scanning is not well planned, may be X/Y/Z direction is skewed so the last `3D->2D`projection is not as expected.\n", "2941385": "correct way to sort ... (hint : please simplify this)\n\n\nnow you need college maths: equation of plane, normal distance of 3d point to plane.\ni wonder if chatgpt is smart enough to give me the code \n\n---\n\nthere is yet another shortcut. simply collect all the IPP (image patient position) points. join them up by connecting to the nearest neighbours.\n\ninstead of using IPP, for each axial plane detect the center point of the lumbar spine. Use this point for connection.", "2957833": "@hengck23, your approach is ok, and you are also right I think, because when I used my approach the whole images where grouped into l4/l5 and l5/s1 but didn't classify into the rest.\n\nAccuracy of approach (99%)", "2939670": "According to https://www.kaggle.com/code/abhinavsuri/anatomy-image-visualization-overview-rsna-raids when diagnosed the professionals look principally different parts on different MRI:\n\nSagittal T1: \"The spinal cord has spinal nerves that exit the spinal canal through openings called foramina.\"\n\nAxial T2: \"...the spinal cord in the subarticular zone (this compression can be best visualized in the axial plane).\n\nSagittal T2: \"Canal stenosis is impingement on the spinal canal (where the spinal cord travels).\"\n\nThey're close and related but don't espect a perfect match between MRI and diagnoses.\n\nEDIT: And I've seen Axial to Sagittal correspondence repressentations before, why we espect a perfect fit between volumes? May be Axial starts and ends before or after the correspondig Sagittal slices. I mean, each MRI stacked refers to the same volume (chest), but why perfectly fitted?", "2940095": "" } }