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

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

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.



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

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.


Reply to: