What replaces removed/renamed items from v3.5.4

[thomb]

I'm porting some code that used the 3.5.4 toolkit to 3.6.8.
One error I see is that AP_GeneralPurposeDVD is not longer available.
What should I use instead? I was considering AP_GeneralPurpose, but not sure that's correct.

DicomDirInterface.enableVerboseMode() has been removed or renamed. What is the 3.6 equivalent?
Same for:
DicomDirInterface.addDicomFileFast

dcmtk/dcmdata/dcdebug.h was removed. Does this functionality still exist elsewhere in 3.6?

UID_BasicTextSR

I will collect the rest if folks think they can provide answers. I've resolved some via commit comments, and diffs between tagged versions. Not always easy to find when it changed and why.

Thanks.

[thomb]

It seems that addDicomFileFast was removed from the toolkit. Is addDicomFile now doing the fast all the time or was it decided that the fast was no longer good?
I have some code that uses both and creates a file with a name based on the type of add we are doing.

[thomb]

I've made some progress. However, what replace DU_fileSize?

Update: Seems to be OFStandard::getFileSize

[J. Riesmeier]

I am not aware that there was a DicomDirInterface::addDicomFileFast() in DCMTK 3.5.4, which is almost 19 years old. Therefore, it's not surprising that there have been a number of API changes over time.

For example, AP_GeneralPurposeDVD has been replaced by AP_GeneralPurposeDVDJPEG and AP_GeneralPurposeDVDJPEG2000 in order to be more consistent with the definitions of the DICOM standard.

Of course, you could collect all changes between DCMTK 3.5.4 and 3.6.8 and post the list here, but I hope that no one is still using an almost 19 years old software in the field of medical imaging.

[thomb]

Thanks.

Did you mean AP_GeneralPurposeDVD was replaced by AP_GeneralPurposeDVDJPEG and AP_GeneralPurposeDVDJPEG2000 ?

[J. Riesmeier]

Yes, this is because there never was a single General Purpose DVD Application Profile in DICOM PS3.11, but one for JPEG and another one for JPEG2000 compression. So, we fixed this issue with this commit back in 2011.

[thomb]

What should I use instead of DIMSE_DATASET_NONE?

What replaced OFBitmanipTemplate<char>::zeroMem and OFBitmanipTemplate? I ended up using std::memset

[Marco Eichelberg]

OFBitmanipTemplate still exists, see ofstd/include/dcmtk/ofstd/ofbmanip.h.
There never was DIMSE_DATASET_NONE, as far as I know. It is called DIMSE_DATASET_NULL and still exists.

[thomb]

Thanks. DIMSE_DATASET_NONE definitely existed in the copy of 3.5.4 that we've been using. I wonder if someone added it in-house because I don't see it in the 3.5.4 tagged code in https://github.com/DCMTK/dcmtk/blob/4c4 ... mse.h#L235
Here is what I see:

Code: Select all

typedef enum {			/* DIC_US */
    DIMSE_DATASET_PRESENT = 0x0001,	/* anything other than 0x0101) */
    DIMSE_DATASET_NULL = 0x0101,
	DIMSE_DATASET_NONE = 0x0000
} T_DIMSE_DataSetType;

Not sure why they would do that.
I'll see if the header for OFBitmanipTemplate had moved so our code could not find it.
Here is the code that was using it:

Code: Select all

OFBitmanipTemplate<char>::zeroMem ((char *) &variable, sizeof (variable));

I changed the name of the variable to make it more generic.
Thanks.

[thomb]

Here is the like using DIMSE_DATASET_NONE.

Code: Select all

T_DIMSE_C_FindRQ            findRequest;
findRequest.DataSetType =f DIMSE_DATASET_NONE;

findRequest is passed to DIMSE_findUser as the request parameter.

I'm investigating the consequences of changing that to DMSE_DATASET_NULL.

[thomb]

Looks like DIMSE_findUser overrides the DataSetType at this line: https://github.com/DCMTK/dcmtk/blob/442 ... nd.cc#L153
Seems it doesn't matter what we set it to before passing the request variable to DIMSE_findUser.

[thomb]

OFBitmanipTemplate still exists, see ofstd/include/dcmtk/ofstd/ofbmanip.h.

I had to add that header to our header so the cpp file could resolve it.
The location of OFBitmanipTemplate doesn't seem to have moved between 3.5.4 and 3.6.8.
I wonder if ofbmanip.h was included in one of the headers we already used in 3.5.4 and it was pulled out by
the time 3.6.8 came around.

[thomb]

DicomDirInterface.enableVerboseMode() has been removed or renamed. What is the 3.6 equivalent?
Same for:
DicomDirInterface.addDicomFileFast

Thanks.

Any suggestions for these questions?
Has addDicomFileFast been moved or has addDicomFile been made the fast version?
Or perhaps there was something wrong with FileFast and it was removed.

[thomb]

Yes, this is because there never was a single General Purpose DVD Application Profile in DICOM PS3.11, but one for JPEG and another one for JPEG2000 compression. So, we fixed this issue with this commit back in 2011.

Thanks. That commit helped. After looking at the changes there, it seems that AP_GeneralPurposeDVDJPEG is the best choice to replace AP_GeneralPurposeDVD.
It is handled in the same case statement in dcmdata/libsrc/dcddirif.cc

Do you agree?

[J. Riesmeier]

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.