It's done, great results, very fast too. No need to build a graph, and rid the recursions!!
work on open soon yo!
Tuesday, August 9, 2011
Wednesday, August 3, 2011
Verb - Tense in Scientific Writing
In general, we should stick to the present tense
We would use other verb tenses too but under specific scenarios:
PAST
FUTURE
Reference:
"Writing for Publication in Medical Imaging" by Kenneth M. Hanson in SPIE Medical Imaging Symposium 2010
We would use other verb tenses too but under specific scenarios:
PAST
- previous work done by others
- work that you did for the paper
- earlier sections in your paper
FUTURE
- subsequent sections in your paper
- future work
Reference:
"Writing for Publication in Medical Imaging" by Kenneth M. Hanson in SPIE Medical Imaging Symposium 2010
Monday, August 1, 2011
Rendering a 3D Volume from a stack of 2D images
I have seen a number of questions related to the title. I even experienced the question myself. Here, i would like to document my approach.
The Question
If you are in the medical imaging field, at the time of writing, you are almost guaranteed that you'd need to reconstruct a 3D volume based on a stack of 2D images(let it be a stack of 'gray-scale' images). The question is how in Matlab?
The Possible Solutions
The above writing is documented here but was aiming at answering this question on StackOverflow.
The Question
If you are in the medical imaging field, at the time of writing, you are almost guaranteed that you'd need to reconstruct a 3D volume based on a stack of 2D images(let it be a stack of 'gray-scale' images). The question is how in Matlab?
The Possible Solutions
Part 0 - Assumptions
- all 2D images are of the same dimension, hence your 3D volume can hold all of them in a rectangular cube
- majority of the pixels in each of the 2D images have 3D spatial relationships (you can't visualize much if the pixels in each of the 2D images are of some random distribution. )
Part 1 - Visualizing 3D Volume from A Stack of 2D Images
To visualize or reconstruct a 3D volume from a stack of 2D images, you can try the following toolkits in matlab.
[1] 3D CT/MRI images interactive sliding viewerhttp://www.mathworks.com/matlabcentral/fileexchange/29134-3d-ctmri-images-interactive-sliding-viewer
[4] Surface2Volume http://www.mathworks.com/matlabcentral/fileexchange/8772-surface2volume
[5] SliceOMatic http://www.mathworks.com/matlabcentral/fileexchange/764
Note that if you are familiar with VTK, you can try this: [6] matVTKhttp://www.cir.meduniwien.ac.at/matvtk/
I am currently sticking with [5] SliceOMatic for its simplicity and ease of use. However, by default, rendering 3D is quite slow in Matlab. Turning on openGL would give faster rendering. (http://www.mathworks.com/help/techdoc/ref/opengl.html) Or simply put, set(gcf, 'Renderer', 'OpenGL').
Part 2 - Interpolating pixels in between the slices
To interpolate pixels in between the slices, you need to specify an interpolation method (some of the above toolkits have this capability / flexibility. Otherwise, to give you a head start, some examples for interpolation are bicubic, spline, polynomial etc..(you can work this out by looking up on google or google/scholar for interpolation methods much more specific to your problem domain).
Part 3 - 3D Pre-processing
Looking at the procedures, one may process the volumetric data by processing each of the 2D images first. In many advanced algorithms, or in true 3D processing, what you can do is to process the volumetric data in 3D domain first (simply put, you take the 26 neighbors or more in to account first.). Once this step is done, you can simply output the volumetric data into a stack of 2D images for cross-sectional viewing or supply to one of the aforementioned toolkits for 3D viewing or output to third party 3D viewing applications.
I have followed the above concepts for my own medical imaging research projects.
The above writing is documented here but was aiming at answering this question on StackOverflow.
Tuesday, July 26, 2011
Cutlines / Cutline Navigation GE Centricity
What exactly is a 'cutline' or 'cutline navigation'?
GE Centricity Web Manual [1]
If you are a GE Centricity Web user or if you read carefully through the GE's Centricity Web User Manual, you should know that there is a function called 'Displaying Cutlines'.
In the manual, it states that a cutline is the intersection between two planes..
"With Centricity Web you can display cutlines (intersections between two planes) provided your study has images suitable for this... If a series contains images in random order, you will not be able to turn on cutlines..." [1]
But, the explanation is extremely vague. Two planes. What kind of planes? orthogonal planes? planes between two series? more than two series? just one series?
DICOM Standard
Since the above basically did not help with my concerns, i went back to my favorite source: DICOM STANDARD.
In PS3.3, by searching the keyword 'localizer', you should get quite a number of hits. You should then start by reading CT Image Type. There, you should see that DICOM 3.3 defined CT Image Type (0008,0008) as one of the followings: AXIAL or LOCALIZER.
In PS3.3, section C.7.4.1.1.1, it clearly states that The Referenced Image Sequence (0008, 1140) provides an unambiguous method for relating localizer images.
In PS3.11, section E.3.3.2, it clearly states the localizer related attributes allow the image to be referenced to a localizer image or other orthogonal image. The Rows (0028, 0010) and Columns(0028, 0011) attributes are required in order to facilitate annotation of such a localizer. It also refers to the Frame of Reference section in PS3.3
In PS3.16, in the annex, it defines localizer as "Image providing an anatomical reference on the patient under examination, for the purpose of defining the location of the ensuing image".
From the most notable and respectable figure in DICOM, D. Clunie [2]
You will need to make a careful reading in the attached section. Therefore, i will not repeat the info here. However, it must not be neglected that the Frame of Reference UID is being used throughout for the projections. That is, they must be the same for both the localizer and the orthogonal images.
So....
Basically, a cutline maps the orthogonal relationship between two planes that are supposingly orthogonal to each other. In this situation, those two planes are most likely from two different series that are, perhaps, meant to be registered the moment the DCM files are generated (hence, Frame of Reference UID). Note that this can lead to co-registrations between multiple series if those multiple series are related but do not provide direct spatial mapping. And, there is a huge research history of algorithms that produce good results for co-registrations.
Ref
[1] http://pulmonaryfellowship.hms.harvard.edu/NewFiles/CentricityWeb2UserGuideM3.pdf
[2] http://www.dclunie.com/medical-image-faq/html/part2.html#DICOMLocalizers
GE Centricity Web Manual [1]
If you are a GE Centricity Web user or if you read carefully through the GE's Centricity Web User Manual, you should know that there is a function called 'Displaying Cutlines'.
In the manual, it states that a cutline is the intersection between two planes..
"With Centricity Web you can display cutlines (intersections between two planes) provided your study has images suitable for this... If a series contains images in random order, you will not be able to turn on cutlines..." [1]
But, the explanation is extremely vague. Two planes. What kind of planes? orthogonal planes? planes between two series? more than two series? just one series?
DICOM Standard
Since the above basically did not help with my concerns, i went back to my favorite source: DICOM STANDARD.
In PS3.3, by searching the keyword 'localizer', you should get quite a number of hits. You should then start by reading CT Image Type. There, you should see that DICOM 3.3 defined CT Image Type (0008,0008) as one of the followings: AXIAL or LOCALIZER.
In PS3.3, section C.7.4.1.1.1, it clearly states that The Referenced Image Sequence (0008, 1140) provides an unambiguous method for relating localizer images.
In PS3.11, section E.3.3.2, it clearly states the localizer related attributes allow the image to be referenced to a localizer image or other orthogonal image. The Rows (0028, 0010) and Columns(0028, 0011) attributes are required in order to facilitate annotation of such a localizer. It also refers to the Frame of Reference section in PS3.3
In PS3.16, in the annex, it defines localizer as "Image providing an anatomical reference on the patient under examination, for the purpose of defining the location of the ensuing image".
From the most notable and respectable figure in DICOM, D. Clunie [2]
You will need to make a careful reading in the attached section. Therefore, i will not repeat the info here. However, it must not be neglected that the Frame of Reference UID is being used throughout for the projections. That is, they must be the same for both the localizer and the orthogonal images.
So....
Basically, a cutline maps the orthogonal relationship between two planes that are supposingly orthogonal to each other. In this situation, those two planes are most likely from two different series that are, perhaps, meant to be registered the moment the DCM files are generated (hence, Frame of Reference UID). Note that this can lead to co-registrations between multiple series if those multiple series are related but do not provide direct spatial mapping. And, there is a huge research history of algorithms that produce good results for co-registrations.
Ref
[1] http://pulmonaryfellowship.hms.harvard.edu/NewFiles/CentricityWeb2UserGuideM3.pdf
[2] http://www.dclunie.com/medical-image-faq/html/part2.html#DICOMLocalizers
Monday, July 11, 2011
Correlating PET-CT images using DICOM tags
This is actually a wonderful question, which i am yet to find a good answer.
Note that, PET's SOP UID is 1.2.840.10008.5.1.4.1.1.128 and CT's SOP UID is 1.2.840.10008.5.1.4.1.1.2.
But there isn't a SOP UID for both (PET/CT) because essentially these two are two physical copies only that they are scanned in one single gantry simultaneously or immediately sequentially.
Now, assuming that you have inserted a lot of DCMs into the pacs/db, and now you would like to retrieve a set of PET/CT. How would you search or query for this pair of stacks?
Modality Tag and Study/Series UIDs
Initially, i would have assumed that the study/series UIDs would be the same; however, here is my finding:
Purely relying on either modality tag or study/series UIDs would fail to do the job.
Frame of Reference UIDs
They would be different most of the time.
StudyTime/AcquisitionTime
Some suggest to look into study time and/or acquisition time; however, for simultaneous scanning, they may be advisable. However, obviously, this won't work with sequential scanning.
Study Description
Study description is primarily input by the machines and if the machine is indeed a pet/ct scanner, the study description should somehow have the string (pet/ct, petct, ptct, ctpt etc...). With that said, if that specific study is only for CT but using the same machine, this study description would also include the aforementioned list of possible strings. In addition, some pet/ct machines have NM capabilities, so their study description would contain NM as well.
Referenced Study Sequence
This may refer to the same study; however, not all pet/ct image sets have this tag as this is an O(optional) key1.
Footnote
1. According to DICOM standard PS3.4-2009, there are types of keys used in Q/R Information Models: U is unique key attribute, R is required key attribute, and O is optional key attribute.
Note that, PET's SOP UID is 1.2.840.10008.5.1.4.1.1.128 and CT's SOP UID is 1.2.840.10008.5.1.4.1.1.2.
But there isn't a SOP UID for both (PET/CT) because essentially these two are two physical copies only that they are scanned in one single gantry simultaneously or immediately sequentially.
Now, assuming that you have inserted a lot of DCMs into the pacs/db, and now you would like to retrieve a set of PET/CT. How would you search or query for this pair of stacks?
Modality Tag and Study/Series UIDs
Initially, i would have assumed that the study/series UIDs would be the same; however, here is my finding:
Purely relying on either modality tag or study/series UIDs would fail to do the job.
Frame of Reference UIDs
They would be different most of the time.
StudyTime/AcquisitionTime
Some suggest to look into study time and/or acquisition time; however, for simultaneous scanning, they may be advisable. However, obviously, this won't work with sequential scanning.
Study Description
Study description is primarily input by the machines and if the machine is indeed a pet/ct scanner, the study description should somehow have the string (pet/ct, petct, ptct, ctpt etc...). With that said, if that specific study is only for CT but using the same machine, this study description would also include the aforementioned list of possible strings. In addition, some pet/ct machines have NM capabilities, so their study description would contain NM as well.
Referenced Study Sequence
This may refer to the same study; however, not all pet/ct image sets have this tag as this is an O(optional) key1.
Conclusion
In short, there seems to be a missing link for a good, solid correlation between pet/ct image stacks. Feel free to comment and, by all means, please correct me if this is wrong and let me know the right way. Thanks!
Footnote
1. According to DICOM standard PS3.4-2009, there are types of keys used in Q/R Information Models: U is unique key attribute, R is required key attribute, and O is optional key attribute.
[research log] for the opening...
1) See if the validation size can be halved.
2) Multiresolution? (could be based on 5), too).
3) Hough Transform for locating specific angle of edges?
4) Look for patterns again.
5) addition of images (by quadrants)?
6) instead of line/ try circular
2) Multiresolution? (could be based on 5), too).
3) Hough Transform for locating specific angle of edges?
4) Look for patterns again.
5) addition of images (by quadrants)?
6) instead of line/ try circular
Friday, July 8, 2011
Subscribe to:
Posts (Atom)