[Debian-med-packaging] ITK and embedded libs

[Mathieu Malaterre]

Hi Steve,

  Back from vacation, going through mails...

On Thu, Aug 18, 2011 at 5:58 AM, Steve M. Robbins <steve at sumost.ca> wrote:
> CC'ing Mathieu for his thoughts; threads starts at [1].
>
> [1] http://lists.alioth.debian.org/pipermail/debian-med-packaging/2011-July/011030.html
>
>
> On Sun, Jul 24, 2011 at 04:02:45PM -0400, Michael Hanke wrote:
>> On Sun, Jul 24, 2011 at 01:59:09PM -0500, Steve M. Robbins wrote:
>> > > > Reject Reasons:
>> > > > libinsighttoolkit3.20: lintian output: 'embedded-library usr/lib/libitkjpeg12.so.3.20.0: libjpeg', automatically rejected package.
>> > > > libinsighttoolkit3.20: If you have a good reason, you may override this lintian tag.
>> > > > libinsighttoolkit3.20: lintian output: 'embedded-library usr/lib/libitkjpeg16.so.3.20.0: libjpeg', automatically rejected package.
>> > > > libinsighttoolkit3.20: If you have a good reason, you may override this lintian tag.
>> > > > libinsighttoolkit3.20: lintian output: 'embedded-library usr/lib/libitkjpeg8.so.3.20.0: libjpeg', automatically rejected package.
>> > > > libinsighttoolkit3.20: If you have a good reason, you may override this lintian tag.
>> > > > libinsighttoolkit3.20: lintian output: 'embedded-library usr/lib/libitkopenjpeg.so.3.20.0: openjpeg', automatically rejected package.
>> > > > libinsighttoolkit3.20: If you have a good reason, you may override this lintian tag.
>> >
>> > My understanding from the authors is that the jpeg libraries are
>> > heavily modified for use in ITK (and gdcm), so I'm going to override
>> > this tag and re-upload.
>>
>> Hmm, haven't heard this yet. Is there any source where the modifications
>> are described? I'm asking because I routinely patch all software to
>> avoid linking to any of the foreign libs included in ITK/VTK -- I never
>> saw any change in behavior, never experienced any breakage of API.
>
> For the case of JPEG: the first obvious difference is that ITK builds
> flavours for 3 different bit-depths: 8, 12, and 16.  The system JPEG
> handles only 8-bit pixels.  The code to handle 16 bits is an addition
> by ITK.  Mathieu: do you know of any other differences?

See:

gdcm/Utilities/gdcmjpeg/README.GDCM.txt

There is no plan to update ijg6b -> 8, because the lossless patch is
huge. Both DCMTK and GDCM uses the same 6b+lossless patch for its
encoder/decoder.

ijg 8a supports arithmetic codec AFAIK but I have not seen it used in DICOM yet.

> There is no cmake option to use the system JPEG library in preference
> to itkjpeg.

There is one to use a system LJPG (note the L), the default 8bits jpeg
(ijg) on debian (and other linux) will not support 12bits lossy (would
need a recompilation). But the bigest change would be the
incorporation of the lossless patch which heavily changes the
internals.

> In the case of OpenJPEG: I just had a look at the ITK build tree and
> discovered that there IS an option to use the system OpenJpeg library,
> which I had not enabled.  Mathieu: I see GDCM's changelog has a
> notation:
>
> gdcm (2.0.17-1) experimental; urgency=low
>
>  * New upstream
>  * Do not use system OpenJPEG v1, prefer OpenJPEG v2
>
> but the build system actually disables GDCM_USE_SYSTEM_OPENJPEG!  Is
> there a problem using the system lib?  If so, will it affect ITK as
> well?

No, this is ok, if you read the next changelog, I reverted back to
OpenJPEG v1. You may need GDCM 2.0.18 for this as there was a typo
which prevented from using a system openjpeg (fedora manage to achieve
it though using a minor change).

>
>> > > in this context: http://bugs.debian.org/586997
>> >
>> > I'm not sure the status of the NIfTI libs.  This bug suggests there
>> > are fixes applied to the ITK version.  It would be useful for someone
>> > to audit them and contribute them back to the NIfTI sources.
>>
>> ... and doing that for every upload of ITK from now on until the world
>> ends.
>
> Well, no; the goal would be to contribute them back to NIfTI (or at
> least NIfTI in Debian) and use the system libs instead.
>
>
>> I think it would be more efficient the remove ALL embedded libs
>> from ITK and always use the corresponding Debian packages.
>
> That is the goal.  To the best of my knowledge, all the available
> ITK_USE_SYSTEM_xxx variables are set to ON -- with the exception of
> OpenJPEG as noted above.

No, openjpeg v2 is really unstable, there is an ongoing effort to
really fixing it anyway. So for now simply use the default system
installed openjpeg.


HTH
-- 
Mathieu