What replaces removed/renamed items from v3.5.4

[thomb]

Thanks. I will have to examine the code more closely that used AP_GeneralPurposeDVD to see how they are handling JPEG2000.
What happens if I use AP_GeneralPurposeDVDJPEG2000 instead of AP_GeneralPurposeDVDJPEG?

[thomb]

I think I need to add addition detail to get to the best recommendation.

The code that used AP_GeneralPurposeDVD initialized a DicomDirInterface data member in a class that is devoted to burning a CDROM based on the class's name.
This data member is later used with a call to DicomDirInterface->createNewDicomDir.
After the DICOMDIR is created, it eventually writes DICOM files to the current DICOMDIR using DicomDirInterface->addDicomFile in a loop.
Once all the files have been added, the DICOMDIR is written with DicomDirInterface->writeDicomDir

The DicomDirInterface data member value set in the initialization can be overridden by a method call to set it to something new.

There are no calls to updateDicomDir to change the DicomDirInterface to match the current file being added.
This makes it seem like we need to use:

Code: Select all

/// General Purpose Interchange on CD-R or DVD-RAM Media (STD-GEN-CD/DVD-RAM)
AP_GeneralPurpose,

Does that DicomDirInterface allow for adding any type of DICOM file to the DICOMDIR?

Does this make it easier to determine the right replacement for AP_GeneralPurposeDVD for this scenario?

Thank you.

[J. Riesmeier]

AP_GeneralPurpose only supports uncompressed images, i.e. no JPEG or JPEG 2000 compression. Also the storage medium is limited to CD-R and DVD-RAM.

You have to understand that the DicomDirInterface class implements what is defined in the DICOM Standard, especially in PS3.11.

[thomb]

AP_GeneralPurpose only supports uncompressed images, i.e. no JPEG or JPEG 2000 compression. Also the storage medium is limited to CD-R and DVD-RAM.

You have to understand that the DicomDirInterface class implements what is defined in the DICOM Standard, especially in PS3.11.

yes, but I need to understand what the code on my side was doing with DCMTK 3.5.4. That code was using AP_GeneralPurposeDVD and I sorta expected
to hear that one needs to move from AP_GeneralPurpose to another application profile that would provide the same functionality as AP_GeneralPurposeDVD.
Why did DCMTK remove AP_GeneralPurposeDVD and what is its equivalent.
I wasn't expecting to have to learn all about DICOMDIR to make this adjustment.
Can you tell I'm feeling a bit frustrated?

[J. Riesmeier]

I thought I answered this question already: There was a bug in older versions of the DCMTK that was fixed with the above referenced commit: AP_GeneralPurposeDVD did not implement a Storage Media Application Profile as defined in the DICOM Standard.

I wasn't expecting to have to learn all about DICOMDIR to make this adjustment.
Can you tell I'm feeling a bit frustrated?

How could you implement a standard or an application based on it without knowing at least some technical details? You don't have to understand all details but in this case you should at least understand what an Application Profile is and where you can find the details in the standard.

[thomb]

Thanks.
As I have said, I have taken over this code.
It wasn't implemented by me.
That's why I'm asking for guidance with this change.
I have looked at the spec before asking some of these questions about DICOMDIR, but I didn't see anything that would help me understand the comparable change needed in the code I am working with vs the bug fix in DCMTK.

[thomb]

How could you implement a standard or an application based on it without knowing at least some technical details? You don't have to understand all details but in this case you should at least understand what an Application Profile is and where you can find the details in the standard.

This effort is moving from 3.5.4 to 3.6.8. There is no other development involved.
That would explain why I don't know this area and had expected to be able to just swap in a new application profile value where AP_GeneralPurposeDVD had been used.

The bug in 3.5.4 could explain an issue we've seen with DICOMDIR.

[J. Riesmeier]

As explained before, DCMTK 3.5.4 is almost 20 years old, so there are numerous changes between both versions and also a large number of bug fixes.

Regarding the Application Profiles: First, you need to find out what the application you are upgrading to a latest DCMTK release shall support in terms of "Media Services". For example, did you already check the DICOM Conformance Statement of the system/product to determine what the intended behavior is? If there is none, which should not happen for an implementation of the DICOM Standard unless it is a toolkit or just a sample application, there might be other technical documentation that you could check. As soon as you know what the intended behavior is, we should be able to suggest what to do, e.g. support a single Application Profile only or a combination of Application Profiles (as suggested in a previous posting).

[thomb]

As explained before, DCMTK 3.5.4 is almost 20 years old, so there are numerous changes between both versions and also a large number of bug fixes.

I completely understand and it's an unfortunate situation.

Regarding the Application Profiles: First, you need to find out what the application you are upgrading to a latest DCMTK release shall support in terms of "Media Services". For example, did you already check the DICOM Conformance Statement of the system/product to determine what the intended behavior is? If there is none, which should not happen for an implementation of the DICOM Standard unless it is a toolkit or just a sample application, there might be other technical documentation that you could check. As soon as you know what the intended behavior is, we should be able to suggest what to do, e.g. support a single Application Profile only or a combination of Application Profiles (as suggested in a previous posting).

I was thinking about a Conformance Statement before I left the office yesterday. I hope there is one. I will also keep looking at the usage of the Application Profile and the DICOMDIR related code to see what that illuminates.

If I find anything useful, I'll bring it back here to see what suggestions you can make.
Thank you for your time and feedback.

[thomb]

Unfortunately there is no DICOM Conformance Statement for this product. Nor is there any documentation the provides the expected behavior.
After looking at the comment for the version 3.5.4 of DCMTK, I believe the intent of the original developer was to use the STD-GEN-DVD profile class. I believe they wanted to create a DICOMDIR using the Application profile that supports that class. Originally that seemed to be AP_GeneralPurposeDVD.
Since that wasn't correctly implemented in the DCMTK according to the DICOM spec, I would think any of the of the new AP_GeneralPurposeDVD* application profiles would match the intent of the original developer.
Did AP_GeneralPurposeDVD support compression (via JPEG formats) and uncompressed Composite SOP Instances or did it only support uncompressed Composite SOP Instances?

With that said, I am leaning toward General Purpose DVD Interchange with JPEG 2000 (AP_GeneralPurposeDVDJPEG2000).

Also, it appeared to support a single Application Profile.

[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).

[thomb]

For the future, what happens when these actions are taken?

DICOMDIR is created with an Application Profile.
Files are added that can be supported by that profile.
A file that needs a new profile is read.
updateDIcomDir is called with the new file and the appropriate Application Profile.

The API doc for updateDicomDIr says

This function can be used to append new entries to and update existing entries in an existing DICOMDIR file.

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

Same if appendToDicomDir is used.

[thomb]

I just noticed

Code: Select all

case AP_GeneralPurposeMIME:
                 /* accept all transfer syntaxes */
                  break;

in dcddirif.cc

Why can't I just use that Application Profile so our code can accept all transfer syntaxes?

[J. Riesmeier]

As you can read in PS3.11 Annex G, this Application Profile "is intended to be used for the interchange of Composite SOP Instances via e-mail for general purpose applications", i.e. not on storage media.

[thomb]

I figured it was unlikely I could use the MIME profile.

Would you be able to answer my questions in the posts above the MIME post?
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.

Thank you again for your suggestions and answers.