[Debian-med-packaging] ITK and embedded libs

[Steve M. Robbins]

Hello Michael,

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?

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


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?


> > > 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.


Regards,
-Steve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/debian-med-packaging/attachments/20110817/debaa892/attachment.pgp>