I tried your code. For what it's worth: it works fine on my system.
Judging from your output it seems the DICOM dictionary has not been loaded. I do not know if this could be the problem though.
Search found 12 matches
- Wed, 2009-08-26, 13:53
- Forum: DCMTK - General
- Topic: reading DICOMDIR
- Replies: 7
- Views: 11243
- Wed, 2009-08-26, 10:26
- Forum: DCMTK - General
- Topic: reading DICOMDIR
- Replies: 7
- Views: 11243
- Fri, 2007-08-31, 14:21
- Forum: DCMTK - General
- Topic: detemine attribute level
- Replies: 1
- Views: 3491
detemine attribute level
I am adding some Q/R functionality to my software and I would like to write a function that checks and corrects the C-FIND request before sending it out. To do this correctly this function needs to know at which level (patient, study, series or composite object instance level) each attribute is defi...
- Fri, 2007-08-31, 13:38
- Forum: DCMTK - General
- Topic: Querying a PACS
- Replies: 12
- Views: 19167
It seems your PACS thinks it did actually sent you something, so you could check the following things: - Are you actually waiting for DICOM messages (image?) at the port number that is specified for JCKOSIOR in the PACS (just to make sure you don't think you should be listening at the port you speci...
- Fri, 2006-06-23, 15:31
- Forum: DCMTK - General
- Topic: Some questions about DICOM-UIDs & Connection Titles
- Replies: 1
- Views: 2923
Hello Juan, #1. The Unique IDentifier for a DICOM image you should be using is the SOP Instance UID (0008,0018). It is mandatory and unique for all DICOM images. #2. Very often a medical system only accepts communications with known other systems. Therefore the other systems will have to be configur...
- Fri, 2006-06-23, 13:51
- Forum: DCMTK - General
- Topic: bug in DcmPixelData::hasRepresentation ?
- Replies: 1
- Views: 2846
bug in DcmPixelData::hasRepresentation ?
I had some unexpected behaviour of my software which may be caused by a bug in DcmPixelData::hasRepresentation: DcmPixelData::hasRepresentation checks if an appropriate representation of the pixel data is available. However, since DcmPixelData::findConformingEncapsulatedRepresentation returns either...
- Fri, 2006-01-20, 12:51
- Forum: DCMTK - General
- Topic: change of data type for LUTData with dcmtk v3.5.4
- Replies: 2
- Views: 3735
- Mon, 2006-01-16, 15:52
- Forum: DCMTK - General
- Topic: change of data type for LUTData with dcmtk v3.5.4
- Replies: 2
- Views: 3735
change of data type for LUTData with dcmtk v3.5.4
Some time ago I wrote a program to insert a VOI LUT into a DICOM image using the DCMTK v3.5.3 libraries. After upgrading to DCMTK 3.5.4 I noticed that the data type for my LUT Data (0028,3006) has changed from "OW" to "UN" (unknown). This appears to be caused by a change in dicom...
- Wed, 2005-05-25, 12:27
- Forum: DCMTK - General
- Topic: JPEG2000LossLessOnly Transfer Syntax with native Icon Image
- Replies: 4
- Views: 7602
- Mon, 2005-05-23, 10:46
- Forum: DCMTK - General
- Topic: JPEG2000LossLessOnly Transfer Syntax with native Icon Image
- Replies: 4
- Views: 7602
Adding a function to enable the user to set or unset the isIconImage mark would indeed solve my problem, but I think it is an (ugly) work-around. Personally, I would prefer having all (and only) Icon Images marked with isIconImage , and maybe private elements with isPrivate . This would be clearer a...
- Thu, 2005-05-19, 17:00
- Forum: DCMTK - General
- Topic: JPEG2000LossLessOnly Transfer Syntax with native Icon Image
- Replies: 4
- Views: 7602
JPEG2000LossLessOnly Transfer Syntax with native Icon Image
I have written a program for JPEG2000 compression of DICOM files, but it does not work when an icon image is present. I chose not to compress the icon image, because it is not required by the DICOM standard (PS 3.5-2004, page 63: "Pixel Data within an Icon Image Sequence may or may not be compr...
- Thu, 2005-04-21, 15:40
- Forum: DCMTK - General
- Topic: Lossless JPEG compression not lossless for 14 bit images?
- Replies: 3
- Views: 6512
Lossless JPEG compression not lossless for 14 bit images?
One of my colleagues recently discovered that the 14 bpp images we have been compressing using dcmcjpeg, are not compressed completely lossless. The images are in fact being scaled to 16 bpp prior to compression (using a gain and an offset), hereby changing the pixel values irreversibly. While check...