This may be answered elsewhere but I can't find a reference to this issue on the forum.
\n\nWhy do many cases have different image sizes for some slices in the case? Is it because they were re-taken/resized for the same slice positions? Usually I find 2 different images sizes (haven't seen more than 2) - e.g. case 442. Most samples do seem to have the same image size. This differing sizes is complicating any efforts to process these images across slices.
\n\nThanks!\nArvind
", "messages": [ { "id": "108769", "postDate": "02/19/2016 18:17:02", "content": "This may be answered elsewhere but I can't find a reference to this issue on the forum.
\n\nWhy do many cases have different image sizes for some slices in the case? Is it because they were re-taken/resized for the same slice positions? Usually I find 2 different images sizes (haven't seen more than 2) - e.g. case 442. Most samples do seem to have the same image size. This differing sizes is complicating any efforts to process these images across slices.
\n\nThanks!\nArvind
", "rawMarkdown": "This may be answered elsewhere but I can't find a reference to this issue on the forum.\r\n\r\nWhy do many cases have different image sizes for some slices in the case? Is it because they were re-taken/resized for the same slice positions? Usually I find 2 different images sizes (haven't seen more than 2) - e.g. case 442. Most samples do seem to have the same image size. This differing sizes is complicating any efforts to process these images across slices. \r\n\r\nThanks!\r\nArvind", "votes": null }, { "id": "108776", "postDate": "02/19/2016 20:49:39", "content": "Can you tell me, which two images have different size in study #442?
", "rawMarkdown": "Can you tell me, which two images have different size in study #442?", "votes": null }, { "id": "108779", "postDate": "02/19/2016 21:12:12", "content": "In 442, images sax_20 to sax_24 is 192x256 (x30 frame) whereas sax_13 to sax_19 is 256x192. It's possible these are transposed - but there are other samples where the images are of diff dimensions.
\n\nE.g. for 437, images sax_12 to sax_22 is 256x218, while sax_5 to sax_11 is 256x192. Some of these images might be repeat captures due to lower/bad quality; but can't understand why they are of different sizes.
", "rawMarkdown": "In 442, images sax_20 to sax_24 is 192x256 (x30 frame) whereas sax_13 to sax_19 is 256x192. It's possible these are transposed - but there are other samples where the images are of diff dimensions. \r\n\r\nE.g. for 437, images sax_12 to sax_22 is 256x218, while sax_5 to sax_11 is 256x192. Some of these images might be repeat captures due to lower/bad quality; but can't understand why they are of different sizes.", "votes": null }, { "id": "108784", "postDate": "02/19/2016 21:27:19", "content": "Good catch! These images have different orientations, so DICOM tag data has to be used for proper spatial alignment of different slices. I have no idea why these studies are presented this way.
", "rawMarkdown": "Good catch! These images have different orientations, so DICOM tag data has to be used for proper spatial alignment of different slices. I have no idea why these studies are presented this way.", "votes": null }, { "id": "108788", "postDate": "02/19/2016 21:41:41", "content": "@Arfoss. excellent catch. do you know what the minimum size and the maximum size is across sax and stacks?
", "rawMarkdown": "Arfoss. excellent catch. do you know what the minimum size and the maximum size is across sax and stacks?", "votes": null }, { "id": "108790", "postDate": "02/19/2016 21:43:19", "content": "I think they exists in this way because the model will run in hundreds of organizations, and the model need to be smart enough to handle with this situations.
", "rawMarkdown": "I think they exists in this way because the model will run in hundreds of organizations, and the model need to be smart enough to handle with this situations.", "votes": null }, { "id": "108797", "postDate": "02/19/2016 22:53:37", "content": "@ WD - I haven't computed the max and min sizes for everything - though I can find that easily through a script - including identifying cases that has varying image sizes for the sax files. Most seems to have the same image size for all the sax folders within a case folder. The algorithm I initially wrote assumed same image size within a case folder - but when that broke I had to investigate this issue further.
\n\n@Alvaro - I don't think having to deal with this complexity is/should be a job for the algorithm itself - as most systems should be writing out the MRI stack files in some standard format that's pre-registered. Otherwise, where you draw the line of what our algorithm supposed to handle; and spending time and effort on painful but really low value-add pre-processing steps that could be standardized through appropriate data collection regimen. I'll certainly include logic in my algorithm to deal with this - but unsure what other curve balls on the data format issue I might run into.
", "rawMarkdown": "WD - I haven't computed the max and min sizes for everything - though I can find that easily through a script - including identifying cases that has varying image sizes for the sax files. Most seems to have the same image size for all the sax folders within a case folder. The algorithm I initially wrote assumed same image size within a case folder - but when that broke I had to investigate this issue further. \r\n\r\n@Alvaro - I don't think having to deal with this complexity is/should be a job for the algorithm itself - as most systems should be writing out the MRI stack files in some standard format that's pre-registered. Otherwise, where you draw the line of what our algorithm supposed to handle; and spending time and effort on painful but really low value-add pre-processing steps that could be standardized through appropriate data collection regimen. I'll certainly include logic in my algorithm to deal with this - but unsure what other curve balls on the data format issue I might run into.", "votes": null }, { "id": "108800", "postDate": "02/19/2016 23:48:08", "content": "@Arfoss, i agree. However, i think i have read it in this forum.
", "rawMarkdown": "Arfoss, i agree. However, i think i have read it in this forum.", "votes": null } ], "comments": [ { "id": 108776, "author_name": "pauljurczak", "author_url": "", "post_date": "02/19/2016 20:49:39", "content": "Can you tell me, which two images have different size in study #442?
", "votes": null, "replies": [] }, { "id": 108779, "author_name": "arfoss", "author_url": "", "post_date": "02/19/2016 21:12:12", "content": "In 442, images sax_20 to sax_24 is 192x256 (x30 frame) whereas sax_13 to sax_19 is 256x192. It's possible these are transposed - but there are other samples where the images are of diff dimensions.
\n\nE.g. for 437, images sax_12 to sax_22 is 256x218, while sax_5 to sax_11 is 256x192. Some of these images might be repeat captures due to lower/bad quality; but can't understand why they are of different sizes.
", "votes": null, "replies": [] }, { "id": 108784, "author_name": "pauljurczak", "author_url": "", "post_date": "02/19/2016 21:27:19", "content": "Good catch! These images have different orientations, so DICOM tag data has to be used for proper spatial alignment of different slices. I have no idea why these studies are presented this way.
", "votes": null, "replies": [] }, { "id": 108788, "author_name": "wouterd1", "author_url": "", "post_date": "02/19/2016 21:41:41", "content": "@Arfoss. excellent catch. do you know what the minimum size and the maximum size is across sax and stacks?
", "votes": null, "replies": [] }, { "id": 108790, "author_name": "alvaroosvaldo", "author_url": "", "post_date": "02/19/2016 21:43:19", "content": "I think they exists in this way because the model will run in hundreds of organizations, and the model need to be smart enough to handle with this situations.
", "votes": null, "replies": [] }, { "id": 108797, "author_name": "arfoss", "author_url": "", "post_date": "02/19/2016 22:53:37", "content": "@ WD - I haven't computed the max and min sizes for everything - though I can find that easily through a script - including identifying cases that has varying image sizes for the sax files. Most seems to have the same image size for all the sax folders within a case folder. The algorithm I initially wrote assumed same image size within a case folder - but when that broke I had to investigate this issue further.
\n\n@Alvaro - I don't think having to deal with this complexity is/should be a job for the algorithm itself - as most systems should be writing out the MRI stack files in some standard format that's pre-registered. Otherwise, where you draw the line of what our algorithm supposed to handle; and spending time and effort on painful but really low value-add pre-processing steps that could be standardized through appropriate data collection regimen. I'll certainly include logic in my algorithm to deal with this - but unsure what other curve balls on the data format issue I might run into.
", "votes": null, "replies": [] }, { "id": 108800, "author_name": "alvaroosvaldo", "author_url": "", "post_date": "02/19/2016 23:48:08", "content": "@Arfoss, i agree. However, i think i have read it in this forum.
", "votes": null, "replies": [] } ], "raw_markdown_by_id": { "108769": "This may be answered elsewhere but I can't find a reference to this issue on the forum.\r\n\r\nWhy do many cases have different image sizes for some slices in the case? Is it because they were re-taken/resized for the same slice positions? Usually I find 2 different images sizes (haven't seen more than 2) - e.g. case 442. Most samples do seem to have the same image size. This differing sizes is complicating any efforts to process these images across slices. \r\n\r\nThanks!\r\nArvind", "108776": "Can you tell me, which two images have different size in study #442?", "108779": "In 442, images sax_20 to sax_24 is 192x256 (x30 frame) whereas sax_13 to sax_19 is 256x192. It's possible these are transposed - but there are other samples where the images are of diff dimensions. \r\n\r\nE.g. for 437, images sax_12 to sax_22 is 256x218, while sax_5 to sax_11 is 256x192. Some of these images might be repeat captures due to lower/bad quality; but can't understand why they are of different sizes.", "108784": "Good catch! These images have different orientations, so DICOM tag data has to be used for proper spatial alignment of different slices. I have no idea why these studies are presented this way.", "108788": "Arfoss. excellent catch. do you know what the minimum size and the maximum size is across sax and stacks?", "108790": "I think they exists in this way because the model will run in hundreds of organizations, and the model need to be smart enough to handle with this situations.", "108797": "WD - I haven't computed the max and min sizes for everything - though I can find that easily through a script - including identifying cases that has varying image sizes for the sax files. Most seems to have the same image size for all the sax folders within a case folder. The algorithm I initially wrote assumed same image size within a case folder - but when that broke I had to investigate this issue further. \r\n\r\n@Alvaro - I don't think having to deal with this complexity is/should be a job for the algorithm itself - as most systems should be writing out the MRI stack files in some standard format that's pre-registered. Otherwise, where you draw the line of what our algorithm supposed to handle; and spending time and effort on painful but really low value-add pre-processing steps that could be standardized through appropriate data collection regimen. I'll certainly include logic in my algorithm to deal with this - but unsure what other curve balls on the data format issue I might run into.", "108800": "Arfoss, i agree. However, i think i have read it in this forum." }, "source": "meta" }