22 December 2010

Seems like I have missed out something critical too. There is also this Patient Position (0018, 5100) tag that we have to factor in as well. The axes of the patient based coordinate system varies at different patient positions. The following images should illustrate this well enough:

Fig. 1 - Head First-Supine (HFS)

---

Fig. 2 - Feet First-Supine (FFS)

---

Fig. 3 - Head First-Prone (HFP)

---

Fig. 4 - Feet First-Prone (FFP)

---

Fig. 5 - Imaging Equipment

---

The figures above can be found from here as well, and there are also some comprehensive explanations:

http://xmedcon.sourceforge.net/Docs/OrientationXMedConPatientBased

---

When facing the front of the imaging equipment (refer to Fig. 5),

- Head First is defined as the patient’s head being positioned toward the front of the imaging equipment.

- Feet First is defined as the patient’s feet being positioned toward the front of the imaging equipment.

- Prone is defined as the patient’s face being positioned in a downward (gravity) direction.

- Supine is defined as the patient’s face being in an upward direction.

- Decubitus Right is defined as the patient’s right side being in a downward direction.

- Decubitus Left is defined as the patient’s left side being in a downward direction.

Here are the following terms that can be found in the Patient Position (0018, 5100) tag:

- HFP (Head First-Prone)

- HFS (Head First-Supine)

- HFDR (Head First-Decubitus Right)

- HFDL (Head First-Decubitus Left)

- FFP (Feet First-Prone)

- FFS (Feet First-Supine)

- FFDR (Feet First-Decubitus Right)

- FFDL (Feet First-Decubitus Left)

---

After a short discussion with Zac yesterday, I decided to look a little more into the patient-based coordinate system, in particular, to find out where the origin is. Since the position and orientation of the dicom images are provided to us with respect to the patient-based coordinate system, we would have to know where the origin is in order to map it into our models in our application. Looked around for quite some time but I cannot seem to find any sources that talks about the origin of the patient-based coordinate system.

Zac and I then had a short discussion again, and somehow we realized that we do not have a need to know the origin of the patient-based coordinate system at all. We were only loading the specific object models, not the whole human body. Hence, we would only need to know where the images should face, and at which orientation using the following 3 tags in the dicom images:

- Patient Position

- Image Position

- Image Orientation

The newly renamed images now look like this:

IM-0001-0001_x-74.798828125y-268.798828125z-82.5r100c010pFFS.png

In the case above,

x = -74.798828125

y = -268.798828125

z = -82.5

r (row vector) = (1, 0, 0)

c (column vector) = (0, 1, 0)

p (Patient Position) = FFS (Feet First-Supine)

Finally, it is time for me to move on back to work on the pan gesture to translate feature.

21 December 2010

Time really flies. We would be ending our internship in just 9 more weeks, including this week. Gonna miss the people and this place a lot.

Read the PDF document which I chanced upon yesterday. The tag (0020, 0032) Image Position (Patient) specifies the x, y, and z coordinates of the upper left hand corner of the image. This is also the center of the first voxel (a 3-dimensional equivalent of a pixel) that is being transmitted. This position is relative to the patient-based coordinate system:

- The x-axis is increasing to the left hand side of the patient.

- The y-axis is increasing to the posterior side of the patient.

- The z-axis is increasing toward the head of the patient.

This link further illustrates the patient-based coordinate system. It has several pictures there too:

http://www.itk.org/Wiki/Proposals:Orientation

In each image frame, the Image Position (Patient) (0020,0032) specifies the origin of the image with respect to the patient-based coordinate system.

Managed to rename a set of 76 png images with the respective image positions, but something seems to be wrong. Even with the image position, I would need to know which direction the image should be facing, and at which orientation. This definitely has got something to do with the Image Orientation (Patient) (0020,0037) tag.

Read a number of sources on the web, and it is mentioned that Image Orientation tag specifies the direction cosines of the first row and the first column with respect to the patient. Did some searching on the web, but I still do not understand what that sentence is supposed to mean.

Towards the end of the day, I managed to find a link. From there, I got to understand the Image Orientation tag. This is the tag that identifies the direction in which the image should be facing as well as it's orientation. Here's the link:

http://www.medicalconnections.co.uk/wiki/Image_Orientation_Attributes

Now, I only have the png images named with the x, y and z coordinates. In addition to that, I would have to find a way to put in the direction cosines as well, if not, we would not be able to identify where the image should face and at which orientation. Got the renaming done at the end of the day. Now, the file names look like this:

IM-0001-0001_x-74.798828125y-268.798828125z-82.5r100c010.png

In the case above,

x = -74.798828125

y = -268.798828125

z = -82.5

row vector = (1, 0, 0)

column vector = (0, 1, 0)

20 December 2010

The office seems so quiet today, as if no one's working today. Weird. Oh well, holiday season?

Started the day by continuing the search for image converters. While doing that, I realized that on Windows, the .dcm images that I have cannot be viewed properly. I downloaded some image viewers, and all of them show a black patch at the top following by a white patch at the bottom. This explains why the converters are "not work properly" when I tried them out on Thursday last week.

Decided to do the manual conversion myself. Fortunately, there is this feature in OsiriX that allows exporting of the dicom images to jpeg format. From there, I then learnt how to make use of the Automator tool in OSX to do the conversion from jpeg to png. Learnt it here:

http://www.devdaily.com/mac-os-x/batch-convert-bmp-to-jpg-png-tiff-image-files-free

Got this done pretty quickly. The tough part comes the renaming of the images. I have to fish out the position information and put it into the name of the image. But before that, I would have to find out which of the dicom's metadata refers to the images position information. I am suspecting that it is under the tag (0020, 0032) Image Position (Patient). I am still not very sure though. Found this PDF document on the web:

http://medical.nema.org/dicom/2004/04_03PU.PDF

Got to read through that to find out more, and hopefully it helps. In that document, it is said that there is also another field, called the Image Orientation (Patient) (0020, 0037). It is mentioned that this field should be provided as a pair with the Image Position (0020, 0032) field. Getting a little confused here.

16 December 2010

Finally managed to fish out the formula that the library uses to calculate the perspective view. In the end, it's the same formula that we used previously. At least now I got my problems narrowed down. Seems like the way we created the perspective view now and the way we did it previously probably has no difference.

Looks like it's the camera that we have set up that is causing the problem. This setting up of the camera is necessary such that we would be able to see the object being loaded without doing an extra translation into the z-axis. Even if the extra translation is done, the object is still not being displayed correctly. Furthermore, without the camera set up, all the objects' animations are not displayed.

Zac and I had a small discussion at around 2p.m. We decided to pause the explode and the pan to translate gesture first. Both of us felt that these 2 functionalities would definitely take quite some time. Hence, we moved on to work on the plane cutting functionality, and the reading of the dicom location information.

I first started out looking for conversion tools that are available to do a dicom to png conversion. Found quite a few, and they only worked on Windows. I tried out a few of them, but none of them worked at all. Some did not even do a conversion, and some conversions gave me png images that looked totally different from the original dicom images.

15 December 2010

Decided to figure out the formula in which the library uses to create the perspective view today. Spent the day studying the methods in the library and how they work. Did some search on the web as well to check on the various ways people create perspective views. Though I did not managed to have any breakthroughs for the pan to translate gesture today, I managed to resolve some issues in the application along the way. It has got to do with the color picking method that we used. We missed out some parts of drawing which caused the display to go haywire at times.

Along the way, Zac and I also had several discussions. We talked about how to go about improving the rotation for both the object as a whole, as well as the individual components. We found the current swipe to rotate being too static, in which every swipe only causes the object to rotate by 45 degrees. Hence, we decided to make use of the pan gesture to do the rotation. Once we got the idea laid out nicely, Zac took over this while I continued to work on the pan to translate gesture.

14 December 2010

Spent the whole day working on the pan to translate gesture. I thought it was going to be fairly simple at first, since we already got the algorithm up in our previous application where we worked with .obj files.

That obviously was not the case. Somehow, the same algorithm does not translate the object we have in the current application properly. From the looks of it, it seems that the final translation value was not enough to produce the same effect that we see in our previous application.

The only difference that I see in both applications is that in the current one, the perspective of the projection matrix is being calculated through the c++ library, and we have the camera set up. In the previous one, we made use of the glFrustumf to create our perspective view.

I spent the whole day trying to work things out, but to no avail. It seems that the formula that we used does not work in our current application at all. Got to spend some more time trying to understand how this whole thing works.

13 December 2010

Started the day by implementing the ModelTransformation class and tweaking our application to cater for that.

At first, both of us expected lots of work to be done in order to get the ModelTransformation class working. However, we got that up fairly quickly before lunch, including the tweaking of the swipe to rotate gesture. I think the fact that we were able to make such changes in such a short time really reflects our understanding of our application.

After lunch, we decided to split the work among ourselves. I worked on the double tap to scale gesture while Zac researched on how to go about implementing the explode functionality. I managed to complete my part at the end of the day. The UIGestureRecognizer is really useful for our application. Managed to get the effect of double tapping a photo in the iPhone's photo application.