<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000066">
It does work, both debug and release of gdcminfo and gdcmdump do work.
That means I've got something going on :(<br>
Hopefully just a library problem.<br>
-Greg<br>
<br>
Mathieu Malaterre wrote:
<blockquote
cite="mid:bf0c3b3f0809081138v15e92df4x1c781340d4f973b9@mail.gmail.com"
type="cite">
<pre wrap="">Instead of gdcmdump, try gdcminfo.
gdcminfo on an image will create an imagereader... if this works I
would think the issue is not in gdcm
-M
On Mon, Sep 8, 2008 at 8:07 PM, Greg Book <a class="moz-txt-link-rfc2396E" href="mailto:gbook@gbook.org"><gbook@gbook.org></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Here's the output. It looks like it can read it just fine, and there were no
errors.
C:\gdcm\gdcm-2.0-binaries\bin\release>gdcmdump.exe --verbose
CT-MONO2-16-ankle.dcm
# Dicom-File-Format
# Dicom-Meta-Information-Header
# Used TransferSyntax:
(0002,0000) UL 192 # 4,1 File
Meta Information Group Length
(0002,0001) OB 00\01 # 2,1 File
Meta Information Version
(0002,0002) UI [1.2.840.10008.5.1.4.1.1.7] # 26,1
Media Storage SOP Class UID
(0002,0003) UI [1.2.840.113619.2.1.2411.1031152382.365.1.736169244]
# 50,1 Media Storage SOP Instance UID
(0002,0010) UI [1.2.840.10008.1.2] # 18,1
Transfer Syntax UID
(0002,0012) UI [1.2.840.113619.6.5] # 18,1
Implementation Class UID
(0002,0013) SH [1_2_5 ] # 6,1
Implementation Version Name
(0002,0016) AE [CTN_STORAGE ] # 12,1
SourceApplication Entity Title
# Dicom-Data-Set
# Used TransferSyntax: 1.2.840.10008.1.2
(0008,0000) ?? (UL) 414 # 4,1
GenericGroup Length
(0008,0008) ?? (CS) [DERIVED\SECONDARY\3D] # 20,2-n
Image Type
(0008,0016) ?? (UI) [1.2.840.10008.5.1.4.1.1.7] # 26,1 SOP
Class UID
(0008,0018) ?? (UI) [1.2.840.113619.2.1.2411.1031152382.365.1.736169244] #
50,1 SOP Instance UID
(0008,0020) ?? (DA) [1993.04.30] # 10,1
Study Date
(0008,0021) ?? (DA) [1993.04.30] # 10,1
SeriesDate
(0008,0023) ?? (DA) [1993.04.30] # 10,1
Content Date
(0008,0030) ?? (TM) [11:27:24] # 8,1
Study Time
(0008,0031) ?? (TM) [11:27:24] # 8,1
Series Time
(0008,0033) ?? (TM) [11:27:24] # 8,1
ContentTime
(0008,0060) ?? (CS) [CT] # 2,1
Modality
(0008,0064) ?? (CS) [WSD ] # 4,1
Conversion Type
(0008,0070) ?? (LO) [GE MEDICAL SYSTEMS] # 18,1
Manufacturer
(0008,0080) ?? (LO) [JFK IMAGING CENTER] # 18,1
Institution Name
(0008,0090) ?? (PN) [Anonymized] # 10,1
Referring Physician's Name
(0008,1010) ?? (SH) [CT01OC0 ] # 8,1
StationName
(0008,1030) ?? (LO) [RT ANKLE] # 8,1
Study Description
(0008,1060) ?? (PN) [Anonymized] # 10,1-n
Nameof Physician(s) Reading Study
(0008,1070) ?? (PN) [Anonymized] # 10,1-n
Operators' Name
(0008,1090) ?? (LO) [GENESIS_ZEUS] # 12,1
Manufacturer's Model Name
(0010,0000) ?? (UL) 18 # 4,1
GenericGroup Length
(0010,0010) ?? (PN) [Anonymized] # 10,1
Patient's Name
(0018,0000) ?? (UL) 10 # 4,1
GenericGroup Length
(0018,1020) ?? (LO) [03] # 2,1-n
Software Version(s)
(0020,0000) ?? (UL) 134 # 4,1
GenericGroup Length
(0020,000d) ?? (UI)
[1.2.840.113619.2.1.1.322987881.621.736170080.681] # 48,1 Study
Instance UID
(0020,000e) ?? (UI)
[1.2.840.113619.2.1.2411.1031152382.365.736169244] # 48,1 Series
Instance UID
(0020,0011) ?? (IS) [365 ] # 4,1
Series Number
(0020,0013) ?? (IS) [1 ] # 2,1
Instance Number
(0028,0000) ?? (UL) 168 # 4,1
GenericGroup Length
(0028,0002) ?? (US) 1 # 2,1
Samplesper Pixel
(0028,0004) ?? (CS) [MONOCHROME2 ] # 12,1
Photometric Interpretation
(0028,0010) ?? (US) 512 # 2,1 Rows
(0028,0011) ?? (US) 512 # 2,1
Columns
(0028,0100) ?? (US) 16 # 2,1 Bits
Allocated
(0028,0101) ?? (US) 16 # 2,1 Bits
Stored
(0028,0102) ?? (US) 15 # 2,1 High
Bit
(0028,0103) ?? (US) 1 # 2,1
Pixel Representation
(0028,0106) ?? (US or SS => SS) 0 # 2,1
Smallest Image Pixel Value
(0028,0120) ?? (US or SS => SS) 0 # 2,1
Pixel Padding Value
(0028,1050) ?? (DS) [1024] # 4,1-n
Window Center
(0028,1051) ?? (DS) [4095] # 4,1-n
Window Width
(0028,1052) ?? (DS) [-1024 ] # 6,1
RescaleIntercept
(0028,1053) ?? (DS) [1 ] # 2,1
RescaleSlope
(0028,1054) ?? (LO) [US] # 2,1
RescaleType
(7fe0,0000) ?? (UL) 524296 # 4,1
GenericGroup Length
(7fe0,0010) ?? (OB or OW => OW)
f0\0f\f0\0f\f0\0f\f0\0f\f0\0f\f0\0f\f0\0f\f0\0f\
f0\0f\f0\0f\f0\0f\f0\0f\f0\0f\f0\0f\f0\0f\f0\0f\f0\0f\f0\0f\f0\0f\f0\0f\f0\0f\f0
\0f\f0\0f\f0\0f\f0\0f\f0\0f\f0\0f\f0\0f\f0\0f\f0\0f\f0\0f\f0\0f #
524288,1 Pixel Data
Filename: CT-MONO2-16-ankle.dcm
C:\gdcm\gdcm-2.0-binaries\bin\release>
Mathieu Malaterre wrote:
I am using VC++ 2008 here too :(
Pick a DICOM file from gdcmData and send me the output of gdcmdump
--verbose on your machine.
Thx
On Mon, Sep 8, 2008 at 4:43 PM, Greg Book <a class="moz-txt-link-rfc2396E" href="mailto:gbook@gbook.org"><gbook@gbook.org></a> wrote:
It's actually happening with all dicom files. I tried compiling with
VC++2008, and I got a similar result, but it was a little more specific with
it's error. It seemed to fail on the ImageReader.Read() call.
-Greg
Mathieu Malaterre wrote:
Hi Greg,
The fact that it is working is not a guarantee there is not an
issue. Can your reproduce the problem with multiple DICOM files, or
just one ?
If just one, please send me a copy of it (private email).
Thanks
-Mathieu
On Mon, Sep 8, 2008 at 1:00 AM, Greg Book <a class="moz-txt-link-rfc2396E" href="mailto:gbook@gbook.org"><gbook@gbook.org></a> wrote:
I've successfully built and used gdcm without shared libs, but am having
trouble getting it to work with shared libs on windows. It builds ok and I
can link it ok with my program, but when I run it... it fails when trying to
open a dicom image.
CMake was configured with:
build shared libs: on
build examples: off
build testing: off
build applications: off
documentation: off
use itk: off
use vtk: off
wrap python: off
For VC++ 2005
When running the program in debug, this is the error I get when breaking:
"Unhandled exception at 0x7c91b1fa in MIView.exe: 0xC0000005: Access
violation writing location 0x00000010."
The call stack is as follows:
ntdll.dll!7c91b1fa()
[Frames below may be incorrect and/or missing, no symbols loaded for
ntdll.dll]
msvcp80d.dll!std::basic_filebuf<char,std::char_traits<char>
::_Endwrite() Line 553 + 0x16 bytes C++
msvcp80d.dll!std::basic_ifstream<char,std::char_traits<char> >::close()
Line 700 + 0xb bytes C++
gdcmDSED.dll!10055cbb()
gdcmMSFF.dll!00eb571c()
I'm wondering if the problem is in the gdcmDSED and gdcmMSFF DLLs? It worked
fine when linking regular .lib files, but not for dlls, which is
surprising...
-Greg
_______________________________________________
Dcmlib mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Dcmlib@creatis.insa-lyon.fr">Dcmlib@creatis.insa-lyon.fr</a>
<a class="moz-txt-link-freetext" href="http://www.creatis.insa-lyon.fr/mailman/listinfo/dcmlib">http://www.creatis.insa-lyon.fr/mailman/listinfo/dcmlib</a>
_______________________________________________
Dcmlib mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Dcmlib@creatis.insa-lyon.fr">Dcmlib@creatis.insa-lyon.fr</a>
<a class="moz-txt-link-freetext" href="http://www.creatis.insa-lyon.fr/mailman/listinfo/dcmlib">http://www.creatis.insa-lyon.fr/mailman/listinfo/dcmlib</a>
_______________________________________________
Dcmlib mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Dcmlib@creatis.insa-lyon.fr">Dcmlib@creatis.insa-lyon.fr</a>
<a class="moz-txt-link-freetext" href="http://www.creatis.insa-lyon.fr/mailman/listinfo/dcmlib">http://www.creatis.insa-lyon.fr/mailman/listinfo/dcmlib</a>
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
<br>
</body>
</html>