I have a DICOM study with 3 series and want to refresh its UIDs (StudyInstanceUID, SeriesInstanceUID, SOPInstanceUID) to do some tests. All the data is in a single directory so it's not possible to tell which DICOM belongs to which series.
What I have tried is using dcmodify (dcmtk) with some generate options :
dcmodify mydirectory/*.dcm -gst -gse -gin
but it makes all single files different studies, the structure was broken.
Is there a way to do this or do I have to use other dcmtk tools to identify series UIDs that every single file has?
-gst -gse and -gin
Create a new Study-, Series and SOP Instance UID for each individual image matching mydirectory/*.dcm, hence destroying the study/series structure as you already observed.
The answer is two-fold:
To assign the same UID to all images, you rather use
-m (0020,000D)=...
(this example for the Study Instance UID)
But there is no command line tool in DCMTK that I am aware of which would completely solve your problem. The storescp has an option to create subdirectories for each study (e.g. --sort-on-study-uid) but that does not solve the series-level problem.
With the means of DCMTK, I think you need to do some scripting work around it using dcmdump to dump the files to text, extracting Study- and Series Instance UID from it and then moving the file to an appropriate Study+Series folder.
Related
I would like to know how to transfer data between tasks without storing them in between.
Attached image one can find the flow of tasks. As of now I am storing the output csv files of each task as a file in my local machine and fetching this csv file again as an input to next task. I wanted to know if there is any otherway to pass data between tasks without storing it after each task. I researched a bit and came across Xcoms. I wanted to make sure if Xcoms are the right way to achieve this or am I wrong. I could not find any practical examples. Any help is appreciated as I am just a newbie in airflow started couple of days
Short answer is no, tasks require data to be at rest before moving to the nest task. Xcom's are most suited to short strings that can be shared between tasks (file directories, object names, etc.). Your current flow of storing the data in csv files between tasks is the optimal way of running your flow.
XCom is intended for sharing little pieces of information, like the len of the sql table, any specific values or things like that. It is not made for sharing dataframes (which can be huge) because the shared information is written in the metadata database.
So either you keep exporting the csv to your computer (or uploading them somewhere), for reading it in the next Operator, or you combine the operators into one.
Is it possible to manage data stored amongst several files?
Let's say I have several files data1.realm, data2.realm, data3.realm, etc. containing objects with the same model. Is it possible to get a unique RLMRealm instance that will access the datas of all these files?
If not, what is the best way to handle this situation? Migration?
It's definitely possible to manage data stored amongst separate Realms, but it wouldn't be automatic. You would need to manage access to this data in your own app's logic.
RLMRealm instances themselves represent a single file on disk and cannot be dynamically created to reference combinations of other Realms. Once an RLMObject has been added to a parent RLMRealm, it cannot be moved/backed to another RLMRealm representing a different file.
It most likely depends on your specific use-cases, but the simplest solution would be to simply query for your objects in separate RLMRealm instances for each file, and placing the resulting RLMResults objects from each one in an NSArray.
While data can't be directly shared between Realms, you could use globally unique primary keys (For example NSUUID) to indicate relationships between objects in different Realms.
If you need, it's also possible to create Realmless copies of RLMObjects if you do end up wanting to move objects between Realms:
Dog *savedDog = [[Dog allObjects] firstObject];
Dog *copiedDog = [[Dog alloc] initWithValue:savedDog];
I'm running an optimization in OpenMDAO. One of the components in the model writes a few files to a directory which is given a random name. I track the progress of the optimization using a SqliteRecorder. I would like to be able to correlate iterations in the sqlite database to the directories of each evaluation.
Is there a way to attach arbitrary information to a recorder - in this case, the directory name?
i suggest that you add a string typed output to the component and set it to the folder name. Then the recorder will capture it.
I wonder if it is possible to have two different images with the same header. If so, can we display this two images in the PACS or otherwise which tags should be changed to display them?
No you can't. The issue is that Dicom requires every image to have it's own Unique UID stored in the header.
PACS systems commonly ignore newly received images if their UID is identical to one they already have in the database, so if you don't follow this part of the standard you probably don't get very far.
If you want to generate DICOM images, and you are unfamiliar with the standard, my advice is to use OFFIS img2dcm or a similar tool to convert them from normal images.
Jan de Vaan is correct, you SHOULDNT have duplicate headers with different image bitmaps and that is 'guaranteed' by the unique SOP instance UID. I've never seen a duplicate UID come from any modality. Saying that, there are sloppy applications with terrible UID implementations to generate the unique UID. There are teleradiology apps, secondary capture devices and other open source DICOM packages (for instance) that, typically on reset, could and do create a repeatable UID sequence. Many research labs get along fine with these. I expect you have one of these applications up the pipeline back to the source modality. If its messing up something as fundamental to DICOM as the UID, I would wonder what other wonderful things are happening.
If you must get these into the PACS, you would have to change the SOP Instance UID, which is not a recommended practice.
DICOM already provides a unique enough identifier for the Series (e.g. Series Instance UID), so why also include one on the lower level objects (e.g. SOPInstanceUID)?
What I find really annoying is the fact that when referencing other objects - for example when RTPlan object references RTStruct object via ReferencedStructureSetSequence / ReferencedSOPInstanceUID - it's done using the SOP Instance UID. However any of the DICOM SCPs - such as find/move - don't work with SOP Instance UID, they work with the Series Instance UID. So what gives? Do I have to load the whole Series to find all the referenced objects?
This question was from quite a while ago, but I thought I'd add that, ignoring QR altogether, a SeriesInstanceUID is a globally unique identifier for a single series. SOPInstanceUID is a globally unique identifier for a DICOM file. A series can have multiple DICOM files, so each would share that same SeriesInstanceUID, but each file would have it's own SOPInstanceUID.
As you probably know, DICOM has a hierarchy of identifiers for each individual SOP (Service Object Pair) Instance (Patient ID / Study Instance UID / Series Instance UID / SOP Instance UID). This hierarchy is built into the Query/Retrieve mechanism in DICOM, and is also used to identify specific SOP Instances.
In the specific case you're mentioning, I believe there could be the possibility of multiple RT Structure Sets within a Series/Study. The individual SOP Instance must be referenced so that you know which Structure Set the RT Plan is referencing.
As for products supporting retrieving by SOP Instance UID, unfortunately, relational queries are not widely supported in DICOM Query/Retrieve SCPs, as you've discovered, and some DICOM servers do not support Image level queries. In this specific case, you could query at the series level specifically for the RTSTRUCT modality, and only retrieve the Series that have this modality, thus narrowing down which data you need to download to just the RT Structure Sets.
SOPInstanceUID represent separate uid of the Dicom Image File. Study, series and sopinstace uids are based on data model. StudyUID give you the particular study information. In which different series devided. Series instance uid used for for this. And SOP instance uid represent seperate Dicom image. It's hierarchy structure. I also never used SOPInstanceUID when i developed PACS workstation in Java. As per my experience, Study & Series uids are enough for represent patient's data. But still SOPInstanceUID gives unique identity to dicom image.
SOP Instance UID : Represent your a unique Identifier for IOD, Its a TYPE 1 tag must present with value.
For Example :
Each DICOM Image has unique identifier
Series reference is not specific enough. In the case of structure sets the Reference SOP Instance UID ties the contours in the structure set to the specific slice in the dataset. It's not enough to just reference the series because you have to ensure that the contour is exactly aligning with a slice.
SOPInstanceUId is for image level identification.
Understand it like:
A study can have multiple series and a series can have multiple images/DICOM
So,
to identify study uniquely we use StudyInstanceUID
to identify series uniquely we use SeriesInstanceUID and
to identify an image/DICOM uniquely we use SOPInstanceUId