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:
http://jpeg.svn.sf.net/viewvc/jpeg/ljpeg/debian/
Thanks
--
Mathieu
Reply to: