On Friday, November 11, 2011 10:42:23 PM Mathieu Malaterre wrote: > On Fri, Nov 11, 2011 at 10:26 PM, Sebastian Hilbert > > <[email protected]> wrote: > > On Friday, November 11, 2011 09:42:23 PM Mathieu Malaterre wrote: > >> On Fri, Nov 11, 2011 at 6:12 PM, Sebastian Hilbert > >> > >> <[email protected]> wrote: > >> > On Friday, November 11, 2011 01:55:51 AM Steve M. Robbins wrote: > >> >> On Thu, Nov 10, 2011 at 10:23:01AM +0100, Sebastian Hilbert wrote: > >> >> > On Thursday, November 10, 2011 10:03:09 AM Steffen Möller wrote: > >> >> > > Sorry for saying the obvious here, but if the bug is not > >> >> > > Debian-specific, then it should go to ITK upstream. > >> >> > >> >> I definitely encourage that patches for upstream bugs be sent > >> >> upstream. > >> >> > >> >> > The question was more along the lines if Debian packages accept > >> >> > patches which upstream refuses (have not checked with upstream ITK > >> >> > but have had issues with wxwidgets). > >> >> > >> >> It's common for Debian to have patches not in upstream. Often, in my > >> >> experience, it's not because of upstream refusal but due to differing > >> >> priority or differing release cycles. I generally have a number of > >> >> patches for Boost that upstream takes multiple releases to > >> >> incorporate. > >> >> > >> >> If you have a patch for the problem, I encourage you to submit a > >> >> Debian bug report as well as the upstream one, and link them. > >> > > >> > Raising this problem upstream at Ginkgo I was pointed to > >> > > >> > this bug report against itk upstream > >> > > >> > https://itk.icts.uiowa.edu/jira/browse/ITK-2457 > >> > > >> > The comment from Mathieu there made me check which gdcm > >> > libinsighttolkit depends on in Debian > >> > > >> > http://packages.debian.org/sid/libinsighttoolkit3.20 > >> > > >> > This however indicates that it already depends on gdcm 2.x > >> > > >> > which in turn means the bug is not fixed ? > >> > > >> > Supposedly most work is on itk4 which might make the problem go away. > >> > >> That's correct. ITK in debian has not been using the old GDCM 1.x > >> where a static buffer was used to decompress JPEG segment since years. > >> ITK uses a thread safe implementation in GDCM 2.x. I would think the > >> issue is not the one described in bug ITK-2457 > >> > >> HTH > > > > Now that I think of it upstream release 2.6.0 seems to work better. I > > will follow up on this when this is packaged for Debian. > > > > Has the patch mentioned ever made it into ITK ? > > There is no "patch" per-say. ITK policy is very strict with regards to > backward compatible API. Unfortunately GDCM 2.x did break quite a lot > of GDCM 1.x API. Since the low level GDCM API was used so much, it was > considered that breaking GDCM API would mean breaking ITK API, and > thus never made it officially into ITK. ITKv4 effort was specifically > designed with this goal in mind: break the API and cleanup old cruft. > > Because I needed better DICOM functionalities in ITK, I made an option > 'system GDCM' from the ITK configuration which allowed advanced users > to compile ITK against both a GDCM 1.x and GDCM 2.x API. > > I believe there has been a first rc for ITKv4, so this issue should > soon be solved. >
I will wait for that. Thanks for the info. There seems to be another issue in that Ginkgo-CADx from Unstable uses libinsighttoolkit3.20. Ginkgo cannot open a dicom file I have available since updating from libinsighttoolkit3.18 to 3.20. I will raise this issue upstream. Regards, Sebastian > HTH -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
