gdcm-developers Mailing List for Grassroots DICOM
Cross-platform DICOM implementation
Brought to you by:
malat
Menu
▾
▴
gdcm-developers — gdcm users mailing list
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(4) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(14) |
Feb
(4) |
Mar
(4) |
Apr
|
May
|
Jun
(1) |
Jul
(6) |
Aug
(5) |
Sep
|
Oct
|
Nov
(3) |
Dec
|
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(2) |
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2008 |
Jan
|
Feb
(18) |
Mar
(52) |
Apr
(40) |
May
(73) |
Jun
(74) |
Jul
(69) |
Aug
(93) |
Sep
(73) |
Oct
(142) |
Nov
(127) |
Dec
(90) |
| 2009 |
Jan
(46) |
Feb
(77) |
Mar
(29) |
Apr
(48) |
May
(63) |
Jun
(59) |
Jul
(60) |
Aug
(76) |
Sep
(66) |
Oct
(97) |
Nov
(162) |
Dec
(175) |
| 2010 |
Jan
(66) |
Feb
(75) |
Mar
(73) |
Apr
(88) |
May
(66) |
Jun
(97) |
Jul
(86) |
Aug
(78) |
Sep
(82) |
Oct
(95) |
Nov
(33) |
Dec
(82) |
| 2011 |
Jan
(150) |
Feb
(140) |
Mar
(187) |
Apr
(46) |
May
(41) |
Jun
(113) |
Jul
(104) |
Aug
(42) |
Sep
(59) |
Oct
(30) |
Nov
(39) |
Dec
(27) |
| 2012 |
Jan
(83) |
Feb
(22) |
Mar
(67) |
Apr
(56) |
May
(77) |
Jun
(69) |
Jul
(65) |
Aug
(28) |
Sep
(63) |
Oct
(33) |
Nov
(31) |
Dec
(16) |
| 2013 |
Jan
(20) |
Feb
(26) |
Mar
(60) |
Apr
(16) |
May
(12) |
Jun
(17) |
Jul
(29) |
Aug
(47) |
Sep
(18) |
Oct
(30) |
Nov
(45) |
Dec
(35) |
| 2014 |
Jan
(13) |
Feb
(9) |
Mar
(27) |
Apr
(29) |
May
(33) |
Jun
(14) |
Jul
(38) |
Aug
(3) |
Sep
(6) |
Oct
(25) |
Nov
(20) |
Dec
(4) |
| 2015 |
Jan
(11) |
Feb
(24) |
Mar
(11) |
Apr
(13) |
May
(4) |
Jun
(6) |
Jul
(1) |
Aug
(20) |
Sep
(12) |
Oct
(32) |
Nov
(29) |
Dec
(32) |
| 2016 |
Jan
(21) |
Feb
(28) |
Mar
(12) |
Apr
(3) |
May
(7) |
Jun
(14) |
Jul
(10) |
Aug
(16) |
Sep
(9) |
Oct
(15) |
Nov
(8) |
Dec
(7) |
| 2017 |
Jan
(13) |
Feb
(18) |
Mar
(12) |
Apr
(17) |
May
(4) |
Jun
(18) |
Jul
(30) |
Aug
(17) |
Sep
(9) |
Oct
(8) |
Nov
(3) |
Dec
(5) |
| 2018 |
Jan
(6) |
Feb
(9) |
Mar
(4) |
Apr
(6) |
May
|
Jun
(7) |
Jul
(2) |
Aug
(15) |
Sep
(2) |
Oct
|
Nov
(4) |
Dec
|
| 2019 |
Jan
(8) |
Feb
(10) |
Mar
(1) |
Apr
(5) |
May
(24) |
Jun
(2) |
Jul
|
Aug
(3) |
Sep
(7) |
Oct
(6) |
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
(3) |
Mar
(1) |
Apr
(5) |
May
(5) |
Jun
(10) |
Jul
|
Aug
(4) |
Sep
|
Oct
|
Nov
(3) |
Dec
|
| 2021 |
Jan
(1) |
Feb
(1) |
Mar
(1) |
Apr
(1) |
May
|
Jun
|
Jul
(2) |
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2022 |
Jan
(14) |
Feb
(1) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(12) |
Dec
(4) |
| 2023 |
Jan
|
Feb
(1) |
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
(1) |
Mar
|
Apr
(1) |
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2025 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2026 |
Jan
(8) |
Feb
(1) |
Mar
(4) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Mathieu M. <mat...@gm...> - 2026-03-12 19:48:36
|
Axel, Can you post your exact issue here (not a full log): * https://github.com/malaterre/GDCM/pull/207 thanks Le jeu. 12 mars 2026 à 08:41, Axel Braun <axe...@gm...> a écrit : > > Hi, > > any updates here? > I compiled the latest git, but it runs into a similar error as well: > > https://build.opensuse.org/package/live_build_log/home:DocB:Orthanc/gdcm/openSUSE_Tumbleweed/x86_64 > > Cheers > Axel > > Am Montag, 2. März 2026, 14:21:01 Mitteleuropäische Normalzeit schrieb Mathieu Malaterre: > > Hi > > > > Latest 3.2.x should work. Please check github until I upload to st.net. > > thanks > > > > Mathieu > > > > Le lun. 2 mars 2026, 13:12, Axel Braun via Gdcm-developers < > > gdc...@li...> a écrit : > > > > > Hi, > > > > > > just a pointer to [bugs:#578] https://sourceforge.net/p/gdcm/bugs/578/ > > > with the error messages coming up when compiling gdcm against latest > > > poppler. > > > A fix is much appreciated > > > > > > BTW, is there a plan to release 3.0.26 any time soon? > > > > > > Cheers > > > Axel > > > > > > > > > > > > > > > _______________________________________________ > > > Gdcm-developers mailing list > > > Gdc...@li... > > > https://lists.sourceforge.net/lists/listinfo/gdcm-developers > > > > > > > > -- > Dr.-Ing. Axel K. Braun > M: +49.173.7003.154 > T: @coogor > Matrix/Elements: @docb:matrix.org > PGP Fingerprint: 2E7F 3A19 A4A4 844A 3D09 7656 822D EB64 A3BA 290D > Public Key available at http://www.axxite.com/axe...@gm... > > Personal Freedom starts with free/libre Software > ThinkPad P1 Gen 7 running openSUSE Tumbleweed 20260224 > > > -- Mathieu |
|
From: Axel B. <axe...@gm...> - 2026-03-12 07:41:57
|
Hi, any updates here? I compiled the latest git, but it runs into a similar error as well: https://build.opensuse.org/package/live_build_log/home:DocB:Orthanc/gdcm/openSUSE_Tumbleweed/x86_64 Cheers Axel Am Montag, 2. März 2026, 14:21:01 Mitteleuropäische Normalzeit schrieb Mathieu Malaterre: > Hi > > Latest 3.2.x should work. Please check github until I upload to st.net. > thanks > > Mathieu > > Le lun. 2 mars 2026, 13:12, Axel Braun via Gdcm-developers < > gdc...@li...> a écrit : > > > Hi, > > > > just a pointer to [bugs:#578] https://sourceforge.net/p/gdcm/bugs/578/ > > with the error messages coming up when compiling gdcm against latest > > poppler. > > A fix is much appreciated > > > > BTW, is there a plan to release 3.0.26 any time soon? > > > > Cheers > > Axel > > > > > > > > > > _______________________________________________ > > Gdcm-developers mailing list > > Gdc...@li... > > https://lists.sourceforge.net/lists/listinfo/gdcm-developers > > > -- Dr.-Ing. Axel K. Braun M: +49.173.7003.154 T: @coogor Matrix/Elements: @docb:matrix.org PGP Fingerprint: 2E7F 3A19 A4A4 844A 3D09 7656 822D EB64 A3BA 290D Public Key available at http://www.axxite.com/axe...@gm... Personal Freedom starts with free/libre Software ThinkPad P1 Gen 7 running openSUSE Tumbleweed 20260224 |
|
From: Mathieu M. <mat...@gm...> - 2026-03-02 13:21:24
|
Hi Latest 3.2.x should work. Please check github until I upload to st.net. thanks Mathieu Le lun. 2 mars 2026, 13:12, Axel Braun via Gdcm-developers < gdc...@li...> a écrit : > Hi, > > just a pointer to [bugs:#578] https://sourceforge.net/p/gdcm/bugs/578/ > with the error messages coming up when compiling gdcm against latest > poppler. > A fix is much appreciated > > BTW, is there a plan to release 3.0.26 any time soon? > > Cheers > Axel > > > > > _______________________________________________ > Gdcm-developers mailing list > Gdc...@li... > https://lists.sourceforge.net/lists/listinfo/gdcm-developers > |
|
From: Axel B. <axe...@gm...> - 2026-03-02 12:11:59
|
Hi, just a pointer to [bugs:#578] https://sourceforge.net/p/gdcm/bugs/578/ with the error messages coming up when compiling gdcm against latest poppler. A fix is much appreciated BTW, is there a plan to release 3.0.26 any time soon? Cheers Axel |
|
From: Emmanuel A. <ea...@de...> - 2026-02-17 18:55:29
|
Hi!
Sorry for bother you again.
I saw your bugs created in SourceForge. Do you have an estimate when a
patch will be avaiable?
Thanks!
Quoting Pierre Le Duff (2026-01-07 13:22:28)
> In cybersecurity, it is difficult to provide an example, as it could
> be used to exploit a vulnerability.
> For now, I have built a few samples for one CVE.
> Pierre
>
> Le mer. 7 janv. 2026 à 16:32, Sean McBride <se...@ro...> a écrit :
> >
> > On 7 Jan 2026, at 3:42, Pierre Le Duff wrote:
> >
> > > I will enter the CVEs in the SourceForge bug tracker. I will
> > > investigate them and, if possible, propose a merge request to resolve
> > > the issues.
> >
> > Investigating them would of course be easier with the DICOM files that trigger the crashes. Does no one have access to those files?
cheers,
Emmanuel Arias
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ ea...@de...
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: 13796755BBC72BB8ABE2AEB5 FA9DEC5DE11C63F1
⠈⠳⣄
|
|
From: Pierre Le D. <pie...@gm...> - 2026-01-07 16:22:48
|
In cybersecurity, it is difficult to provide an example, as it could be used to exploit a vulnerability. For now, I have built a few samples for one CVE. Pierre Le mer. 7 janv. 2026 à 16:32, Sean McBride <se...@ro...> a écrit : > > On 7 Jan 2026, at 3:42, Pierre Le Duff wrote: > > > I will enter the CVEs in the SourceForge bug tracker. I will > > investigate them and, if possible, propose a merge request to resolve > > the issues. > > Investigating them would of course be easier with the DICOM files that trigger the crashes. Does no one have access to those files? |
|
From: Sean M. <se...@ro...> - 2026-01-07 15:33:05
|
On 7 Jan 2026, at 3:42, Pierre Le Duff wrote: > I will enter the CVEs in the SourceForge bug tracker. I will > investigate them and, if possible, propose a merge request to resolve > the issues. Investigating them would of course be easier with the DICOM files that trigger the crashes. Does no one have access to those files? |
|
From: Emmanuel A. <ea...@de...> - 2026-01-07 15:29:45
|
Hi, Quoting Pierre Le Duff (2026-01-07 05:42:19) > Hi, > I will enter the CVEs in the SourceForge bug tracker. I will > investigate them and, if possible, propose a merge request to resolve > the issues. Thanks! > > Pierre > > Le dim. 4 janv. 2026 à 19:07, Sean McBride <se...@ro...> a écrit : > > > > On 4 Jan 2026, at 6:26, Emmanuel Arias wrote: > > > > Seems vuln reports are here: > > > > https://talosintelligence.com/vulnerability_reports/TALOS-2025-2210 (CVE-2025-53619,CVE-2025-53618) > > https://talosintelligence.com/vulnerability_reports/TALOS-2025-2211 (CVE-2025-52582) > > https://talosintelligence.com/vulnerability_reports/TALOS-2025-2214 (CVE-2025-48429) > > > > They are very long and wordy, but I read one, and I still don't see any repro steps. I also don't see any example DICOM files to repro with. Sean, sorry for dont reply you before. I wanted to review them in depth but I didn't have time. > > > > Sean > > > > _______________________________________________ > > Gdcm-developers mailing list > > Gdc...@li... > > https://lists.sourceforge.net/lists/listinfo/gdcm-developers cheers, Emmanuel Arias ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ ea...@de... ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: 13796755BBC72BB8ABE2AEB5 FA9DEC5DE11C63F1 ⠈⠳⣄ |
|
From: Pierre Le D. <pie...@gm...> - 2026-01-07 08:42:45
|
Hi, I will enter the CVEs in the SourceForge bug tracker. I will investigate them and, if possible, propose a merge request to resolve the issues. Pierre Le dim. 4 janv. 2026 à 19:07, Sean McBride <se...@ro...> a écrit : > > On 4 Jan 2026, at 6:26, Emmanuel Arias wrote: > > Seems vuln reports are here: > > https://talosintelligence.com/vulnerability_reports/TALOS-2025-2210 (CVE-2025-53619,CVE-2025-53618) > https://talosintelligence.com/vulnerability_reports/TALOS-2025-2211 (CVE-2025-52582) > https://talosintelligence.com/vulnerability_reports/TALOS-2025-2214 (CVE-2025-48429) > > They are very long and wordy, but I read one, and I still don't see any repro steps. I also don't see any example DICOM files to repro with. > > Sean > > _______________________________________________ > Gdcm-developers mailing list > Gdc...@li... > https://lists.sourceforge.net/lists/listinfo/gdcm-developers |
|
From: Sean M. <se...@ro...> - 2026-01-04 18:06:06
|
On 4 Jan 2026, at 6:26, Emmanuel Arias wrote: > Seems vuln reports are here: > > * https://talosintelligence.com/vulnerability_reports/TALOS-2025-2210 > (CVE-2025-53619,CVE-2025-53618) > * https://talosintelligence.com/vulnerability_reports/TALOS-2025-2211 > (CVE-2025-52582) > * https://talosintelligence.com/vulnerability_reports/TALOS-2025-2214 > (CVE-2025-48429) They are very long and wordy, but I read one, and I still don't see any repro steps. I also don't see any example DICOM files to repro with. Sean |
|
From: Emmanuel A. <ea...@de...> - 2026-01-04 11:27:10
|
Hi! Quoting Sean McBride (2026-01-03 22:32:35) > Were these filed in the bug tracker? I don't see "cve" when searching: > > https://sourceforge.net/p/gdcm/bugs/search/?q=cve > > Looking at the link you gave, I see some details, but no actual repro > steps. Seems vuln reports are here: * https://talosintelligence.com/vulnerability_reports/TALOS-2025-2210 (CVE-2025-53619,CVE-2025-53618) * https://talosintelligence.com/vulnerability_reports/TALOS-2025-2211 (CVE-2025-52582) * https://talosintelligence.com/vulnerability_reports/TALOS-2025-2214 (CVE-2025-48429) > > On 3 Jan 2026, at 17:33, Emmanuel Arias wrote: > > Hello gdcm developers, > > Happy New Year! > > I'm Emmanuel Arias (eamanu). With the Debian LTS team[0] hat, I'm > working in > gdcm[1] and I'd like to ask if you have some plan to fix the next CVE-*: > > CVE-2025-53619 > CVE-2025-53618 > CVE-2025-52582 > CVE-2025-48429 > > In anycase, I will try to make a patch, but I'm not sure if I will can. > So, > that's why I'm asking you :-) > > I hope we can continue in contact. > > Thanks! > > [0] https://www.debian.org/lts/ > [1] https://security-tracker.debian.org/tracker/source-package/gdcm > > -- > cheers, > Emmanuel Arias > > ⢀⣴⠾⠻⢶⣦⠀ > ⣾⠁⢠⠒⠀⣿⡁ ea...@de... > ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: 13796755BBC72BB8ABE2AEB5 FA9DEC5DE11C63F1 > ⠈⠳⣄ > > ---------------------------------------------------------------------- > > Gdcm-developers mailing list > Gdc...@li... > https://lists.sourceforge.net/lists/listinfo/gdcm-developers cheers, Emmanuel Arias ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ ea...@de... ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: 13796755BBC72BB8ABE2AEB5 FA9DEC5DE11C63F1 ⠈⠳⣄ |
|
From: Sean M. <se...@ro...> - 2026-01-04 01:50:42
|
Were these filed in the bug tracker? I don't see "cve" when searching: https://sourceforge.net/p/gdcm/bugs/search/?q=cve Looking at the link you gave, I see some details, but no actual repro steps. On 3 Jan 2026, at 17:33, Emmanuel Arias wrote: > Hello gdcm developers, > > Happy New Year! > > I'm Emmanuel Arias (eamanu). With the Debian LTS team[0] hat, I'm > working in > gdcm[1] and I'd like to ask if you have some plan to fix the next > CVE-*: > > CVE-2025-53619 > CVE-2025-53618 > CVE-2025-52582 > CVE-2025-48429 > > In anycase, I will try to make a patch, but I'm not sure if I will > can. So, > that's why I'm asking you :-) > > I hope we can continue in contact. > > Thanks! > > [0] https://www.debian.org/lts/ > [1] https://security-tracker.debian.org/tracker/source-package/gdcm > > -- > cheers, > Emmanuel Arias > > ⢀⣴⠾⠻⢶⣦⠀ > ⣾⠁⢠⠒⠀⣿⡁ ea...@de... > ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: 13796755BBC72BB8ABE2AEB5 > FA9DEC5DE11C63F1 > ⠈⠳⣄ > > > _______________________________________________ > Gdcm-developers mailing list > Gdc...@li... > https://lists.sourceforge.net/lists/listinfo/gdcm-developers |
|
From: Emmanuel A. <ea...@de...> - 2026-01-03 22:34:23
|
Hello gdcm developers, Happy New Year! I'm Emmanuel Arias (eamanu). With the Debian LTS team[0] hat, I'm working in gdcm[1] and I'd like to ask if you have some plan to fix the next CVE-*: CVE-2025-53619 CVE-2025-53618 CVE-2025-52582 CVE-2025-48429 In anycase, I will try to make a patch, but I'm not sure if I will can. So, that's why I'm asking you :-) I hope we can continue in contact. Thanks! [0] https://www.debian.org/lts/ [1] https://security-tracker.debian.org/tracker/source-package/gdcm -- cheers, Emmanuel Arias ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ ea...@de... ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: 13796755BBC72BB8ABE2AEB5 FA9DEC5DE11C63F1 ⠈⠳⣄ |
|
From: Michael L. <mic...@gm...> - 2025-08-26 03:34:48
|
Hi I am planning on using gdmcconv to save some space with a large library of DICOMS, both new and historical data The data is raw/little endian - 50-70% zeroes! After some testing, RLE looks great. I get rid of the zeroes and its fast to convert, and fast to open performance in the viewer. I would like to, after the files grow older, then convert them to JPEG-LS, for a further ~60% saving. This would mean a simple gdcmconv from the RLE file to a JPEG-LS file. Trouble is, the convert took a minute, 3x longer than RAW -> JPEG-LS gdcmconv -L -i RAW.dcm -o JLS.dcm -> 24s gdcmconv -L -i RLE.dcm -o JLS.dcm -> 1m:06s If I test RLE to RAW, it is very slow. gdcmconv -w -i RLE.dcm -o RAW.dcm -> 45s Am I perhaps missing something simple like linux large pages? RAM slower under VBox? The VM is Ubuntu 24, host Win11 The bottleneck, in top, was purely CPU - 100% one core Thanks Michael |
|
From: qbisi <qbi...@gm...> - 2025-06-20 12:08:43
|
Implcit conversion of vtkStdString to const char* has been deprecated
since vtk-9.3.0 and removed since vtk-9.5.0.
Signed-off-by: qbisi <qbi...@gm...>
---
Utilities/VTK/Applications/gdcm2vtk.cxx | 2 +-
Utilities/VTK/Applications/gdcmviewer.cxx | 2 +-
Utilities/VTK/Testing/Cxx/TestvtkGDCMImageWriter2.cxx | 2 +-
.../VTK/Testing/Cxx/TestvtkGDCMThreadedImageReader.cxx | 2 +-
.../VTK/Testing/Cxx/TestvtkGDCMThreadedImageReader2.cxx | 2 +-
Utilities/VTK/vtkGDCMImageReader.cxx | 6 +++---
Utilities/VTK/vtkGDCMImageReader2.cxx | 6 +++---
Utilities/VTK/vtkGDCMImageWriter.cxx | 4 ++--
Utilities/VTK/vtkGDCMThreadedImageReader.cxx | 2 +-
Utilities/VTK/vtkGDCMThreadedImageReader2.cxx | 4 ++--
10 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/Utilities/VTK/Applications/gdcm2vtk.cxx b/Utilities/VTK/Applications/gdcm2vtk.cxx
index 344aec0df..c1cd4b43d 100644
--- a/Utilities/VTK/Applications/gdcm2vtk.cxx
+++ b/Utilities/VTK/Applications/gdcm2vtk.cxx
@@ -498,7 +498,7 @@ int main(int argc, char *argv[])
{
imgreader->SetFileLowerLeft( lowerleft );
if( names->GetNumberOfValues() == 1 )
- imgreader->SetFileName( names->GetValue(0) );
+ imgreader->SetFileName( names->GetValue(0).c_str() );
else
imgreader->SetFileNames(names);
imgreader->Update();
diff --git a/Utilities/VTK/Applications/gdcmviewer.cxx b/Utilities/VTK/Applications/gdcmviewer.cxx
index 3ed4778f8..58236a6a5 100644
--- a/Utilities/VTK/Applications/gdcmviewer.cxx
+++ b/Utilities/VTK/Applications/gdcmviewer.cxx
@@ -321,7 +321,7 @@ void ExecuteViewer(TViewer *viewer, vtkStringArray *filenames)
vtkGDCMImageReader *reader = vtkGDCMImageReader::New();
if( filenames->GetSize() == 1 ) // Backward compatible...
{
- reader->SetFileName( filenames->GetValue(0) );
+ reader->SetFileName( filenames->GetValue(0).c_str() );
}
else
{
diff --git a/Utilities/VTK/Testing/Cxx/TestvtkGDCMImageWriter2.cxx b/Utilities/VTK/Testing/Cxx/TestvtkGDCMImageWriter2.cxx
index fa1d7d895..00d9f3845 100644
--- a/Utilities/VTK/Testing/Cxx/TestvtkGDCMImageWriter2.cxx
+++ b/Utilities/VTK/Testing/Cxx/TestvtkGDCMImageWriter2.cxx
@@ -113,7 +113,7 @@ int TestvtkGDCMImageWrite2(const char *filename, bool verbose = false)
// Need to check we can still read those files back:
for(int file=0; file<filenames->GetNumberOfValues(); ++file)
{
- const char *fname = filenames->GetValue(file);
+ const char *fname = filenames->GetValue(file).c_str();
gdcm::ImageReader r;
//r.SetFileName( gdcmfile.c_str() );
r.SetFileName( fname );
diff --git a/Utilities/VTK/Testing/Cxx/TestvtkGDCMThreadedImageReader.cxx b/Utilities/VTK/Testing/Cxx/TestvtkGDCMThreadedImageReader.cxx
index 8b253ec83..1c83ed417 100644
--- a/Utilities/VTK/Testing/Cxx/TestvtkGDCMThreadedImageReader.cxx
+++ b/Utilities/VTK/Testing/Cxx/TestvtkGDCMThreadedImageReader.cxx
@@ -170,7 +170,7 @@ int TestvtkGDCMThreadedImageRead(const char *filename, bool verbose = false)
assert( sarray->GetNumberOfValues() == (int)nfiles );
reader->SetFileNames( sarray );
sarray->Delete();
- refimage = sarray->GetValue( 0 ); // Ok since sarray is ref count
+ refimage = sarray->GetValue( 0 ).c_str(); // Ok since sarray is ref count
}
else
{
diff --git a/Utilities/VTK/Testing/Cxx/TestvtkGDCMThreadedImageReader2.cxx b/Utilities/VTK/Testing/Cxx/TestvtkGDCMThreadedImageReader2.cxx
index 5151893e8..22dd4fd57 100644
--- a/Utilities/VTK/Testing/Cxx/TestvtkGDCMThreadedImageReader2.cxx
+++ b/Utilities/VTK/Testing/Cxx/TestvtkGDCMThreadedImageReader2.cxx
@@ -160,7 +160,7 @@ int TestvtkGDCMThreadedImageRead2(const char *filename, bool verbose = false)
assert( sarray->GetNumberOfValues() == (int)nfiles );
reader->SetFileNames( sarray );
sarray->Delete();
- refimage = sarray->GetValue( 0 ); // Ok since sarray is ref count
+ refimage = sarray->GetValue( 0 ).c_str(); // Ok since sarray is ref count
}
else
{
diff --git a/Utilities/VTK/vtkGDCMImageReader.cxx b/Utilities/VTK/vtkGDCMImageReader.cxx
index c62034300..463c3879b 100644
--- a/Utilities/VTK/vtkGDCMImageReader.cxx
+++ b/Utilities/VTK/vtkGDCMImageReader.cxx
@@ -608,7 +608,7 @@ ComputePixelTypeFromFiles(const char *inputfilename, vtkStringArray *filenames,
// FIXME a gdcm::Scanner would be much faster here:
for(int i = 0; i < filenames->GetNumberOfValues(); ++i )
{
- const char *filename = filenames->GetValue( i );
+ const char *filename = filenames->GetValue( i ).c_str();
gdcm::ImageReader reader;
reader.SetFileName( filename );
if( !reader.Read() )
@@ -703,7 +703,7 @@ int vtkGDCMImageReader::RequestInformationCompat()
}
else if ( this->FileNames && this->FileNames->GetNumberOfValues() > 0 )
{
- filename = this->FileNames->GetValue( 0 );
+ filename = this->FileNames->GetValue( 0 ).c_str();
}
else
{
@@ -1459,7 +1459,7 @@ int vtkGDCMImageReader::RequestDataCompat()
for(int j = dext[4]; !this->AbortExecute && j <= dext[5]; ++j)
{
assert( j >= 0 && j <= this->FileNames->GetNumberOfValues() );
- const char *filename = this->FileNames->GetValue( j );
+ const char *filename = this->FileNames->GetValue( j ).c_str();
int load = this->LoadSingleFile( filename, pointer, len );
if( !load )
{
diff --git a/Utilities/VTK/vtkGDCMImageReader2.cxx b/Utilities/VTK/vtkGDCMImageReader2.cxx
index 266c1270a..4976f0190 100644
--- a/Utilities/VTK/vtkGDCMImageReader2.cxx
+++ b/Utilities/VTK/vtkGDCMImageReader2.cxx
@@ -388,7 +388,7 @@ ComputePixelTypeFromFiles(const char *inputfilename, vtkStringArray *filenames,
// FIXME a gdcm::Scanner would be much faster here:
for(int i = 0; i < filenames->GetNumberOfValues(); ++i )
{
- const char *filename = filenames->GetValue( i );
+ const char *filename = filenames->GetValue( i ).c_str();
gdcm::ImageReader reader;
reader.SetFileName( filename );
if( !reader.Read() )
@@ -480,7 +480,7 @@ int vtkGDCMImageReader2::RequestInformationCompat()
}
else if ( this->FileNames && this->FileNames->GetNumberOfValues() > 0 )
{
- filename = this->FileNames->GetValue( 0 );
+ filename = this->FileNames->GetValue( 0 ).c_str();
}
else
{
@@ -1177,7 +1177,7 @@ int vtkGDCMImageReader2::RequestDataCompat()
for(int j = outExt[4]; !this->AbortExecute && j <= outExt[5]; ++j)
{
assert( j >= 0 && j <= this->FileNames->GetNumberOfValues() );
- const char *filename = this->FileNames->GetValue( j );
+ const char *filename = this->FileNames->GetValue( j ).c_str();
int load = this->LoadSingleFile( filename, pointer, len );
vtkDebugMacro( "LoadSingleFile: " << filename );
if( !load )
diff --git a/Utilities/VTK/vtkGDCMImageWriter.cxx b/Utilities/VTK/vtkGDCMImageWriter.cxx
index 37e1245a5..e723d15b7 100644
--- a/Utilities/VTK/vtkGDCMImageWriter.cxx
+++ b/Utilities/VTK/vtkGDCMImageWriter.cxx
@@ -255,7 +255,7 @@ int vtkGDCMImageWriter::RequestData(
{
if( this->FileNames->GetNumberOfValues() )
{
- const char *filename = this->FileNames->GetValue(0);
+ const char *filename = this->FileNames->GetValue(0).c_str();
return const_cast<char*>(filename);
}
return this->Superclass::GetFileName();
@@ -1148,7 +1148,7 @@ int vtkGDCMImageWriter::WriteGDCMData(vtkImageData *data, int timeStep)
if( this->FileNames->GetNumberOfValues() )
{
//int n = this->FileNames->GetNumberOfValues();
- filename = this->FileNames->GetValue(k);
+ filename = this->FileNames->GetValue(k).c_str();
}
else
{
diff --git a/Utilities/VTK/vtkGDCMThreadedImageReader.cxx b/Utilities/VTK/vtkGDCMThreadedImageReader.cxx
index d50a3fee2..c531b8854 100644
--- a/Utilities/VTK/vtkGDCMThreadedImageReader.cxx
+++ b/Utilities/VTK/vtkGDCMThreadedImageReader.cxx
@@ -592,7 +592,7 @@ void vtkGDCMThreadedImageReader::RequestDataCompat()
const char **filenames = new const char* [ nfiles ];
for(unsigned int i = 0; i < nfiles; ++i)
{
- filenames[i] = this->FileNames->GetValue( i );
+ filenames[i] = this->FileNames->GetValue( i ).c_str();
//std::cerr << filenames[i] << std::endl;
}
ReadFiles((unsigned int)nfiles, filenames);
diff --git a/Utilities/VTK/vtkGDCMThreadedImageReader2.cxx b/Utilities/VTK/vtkGDCMThreadedImageReader2.cxx
index 2e6a2e932..72ce6453c 100644
--- a/Utilities/VTK/vtkGDCMThreadedImageReader2.cxx
+++ b/Utilities/VTK/vtkGDCMThreadedImageReader2.cxx
@@ -71,7 +71,7 @@ vtkGDCMThreadedImageReader2::~vtkGDCMThreadedImageReader2()
//----------------------------------------------------------------------------
const char *vtkGDCMThreadedImageReader2::GetFileName(int i)
{
- return this->FileNames->GetValue( i );
+ return this->FileNames->GetValue( i ).c_str();
}
//----------------------------------------------------------------------------
@@ -106,7 +106,7 @@ void vtkGDCMThreadedImageReader2Execute(vtkGDCMThreadedImageReader2 *self,
for( int i = outExt[4]; i <= outExt[5] && i < maxfiles; ++i )
{
assert( i < maxfiles );
- const char *filename = self->GetFileNames()->GetValue( i );
+ const char *filename = self->GetFileNames()->GetValue( i ).c_str();
//ReadOneFile( filename );
//outData->GetPointData()->GetScalars()->SetName("GDCMImage");
--
2.49.0
|
|
From: qbisi <qbi...@gm...> - 2025-06-20 12:08:36
|
Signed-off-by: qbisi <qbi...@gm...>
---
.../Cxx/TestTransferSyntax.cxx | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Testing/Source/DataStructureAndEncodingDefinition/Cxx/TestTransferSyntax.cxx b/Testing/Source/DataStructureAndEncodingDefinition/Cxx/TestTransferSyntax.cxx
index 7ad350d13..6f962ce46 100644
--- a/Testing/Source/DataStructureAndEncodingDefinition/Cxx/TestTransferSyntax.cxx
+++ b/Testing/Source/DataStructureAndEncodingDefinition/Cxx/TestTransferSyntax.cxx
@@ -43,6 +43,9 @@ static const int losslylosslessarray[][3] = {
{ 1, 0, 1 }, // MPEG2MainProfileHighLevel
{ 1, 0, 1 }, // MPEG4AVCH264HighProfileLevel4_1
{ 1, 0, 1 }, // MPEG4AVCH264BDcompatibleHighProfileLevel4_1
+ { 0, 1, 1 }, // HTJ2KLossless
+ { 0, 1, 1 }, // HTJ2KRPCLLossless
+ { 1, 0, 1 }, // HTJ2K
};
static int TestTransferSyntaxAll()
--
2.49.0
|
|
From: M A L. <mal...@gm...> - 2025-02-11 17:57:41
|
sorry that should have read: same with python 3.13.2 + python-gdcm==3.0.24.1 On Tue, Feb 11, 2025 at 11:41 AM M A Lewis <mal...@gm...> wrote: > we're seeing the same issue with the latest version of dcm4chee-arc-light. > > python-gdcm>3.0.8.1 will crash the python kernel when cnf.Find() is called > (Study query level with StudyRoot model, python 3.9.21) > same with python 3.13.2 + python-gdcm==3.0.2.1 > > With 3.0.8.1, one does not get a crash, but behavior is incorrect. > If accession is specified in CFind dataset (ex. [R123456]) or wildcard is > used for accession (ex. [R*]), it appears from DCM4CHEE logs that DCM4CHEE > is > finding the correct number of studies, but the association is not closing > until it times out 4-5 minutes later. > 2025-02-11 11:27:08,990 INFO [org.dcm4che3.net.Dimse] > (EE-ManagedExecutorService-default-Thread-6085) DCM4CHEE<-PROMIS(447) << > 1:C-FIND-RSP[pcid=1, status=ff00H > cuid=1.2.840.10008.5.1.4.1.2.2.1 - Study Root Query/Retrieve Information > Model - FIND > tsuid=1.2.840.10008.1.2 - Implicit VR Little Endian] > 2025-02-11 11:27:08,990 INFO [org.dcm4che3.net.Dimse] > (EE-ManagedExecutorService-default-Thread-6085) DCM4CHEE<-PROMIS(447) << > 1:C-FIND-RSP[pcid=1, status=0H > cuid=1.2.840.10008.5.1.4.1.2.2.1 - Study Root Query/Retrieve Information > Model - FIND > tsuid=1.2.840.10008.1.2 - Implicit VR Little Endian] > > > If accession is blank (ex. []), then the cnf.Find() results are partial. > For example, if there are 10 studies in DCM4CHEE, len(results)=5. > Again, DCM4CHEE logs show 10 results for C-FIND query. > In this case, I am wondering if the association is being closed too > quickly. > > On Fri, Apr 28, 2023 at 6:20 AM Mihail Isakov via Gdcm-developers < > gdc...@li...> wrote: > >> Probably the commit could be revisited: >> >> >> https://github.com/malaterre/GDCM/commit/6cec12baf535af5d108dd3b21b378be8882d0505 >> >> >> Regards, >> M >> >> On Thu, Apr 27, 2023 at 9:22 PM Matthew Lewis <ma...@ca...> wrote: >> >>> this is not limited to macOS.... same issue with Ubuntu >>> >>> On Wed, Apr 26, 2023 at 11:30 AM Matthew Lewis <ma...@ca...> wrote: >>> >>>> jupyter notebook development on macOS >>>> talking to Philips iSite clinical PACS (unknown version) >>>> >>>> pip has a bunch of wheels available for python-gdcm >>>> >>>> for a simple query with ascession number, only 3.0.8 and 3.0.8.1 >>>> work..... >>>> all later versions crash the python kernel in jupyter notebook. >>>> at the command line, here is the issue. Has anyone seen this before: >>>> >>>> >>> cnf.CFind(IP_ADDRESS,107,query,results,'FW','QRP') >>>> >>>> libc++abi: terminating with uncaught exception of type gdcm::Exception: >>>> /private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/pip-req-build-ficieuwp/gdcm_src/Source/Common/gdcmException.h:74 >>>> (): >>>> >>>> ProtocolStream as nullptr is invalid >>>> >>>> zsh: abort python >>>> >>> _______________________________________________ >>> Gdcm-developers mailing list >>> Gdc...@li... >>> https://lists.sourceforge.net/lists/listinfo/gdcm-developers >>> >> _______________________________________________ >> Gdcm-developers mailing list >> Gdc...@li... >> https://lists.sourceforge.net/lists/listinfo/gdcm-developers >> > |
|
From: M A L. <mal...@gm...> - 2025-02-11 17:41:48
|
we're seeing the same issue with the latest version of dcm4chee-arc-light. python-gdcm>3.0.8.1 will crash the python kernel when cnf.Find() is called (Study query level with StudyRoot model, python 3.9.21) same with python 3.13.2 + python-gdcm==3.0.2.1 With 3.0.8.1, one does not get a crash, but behavior is incorrect. If accession is specified in CFind dataset (ex. [R123456]) or wildcard is used for accession (ex. [R*]), it appears from DCM4CHEE logs that DCM4CHEE is finding the correct number of studies, but the association is not closing until it times out 4-5 minutes later. 2025-02-11 11:27:08,990 INFO [org.dcm4che3.net.Dimse] (EE-ManagedExecutorService-default-Thread-6085) DCM4CHEE<-PROMIS(447) << 1:C-FIND-RSP[pcid=1, status=ff00H cuid=1.2.840.10008.5.1.4.1.2.2.1 - Study Root Query/Retrieve Information Model - FIND tsuid=1.2.840.10008.1.2 - Implicit VR Little Endian] 2025-02-11 11:27:08,990 INFO [org.dcm4che3.net.Dimse] (EE-ManagedExecutorService-default-Thread-6085) DCM4CHEE<-PROMIS(447) << 1:C-FIND-RSP[pcid=1, status=0H cuid=1.2.840.10008.5.1.4.1.2.2.1 - Study Root Query/Retrieve Information Model - FIND tsuid=1.2.840.10008.1.2 - Implicit VR Little Endian] If accession is blank (ex. []), then the cnf.Find() results are partial. For example, if there are 10 studies in DCM4CHEE, len(results)=5. Again, DCM4CHEE logs show 10 results for C-FIND query. In this case, I am wondering if the association is being closed too quickly. On Fri, Apr 28, 2023 at 6:20 AM Mihail Isakov via Gdcm-developers < gdc...@li...> wrote: > Probably the commit could be revisited: > > > https://github.com/malaterre/GDCM/commit/6cec12baf535af5d108dd3b21b378be8882d0505 > > > Regards, > M > > On Thu, Apr 27, 2023 at 9:22 PM Matthew Lewis <ma...@ca...> wrote: > >> this is not limited to macOS.... same issue with Ubuntu >> >> On Wed, Apr 26, 2023 at 11:30 AM Matthew Lewis <ma...@ca...> wrote: >> >>> jupyter notebook development on macOS >>> talking to Philips iSite clinical PACS (unknown version) >>> >>> pip has a bunch of wheels available for python-gdcm >>> >>> for a simple query with ascession number, only 3.0.8 and 3.0.8.1 >>> work..... >>> all later versions crash the python kernel in jupyter notebook. >>> at the command line, here is the issue. Has anyone seen this before: >>> >>> >>> cnf.CFind(IP_ADDRESS,107,query,results,'FW','QRP') >>> >>> libc++abi: terminating with uncaught exception of type gdcm::Exception: >>> /private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/pip-req-build-ficieuwp/gdcm_src/Source/Common/gdcmException.h:74 >>> (): >>> >>> ProtocolStream as nullptr is invalid >>> >>> zsh: abort python >>> >> _______________________________________________ >> Gdcm-developers mailing list >> Gdc...@li... >> https://lists.sourceforge.net/lists/listinfo/gdcm-developers >> > _______________________________________________ > Gdcm-developers mailing list > Gdc...@li... > https://lists.sourceforge.net/lists/listinfo/gdcm-developers > |
|
From: bokuhei yo (葉 牧. <bok...@ev...> - 2024-10-15 00:42:16
|
Hi, everyone: I’m following up on an existing thread, [Gdcm2] Extract Compressed Frame: https://sourceforge.net/p/gdcm/mailman/message/35606406/ I’m encountering a similar issue. I initially implemented a DICOM read sample application to retrieve a specific JPEG-compressed frame from a large multi-frame DICOM using the gdcm::ImageReader class. However, when I call gdcm::ImageReader::Read(), it loads the entire DICOM file into memory, causing RAM exhaustion. To address this, I switched to using the gdcm::ImageRegionReader to limit memory usage by calculating and clipping the desired frame region. While this method prevents memory overflow, I can only obtain decompressed pixel data. What I need is the original JPEG-compressed frame data, as it needs to be embedded into another application. Is there a way to extract only the compressed frame data without fully loading the image? Please provide some another methods to achieve this if my current approach is incorrect. Thank you in advance! Best Regards, Yo |
|
From: Mathieu M. <mat...@gm...> - 2024-05-31 07:39:44
|
Hi David, On Thu, May 30, 2024 at 6:38 PM David Cooke <cc...@sy...> wrote: > > Hello All - > > I am wondering if there is a recommended/preferred method for reading internationalized strings from a DICOM file. I would *sincerly* suggest using DCMTK in this case. I've been working personally with the DCMTK team to get this part of the standard in shape. If you need a convincing argument for management, point them to current CP-2396. Sorry for the mess, but GDCM is absolutely not ready for internationalization. > I am currently using the StringFilter to get the string, then converting that string to a byte array using Encoding.Default.GetBytes(), then using the proper encoder (proper, meaning the encoder that corresponds to the SpecificCharacterSet, Dicom Element [0x0008,0x0005]) to encode the byte array to the correct string. See example code below (using the latest GDCM 3.0.24) ... > > Is this the preferred method? Using the "Default" Encoding to get the actual byte array seems wrong to me and comes with all kinds of warnings from Microsoft (the default encoding is likely different from computer to computer), but I could not find any other method that returns the correct byte array from the string that is read from the DICOM file ... > > The example DICOM file (SCSX1) is freely available from David Clunies website: https://www.dclunie.com/images/charset/index.html, charsettests.20070405.tar.bz2 > > Thanks for any help/insight anyone can provide! > > David > > static void Main(string[] args) > { > string topFolderPath = @"D:\Projects\CharacterSetTesting\charsettests\"; > string dicomFileName = "SCSX1.dcm"; > string fileToOpen = System.IO.Path.Combine(topFolderPath, dicomFileName); > > Reader reader = new Reader(); > reader.SetFileName(fileToOpen); > bool status = reader.Read(); > if (status) > { > File gdcmFile = reader.GetFile(); > DataSet ds = gdcmFile.GetDataSet(); > StringFilter gdcmFilter = new StringFilter(); > gdcmFilter.SetFile(gdcmFile); > > Tag tag = new Tag((uint)0x00100010); // Patient Name > string ptName = gdcmFilter.ToString(tag); > > byte[] actualValues = new byte[] { 87, 97, 110, 103, 94, 88, 105, 97, 111, 68, 111, 110, 103, 61, 231, 142, 139, 94, 229, 176, 143, 230, 157, 177, 61, 32 }; > char[] charValues = ptName.ToCharArray(); > // this gives incorrect values: { 87, 97, 110, 103, 94, 88, 105, 97, 111, 68, 111, 110, 103, 61, 231, 381, 8249, 94, 229, 176, 143, 230, 157, 177, 61, 32 } > // ^^^ ^^^^ > > byte[] utf8Values = Encoding.UTF8.GetBytes(ptName); > // this gives too many values (36 instead of 26) and incorrect values as well > // { 87, 97, 110, 103, 94, 88, 105, 97, 111, 68, 111, 110, 103, 61, 195, 167, 197, 189, 226, 128, 185, 94, 195, 165, 194, 176, 194, 143, 195, 166, 194, 157, 194, 177, 61, 32 } > // ^^^ ^^^ ^^^ ^^^ ^^^ ^^^ and following => > > byte[] unicodeValues = Encoding.Unicode.GetBytes(ptName); > // this gives too many values (52 instead of 26) and incorrect values as well > //{ 87, 0, 97, 0, 110, 0, 103, 0, 94, 0, 88, 0, 105, 0, 97, 0, 111, 0, 68, 0, 111, 0, 110, 0, 103, 0, 61, 0, 231, 0, 125, 1, 57, 32, 94, 0, 229, 0, 176, 0, 143, 0, 230, 0, 157, 0, 177, 0, 61, 0, 32, 0 } > > //When Specific Character Set is ISO_IR 192, need to do this to get the correct strings: > byte[] correctValues = Encoding.Default.GetBytes(ptName); > string patientName = Encoding.UTF8.GetString(correctValues); > > reader.Dispose(); > } > } > _______________________________________________ > Gdcm-developers mailing list > Gdc...@li... > https://lists.sourceforge.net/lists/listinfo/gdcm-developers -- Mathieu |
|
From: David C. <cc...@sy...> - 2024-05-30 16:38:08
|
Hello All - I am wondering if there is a recommended/preferred method for reading internationalized strings from a DICOM file. I am currently using the StringFilter to get the string, then converting that string to a byte array using Encoding.Default.GetBytes(), then using the proper encoder (proper, meaning the encoder that corresponds to the SpecificCharacterSet, Dicom Element [0x0008,0x0005]) to encode the byte array to the correct string. See example code below (using the latest GDCM 3.0.24) ... Is this the preferred method? Using the "Default" Encoding to get the actual byte array seems wrong to me and comes with all kinds of warnings from Microsoft (the default encoding is likely different from computer to computer), but I could not find any other method that returns the correct byte array from the string that is read from the DICOM file ... The example DICOM file (SCSX1) is freely available from David Clunies website: https://www.dclunie.com/images/charset/index.html , charsettests.20070405.tar.bz2 Thanks for any help/insight anyone can provide! David static void Main(string[] args) { string topFolderPath = @"D:\Projects\CharacterSetTesting\charsettests\"; string dicomFileName = "SCSX1.dcm"; string fileToOpen = System.IO.Path.Combine(topFolderPath, dicomFileName); Reader reader = new Reader(); reader.SetFileName(fileToOpen); bool status = reader.Read(); if (status) { File gdcmFile = reader.GetFile(); DataSet ds = gdcmFile.GetDataSet(); StringFilter gdcmFilter = new StringFilter(); gdcmFilter.SetFile(gdcmFile); Tag tag = new Tag((uint)0x00100010); // Patient Name string ptName = gdcmFilter.ToString(tag); byte[] actualValues = new byte[] { 87, 97, 110, 103, 94, 88, 105, 97, 111, 68, 111, 110, 103, 61, 231, 142, 139, 94, 229, 176, 143, 230, 157, 177, 61, 32 }; char[] charValues = ptName.ToCharArray(); // this gives incorrect values: { 87, 97, 110, 103, 94, 88, 105, 97, 111, 68, 111, 110, 103, 61, 231, 381, 8249, 94, 229, 176, 143, 230, 157, 177, 61, 32 } // ^^^ ^^^^ byte[] utf8Values = Encoding.UTF8.GetBytes(ptName); // this gives too many values (36 instead of 26) and incorrect values as well // { 87, 97, 110, 103, 94, 88, 105, 97, 111, 68, 111, 110, 103, 61, 195, 167, 197, 189, 226, 128, 185, 94, 195, 165, 194, 176, 194, 143, 195, 166, 194, 157, 194, 177, 61, 32 } // ^^^ ^^^ ^^^ ^^^ ^^^ ^^^ and following => byte[] unicodeValues = Encoding.Unicode.GetBytes(ptName); // this gives too many values (52 instead of 26) and incorrect values as well //{ 87, 0, 97, 0, 110, 0, 103, 0, 94, 0, 88, 0, 105, 0, 97, 0, 111, 0, 68, 0, 111, 0, 110, 0, 103, 0, 61, 0, 231, 0, 125, 1, 57, 32, 94, 0, 229, 0, 176, 0, 143, 0, 230, 0, 157, 0, 177, 0, 61, 0, 32, 0 } //When Specific Character Set is ISO_IR 192, need to do this to get the correct strings: byte[] correctValues = Encoding.Default.GetBytes(ptName); string patientName = Encoding.UTF8.GetString(correctValues); reader.Dispose(); } } |
|
From: George z. <geo...@gm...> - 2024-04-15 17:07:13
|
Hello, I am interested in a hand in manners of image slicing for example extracting images from dicom to dicom format. as beginner I think that I can use gdcmimg but it seems that I do not know how it works so maybe someone can advise Best Regards George <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Virus-free.www.avg.com <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> |
|
From: George z. <geo...@gm...> - 2024-02-29 20:44:52
|
Hello, I am interested in learning how to split large dicom files, I want information about segmentation, extracting images, and splitting volumes. Best Regards George |
|
From: Sean M. <se...@ro...> - 2023-10-07 17:43:38
|
Hi all, When building GDCM, it directs you to this URL to get the test files: http://gdcm.sourceforge.net/wiki/index.php/General_questions#What_is_gdcmData_.3F But that URL has not worked for at least the last few days, at least for me. Has it moved? Thanks, Sean |
|
From: Mihail I. <mih...@go...> - 2023-04-28 11:49:09
|
Probably the commit could be revisited: https://github.com/malaterre/GDCM/commit/6cec12baf535af5d108dd3b21b378be8882d0505 Regards, M On Thu, Apr 27, 2023 at 9:22 PM Matthew Lewis <ma...@ca...> wrote: > this is not limited to macOS.... same issue with Ubuntu > > On Wed, Apr 26, 2023 at 11:30 AM Matthew Lewis <ma...@ca...> wrote: > >> jupyter notebook development on macOS >> talking to Philips iSite clinical PACS (unknown version) >> >> pip has a bunch of wheels available for python-gdcm >> >> for a simple query with ascession number, only 3.0.8 and 3.0.8.1 work..... >> all later versions crash the python kernel in jupyter notebook. >> at the command line, here is the issue. Has anyone seen this before: >> >> >>> cnf.CFind(IP_ADDRESS,107,query,results,'FW','QRP') >> >> libc++abi: terminating with uncaught exception of type gdcm::Exception: >> /private/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/pip-req-build-ficieuwp/gdcm_src/Source/Common/gdcmException.h:74 >> (): >> >> ProtocolStream as nullptr is invalid >> >> zsh: abort python >> > _______________________________________________ > Gdcm-developers mailing list > Gdc...@li... > https://lists.sourceforge.net/lists/listinfo/gdcm-developers > |
77 messages has been excluded from this view by a project administrator.
