Quantcast

dicom package maintainer

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

dicom package maintainer

JohnD
Andy & Octave maintainers,

Any issues if I step in to update the dicom package for a new release ?


There are a few bugs that have mainly been fixed in the repo and the
current release version was back in 2011.

It needs an update for the current toplevel makefile requirements, as
well as a few minor bug fixes.

JohnD


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: dicom package maintainer

andy buckle


On 28 January 2017 at 23:07, John Donoghue <[hidden email]> wrote:
Andy & Octave maintainers,

Any issues if I step in to update the dicom package for a new release ?


There are a few bugs that have mainly been fixed in the repo and the current release version was back in 2011.

It needs an update for the current toplevel makefile requirements, as well as a few minor bug fixes.

JohnD


Fine with me.

The packaging/cmake issues are beyond my ability to fix.

--
/* andy buckle */
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: dicom package maintainer

JohnD
On 01/28/2017 06:43 PM, Andy Buckle wrote:


On 28 January 2017 at 23:07, John Donoghue <[hidden email]> wrote:
Andy & Octave maintainers,

Any issues if I step in to update the dicom package for a new release ?


There are a few bugs that have mainly been fixed in the repo and the current release version was back in 2011.

It needs an update for the current toplevel makefile requirements, as well as a few minor bug fixes.

JohnD


Fine with me.

The packaging/cmake issues are beyond my ability to fix.

--
/* andy buckle */

There are some test dcm files referenced within the .cpp source tests - where are they, and can they be included in the package?

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: dicom package maintainer

Carnë Draug
On 29 January 2017 at 14:50, John Donoghue
<[hidden email]> wrote:
> [...]
> There are some test dcm files referenced within the .cpp source tests -
> where are they, and can they be included in the package?

I removed binary files when the packages were converted to mercurial.
You can still get them from the svn repo [1] or you can use the hg
copy of the whole svn [2].  The file will be at
"extra/dicom/dcm_examples/RD.15MV.DCM"

A set of dicom files for a thorough test suite may become quite large
so I am not sure if it's a good idea to start adding them to the
repository.  Maybe a repository with test datasets could be created
and there could be optional tests that download the files as part of
maintainer tests.  Such setup would also be handy for core and at
least the io package.

Carnë

[1] svn://svn.code.sf.net/p/octave/code/trunk/octave-forge/
[2] http://hg.octave.org/forge/

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: dicom package maintainer

JohnD
On 01/29/2017 10:20 AM, Carnë Draug wrote:

> On 29 January 2017 at 14:50, John Donoghue
> <[hidden email]> wrote:
>> [...]
>> There are some test dcm files referenced within the .cpp source tests -
>> where are they, and can they be included in the package?
> I removed binary files when the packages were converted to mercurial.
> You can still get them from the svn repo [1] or you can use the hg
> copy of the whole svn [2].  The file will be at
> "extra/dicom/dcm_examples/RD.15MV.DCM"
>
> A set of dicom files for a thorough test suite may become quite large
> so I am not sure if it's a good idea to start adding them to the
> repository.  Maybe a repository with test datasets could be created
> and there could be optional tests that download the files as part of
> maintainer tests.  Such setup would also be handy for core and at
> least the io package.
>
> Carnë
>
> [1] svn://svn.code.sf.net/p/octave/code/trunk/octave-forge/
> [2] http://hg.octave.org/forge/

I'll take a look


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: dicom package maintainer

PhilipNienhuis
In reply to this post by Carnë Draug
Carnë Draug wrote
<snip>

A set of dicom files for a thorough test suite may become quite large
so I am not sure if it's a good idea to start adding them to the
repository.  Maybe a repository with test datasets could be created
and there could be optional tests that download the files as part of
maintainer tests.  Such setup would also be handy for core and at
least the io package.
.... and the mapping package ..... (think of .shp, .dxf and the various raster file formats.)

Good idea, Carnë.

That said, for io it would only be the reading of (especially) .xlsx files that would benefit.
Properly writing those files can only be tested by Excel itself :-(  (only to some extent by LibreOffice)

I still may have several example files that I used for debugging that were handed to me in good faith, yet I think it could be a lot of work to "anonymize" them.

Philip
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: dicom package maintainer

Carnë Draug
On 29 January 2017 at 20:26, PhilipNienhuis <[hidden email]> wrote:

> Carnë Draug wrote
>>
>> <snip>
>> A set of dicom files for a thorough test suite may become quite large
>> so I am not sure if it's a good idea to start adding them to the
>> repository.  Maybe a repository with test datasets could be created
>> and there could be optional tests that download the files as part of
>> maintainer tests.  Such setup would also be handy for core and at
>> least the io package.
>
> .... and the mapping package ..... (think of .shp, .dxf and the various
> raster file formats.)
>
> Good idea, Carnë.
>
> That said, for io it would only be the reading of (especially) .xlsx files
> that would benefit.
> Properly writing those files can only be tested by Excel itself :-(  (only
> to some extent by LibreOffice)
>
> I still may have several example files that I used for debugging that were
> handed to me in good faith, yet I think it could be a lot of work to
> "anonymize" them.
>

It would also be some work to make it in a way that is not Octave
specific since Octave is not the only project that would gain from
such repository.  I guess that would also attract contributors from
other projects too.

I have seen projects that have their own repositories of test data in
a format useful for them.  I am not familiar with any general purpose
repository for test data.  I don't believe I am the first person to
think of it but I didn't found anything online.  I guess others have
also found it to be a difficult problem.

Carnë

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: dicom package maintainer

JohnD
In reply to this post by Carnë Draug


> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of
> Carnë Draug
> Sent: Sunday, January 29, 2017 10:20 AM
> To: John Donoghue
> Cc: Andy Buckle; Octave Maintainers List
> Subject: Re: dicom package maintainer
>
> On 29 January 2017 at 14:50, John Donoghue
> <[hidden email]> wrote:
> > [...]
> > There are some test dcm files referenced within the .cpp source tests
> > - where are they, and can they be included in the package?
>
> I removed binary files when the packages were converted to mercurial.
> You can still get them from the svn repo [1] or you can use the hg copy of the
> whole svn [2].  The file will be at "extra/dicom/dcm_examples/RD.15MV.DCM"
>
> A set of dicom files for a thorough test suite may become quite large so I am
> not sure if it's a good idea to start adding them to the repository.  Maybe a
> repository with test datasets could be created and there could be optional tests
> that download the files as part of maintainer tests.  Such setup would also be
> handy for core and at least the io package.
>
> Carnë
>
> [1] svn://svn.code.sf.net/p/octave/code/trunk/octave-forge/
> [2] http://hg.octave.org/forge/

The gdcm project already has a repo for test data files [1] , so I can use that.

I can create a shared variable for the testname, download to tmp, run the tests and then delete the temp file on the last test

Unless there is  nicer way to cleanup after running the tests?

[1] https://sourceforge.net/p/gdcm/gdcmdata/ci/master/tree/


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: dicom package maintainer

andy buckle


On 30 January 2017 at 17:21, JohnD <[hidden email]> wrote:


> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of
> Carnë Draug
> Sent: Sunday, January 29, 2017 10:20 AM
> To: John Donoghue
> Cc: Andy Buckle; Octave Maintainers List
> Subject: Re: dicom package maintainer
>
> On 29 January 2017 at 14:50, John Donoghue
> <[hidden email]> wrote:
> > [...]
> > There are some test dcm files referenced within the .cpp source tests
> > - where are they, and can they be included in the package?
>
> I removed binary files when the packages were converted to mercurial.
> You can still get them from the svn repo [1] or you can use the hg copy of the
> whole svn [2].  The file will be at "extra/dicom/dcm_examples/RD.15MV.DCM"
>
> A set of dicom files for a thorough test suite may become quite large so I am
> not sure if it's a good idea to start adding them to the repository.  Maybe a
> repository with test datasets could be created and there could be optional tests
> that download the files as part of maintainer tests.  Such setup would also be
> handy for core and at least the io package.
>
> Carnë
>
> [1] svn://svn.code.sf.net/p/octave/code/trunk/octave-forge/
> [2] http://hg.octave.org/forge/

The gdcm project already has a repo for test data files [1] , so I can use that.

I can create a shared variable for the testname, download to tmp, run the tests and then delete the temp file on the last test

Unless there is  nicer way to cleanup after running the tests?

[1] https://sourceforge.net/p/gdcm/gdcmdata/ci/master/tree/



Most DICOM images are 2D. I had an example 3D dose file. The GDCM test file list looks quite long, and covers more odd cases than I ever did, but may not have a 3D file.


--
/* andy buckle */
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: dicom package maintainer

PhilipNienhuis
In reply to this post by Carnë Draug
Carnë Draug wrote
On 29 January 2017 at 20:26, PhilipNienhuis <[hidden email]> wrote:
> Carnë Draug wrote
>>
>> <snip>
>> A set of dicom files for a thorough test suite may become quite large
>> so I am not sure if it's a good idea to start adding them to the
>> repository.  Maybe a repository with test datasets could be created
>> and there could be optional tests that download the files as part of
>> maintainer tests.  Such setup would also be handy for core and at
>> least the io package.
>
> .... and the mapping package ..... (think of .shp, .dxf and the various
> raster file formats.)
>
> Good idea, Carnë.
>
> That said, for io it would only be the reading of (especially) .xlsx files
> that would benefit.
> Properly writing those files can only be tested by Excel itself :-(  (only
> to some extent by LibreOffice)
>
> I still may have several example files that I used for debugging that were
> handed to me in good faith, yet I think it could be a lot of work to
> "anonymize" them.
>

It would also be some work to make it in a way that is not Octave
specific since Octave is not the only project that would gain from
such repository.  I guess that would also attract contributors from
other projects too.

I have seen projects that have their own repositories of test data in
a format useful for them.  I am not familiar with any general purpose
repository for test data.  I don't believe I am the first person to
think of it but I didn't found anything online.  I guess others have
also found it to be a difficult problem.
This is a smart idea as well.
Yet my experience in day-to-day business is that connecting everything to everything merely leads to endless delays and nothing done (+ often a lot of frustrations).

As to .shp, .dxf and raster files for the mapping package:
I found heaps and heaps of online examples when I wrote/adapted the relevant functions.  So, extending JohnD's idea in another posting in this thread, we might add integrated lists in OF packages, or an online-repo, of URLs where test data sets can be downloaded and add functions to d/ld & unpack those test data, run tests & delete them afterwards.
Maybe those lists can be in the wiki, so URLs can be maintained & updated when URLs change (as they tend to do).

Philip
Loading...