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

Re: LJPEG 62.1 release ! (was Re: [med-svn] r2712 - trunk/packages/gdcm/trunk/debian (jpeg))

On Tue, Nov 25, 2008 at 5:24 PM, Mathieu Malaterre
<mathieu.malaterre@gmail.com> wrote:
> On Thu, Nov 20, 2008 at 12:05 PM, Andreas Tille <tillea@rki.de> wrote:
>> On Thu, 20 Nov 2008, Mathieu Malaterre wrote:
>>> Well the size of the lib will change. I think the API is compatible,
>>> but I do not know about the ABI. I really do not feel comfortable with
>>> option 1.
>> OK - I just trust you because I never dived into this.
>>> I'll start anyway with option 2, in the end there need to be such a
>>> package. It is so completely different from the libjpeg62, that I am
>>> now convinced this is not a bug against libjpeg62.
>> Fine.  So we have sorted out the way to go: Build a separate libjpeg62+
>> (or whatever name seems to be apropriate - I would not attach the name
>> gdcm to this one) which can be used to link gdcm against.
>>> ijg 6b was release in 98. no one really complain about that. At one
>>> point, when I had much more free time on my hand I found out that
>>> imagemagick people are supporting both lib (the official lib and the
>>> patched one). and of course the only other people using it are the
>>> dcmtk people.
>> Could anybody verify how the Debian packaged version of imagemagick
>> and dcmtk are dealing with this issue.  Does it might be that these
>> both ship their own version of lossless JPEG compression algorithm -
>> which would make even more sense to create the additional package.
>> What about graphicsmagick?
>>> Anyway this is a no-op to create such package (option #2). I even
>>> maintain the jpeg.sf.net for that particular point. I'll be away for a
>>> couple of days, do you have some sort of bug tracker to keep track of
>>> this sort of thing ?
>> I'm afraid I do not understand this parapgraph.  Above you seem to
>> agree that building a separate package and now you call it a no-op?
>> And what do you mean with a bug tracker.  If you intent to create a
>> new package you can use the Debian BTS and file an ITP bug against
>> the WNPP pseudo package.
> Done.
> http://sourceforge.net/project/showfiles.php?group_id=143299&package_id=300399&release_id=642896
> This package contains:
> * IJG 6b
> * Lossless patch (oceana)
> * cmakelists.txt
> * debian/* files
> For people starting from this thread, LJPEG is simply an integration
> of the lossless patch for IJG. It comes with cmakelists.txt as a
> default build system since the building of IJG to support 8 / 12 and
> 16 bits is not a runtime option but a compile time option. I feel much
> more comfortable writing that in cmake than with the previous build
> system.
> Let see if the community has any interest in this package. There are a
> couple of gray areas remaining:
> - should I keep the version number 62 (aka 6b) from IJG or will this
> confuse people ?
> - I have a couple of patch in the gdcm/jpeg that have not been
> applied. It concern broken JPEG implementation and have not been seen
> outside of the DICOM world.
> - if this package ever gets into debian, I think dcmtk package should
> use it instead.

I forgot to mention, the debian/* files are not shipped with the
tarball and can be found instead at:



Reply to: