The Flow for making JPIP streaming possible from a DCM4CHEE (manually)

This documents my way to get the DCMs to output to a JPIP Stream

You will need:

1) A remote archive( preferably, if not try local) DICOM archive (supports dicom queries)
2) DCM4CHEE (unzipped)
3) Kakadu JPIP Server and Client (you can sub this in with others)
4) DCMTK

Pseudo-Steps:

1) Retrieve Images from a remote archive


a) set up a dcmrcv
> dcmrcv AE_TITLE@11112 -dest H:\Folder


b) cmove from a remote archive to dcmrcv
> dcmqr -L AE_TITLE@LOCALMACHINE AE_TITLE@REMOTEMACHINE:PORT -cmove AE_TITLE -qPatientID=1234567 -cstoredest /tmp


2) Convert 'cmove'ed images to a kakadu encoder-compatible format

a) this step is a bit important if your remote archive tends to store everything to a jpeg-ls or jpeg lossless format with different process tables).  Step a) is to ensure it will be converted to explicit big endian (which dcmtk knows what it is.
>DCM4CHEE\DCM2DCM "H:\Folder\abc.dcm" "H:\Folder\convertedabc.dcm" 

b) Convert to PGM with DCMTK
> DCMTK\DCMP2PGM "H:\Folder\convertedabc.dcm" "H:\Folder\convertedabc.pgm"

c) Convert to JP2 with Kakadu
> Kakadu\kdu_compress -i "H:\Folder\convertedabc.dcm" -o "H:\Folder\convertedabc.jp2" -rate 1.0




3) Start JPIP Server

*assuming you have moved convertedabc.jp2 to a place where the server knows where to read from
> kdu_server -address localhost -port 8080

4) Start JPIP Client
Just make sure your JPIP Url is correct and the target file is convertedabc.jp2 (in this example).






There, that'd do it.  If not, email me or leave me a comment for me to analyze your situation.  Thanks!!

DICOM Transfer Syntax UID

1.2.840.10008 is reserved for DICOM Transfer Syntaxes

Below is the set of UIDs for a number of  Transfer Syntaxes

Implicit VR Little Endian	1.2.840.10008.1.2
Explicit VR Little Endian Transfer Syntax	1.2.840.10008.1.2.1
Explicit VR Big Endian Transfer Syntax	1.2.840.10008.1.2.2
RLE Compression	1.2.840.10008.1.2.5
Deflated Explicit VR Little Endian	1.2.840.10008.1.2.1.99
JPEG Baseline (JPEG Coding Process 1)	1.2.840.10008.1.2.4.50
JPEG Extended  (JPEG Coding Process 2)(8-bit) (JPEG Coding Process 4)(12-bit)	1.2.840.10008.1.2.4.51
JPEG(lossless, non-hierarchical) (JPEG Coding Process 14)	1.2.840.10008.1.2.4.57
JPEG (lossless, non-hierarchical, first-order prediction) (JPEG Coding Process 14)	1.2.840.10008.1.2.4.70
JPEG-LS  (Lossless Mode)	1.2.840.10008.1.2.4.80
JPEG-LS (Near Lossless Mode)	1.2.840.10008.1.2.4.81
JPEG 2000 Part 1(Lossless)	1.2.840.10008.1.2.4.90
JPEG 2000 Part 1(Lossless or Lossy)	1.2.840.10008.1.2.4.91
JPEG 2000 Part 2(Lossless)	1.2.840.10008.1.2.4.92
JPEG 2000 Part 2(Lossless or Lossy)	1.2.840.10008.1.2.4.93
JPIP	1.2.840.10008.1.2.4.94
JPIP (Referenced Deflate)	1.2.840.10008.1.2.4.95
MPEG2 MP@ML	1.2.840.10008.1.2.4.100
MEPG2 MP@HL	1.2.840.10008.1.2.4.101
MPEG4 AVC/H.264	1.2.840.10008.1.2.4.102
MPEG4 AVC/H.264 BD	1.2.840.10008.1.2.4.103

I have put together a table like this for my future reference.

DICOM 2011 Standard is AVAILABLE!!!

DICOM 2011 Standard is AVAILABLE!!!
http://www.dclunie.com/dicom-status/status.html#BaseStandard2011




A quick glance, there are two new chapters

1. PS 3.19  Application Hosting
2. PS 3.20  Transformation of DICOM to and from HL7 Standards

I am still reading the differences in the rest of the base standard.  Can't wait!

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

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) key¹.

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.

re: DICOM LUT for WW/WL-tuning

If you want to know why there's the need for the pointers.... Read below:


The need for the pointer because, you would not need to traverse NxM(width x height), but instead, you probably just need to traverse window_min to window_max.
But initially, you need to set the ptrs of each pixel to the gray_scale arrays.

Email me, if you want more details.  Or leave comments.