StoreSCP writing dicomdir index for received file

All other questions regarding DCMTK

Moderator: Moderator Team

Post Reply
Message
Author
Tsunamis
Posts: 31
Joined: Wed, 2005-05-04, 17:07

StoreSCP writing dicomdir index for received file

#1 Post by Tsunamis »

I added to the storeSCP program a function triggered on end of study reception that writes a dicomdir.
All worked clean until now : i need to support compressed images.
StoreSCP is perfectly able to get them to harddrive normally, i see my harddrive folder filled with all intended images BUT
when i come to dicomdir writing, i need to have codecs registered.

(i use the --fork option to generate a process for each association received)

Either I register them in my write dicom dir function, that seemed logical since i already implemented a mutex to access the dicomdir file so i was sure that 2 process could not register codecs simultaneously. But there i have a crash when registering codecs.

If I try to register them only in parent process, it looks like the AddDicomFile function for my dicomdir crashes. (I saw the problem came from here when not having registered any codecs).

Without the --fork option everything happens fine registering codecs in the write dicom dir function

So I suppose the problem is linked to the mentionned impossibility to register 2 times codecs, or maybe there is a security that i could overpass?

Please help me, since debugging with --fork is clearly not easy ^^

[EDIT] : when tracing all error message i can, i find out that Codecs are correctly registered and that the error is thrown by DicomDirInterface::AddDicomFile -> Pixel representation cannot be changed

here is the code for handling my filename vector:

Code: Select all


DicomDirInterface ddIf;
      ddIf.enableInventPatientIDMode(OFTrue);
      ddIf.enableInventMode(OFTrue);
      ddIf.disableBackupMode();
      ddIf.disableConsistencyCheck();
      ddIf.disableEncodingCheck();
      ddIf.disableResolutionCheck();
      ddIf.disableTransferSyntaxCheck();
      ddIf.enableVerboseMode(OFTrue);

// Two threads / processes cannot register codecs at the same time BUT here, a lock has already been done
        DJDecoderRegistration::registerCodecs(); // register JPEG codecs
        cout<<"register codecs successful! \n";

        for (int i=0; i < dicomFiles.size(); i++)
        {
          OFString strDcm = dicomFiles[i];
          cout<<strDcm.c_str()<<"\n";
          OFCondition myCond = ddIf.addDicomFile(strDcm.c_str(), opt_outputDirectory.c_str());
          if(myCond.bad())
          {
            cout<<myCond.text()<<"\n";
            throw exception();
          }
        }

        // cleanup codecs so others processes can register them later.
        DJDecoderRegistration::cleanup(); // deregister JPEG codecs
        cout<<"unregister codecs successful! \n";
        
here is output
writing dcm dir
register codecs successful!
00000001\IM000000
Pixel representation cannot be changed
[EDIT2]
I tried to check the following :

Code: Select all

cout << DcmCodecList::canChangeCoding(EXS_JPEGProcess1TransferSyntax, EXS_LittleEndianExplicit); 
          cout << DcmCodecList::canChangeCoding(EXS_JPEGProcess14SV1TransferSyntax, EXS_LittleEndianExplicit);
and i get 1 and 1 so codecs are registered before i call the addDicomFile function.
I saw in DicomDirInterface that JPEG support was tested at construction, so i tried to move decoders registration before creation of this object :

Code: Select all

   DJDecoderRegistration::registerCodecs(EDC_photometricInterpretation, EUC_default, EPC_default,OFTrue); // register JPEG codecs
        cout<<"register codecs successful! \n";

        cout << DcmCodecList::canChangeCoding(EXS_JPEGProcess1TransferSyntax, EXS_LittleEndianExplicit); 
        cout << DcmCodecList::canChangeCoding(EXS_JPEGProcess14SV1TransferSyntax, EXS_LittleEndianExplicit);
        //add to dicomdir file
      DicomDirInterface ddIf;
      ddIf.enableInventPatientIDMode(OFTrue);
      ddIf.enableInventMode(OFTrue);
      ddIf.disableBackupMode();
      ddIf.disableConsistencyCheck();
      ddIf.disableEncodingCheck();
      ddIf.disableResolutionCheck();
      ddIf.disableTransferSyntaxCheck();
      ddIf.setLogStream(&(OFConsole::instance()));
It works quite better, BUT i have a strange output :
checking file: c:\mediansite\dicomserver\00000001\IM000000
Warning: LittleEndianExplicit expected: 00000001\IM000000
adding file: c:\mediansite\dicomserver\00000001\IM000000
Can someone explain to me this warning?
Last edited by Tsunamis on Tue, 2011-02-01, 14:42, edited 2 times in total.

Jörg Riesmeier
ICSMED DICOM Services
ICSMED DICOM Services
Posts: 2217
Joined: Fri, 2004-10-29, 21:38
Location: Oldenburg, Germany

#2 Post by Jörg Riesmeier »

Warning: LittleEndianExplicit expected: 00000001\IM000000
Did you check the transfer syntax of that file and compare it with the requirements of the selected application profile?

Post Reply

Who is online

Users browsing this forum: Ahrefs [Bot], Baidu [Spider] and 1 guest