Discussion Forum for OFFIS DICOM Tools - For registration, send email with desired user name to the OFFIS DICOM team
It is currently Fri, 2018-03-23, 04:20

All times are UTC + 1 hour

Post new topic Reply to topic  [ 3 posts ] 
Author Message
PostPosted: Sat, 2017-08-12, 14:11 

Joined: Wed, 2015-09-02, 09:24
Posts: 34
I am a bit confused with the DcmFileFormat::validateMetaInfo and DcmFileFormat::calcElementLength(). Using the following code, I load in a Dicom file, compress it, write it to a butter and then save the buffer through cstdio. Afterwards, when I try to read (dcmdjpeg.exe) the resulting file, it shows "I/O suspension or premature end of stream". However, if I comment out the validateMetaInfo() or save file by use of DcmFileFormat::saveFile(), everything seems fine. I guess the validateMetaInfo is somehow influencing the behavior of DcmFileFormat::calcElementLength(). How is that so?
DcmFileFormat fileFormat;

DJ_RPLossless params;
fileFormat->chooseRepresentation(EXS_JPEGProcess14SV1, & params);

/* seems to create problems, regardless of the 2nd argument */
fileFormat->validateMetaInfo(EXS_JPEGProcess14SV1, ***);

   unsigned len = fileFormat->calcElementLength(EXS_JPEGProcess14SV1, EET_UndefinedLength);
   char * buffer = new char[len];
   DcmOutputBufferStream  dcmOBStream(buffer, len);
   OFCondition cond = fileFormat->write(dcmOBStream, EXS_JPEGProcess14SV1, EET_UndefinedLength, NULL);

   FILE * pFile;
   pFile = fopen("savepath", "wb");
   fwrite(buffer, sizeof(char), len, pFile)

If I would like to compress at the "DcmFileFormat" level instead of the "DcmDataset" level, what would be the correct way to perform "DcmFileFormat::chooseRepresentation()", "DcmFileFormat::calcElementLength()", and "DcmFileFormat::write()"? Thanks!

PostPosted: Mon, 2017-09-04, 16:53 

Joined: Mon, 2014-03-03, 09:51
Posts: 229
Location: Oldenburg, Germany
I'm not sure I understand your question entirely, but, you can ONLY compress the dataset, not the whole DICOM file. The DcmFileFormat consists of two components: the meta header and the actual file (data set). So I guess that what happens is that you "accidentally" also compress the meta header and not just the data set and the file therefore cannot be read since the meta header must always be uncompressed.

PostPosted: Tue, 2017-09-05, 14:18 

Joined: Wed, 2015-09-02, 09:24
Posts: 34
Thanks for replying!

My problem was solved after correcting the 'length' given by DcmFileFormat::calcElementLength() with the one given by DcmOutputBufferStream::flushBuffer(). This, of course, is done after the writing finishes.

It seems the value given by DcmFileFormat::calcElementLength() may fall a few bits too large when associated with a change of transfer syntax. Luckily, 'too large' does not really hurts, as opposed to 'too small'. In the meanwhile, DcmFileFormat::validateMetaInfo() seems to be irrelevant because the meta header always gets to be somehow recreated and always says correctly in terms of the transfer syntax. I guess it may only be needed if people hope to update the UIDs.

In reply to your suggestion, yes, the meta header should always be in little-endian explicit.

Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 3 posts ] 

All times are UTC + 1 hour

Who is online

Users browsing this forum: No registered users and 1 guest

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group