[Dcmlib] building with shared libs
Mathieu Malaterre
mathieu.malaterre at gmail.com
Mon Sep 8 20:38:10 CEST 2008
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 <gbook at gbook.org> wrote:
> 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 <gbook at gbook.org> 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 <gbook at gbook.org> 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
> Dcmlib at creatis.insa-lyon.fr
> http://www.creatis.insa-lyon.fr/mailman/listinfo/dcmlib
>
>
>
>
>
> _______________________________________________
> Dcmlib mailing list
> Dcmlib at creatis.insa-lyon.fr
> http://www.creatis.insa-lyon.fr/mailman/listinfo/dcmlib
>
>
>
>
>
>
> _______________________________________________
> Dcmlib mailing list
> Dcmlib at creatis.insa-lyon.fr
> http://www.creatis.insa-lyon.fr/mailman/listinfo/dcmlib
>
--
Mathieu
More information about the Dcmlib
mailing list