On Thu, Nov 20, 2008 at 12:05 PM, Andreas Tille <email@example.com> 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.
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.
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org