What replaces removed/renamed items from v3.5.4

[thomb]

It depends, i.e. it should work if you only need to process JPEG-compressed images. However, JPEG2000-compressed images will not be supported by AP_GeneralPurposeDVDJPEG. If you need to support both, you should first create a DICOMDIR according to AP_GeneralPurposeDVDJPEG and then append the missing entries with AP_GeneralPurposeDVDJPEG2000.

Is there an Application Profile what supports any type of images? I didn't see one that supported any compressed images.
What did AP_GeneralPurposeDVD support in older versions of DCMTK?
Was AP_GeneralPurposeDVD like the AP_GeneralPurpose?

If we need to support JPEG and JPEG2000 images, do we keep a list of the files that aren't added to on profile and update the profile for the DICOMDIR and attempt to add those or do we check each dicom file as we are adding them (the latter I think).

I checked the code for what AP_GeneralPurposeDVD did and I see how the supported transfer syntaxes were split out and put in their own application profiles. So using either of the new DVD profiles will limit the transfer syntax supported by the DICOMDIR that uses it. I'll go back to the product team and see if they can give me the most common transfer syntaxes used by our customers.

[J. Riesmeier]

Are there places that describe DICOMDIR usage more clearly and with cases for situations when you need to support any transfer syntax coming in?
We don't have a UI for selecting the application profiles.

DICOM Media Storage Application Profiles are always related to a certain use case. They are described and the technical details are defined in DICOM PS3.11 (and related Parts).

Is there an Application Profile what supports any type of images?

Yes and no: if you mean any Storage SOP Class by "any type of image", the answer is "yes"; if you also refer to any Transfer Syntax, the answer is "no".

What did AP_GeneralPurposeDVD support in older versions of DCMTK?

It was a mixture of two Standard Application Profiles, and was, therefore, not consistent with DICOM PS3.11. This has been fixed many years ago as explained before.

Was AP_GeneralPurposeDVD like the AP_GeneralPurpose?

No, it was a mixture of General Purpose DVD​ Interchange with JPEG​ (STD-GEN-DVD-JPEG​) and General Purpose DVD​ Interchange with JPEG 2000​ (STD-GEN-DVD-J2K​), i.e. it implemented rather an Application Profile Class than a single Application Profile as it should.

Does this mean that any entry that doesn't work with the new application profile is removed?

No, entries are not removed but might get updated if needed, e.g. the Patient's Birth Date is added to an existing PATIENT directory record if a DICOMDIR is updated and this information is needed for the currently selected Application Profile, but is missing.

By the way, looking at the many DCMTK and DICOM related questions you have posted on this forum in the last few weeks, one would think that you need someone to give you professional advice, not the advice of volunteers like on this forum.

[thomb]

Does this mean that any entry that doesn't work with the new application profile is removed?

No, entries are not removed but might get updated if needed, e.g. the Patient's Birth Date is added to an existing PATIENT directory record if a DICOMDIR is updated and this information is needed for the currently selected Application Profile, but is missing.

Here is the full scenario I was trying to understand.
A DICOMDIR is created with the General Purpose DVD​ Interchange with JPEG​ profile.
DICOM files are added with transfer syntaxes of Explicit VR Little Endian Uncompressed 1.2.840.10008.1.2.1 and JPEG Lossless Process 14 (selection value 1) 1.2.840.10008.1.2.4.70 (both supported by profile).
A file with transfer syntax JPEG 2000 Image Compression (Lossless Only) 1.2.840.10008.1.2.4.90 is read.
This file can't be stored with the Application Profile used to create the DICOMDIR.
The updateDicomDir method is called with the DICOM file and Application Profile for General Purpose DVD​ Interchange with JPEG2000 is used as the profile. Overriding the original profile.
What happens to the previously added DICOM files and the DICOMDIR?
Are they all removed because they can't be stored after updating the profile to JPEG2k?

This is something that isn't very clear to me from the DCMTK code or the DICOM Specification.
What happens to the already stored files (files themselves and the information in the DICOMDIR about them).
Your comment suggests the files are still stored on the media and in the DICOMDIR. Do I have that right?
addDicomFile can fail to add a DICOM file for not matching a supported transfer syntax so I had thought the files not supported by the new
profile would be removed.
See this code from the dcmpgdir:
https://github.com/mdsol/mmi-director-d ... ir.cc#L615
https://github.com/mdsol/mmi-director-d ... ir.cc#L594
These sections show bad results when calling addDicomFile. One of the reasons an add can fail is an incorrect transfer syntax for a profile (as long as the transfer syntax check is enabled).
This led me to believe that any files in the DICOMDIR not matching one of the new profile's supported transfer syntaxes would be purged when the application profile changed.

If I disable the syntax transfer check, will the DICOMDIR work if there files with transfer syntaxes that don't match the application profile?

By the way, looking at the many DCMTK and DICOM related questions you have posted on this forum in the last few weeks, one would think that you need someone to give you professional advice, not the advice of volunteers like on this forum.

Yes, I've worked with several areas of DICOM but haven't had to work with DICOMDIRs. It would be nice to have someone with experience with DICOMDIRs to consult.

Thank you.

[J. Riesmeier]

Your links do not work, probably because the GitHub project is not public.

It would be nice to have someone with experience with DICOMDIRs to consult.

You could e.g. contact Marco from the OFFIS DICOM Team, Michael from Open Connections or me (Freelancer).

[thomb]

Your links do not work, probably because the GitHub project is not public.

Sorry, I picked them from my repo and not the public DCMTK repo.
Here are the ones that should work.
https://github.com/DCMTK/dcmtk/blob/59f ... ir.cc#L615
https://github.com/DCMTK/dcmtk/blob/59f ... ir.cc#L594

It would be nice to have someone with experience with DICOMDIRs to consult.

You could e.g. contact Marco from the OFFIS DICOM Team, Michael from Open Connections or me (Freelancer).

I assume this is for a consulting fee. I'll keep it in mind. Thank you.

Also, I worked with dcmmkdir.exe today and found I could add any number of dicom files to a DICOMDIR as long as I used the update option with an application profile that supports the transfer syntax of the DICOM file being added.

I was able to add several files to a single DICOMDIR with the following transfer syntaxes:
1.2.840.10008.1.2.4.70 JPEG Lossless, Non-Hierarchical, First-Order Prediction(Process 14 [Selection Value 1]): Default Transfer Syntax for Lossless JPEG Image Compression
1.2.840.10008.1.2.4.90 JPEG 2000 Image Compression (Lossless Only)
1.2.840.10008.1.2.1 Explicit VR Little Endian

I started with General Purpose Interchange on CD-R or DVD-RAM Media (STD-GEN-CD/DVD-RAM (default).
Then General Purpose DVD Interchange with JPEG (STD-GEN-DVD-JPEG) using --update and --general-dvd-jpeg
Then General Purpose DVD Interchange with JPEG 2000 (STD-GEN-DVD-J2K) with --update and --general-dvd-j2k

I'd love to see a dump of the data in the DICOMDIR file to see what it looks like.
I was able to load the files from the DICOMDIR in Weasis.

[thomb]

I forgot to try dcmdump.exe from DCMTK. That shows much of what I'm looking for with defaults. I will examine the options.

[J. Riesmeier]

Of course, professional consultancy is not free of charge.

But now, you seem to follow the approach I proposed in one of my first postings in this thread: create a DICOMDIR based on a particular Application Profile and then append further entries based on another Application Profile by updating the DICOMDIR.

[thomb]

Of course, professional consultancy is not free of charge.

I didn't think so, but it was unclear what type of service was being offered.

But now, you seem to follow the approach I proposed in one of my first postings in this thread: create a DICOMDIR based on a particular Application Profile and then append further entries based on another Application Profile by updating the DICOMDIR.

I used dcmmkdir.exe to simulate the behavior. I haven't changed our code yet.
By using dcmmkdir.exe, I was relying on the DICOMDIR being written already and not being in-memory only.
To preserve the files in an in-memory only DICOMDIR before changing to a new profile, do I need to write the file?
I ask because I saw this line in updateDicomDir: https://github.com/DCMTK/dcmtk/blob/59f ... f.cc#L1358
The call to cleanup() removes the DICOMDIR from memory and all of the data written to it before the update is called.
appendToDicomDir appears to behave the same way.

• Just let me know if having a written DICOMDIR is required for updateDicomDir to work (code seems to say this).

• Is there a way to update the application profile and keeping the in-memory DICOMDIR object? I would rather not have to write the DICOMDIR before all the files are added.

Thank you

[J. Riesmeier]

The underlying code of the DcmDicomDir class directly works on the specified DICOMDIR file, i.e. the data structures are managed in memory but are written to file in the destructor of this class.

Just let me know if having a written DICOMDIR is required for updateDicomDir to work (code seems to say this).

As the underlying implementation is as it is (see above), the answer is yes.

Is there a way to update the application profile and keeping the in-memory DICOMDIR object? I would rather not have to write the DICOMDIR before all the files are added.

Theoretically yes, but this would require changes at least to the higher-level DicomDirInterface class.