Hi,
I can't read images coming from a specific camera, sent from PACS to my storescp and then to the application. It does work when I directly send these images from PACS to the application.
I tried to compare the dcmdumps between images that did and didn't went 'correctly' over storescp to my application.
working:
# Dicom-Data-Set
# Used TransferSyntax: JPEG Baseline
(0008,0008) CS [DERIVED\PRIMARY\\0011\GEMSMULTIFRAME\GEMSMGCOUNT1] # 50, 6 ImageType
(0008,0016) UI =UltrasoundMultiframeImageStorage # 28, 1 SOPClassUID
(0008,0018) UI [1.2.336.74746479561284814812455715050514103974759909214] # 56, 1 SOPInstanceUID
not working:
# Dicom-Data-Set
# Used TransferSyntax: JPEG Baseline
(0008,0008) CS [DERIVED\PRIMARY\\0001\GEMSMULTIFRAME\GEMSMGCOUNT1\\GEMSCOMPRESSED] # 66, 8 ImageType
(0008,0016) UI =UltrasoundMultiframeImageStorage # 28, 1 SOPClassUID
(0008,0018) UI [1.2.840.113619.2.98.8527.1254727911.0.1264.512] # 46, 1 SOPInstanceUID
I tried the --prefer-uncompr option but thid din't work...
Regards,
Jan
compressed ultrasound
Moderator: Moderator Team
compressed ultrasound
Last edited by uzleuven on Thu, 2011-02-03, 23:23, edited 2 times in total.
-
- DCMTK Developer
- Posts: 2055
- Joined: Fri, 2004-11-05, 13:47
- Location: Oldenburg, Germany
- Contact:
Hi Jan,
if this is the only difference (ImageType tag) then your application seems to be very picky about what it accepts in that tag and what not. Also I wonder that the SOPInstanceUID is different -- so these are different images you received, not the same one. So I guess there are more differences than the ones you quoted.
However, if the ImageType actually differs, the question is who changed that tag resulting in the non-working version, either storescp or the sender. The sender might differentiate between different receivers and changes attribute encodings accordingly. In this case I would think this is not very probable. Alternatively storescp changes the attribute encoding of ImageType when storing the file to disk. This may be a bug or the transmitted file contains errors. What you can try first is forcing storescp to write the file bit by bit as it comes in by setting option --bit-preserving. Then look at the dump again (hopefully dcmdump is not suffering of the same possible bug as storescp).
Regards,
Michael
if this is the only difference (ImageType tag) then your application seems to be very picky about what it accepts in that tag and what not. Also I wonder that the SOPInstanceUID is different -- so these are different images you received, not the same one. So I guess there are more differences than the ones you quoted.
However, if the ImageType actually differs, the question is who changed that tag resulting in the non-working version, either storescp or the sender. The sender might differentiate between different receivers and changes attribute encodings accordingly. In this case I would think this is not very probable. Alternatively storescp changes the attribute encoding of ImageType when storing the file to disk. This may be a bug or the transmitted file contains errors. What you can try first is forcing storescp to write the file bit by bit as it comes in by setting option --bit-preserving. Then look at the dump again (hopefully dcmdump is not suffering of the same possible bug as storescp).
Regards,
Michael
-
- DCMTK Developer
- Posts: 2055
- Joined: Fri, 2004-11-05, 13:47
- Location: Oldenburg, Germany
- Contact:
Who is online
Users browsing this forum: Baidu [Spider], Google [Bot] and 0 guests