[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Any software package for Radiation Oncology Contouring?



On Sat, Mar 19, 2011 at 15:54, Andreas Tille <andreas@an3as.eu> wrote:
> Ahh, OK.  You always kann install python-dicom from experimental - I
> just wanted to spare this dependency for the purpose of packaging
> without relying on experimental.  I just kept NeuroDebian team in CC to
> let them comment on the python-dicom situation and whether we might
> expect an upload of >= 0.9.5 to unstable soon(ish).

Good to know. I will try to play around with it this week if time permits.

> Ahh - this was a missunderstanding.  I do not really waste your time to
> backport dicompyler to a broken python-dicom.  I just wanted to verify
> that packaging itself works.  Once we have the proper version in
> unstable everything will be fine and your should be able to use the
> version from experimental for testing the package.

Yes, that is the most important part - that the packaging works.

> That's a quite nice habit to be so quickly for support - but as I tried
> to line out it is probably not urgently needed and I'm sorry that my
> mail triggered you to do some work which can probably soonish be
> dropped.

No problem, not that much extra work for me. Anyways, there may be
users on other systems that are using versions of pydicom < 0.9.5.
This will allow them to still run the code without forcing them to
upgrade to the latest version of pydicom, in case they are dependent
on it for other uses.

> So I wonder whether it makes sense to reward your fine work with a new
> test package or whether it makes more sense to wait for an answer of the
> python-dicom packagers.  Considering that we will probable not go for
> uploading a dicompyler alpha version but rather try to move a more
> stabelised version (according to your decision what you would call
> stabelised) I think it is not worth the effort.  I'd rather would do the
> resume: Packaging dicompyler seems not to be a challenge at all and the
> problem is solved.  If you as upstream would consider it in some kind of
> release candidate state just ping the list again.  We will than go for
> an upload into Debian new queue.  Passing new seems to take 1-2 monthes
> of time anyway.  Once this is done we can soonish push your latest
> version to unstable.

Yes, the best option here is to wait for the pydicom packagers to see
when 0.9.5 will be available. Until then, we will continue to complete
0.4 upstream and will ping the list again when we are close wtih a RC.

> While this is definitely possible in principle we should decide how
> important these are for the user.  If a proper description what exactly
> to do to fetch and run the examples can be provided it makes probably
> sense to just add this as documentation and be done.

In the readme file, it is mentioned where to obtain the example code.
There is also a nice FAQ on the web site that allows users to get
oriented with the application [1].

>> Also we do not have test cases at the moment, but they are in the
>> pipeline to be written. At that time we may consider adding back
>> specific DICOM files for each test.
>
> Just keep me informed if this is ready.

May not be ready for 0.4, but if it is, I will let you know.

[1] http://code.google.com/p/dicompyler/wiki/FAQ

Thanks,

Adit


Reply to: