Hi all,
I see what you mean about the dicom package's dependencies, sounds like the
image package is a better place for it.
The underlying read function has a different calling syntax from Matlab, as it
reads both the header and the image in one go (I wrote it like that before I
realized there were similar functions in Matlab). However I've also written
functions which call it using the same format as analyze75info and
analyze75read. This does mean that it runs slower than Matlab, but it
shouldn't be difficult to change it to read only the appropriate parts if
needed.
I've only been able to test it with my own Analyze files, so it's not been
tested using other files with different orientations or anything like that.
Adam
> From: carandraug+...@gmail.com
> Date: Thu, 20 Sep 2012 12:33:35 +0200
> Subject: Re: [OctDev] Dicom package / isdicom function
> To: adamaitkenh...@hotmail.com
> CC: andybuc...@gmail.com; octave-dev@lists.sourceforge.net
>
> On 19 September 2012 20:00, Andy Buckle <andybuc...@gmail.com> wrote:
> >>> Date: Thu, 13 Sep 2012 14:57:29 +0100
> >>
> >>> Subject: Re: [OctDev] Dicom package / isdicom function
> >>> From: andybuc...@gmail.com
> >>> To: adamaitkenh...@hotmail.com
> >>>
> >>> > I have access to Matlab too, and it recognises the non-standard DICOM
> >>> > file.
> >>> > (Just to note, although I have tested the ML behaviour for a some test
> >>> > files, I didn't use Matlab as a basis for the code.)
> >>>
> >>> Excellent. That is the way to do it. We are careful about copyright.
> >>>
> >>> Andy
> > On 19 September 2012 17:26, adam aitkenhead <adamaitkenh...@hotmail.com>
> > wrote:
> >>
> >> Hi Andy,
> >>
> >> I've attached an updated version of the isdicom function which can now
> >> check
> >> a list of files (in a cell array) in one go, which is much quicker than
> >> checking each file separately. Again, no rush for releasing a new version
> >> of the toolbox - just some changes I was making for my own code anyway.
> >>
> >> Also on a different note, I've written functions which read/write the
> >> Analyze format, giving functions equivalent to Matlab's analyze75info and
> >> analyze75read. Would you rather keep the Dicom toolbox purely for the
> >> Dicom
> >> format, or are you interested in expanding it to become a general Medical
> >> File Format toolbox? No worries if not, just thought I'd see what you
> >> thought before I see where else they could fit into Octave-forge.
> >>
> >> Adam
> >
> > Note that I have included the list for further discussion, and edited
> > older text to chronological order.
> >
> > I have not used analyze75. If it is just m-files, then the image
> > package is probably a good place. The main reason dicom is on its own
> > is that it has burdensome dependencies.
>
> I agree with Andy. The analyze75read/write functions would fit better
> on the image package. Are their API matlab compatible?
>
> Carnë
------------------------------------------------------------------------------
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
_______________________________________________
Octave-dev mailing list
Octave-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/octave-dev
