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
|
Sep
|
Oct
|
Nov
|
Dec
|
|
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 > |
|
From: Matthew L. <ma...@ca...> - 2023-04-27 19:21:28
|
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 > |
|
From: Matthew L. <ma...@ca...> - 2023-04-26 16:52:05
|
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 |
|
From: Giacomo P. <gia...@gm...> - 2023-02-27 16:29:48
|
Hi, we are having some issues reading dicom files from a shared file system (NFS) with GDCM. We are using GDCM from Java through JNI wrappers and we observed that sometimes one Java thread can get "stuck" for hours/days waiting for a GDCM method call to return: at gdcm.gdcmJNI.ImageReader_Read (Native Method) at gdcm.ImageReader.Read(ImageReader.java:43) at our.code.ImageOpener.open(ImageOpener.java:123) There is a little chance that the dicom file being read may get overwritten by a different process running in a completely different OS, and we think that the library ends up in an infinite loop when the underlying file handle gets removed. While searching for a possible known GDCM bug, I found this old blog post: https://pvs-studio.com/fr/blog/posts/cpp/0271/ where it points out possible problems in GDCM while reading from file, where the "is.eof()" check is not enough while reading a file. I see that some additional checks have been added in some parts of the code like here: https://github.com/malaterre/GDCM/blob/85fc2b5399ebe340ea977c27225386a613c0b69e/Source/MediaStorageAndFileFormat/gdcmLookupTable.cxx#L463 but I wonder if there are any other parts that can break in case of a file-system problem WHILE reading a file. We are currently using GDCM 2.6.3 and we are trying to update and test the latest version of GDCM. Does anyone have some other tips on what to look for? Thanks |
|
From: Mathieu M. <mat...@gm...> - 2022-12-15 12:10:05
|
On Thu, Dec 15, 2022 at 11:19 AM Axel Braun <axe...@gm...> wrote: > > Am Donnerstag, 15. Dezember 2022, 09:02:50 CET schrieben Sie: > > In the release page, there is only the source code or installation for windows. > > I am using Debian GNU/Linux. > > Then you should complain with Debian - or become the package maintainer in Debian Seems to be present at: * https://tracker.debian.org/pkg/gdcm Are you sure you are using Debian ? |
|
From: Axel B. <axe...@gm...> - 2022-12-15 10:18:38
|
Am Donnerstag, 15. Dezember 2022, 09:02:50 CET schrieben Sie: > In the release page, there is only the source code or installation for windows. > I am using Debian GNU/Linux. Then you should complain with Debian - or become the package maintainer in Debian |
|
From: Axel B. <axe...@gm...> - 2022-12-15 07:46:38
|
Not sure what you are looking for - openSUSE comes with gdcm 3.0.20, which should be the latest version. Maybe complain with $DISTRO? Viele Grüße Axel -- Diese Nachricht wurde von meinem Android-Tablet mit K-9 Mail gesendet. Am 15. Dezember 2022 06:23:35 MEZ schrieb Amikam Snir <ami...@gm...>: >Hey, >Is there any reason we don't release GDCM for Linux anymore? |
|
From: Amikam S. <ami...@gm...> - 2022-12-15 05:24:19
|
Hey, Is there any reason we don't release GDCM for Linux anymore? |
|
From: Mathieu M. <mat...@gm...> - 2022-11-22 07:24:03
|
On Thu, Nov 17, 2022 at 12:11 PM Mikhail Timofeev <mt...@ou...> wrote: > > > OK. Then DCMTK is faster in this case :) > > Thats a pity. I saw the script dcmtk.sh - I guess I could use it to replace the gdcm codecs with dcmtk? I would really like to use the swig bindings of gdcm, but need the best performance I can get 🙂 As pointed out by `perf` this is an issue in gdcm codebase (too much memory allocation), since no other difference in the codec decompression. > > This is odd that you try to benchmark such a lame encoding. > > You mean generally JPEG Lossless? Why do you consider it lame? In my tests the decompression from JPEG Lossless was way faster than JPEG-LS (~50%), while the compression was just slightly slower (20%). Hum. My memory is not that good. I must have remembered the compression ratio benchmarks and mixed it with speed decompression. I am still surprised charls would be slower, can you share your benchmark setup ? > > ________________________________ > From: Mathieu Malaterre <mat...@gm...> > Sent: Tuesday, November 15, 2022 11:16 > To: Mikhail Timofeev <mt...@ou...> > Cc: gdcm-developers <Gdc...@li...> > Subject: Re: [Gdcm2] Decompression speed difference with DCMTK > > On Tue, Nov 15, 2022 at 11:07 AM Mikhail Timofeev <mt...@ou...> wrote: > > > > Hello > > the perf report looks as if indeed memory allocation would be the culprit. But there are also some calls to dcmdjpeg that gdcm seems to skip. For example the "null_convert" or "no_scale". > > On the other side I dont see any non-imaging related big offenders, so I think the dict and xml stuff can be ruled out? > > OK. Then DCMTK is faster in this case :) > > Now you should try a large multiframe JPEG-Lossless to see how it > amortizes in the long run. > > This is odd that you try to benchmark such a lame encoding. Can you > share your use-case (just for curiosity) ? > > Thanks > > > Here are the top 10 lines of dcmtk dcmdjpeg perf report: > > 64,28% dcmdjpeg dcmdjpeg [.] decode_mcus ◆ > > 11,12% dcmdjpeg dcmdjpeg [.] jpeg16_fill_bit_buffer ▒ > > 3,89% dcmdjpeg dcmdjpeg [.] jpeg_undifference1 ▒ > > 2,92% dcmdjpeg dcmdjpeg [.] null_convert ▒ > > 1,57% dcmdjpeg [kernel.vmlinux] [k] copy_user_enhanced_fast_string ▒ > > 1,39% dcmdjpeg libc.so.6 [.] 0x00000000001afbba ▒ > > 0,74% dcmdjpeg [kernel.vmlinux] [k] __add_to_page_cache_locked ▒ > > 0,72% dcmdjpeg dcmdjpeg [.] noscale ▒ > > 0,66% dcmdjpeg [kernel.vmlinux] [k] __get_user_nocheck_1 ▒ > > 0,52% dcmdjpeg libc.so.6 [.] 0x00000000001af28c > > > > and here are top 20 of gdcm: > > > > 44,58% gdcmconv libgdcmjpeg16.so.3.1.0 [.] decode_mcus ◆ > > 7,30% gdcmconv libgdcmjpeg16.so.3.1.0 [.] gdcmjpeg16_jpeg_fill_bit_buffer ▒ > > 2,77% gdcmconv libgdcmjpeg16.so.3.1.0 [.] jpeg_undifference1 ▒ > > 2,54% gdcmconv [kernel.vmlinux] [k] charge_memcg ▒ > > 2,10% gdcmconv [kernel.vmlinux] [k] native_irq_return_iret ▒ > > 2,03% gdcmconv libc.so.6 [.] 0x00000000001afbba ▒ > > 1,90% gdcmconv [kernel.vmlinux] [k] sync_regs ▒ > > 1,49% gdcmconv libc.so.6 [.] 0x00000000001af28c ▒ > > 0,96% gdcmconv [kernel.vmlinux] [k] try_charge_memcg ▒ > > 0,96% gdcmconv libc.so.6 [.] 0x00000000001af613 ▒ > > 0,96% gdcmconv [kernel.vmlinux] [k] copy_user_enhanced_fast_string ▒ > > 0,91% gdcmconv libc.so.6 [.] 0x00000000001af5af ▒ > > 0,89% gdcmconv [kernel.vmlinux] [k] clear_page_erms ▒ > > 0,79% gdcmconv [kernel.vmlinux] [k] do_anonymous_page ▒ > > 0,78% gdcmconv [kernel.vmlinux] [k] rmqueue_bulk ▒ > > 0,74% gdcmconv [kernel.vmlinux] [k] zap_pte_range ▒ > > 0,72% gdcmconv libc.so.6 [.] 0x00000000001af4c5 ▒ > > 0,71% gdcmconv libc.so.6 [.] 0x00000000001af5d7 ▒ > > 0,65% gdcmconv libc.so.6 [.] 0x00000000001af5ff ▒ > > 0,62% gdcmconv libgdcmMSFF.so.3.1.0 [.] gdcm::ImageCodec::DoOverlayCleanup -- Mathieu |
|
From: Mathieu M. <mat...@gm...> - 2022-11-22 07:21:29
|
On Fri, Nov 18, 2022 at 4:24 PM Screaming InDigital <scr...@ho...> wrote: > > >Ok two things. > Thank you for the reply. Apologies for my late response. > > >1. The most obvious fix for jpeg/YBR422 image is simply: > >$ gdcmimg --fill 128 --region 0,100,0,100 -i clip.dcm -o output_neutral_gray.dcm > The whole image still turned to green. So you're basically saying that --fill is never taken into account ? > >2. If you understand what you are doing, I suspect you should really > >consider another implementation as found in pixelmed (*). Search for > >the section which reads as: > >Images encoded in the JPEG baseline (8-bit) Transfer Syntax are > >... > >(*) http://www.dclunie.com/pixelmed/software/webstart/DicomCleanerUsage.html > > I will try that. Thanks again. > > > On Tue, Nov 1, 2022 at 9:51 PM Screaming InDigital > <scr...@ho...> wrote: > > > > Thank you very much. > > > > FYI, the reason that I would prefer to use GDCM over DICOM Toolkit is the ability to erase the banner in the actual image. I can use either GDCM or DICOM Toolkit to remove the identifying information from the DICOM header, but I also need to remove the banner. > > > > This would be extremely helpful with research people that want to keep groups of ultrasound images based on the patient's diagnosis. Once the images are fully anonymized, they can do whatever they want with them. > > > > Given the fact that we have several brands of ultrasound carts, the location of the portion of the banner that needs to be removed varies. We store the ultrasound cart AE title in the database. This can be used to conditionally generate the call to each clip to remove the desired portion, because we know the manufacturer and model of the acquisition cart based on the AE Title. > > ________________________________ > > From: Mathieu Malaterre <mat...@gm...> > > Sent: Tuesday, October 18, 2022 1:45 AM > > To: Screaming InDigital <scr...@ho...> > > Subject: Re: Sample clip for testing with green square issue using gdcmimg > > > > Hi ! > > > > I did see your file, thanks. I'll try to work on it asap. > > > > On Thu, Oct 13, 2022 at 4:43 AM Screaming InDigital > > <scr...@ho...> wrote: > > > > > > Did you discover the reason the clip turns to "green static" when using gdcmimg on the sample clip that I sent? > > > > > > > > -- > > Mathieu > > > > -- > Mathieu -- Mathieu |
|
From: Mathieu M. <mat...@gm...> - 2022-11-22 07:20:06
|
Hi Mikhail No this is not possible right now. Someone would need to implement proper swig wrapping for this feature. On Mon, Nov 21, 2022 at 6:35 PM Mikhail Timofeev <mt...@ou...> wrote: > > Thanks again for responding. Another related question I have is how to acquire the image metadata from the image byte array (when we cannot use ImageHelper.GetDimensionsValue(File)). I think the same problem exists in C# as well, since the relevant values are also hardcoded in this example: > https://github.com/malaterre/GDCM/blob/e501d71938a0889f55885e4401fbfe60a8b7c4bd/Examples/Csharp/DecompressJPEGFile.cs#L58 > Is it possible with current APIs in Java at all? > I think it would be a non-issue, if swig has correctly mapped the StreamImageReader class to java - but it does not, since it cannot map std::istream. > > best regards > Mikhail > > > ________________________________ > From: Mathieu Malaterre <mat...@gm...> > Sent: Thursday, November 10, 2022 08:26 > To: Mikhail Timofeev <mt...@ou...> > Cc: gdc...@li... <gdc...@li...> > Subject: Re: [Gdcm2] Java: pass an image for decompression as byte data > > On Thu, Nov 10, 2022 at 8:23 AM Mathieu Malaterre > <mat...@gm...> wrote: > > > > Hi, > > > > On Wed, Nov 9, 2022 at 7:52 PM Mikhail Timofeev <mt...@ou...> wrote: > > > > > > Hi all, > > > I am trying to create a program similar to the Examples/Java/DecompressImage but with the difference that I would like to read in the file in Java and pass the byte data to gdcm for decompression, ideally avoiding having to copy the data. Anyway here is my naive approach (which does not work): > > > > > > ImageChangeTransferSyntax change = new ImageChangeTransferSyntax(); > > > change.SetTransferSyntax( new TransferSyntax(TransferSyntax.TSType.ImplicitVRLittleEndian) ); > > > > > > byte[] bytes = Files.readAllBytes( Paths.get(file1)); > > > > > > DataElement dataElementIn = new DataElement(); > > > dataElementIn.SetArray( bytes, bytes.length ); > > > Bitmap bitmap = new Bitmap(); > > > > Do not create your own Bitmap, this is a subclass of Object and is not > > well supported in the swig wrapping. > > > > Simply re-use the one from the ImageChangeTransferSyntax, eg: > > > > Bitmap bitmap = change.GetOutput(); > > Meant to say -obviously-: > > Bitmap bitmap = change.GetInput(); > > > > > > > > bitmap.SetDataElement( dataElementIn ); > > > change.SetInput( bitmap ); > > > > > > if( !change.Change() ) > > > { > > > throw new Exception("Could not change: " + file1 ); > > > } > > > Bitmap image = change.GetOutput(); > > > > > > There are multiple issues here I suppose. But the actual error is this one thrown in the very last line: > > > > > > terminate called after throwing an instance of 'std::bad_cast' > > > what(): std::bad_cast > > > > > > Does anybody have any hints how proceed with this? Or maybe even an example of how this should be properly done? > > > Thanks and best regards > > > MT > > > _______________________________________________ > > > Gdcm-developers mailing list > > > Gdc...@li... > > > https://lists.sourceforge.net/lists/listinfo/gdcm-developers > > > > > > > > -- > > Mathieu > > > > -- > Mathieu -- Mathieu |
|
From: Mikhail T. <mt...@ou...> - 2022-11-21 20:11:11
|
Thanks again for responding. Another related question I have is how to acquire the image metadata from the image byte array (when we cannot use ImageHelper.GetDimensionsValue(File)). I think the same problem exists in C# as well, since the relevant values are also hardcoded in this example: https://github.com/malaterre/GDCM/blob/e501d71938a0889f55885e4401fbfe60a8b7c4bd/Examples/Csharp/DecompressJPEGFile.cs#L58 Is it possible with current APIs in Java at all? I think it would be a non-issue, if swig has correctly mapped the StreamImageReader class to java - but it does not, since it cannot map std::istream. best regards Mikhail ________________________________ From: Mathieu Malaterre <mat...@gm...> Sent: Thursday, November 10, 2022 08:26 To: Mikhail Timofeev <mt...@ou...> Cc: gdc...@li... <gdc...@li...> Subject: Re: [Gdcm2] Java: pass an image for decompression as byte data On Thu, Nov 10, 2022 at 8:23 AM Mathieu Malaterre <mat...@gm...> wrote: > > Hi, > > On Wed, Nov 9, 2022 at 7:52 PM Mikhail Timofeev <mt...@ou...> wrote: > > > > Hi all, > > I am trying to create a program similar to the Examples/Java/DecompressImage but with the difference that I would like to read in the file in Java and pass the byte data to gdcm for decompression, ideally avoiding having to copy the data. Anyway here is my naive approach (which does not work): > > > > ImageChangeTransferSyntax change = new ImageChangeTransferSyntax(); > > change.SetTransferSyntax( new TransferSyntax(TransferSyntax.TSType.ImplicitVRLittleEndian) ); > > > > byte[] bytes = Files.readAllBytes( Paths.get(file1)); > > > > DataElement dataElementIn = new DataElement(); > > dataElementIn.SetArray( bytes, bytes.length ); > > Bitmap bitmap = new Bitmap(); > > Do not create your own Bitmap, this is a subclass of Object and is not > well supported in the swig wrapping. > > Simply re-use the one from the ImageChangeTransferSyntax, eg: > > Bitmap bitmap = change.GetOutput(); Meant to say -obviously-: Bitmap bitmap = change.GetInput(); > > > > bitmap.SetDataElement( dataElementIn ); > > change.SetInput( bitmap ); > > > > if( !change.Change() ) > > { > > throw new Exception("Could not change: " + file1 ); > > } > > Bitmap image = change.GetOutput(); > > > > There are multiple issues here I suppose. But the actual error is this one thrown in the very last line: > > > > terminate called after throwing an instance of 'std::bad_cast' > > what(): std::bad_cast > > > > Does anybody have any hints how proceed with this? Or maybe even an example of how this should be properly done? > > Thanks and best regards > > MT > > _______________________________________________ > > Gdcm-developers mailing list > > Gdc...@li... > > https://lists.sourceforge.net/lists/listinfo/gdcm-developers > > > > -- > Mathieu -- Mathieu |
|
From: Mikhail T. <mt...@ou...> - 2022-11-17 11:43:02
|
> OK. Then DCMTK is faster in this case :) Thats a pity. I saw the script dcmtk.sh - I guess I could use it to replace the gdcm codecs with dcmtk? I would really like to use the swig bindings of gdcm, but need the best performance I can get 🙂 > This is odd that you try to benchmark such a lame encoding. You mean generally JPEG Lossless? Why do you consider it lame? In my tests the decompression from JPEG Lossless was way faster than JPEG-LS (~50%), while the compression was just slightly slower (20%). ________________________________ From: Mathieu Malaterre <mat...@gm...> Sent: Tuesday, November 15, 2022 11:16 To: Mikhail Timofeev <mt...@ou...> Cc: gdcm-developers <Gdc...@li...> Subject: Re: [Gdcm2] Decompression speed difference with DCMTK On Tue, Nov 15, 2022 at 11:07 AM Mikhail Timofeev <mt...@ou...> wrote: > > Hello > the perf report looks as if indeed memory allocation would be the culprit. But there are also some calls to dcmdjpeg that gdcm seems to skip. For example the "null_convert" or "no_scale". > On the other side I dont see any non-imaging related big offenders, so I think the dict and xml stuff can be ruled out? OK. Then DCMTK is faster in this case :) Now you should try a large multiframe JPEG-Lossless to see how it amortizes in the long run. This is odd that you try to benchmark such a lame encoding. Can you share your use-case (just for curiosity) ? Thanks > Here are the top 10 lines of dcmtk dcmdjpeg perf report: > 64,28% dcmdjpeg dcmdjpeg [.] decode_mcus ◆ > 11,12% dcmdjpeg dcmdjpeg [.] jpeg16_fill_bit_buffer ▒ > 3,89% dcmdjpeg dcmdjpeg [.] jpeg_undifference1 ▒ > 2,92% dcmdjpeg dcmdjpeg [.] null_convert ▒ > 1,57% dcmdjpeg [kernel.vmlinux] [k] copy_user_enhanced_fast_string ▒ > 1,39% dcmdjpeg libc.so.6 [.] 0x00000000001afbba ▒ > 0,74% dcmdjpeg [kernel.vmlinux] [k] __add_to_page_cache_locked ▒ > 0,72% dcmdjpeg dcmdjpeg [.] noscale ▒ > 0,66% dcmdjpeg [kernel.vmlinux] [k] __get_user_nocheck_1 ▒ > 0,52% dcmdjpeg libc.so.6 [.] 0x00000000001af28c > > and here are top 20 of gdcm: > > 44,58% gdcmconv libgdcmjpeg16.so.3.1.0 [.] decode_mcus ◆ > 7,30% gdcmconv libgdcmjpeg16.so.3.1.0 [.] gdcmjpeg16_jpeg_fill_bit_buffer ▒ > 2,77% gdcmconv libgdcmjpeg16.so.3.1.0 [.] jpeg_undifference1 ▒ > 2,54% gdcmconv [kernel.vmlinux] [k] charge_memcg ▒ > 2,10% gdcmconv [kernel.vmlinux] [k] native_irq_return_iret ▒ > 2,03% gdcmconv libc.so.6 [.] 0x00000000001afbba ▒ > 1,90% gdcmconv [kernel.vmlinux] [k] sync_regs ▒ > 1,49% gdcmconv libc.so.6 [.] 0x00000000001af28c ▒ > 0,96% gdcmconv [kernel.vmlinux] [k] try_charge_memcg ▒ > 0,96% gdcmconv libc.so.6 [.] 0x00000000001af613 ▒ > 0,96% gdcmconv [kernel.vmlinux] [k] copy_user_enhanced_fast_string ▒ > 0,91% gdcmconv libc.so.6 [.] 0x00000000001af5af ▒ > 0,89% gdcmconv [kernel.vmlinux] [k] clear_page_erms ▒ > 0,79% gdcmconv [kernel.vmlinux] [k] do_anonymous_page ▒ > 0,78% gdcmconv [kernel.vmlinux] [k] rmqueue_bulk ▒ > 0,74% gdcmconv [kernel.vmlinux] [k] zap_pte_range ▒ > 0,72% gdcmconv libc.so.6 [.] 0x00000000001af4c5 ▒ > 0,71% gdcmconv libc.so.6 [.] 0x00000000001af5d7 ▒ > 0,65% gdcmconv libc.so.6 [.] 0x00000000001af5ff ▒ > 0,62% gdcmconv libgdcmMSFF.so.3.1.0 [.] gdcm::ImageCodec::DoOverlayCleanup |
|
From: Mathieu M. <mat...@gm...> - 2022-11-15 10:17:10
|
On Tue, Nov 15, 2022 at 11:07 AM Mikhail Timofeev <mt...@ou...> wrote: > > Hello > the perf report looks as if indeed memory allocation would be the culprit. But there are also some calls to dcmdjpeg that gdcm seems to skip. For example the "null_convert" or "no_scale". > On the other side I dont see any non-imaging related big offenders, so I think the dict and xml stuff can be ruled out? OK. Then DCMTK is faster in this case :) Now you should try a large multiframe JPEG-Lossless to see how it amortizes in the long run. This is odd that you try to benchmark such a lame encoding. Can you share your use-case (just for curiosity) ? Thanks > Here are the top 10 lines of dcmtk dcmdjpeg perf report: > 64,28% dcmdjpeg dcmdjpeg [.] decode_mcus ◆ > 11,12% dcmdjpeg dcmdjpeg [.] jpeg16_fill_bit_buffer ▒ > 3,89% dcmdjpeg dcmdjpeg [.] jpeg_undifference1 ▒ > 2,92% dcmdjpeg dcmdjpeg [.] null_convert ▒ > 1,57% dcmdjpeg [kernel.vmlinux] [k] copy_user_enhanced_fast_string ▒ > 1,39% dcmdjpeg libc.so.6 [.] 0x00000000001afbba ▒ > 0,74% dcmdjpeg [kernel.vmlinux] [k] __add_to_page_cache_locked ▒ > 0,72% dcmdjpeg dcmdjpeg [.] noscale ▒ > 0,66% dcmdjpeg [kernel.vmlinux] [k] __get_user_nocheck_1 ▒ > 0,52% dcmdjpeg libc.so.6 [.] 0x00000000001af28c > > and here are top 20 of gdcm: > > 44,58% gdcmconv libgdcmjpeg16.so.3.1.0 [.] decode_mcus ◆ > 7,30% gdcmconv libgdcmjpeg16.so.3.1.0 [.] gdcmjpeg16_jpeg_fill_bit_buffer ▒ > 2,77% gdcmconv libgdcmjpeg16.so.3.1.0 [.] jpeg_undifference1 ▒ > 2,54% gdcmconv [kernel.vmlinux] [k] charge_memcg ▒ > 2,10% gdcmconv [kernel.vmlinux] [k] native_irq_return_iret ▒ > 2,03% gdcmconv libc.so.6 [.] 0x00000000001afbba ▒ > 1,90% gdcmconv [kernel.vmlinux] [k] sync_regs ▒ > 1,49% gdcmconv libc.so.6 [.] 0x00000000001af28c ▒ > 0,96% gdcmconv [kernel.vmlinux] [k] try_charge_memcg ▒ > 0,96% gdcmconv libc.so.6 [.] 0x00000000001af613 ▒ > 0,96% gdcmconv [kernel.vmlinux] [k] copy_user_enhanced_fast_string ▒ > 0,91% gdcmconv libc.so.6 [.] 0x00000000001af5af ▒ > 0,89% gdcmconv [kernel.vmlinux] [k] clear_page_erms ▒ > 0,79% gdcmconv [kernel.vmlinux] [k] do_anonymous_page ▒ > 0,78% gdcmconv [kernel.vmlinux] [k] rmqueue_bulk ▒ > 0,74% gdcmconv [kernel.vmlinux] [k] zap_pte_range ▒ > 0,72% gdcmconv libc.so.6 [.] 0x00000000001af4c5 ▒ > 0,71% gdcmconv libc.so.6 [.] 0x00000000001af5d7 ▒ > 0,65% gdcmconv libc.so.6 [.] 0x00000000001af5ff ▒ > 0,62% gdcmconv libgdcmMSFF.so.3.1.0 [.] gdcm::ImageCodec::DoOverlayCleanup |
|
From: Mathieu M. <mat...@gm...> - 2022-11-15 08:31:15
|
Hi Mikhail ! On Thu, Nov 10, 2022 at 6:44 PM Mikhail Timofeev <mt...@ou...> wrote: > > Hello > I was assuming that GDCM largely uses DCMTK code for compression and decompression of JPEG Lossless. > I noticed that decompression takes roughly 40% longer with GDCM. Interestingly compression speed is equal across the two libraries, as expected. > I compare it like that: > $ time ./gdcmconv -w in.dcm out.dcm > real 0m1,400s > user 0m0,932s > sys 0m0,418s > > and for same input file: > $ time ./dcmdjpeg in.dcm out.dcm > real 0m0,968s > user 0m0,784s > sys 0m0,144s > > the file is pretty large and the TS is 1.2.840.10008.1.2.4.70. > I have compiled both libraries myself in Release mode. Is the difference due to some subtle source code differences I am yet to understand completely or due the way how the codecs are called? > Is it possible to link the core gdcm libraries against the dcmtk libraries directly? Since this is a single run, I suspect two things: 1. GDCM takes a long time to init the dict or xml stuff 2. The mem allocation of ImageChangeTS is pretty bad. Since you seems to be using Linux, why not simply check my wild guess with perf: % perf record ./gdcmconv -w in.dcm out.dcm % perf report HTH |
77 messages has been excluded from this view by a project administrator.
