Search found 14 matches
- Mon, 2006-03-20, 14:30
- Forum: DCMTK - General
- Topic: VR for dictionary entries for offsets
- Replies: 4
- Views: 5367
- Fri, 2006-03-17, 18:11
- Forum: DCMTK - General
- Topic: access to the pixeldata and its pixel sizes etc
- Replies: 4
- Views: 4877
- Fri, 2006-03-17, 16:53
- Forum: DCMTK - General
- Topic: access to the pixeldata and its pixel sizes etc
- Replies: 4
- Views: 4877
- Fri, 2006-03-17, 13:58
- Forum: Other DICOM Tools
- Topic: code for making volumes from gated CT or PET?
- Replies: 1
- Views: 8285
code for making volumes from gated CT or PET?
Hi
I've seen lots of posts on gettin gvolumes out of DICOM slices and replies mentioning on how to do this, refering to comp.protocols.dicom.
Reading all this I get very depressed.
Anyone knows if any code on top of DCMTK (ideally with a license similar to DCMTK) that I can use?
Kris Thielemans
I've seen lots of posts on gettin gvolumes out of DICOM slices and replies mentioning on how to do this, refering to comp.protocols.dicom.
Reading all this I get very depressed.
Anyone knows if any code on top of DCMTK (ideally with a license similar to DCMTK) that I can use?
Kris Thielemans
- Fri, 2006-03-17, 13:55
- Forum: DCMTK - General
- Topic: access to the pixeldata and its pixel sizes etc
- Replies: 4
- Views: 4877
access to the pixeldata and its pixel sizes etc
Hi I need to read CT images in Hounsfield units. From all the posts on this lists, I figured out that my easiest option would be to use DicomImage("filename") and then getInterData. That works, but I don't have access anymore to the dicom fields such as PixelHeight (and lots of others real...
- Thu, 2006-03-16, 14:08
- Forum: DCMTK - General
- Topic: dcmmkdir and non-standard filenames
- Replies: 1
- Views: 3012
dcmmkdir and non-standard filenames
Hi I've received a bunch of DICOM files with names like i478992.CTDC.64.img. dcmmkdir refuses to read any of these. Looking at this forum I found out that this is because the DICOM Standard only allows 8 char filenames with all uppercase letters etc. After renaming files to i478992 etc, I could make...
- Thu, 2006-03-16, 13:20
- Forum: DCMTK - General
- Topic: VR for dictionary entries for offsets
- Replies: 4
- Views: 5367
Yes, I could load both dictionaries (making sure I first cut out the 'standard' part of the GE dictionary).Thanks. However, I was wondering if it wouldn't be better for DCMTK to be able to use a standard DICOM dictionary as opposed to having its own tweaks. Up to you of course. Thanks a lot for all ...
- Thu, 2006-03-16, 12:21
- Forum: DCMTK - General
- Topic: VR for dictionary entries for offsets
- Replies: 4
- Views: 5367
VR for dictionary entries for offsets
Hi I notice that in dcmdata/libsrc/dicom.doc you use up as VR for the offsets, e.g. (0004,1400) up OffsetOfTheNextDirectoryRecord 1 dicom98 This seems in conflict with the standard (see http://medical.nema.org/dicom/2004/04_06PU.PDF p.81) which uses UL . I stumbled on this because I am using a dicom...
- Thu, 2006-03-16, 12:05
- Forum: DCMTK - General
- Topic: DcmSequenceOfItems: Parse error in sequence on GE CT files
- Replies: 6
- Views: 8937
ok. I see that now (p.40 of http://medical.nema.org/dicom/2004/04_05PU.PDF ): There are three special SQ related Data Elements that are not ruled by the VR encoding rules conveyed by the Transfer Syntax. They shall be encoded as Implicit VR. These special Data Elements are Item (FFFE,E000), Item Del...
- Thu, 2006-03-16, 11:48
- Forum: DCMTK - General
- Topic: small bug in DcmDicomDir::resolveAllOffsets ?
- Replies: 3
- Views: 4138
- Tue, 2006-03-14, 02:54
- Forum: DCMTK - General
- Topic: small bug in DcmDicomDir::resolveAllOffsets ?
- Replies: 3
- Views: 4138
small bug in DcmDicomDir::resolveAllOffsets ?
Hi I had some problems with a DICOMDIR file so had to do some debugging. I came across the following code (dcmtk 3.5.4) in DcmDicomDir::resolveAllOffsets (dcdicdir.cc line 353) for (unsigned long i = 0; i < maxitems; i++ ) { DcmDirectoryRecord *rec; rec = OFstatic_cast(DcmDirectoryRecord *, localDir...
- Fri, 2006-03-10, 17:48
- Forum: DCMTK - General
- Topic: DcmSequenceOfItems: Parse error in sequence on GE CT files
- Replies: 6
- Views: 8937
I found out that my problem is related to the DICOM dictionary that I'm using. If I use dcmtk's dicom.dic everything is fine. The relevant difference between the 2 dictionaries is OFFIS dictionary (FFFE,E000) na Item 1 (FFFE,E00D) na ItemDelimitationItem 1 (FFFE,E0DD) na SequenceDelimitationItem 1 m...
- Fri, 2006-03-10, 15:45
- Forum: DCMTK - General
- Topic: DcmSequenceOfItems: Parse error in sequence on GE CT files
- Replies: 6
- Views: 8937
thanks for the suggestion. That gives me .... (0008,1090) LO [Discovery STE] # 14, 1 ManufacturersModelName (0008,1110) SQ (Sequence with undefined length #=0) # u/l, 1 ReferencedStudySequence (fffe,e0dd) UN (SequenceDelimitationItem) # 0, 0 SequenceDelimitationItem and dcmdump then exits (there's s...
- Fri, 2006-03-10, 01:52
- Forum: DCMTK - General
- Topic: DcmSequenceOfItems: Parse error in sequence on GE CT files
- Replies: 6
- Views: 8937
DcmSequenceOfItems: Parse error in sequence on GE CT files
Hi I'm trying to read some CT images from a GE Discovery STE. I managed to read them successfully in Analyze (from the Mayo) and matlab, but dcmdump exists after DcmSequenceOfItems: Parse error in sequence, found (fffe,e000) instead of a sequence delimiter from the dictionary (FFFE,E000) UN Item 1 (...