I want to create an application to read and write DICOM files without using any third party software

Question

I want to create an application to read and write DICOM files without using any third party software How can I do that? Can any one help me?

Answer 1

That would pretty much mean starting from the DICOM standard and writing a lot of code.

Answer 2

Hello jerry, have you ever tried that? is it possible to get any code to refer? Because my project is in a critical situation. I have no time for a trail and error. Anyway here I started from scratch. If you have any samples with you, please share that for me. It will be very helpfull for me. Thank Sajin

Answer 3

Hi all, At alast I done that. I my project, I need only to update pixel data. So it was not too tough to handle. I just parsde the DICOM file till I reach pixel data, and then I replaced the same with my own data. and It become success. :)

Jerry & MSalters , Thanks for your comments.

Answer 4

"I my project, I need only to update pixel data. So it was not too tough to handle. I just parsde the DICOM file till I reach pixel data, and then I replaced the same with my own data. and It become success."

Even though there are quite a few research applications that do the same thing that you've done, it is precisely The Wrong Thing To Do(TM). Why is this such a bad practice? DICOM images are supposed to be uniquely identified by their SOP Instance UIDs. When you take an existing DICOM image and replace the pixel data, leaving the original header information unaltered, you are creating two data objects that share the same primary key.

Consider what will happen if you take this image and send it to a DICOM Storage SCP that already has a copy of the original image. The Storage SCP has to invoke a conflict resolution procedure because it can't have two SOP Instances with the same UID. Upon receipt of your new image, the Storage SCP detects that the new image has the same UID as an existing image and the required behavior of the SCP is not well defined. The Storage SCP can treat your new image as if it is just a retransmission of the original image and ignore your new image, or it can treat it as if it is a corrected version of the original image and replace the original image with your new image, or it can give up and admit that it has absolutely no idea what to do with this new image and throw it into a holding area and require a human being to interact with the application to decide what to do with the two images. You, the creator of the new image, have no way of knowing or controlling what the behavior of the Storage SCP will be when it receives your new image.

At a minimum, you need to generate a new valid SOP Instance UID when you create a new image. Your image type should also be one of the DERIVED\SECONDARY types because it is a post-processed image, not a primary acquisition generated by the modality. You should also look at the other DICOM tags present in the original header and seriously consider whether they accurately describe the new image that you've created.