It does not dictate in any way how Your application should store or process the information internally. One final note - DICOM as a standard defines a standard way of exchanging medical imaging information with other DICOM compliant systems. Writing and updating and reading DICOMDIR files for millions of objects is no feasible in any way.
All PACS-s I have seen just write DICOM instances to disk as files and keep track of them internally in a SQL database. This is a useful thing when burning files on a DVD to be imported or viewed by another DICOM application, but You don't have to follow this part of the standard in Your application internally. This desribes a standardised way of organising collections of DICOM files on a disk with the DICOMDIR file containing some basic information about all the files in the file-set. You may have read the Media Storage part of the standard, which talks about DICOMDIR and such things.
I also see, that you reference a File-set and File ID in your question. They are usually used for short clips of moving images or videos, for example cardiac ultrasound where heart valve movements are recorded. These are called multiframe objects, but MR does not use these as far as I know. There can be DICOM SOP Instances, which contain multiple images. one "3D image" contains tens to hundreds of slices, which means tens to hundreds of SOP Instances, which could be files on disk or stored in some other way. In a DICOM sense, each slice is a SOP instance. Using the information in those images, software can render them as 3D images. It is a series of 2D images grouped together into a series, a single image is called a slice. If we are talking about MRI images, there is actually no such thing as a 3D MRI image. As a sidenote - file extension is a meaningless concept in modern filesystems anyway. It has to have a globally unique ID though, which you are responsible for creating if you create the instance. You could encode the data as a SOP instance in memory and transmit it over network without ever writing it out to disk as an actual file. One MR image usually is encoded as one SOP Instance.Ī single image could be encoded as a single SOP Instance, if we want to be correct with the terminology.Ī SOP Instance does not have to be a file necessarily. Then you combine this IOD with a Service Class and you get a Service-Object Pair Class, usually referenced as a SOP Class. Rather there is a concept known as Information Object Definition, which defines the attributes and rules for a specific type of objects. You might be stuck in technical details, that are not relevant to Your actual goal.įirst of all - as I understand the standard, there is no such thing as an Information Object. It might also help to give a more accurate reply, if You would explain in a few words, what the end goal is, that You are trying to achieve. I am not that much of a DICOM expert either, but I'll try my best.
0 kommentar(er)
