DICOM @ OFFIS

Discussion Forum for OFFIS DICOM Tools - For registration, send email with desired user name to the OFFIS DICOM team
It is currently Tue, 2017-05-23, 13:50

All times are UTC + 1 hour




Post new topic Reply to topic  [ 3 posts ] 
Author Message
PostPosted: Wed, 2015-08-12, 13:50 
Offline

Joined: Thu, 2011-02-24, 11:27
Posts: 24
Location: Bremen
Hi,
We have some data sets that storescu tries to convert to JPEG lossless as requested by the receiver, but fails due to some private sequence. The private sequence contains all tags needed to calculate the pixel data length, and a pixel data tag which contains much less data then expected, so the encoder fails with the message: True lossless encoder: Cannot change representation, not enough data.
I have no idea what this sequence contains, but my question is: is it correct that private sequences are encoded the same way as non-private sequences in this case? I guess it is so, and the data in question may be considered invalid, but I'm not sure I understand the standard correctly in this case.

Sorry for the slightly off-topic post,

Thanks,
Andreas


Top
 Profile  
 
PostPosted: Thu, 2015-08-13, 16:28 
Offline
DCMTK Developer

Joined: Fri, 2004-11-05, 13:47
Posts: 1546
Location: Oldenburg, Germany
Hi,

posted into "DCMTK General" it is more on-topic (I felt free to move it here) ;).

Private sequences usually follow the rules of non-private sequences in terms of encoding. However, as far as I understand one should never use the Pixel Data element at all in private sequence's items, as part 5 of the standard says:

Quote:
For a Standard Extended SOP Class the Attributes Pixel Data (07FE,0010), Float Pixel Data (7FE0,0008), Double Float Pixel Data
(7FE0,0009), Waveform Data (5400,1010) and Overlay Data (60xx,3000) shall not be included within a Private Sequence Item, nor
within a standard Sequence Item nested directly or indirectly within a Private Sequence Item.


So I think the dataset is invalid.

Btw (this is why I moved the topic): I wonder that storescu converts your data automatically at all; did you use the ON_THE_FLY_COMPRESSION define?
What result you get when sending it with dcmsend?

Best,
Michael

Edit: Ah yes, saw it in your other post (ON_THE_FLY_COMPRESSION)


Top
 Profile  
 
PostPosted: Thu, 2015-08-13, 17:01 
Offline

Joined: Thu, 2011-02-24, 11:27
Posts: 24
Location: Bremen
Ah, thanks - I did not see this part.
And yes, we use ON_THE_FLY_COMPRESSION. If we send the data without compression there are no problems.

Thanks,
Andreas


Top
 Profile  
 
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: Baidu [Spider], Bing [Bot] 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