for example, case 429, the volume I got is almost as twice as large the truth value from train.csv.. it takes the largest volume at t~29 and smallest at t~12, I almost have hand labeled the boundaries and measured the volume and what I got is almost twice as large... there are some other similar cases too, any one has an idea why it is so much off? ( I use the sliceLocation variable and maybe in some cases it is wrong?)
", "messages": [ { "id": "104479", "postDate": "01/13/2016 04:57:07", "content": "for example, case 429, the volume I got is almost as twice as large the truth value from train.csv.. it takes the largest volume at t~29 and smallest at t~12, I almost have hand labeled the boundaries and measured the volume and what I got is almost twice as large... there are some other similar cases too, any one has an idea why it is so much off? ( I use the sliceLocation variable and maybe in some cases it is wrong?)
", "rawMarkdown": "for example, case 429, the volume I got is almost as twice as large the truth value from train.csv.. it takes the largest volume at t~29 and smallest at t~12, I almost have hand labeled the boundaries and measured the volume and what I got is almost twice as large... there are some other similar cases too, any one has an idea why it is so much off? ( I use the sliceLocation variable and maybe in some cases it is wrong?)", "votes": null }, { "id": "104511", "postDate": "01/13/2016 13:41:39", "content": "Only have time for a quick comment here. If your measured volumes are much to big, my guess would be that you are including repeated slices multiple times. Slices are often repeated due to breathing motion or other image quality problems. If basal slices repeated, even one repeated slice can cause quite a big error.
", "rawMarkdown": "Only have time for a quick comment here. If your measured volumes are much to big, my guess would be that you are including repeated slices multiple times. Slices are often repeated due to breathing motion or other image quality problems. If basal slices repeated, even one repeated slice can cause quite a big error.", "votes": null }, { "id": "104513", "postDate": "01/13/2016 13:50:41", "content": "No I didn't, my code removes repeated slices, and are sorted by position (so even if it is not remove it is still fine since the thickness between two repeated layer is 0.0)
\n\n[quote=Michael Hansen;104511]
\n\nOnly have time for a quick comment here. If your measured volumes are much to big, my guess would be that you are including repeated slices multiple times. Slices are often repeated due to breathing motion or other image quality problems. If basal slices repeated, even one repeated slice can cause quite a big error.
\n\n[/quote]
", "rawMarkdown": "No I didn't, my code removes repeated slices, and are sorted by position (so even if it is not remove it is still fine since the thickness between two repeated layer is 0.0)\r\n\r\n[quote=Michael Hansen;104511]\r\n\r\nOnly have time for a quick comment here. If your measured volumes are much to big, my guess would be that you are including repeated slices multiple times. Slices are often repeated due to breathing motion or other image quality problems. If basal slices repeated, even one repeated slice can cause quite a big error. \r\n\r\n[/quote]", "votes": null }, { "id": "104515", "postDate": "01/13/2016 13:54:31", "content": "I can't tell you exactly what is going on in your case without looking into it in a lot more detail. I just don't have the time right now to go into a specific case, but from reading on the forum:
\n\n\n\nIt looks like people are getting close to the same numbers. That being said there could be cases that are off due to human error (but a factor of two would be unlikely).
", "rawMarkdown": "I can't tell you exactly what is going on in your case without looking into it in a lot more detail. I just don't have the time right now to go into a specific case, but from reading on the forum:\r\n\r\nhttps://www.kaggle.com/c/second-annual-data-science-bowl/forums/t/18352/clinical-significance/104359#post104359\r\n\r\nIt looks like people are getting close to the same numbers. That being said there could be cases that are off due to human error (but a factor of two would be unlikely).", "votes": null }, { "id": "104516", "postDate": "01/13/2016 14:04:59", "content": "Did you take pixel spacing into account? (case 429 is 0.6195652 x 0.6195652, unlike in most cases 1.406250 x 1.406250).
", "rawMarkdown": "Did you take pixel spacing into account? (case 429 is 0.6195652 x 0.6195652, unlike in most cases 1.406250 x 1.406250).", "votes": null }, { "id": "104519", "postDate": "01/13/2016 14:36:12", "content": "Yes I did. (or else it will be a factor of 5 off larger:)
\n\n[quote=Herra Huu;104516]
\n\nDid you take pixel spacing into account? (case 429 is 0.6195652 x 0.6195652, unlike in most cases 1.406250 x 1.406250).
\n\n[/quote]
", "rawMarkdown": "Yes I did. (or else it will be a factor of 5 off larger:)\r\n\r\n[quote=Herra Huu;104516]\r\n\r\nDid you take pixel spacing into account? (case 429 is 0.6195652 x 0.6195652, unlike in most cases 1.406250 x 1.406250). \r\n\r\n[/quote]", "votes": null }, { "id": "104553", "postDate": "01/13/2016 19:32:33", "content": "@woshialex, I just checked SliceLocation for case 429 in two ways. The values of SliceLocation for this case differ by 10, which agrees with the value of SpacingBetweenSlices (also 10). In addition, the values of slice location agree with slice locations calculated using ImageOrietationPatient and ImagePositionPatient. So while I have no idea why the values you're finding don't agree with the supplied values, I don't think it's related to SliceLocation. At least not for case 429.
", "rawMarkdown": "woshialex, I just checked SliceLocation for case 429 in two ways. The values of SliceLocation for this case differ by 10, which agrees with the value of SpacingBetweenSlices (also 10). In addition, the values of slice location agree with slice locations calculated using ImageOrietationPatient and ImagePositionPatient. So while I have no idea why the values you're finding don't agree with the supplied values, I don't think it's related to SliceLocation. At least not for case 429.", "votes": null }, { "id": "104561", "postDate": "01/13/2016 21:12:08", "content": "woshialex, probably you should also check the size of the source image.
", "rawMarkdown": "woshialex, probably you should also check the size of the source image.", "votes": null }, { "id": "104566", "postDate": "01/13/2016 22:33:05", "content": "sounds like something I don't know, :) what exactly do you mean? I counted the number of pixels in the area I draw, then times the pixel_space_x * pixel_space_y to get the area, then times the slice distances to get the volume, what should I check with respect to the size of the source image?? Thanks
\n\n[quote=Mike;104561]
\n\nwoshialex, probably you should also check the size of the source image.
\n\n[/quote]
", "rawMarkdown": "sounds like something I don't know, :) what exactly do you mean? I counted the number of pixels in the area I draw, then times the pixel_space_x * pixel_space_y to get the area, then times the slice distances to get the volume, what should I check with respect to the size of the source image?? Thanks\r\n\r\n\r\n[quote=Mike;104561]\r\n\r\nwoshialex, probably you should also check the size of the source image.\r\n\r\n[/quote]", "votes": null }, { "id": "104568", "postDate": "01/13/2016 22:52:29", "content": "For what it's worth, I quickly did a rough manual segmentation with an ellipse-drawing tool.\n\nFor the ED (phase 29), I get the following areas for the 11 slices (in pixels):\n\n1 0 (ie, this slice seems to be past the base of the heart, so I don't count it)\n2 5900\n3 7400\n4 9400\n5 9900\n6 9900\n7 9100\n8 6100\n9 3700\n10 2000\n11 600\n\nThe total is 64,000. Multiplied by the slice gap of 10mm and the pixel area\nof 0.6196 squared, I get 246 ml, which is about 35% larger than the expert value of 182.\nI meant that case 429 images are 552x736 while most of others are 192x256 and if you resize images to a some fixed size you should take into account difference in the source sizes.
", "rawMarkdown": "I meant that case 429 images are 552x736 while most of others are 192x256 and if you resize images to a some fixed size you should take into account difference in the source sizes.", "votes": null }, { "id": "104685", "postDate": "01/15/2016 09:07:04", "content": "Are you guys automatically segmenting the data? If so, how? I thought successive frame difference at same slice location would give a proper indication of area, but it has some noise also.
", "rawMarkdown": "Are you guys automatically segmenting the data? If so, how? I thought successive frame difference at same slice location would give a proper indication of area, but it has some noise also.", "votes": null }, { "id": "104698", "postDate": "01/15/2016 14:59:48", "content": "Without knowing what I am saying..\nWhat does the Slice Thickness variable mean ?\nThat one is 8 instead of 10.
\n\n0.8 * 246 = 196 which is ~almost~ 182
", "rawMarkdown": "Without knowing what I am saying..\r\nWhat does the Slice Thickness variable mean ?\r\nThat one is 8 instead of 10.\r\n\r\n0.8 * 246 = 196 which is ~almost~ 182", "votes": null }, { "id": "104711", "postDate": "01/15/2016 17:28:26", "content": "That's interesting. I believe the Slice Thickness value is sometimes used as the spacing between slices, even when it shouldn't be. So that might indeed explain the discrepancy.
", "rawMarkdown": "That's interesting. I believe the Slice Thickness value is sometimes used as the spacing between slices, even when it shouldn't be. So that might indeed explain the discrepancy.", "votes": null }, { "id": "104752", "postDate": "01/16/2016 09:30:11", "content": "@PaulG This is very large error considering what the leaderboard runner can do automatically.
", "rawMarkdown": "PaulG This is very large error considering what the leaderboard runner can do automatically.", "votes": null } ], "comments": [ { "id": 104511, "author_name": "michaelhansen", "author_url": "", "post_date": "01/13/2016 13:41:39", "content": "Only have time for a quick comment here. If your measured volumes are much to big, my guess would be that you are including repeated slices multiple times. Slices are often repeated due to breathing motion or other image quality problems. If basal slices repeated, even one repeated slice can cause quite a big error.
", "votes": null, "replies": [] }, { "id": 104513, "author_name": "woshialex", "author_url": "", "post_date": "01/13/2016 13:50:41", "content": "No I didn't, my code removes repeated slices, and are sorted by position (so even if it is not remove it is still fine since the thickness between two repeated layer is 0.0)
\n\n[quote=Michael Hansen;104511]
\n\nOnly have time for a quick comment here. If your measured volumes are much to big, my guess would be that you are including repeated slices multiple times. Slices are often repeated due to breathing motion or other image quality problems. If basal slices repeated, even one repeated slice can cause quite a big error.
\n\n[/quote]
", "votes": null, "replies": [] }, { "id": 104515, "author_name": "michaelhansen", "author_url": "", "post_date": "01/13/2016 13:54:31", "content": "I can't tell you exactly what is going on in your case without looking into it in a lot more detail. I just don't have the time right now to go into a specific case, but from reading on the forum:
\n\n\n\nIt looks like people are getting close to the same numbers. That being said there could be cases that are off due to human error (but a factor of two would be unlikely).
", "votes": null, "replies": [] }, { "id": 104516, "author_name": "herrahuu", "author_url": "", "post_date": "01/13/2016 14:04:59", "content": "Did you take pixel spacing into account? (case 429 is 0.6195652 x 0.6195652, unlike in most cases 1.406250 x 1.406250).
", "votes": null, "replies": [] }, { "id": 104519, "author_name": "woshialex", "author_url": "", "post_date": "01/13/2016 14:36:12", "content": "Yes I did. (or else it will be a factor of 5 off larger:)
\n\n[quote=Herra Huu;104516]
\n\nDid you take pixel spacing into account? (case 429 is 0.6195652 x 0.6195652, unlike in most cases 1.406250 x 1.406250).
\n\n[/quote]
", "votes": null, "replies": [] }, { "id": 104553, "author_name": "bitsofbits", "author_url": "", "post_date": "01/13/2016 19:32:33", "content": "@woshialex, I just checked SliceLocation for case 429 in two ways. The values of SliceLocation for this case differ by 10, which agrees with the value of SpacingBetweenSlices (also 10). In addition, the values of slice location agree with slice locations calculated using ImageOrietationPatient and ImagePositionPatient. So while I have no idea why the values you're finding don't agree with the supplied values, I don't think it's related to SliceLocation. At least not for case 429.
", "votes": null, "replies": [] }, { "id": 104561, "author_name": "zerrxy", "author_url": "", "post_date": "01/13/2016 21:12:08", "content": "woshialex, probably you should also check the size of the source image.
", "votes": null, "replies": [] }, { "id": 104566, "author_name": "woshialex", "author_url": "", "post_date": "01/13/2016 22:33:05", "content": "sounds like something I don't know, :) what exactly do you mean? I counted the number of pixels in the area I draw, then times the pixel_space_x * pixel_space_y to get the area, then times the slice distances to get the volume, what should I check with respect to the size of the source image?? Thanks
\n\n[quote=Mike;104561]
\n\nwoshialex, probably you should also check the size of the source image.
\n\n[/quote]
", "votes": null, "replies": [] }, { "id": 104568, "author_name": "pgeiger", "author_url": "", "post_date": "01/13/2016 22:52:29", "content": "For what it's worth, I quickly did a rough manual segmentation with an ellipse-drawing tool.\n\nFor the ED (phase 29), I get the following areas for the 11 slices (in pixels):\n\n1 0 (ie, this slice seems to be past the base of the heart, so I don't count it)\n2 5900\n3 7400\n4 9400\n5 9900\n6 9900\n7 9100\n8 6100\n9 3700\n10 2000\n11 600\n\nThe total is 64,000. Multiplied by the slice gap of 10mm and the pixel area\nof 0.6196 squared, I get 246 ml, which is about 35% larger than the expert value of 182.\nI meant that case 429 images are 552x736 while most of others are 192x256 and if you resize images to a some fixed size you should take into account difference in the source sizes.
", "votes": null, "replies": [] }, { "id": 104685, "author_name": "udayabhanu", "author_url": "", "post_date": "01/15/2016 09:07:04", "content": "Are you guys automatically segmenting the data? If so, how? I thought successive frame difference at same slice location would give a proper indication of area, but it has some noise also.
", "votes": null, "replies": [] }, { "id": 104698, "author_name": "juliandewit", "author_url": "", "post_date": "01/15/2016 14:59:48", "content": "Without knowing what I am saying..\nWhat does the Slice Thickness variable mean ?\nThat one is 8 instead of 10.
\n\n0.8 * 246 = 196 which is ~almost~ 182
", "votes": null, "replies": [] }, { "id": 104711, "author_name": "pgeiger", "author_url": "", "post_date": "01/15/2016 17:28:26", "content": "That's interesting. I believe the Slice Thickness value is sometimes used as the spacing between slices, even when it shouldn't be. So that might indeed explain the discrepancy.
", "votes": null, "replies": [] }, { "id": 104752, "author_name": "amazingbob", "author_url": "", "post_date": "01/16/2016 09:30:11", "content": "@PaulG This is very large error considering what the leaderboard runner can do automatically.
", "votes": null, "replies": [] } ], "raw_markdown_by_id": { "104479": "for example, case 429, the volume I got is almost as twice as large the truth value from train.csv.. it takes the largest volume at t~29 and smallest at t~12, I almost have hand labeled the boundaries and measured the volume and what I got is almost twice as large... there are some other similar cases too, any one has an idea why it is so much off? ( I use the sliceLocation variable and maybe in some cases it is wrong?)", "104511": "Only have time for a quick comment here. If your measured volumes are much to big, my guess would be that you are including repeated slices multiple times. Slices are often repeated due to breathing motion or other image quality problems. If basal slices repeated, even one repeated slice can cause quite a big error.", "104513": "No I didn't, my code removes repeated slices, and are sorted by position (so even if it is not remove it is still fine since the thickness between two repeated layer is 0.0)\r\n\r\n[quote=Michael Hansen;104511]\r\n\r\nOnly have time for a quick comment here. If your measured volumes are much to big, my guess would be that you are including repeated slices multiple times. Slices are often repeated due to breathing motion or other image quality problems. If basal slices repeated, even one repeated slice can cause quite a big error. \r\n\r\n[/quote]", "104515": "I can't tell you exactly what is going on in your case without looking into it in a lot more detail. I just don't have the time right now to go into a specific case, but from reading on the forum:\r\n\r\nhttps://www.kaggle.com/c/second-annual-data-science-bowl/forums/t/18352/clinical-significance/104359#post104359\r\n\r\nIt looks like people are getting close to the same numbers. That being said there could be cases that are off due to human error (but a factor of two would be unlikely).", "104516": "Did you take pixel spacing into account? (case 429 is 0.6195652 x 0.6195652, unlike in most cases 1.406250 x 1.406250).", "104519": "Yes I did. (or else it will be a factor of 5 off larger:)\r\n\r\n[quote=Herra Huu;104516]\r\n\r\nDid you take pixel spacing into account? (case 429 is 0.6195652 x 0.6195652, unlike in most cases 1.406250 x 1.406250). \r\n\r\n[/quote]", "104553": "woshialex, I just checked SliceLocation for case 429 in two ways. The values of SliceLocation for this case differ by 10, which agrees with the value of SpacingBetweenSlices (also 10). In addition, the values of slice location agree with slice locations calculated using ImageOrietationPatient and ImagePositionPatient. So while I have no idea why the values you're finding don't agree with the supplied values, I don't think it's related to SliceLocation. At least not for case 429.", "104561": "woshialex, probably you should also check the size of the source image.", "104566": "sounds like something I don't know, :) what exactly do you mean? I counted the number of pixels in the area I draw, then times the pixel_space_x * pixel_space_y to get the area, then times the slice distances to get the volume, what should I check with respect to the size of the source image?? Thanks\r\n\r\n\r\n[quote=Mike;104561]\r\n\r\nwoshialex, probably you should also check the size of the source image.\r\n\r\n[/quote]", "104568": "For what it's worth, I quickly did a rough manual segmentation with an ellipse-drawing tool.\r\n \r\n For the ED (phase 29), I get the following areas for the 11 slices (in pixels):\r\n \r\n 1 0 (ie, this slice seems to be past the base of the heart, so I don't count it)\r\n 2 5900\r\n 3 7400\r\n 4 9400\r\n 5 9900\r\n 6 9900\r\n 7 9100\r\n 8 6100\r\n 9 3700\r\n 10 2000\r\n 11 600\r\n \r\n The total is 64,000. Multiplied by the slice gap of 10mm and the pixel area\r\n of 0.6196 squared, I get 246 ml, which is about 35% larger than the expert value of 182.", "104573": "I meant that case 429 images are 552x736 while most of others are 192x256 and if you resize images to a some fixed size you should take into account difference in the source sizes.", "104685": "Are you guys automatically segmenting the data? If so, how? I thought successive frame difference at same slice location would give a proper indication of area, but it has some noise also.", "104698": "Without knowing what I am saying..\r\nWhat does the Slice Thickness variable mean ?\r\nThat one is 8 instead of 10.\r\n\r\n0.8 * 246 = 196 which is ~almost~ 182", "104711": "That's interesting. I believe the Slice Thickness value is sometimes used as the spacing between slices, even when it shouldn't be. So that might indeed explain the discrepancy.", "104752": "PaulG This is very large error considering what the leaderboard runner can do automatically." }, "source": "meta" }