eOn Tue, May 4, 2010 at 12:35 PM, Søren Hauberg <so...@hauberg.org> wrote: > tir, 04 05 2010 kl. 09:01 +0100, skrev Andy Buckle: >> I don't think image is the correct package for it. I realise that >> matlab has the functions in its image processing toolbox. However, >> dicom does mauch more that store images. My current motivation is that >> I wish to extract dose-volume histograms from RTDose and geometric >> imformation regarding collimators from RTPlan. I guess that mathworks >> have bunged it in with image processing in order to keep the number of >> packages small. Does octave have a similar requirement? > > Well, yes and no. To some extent we have similar requirements. From an > Octave-Forge point of view it doesn't really matter how many packages we > have. However, from a distributors point of view (Debian, Fedora, ...) I > think it matters as the amount of manual labour that has to be done > increases with the number of packages. > > I am not objecting to creating a 'dicom' package, but I think > alternatives should at least be considered.
The only thing that hasn't been explicitly mentioned is that dicom would add a library dependency (gdcm) to the image package. I don't really have any opinion on where it ends up so I'm not pointing this out to support either position just to make sure it's recognized in the decision process. Deciding were it gets sorted in octave-forge doesn't affect the code itself does it? --judd ------------------------------------------------------------------------------ _______________________________________________ Octave-dev mailing list Octave-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/octave-dev
