[med-svn] r2712 - trunk/packages/gdcm/trunk/debian (jpeg)

[Mathieu Malaterre]

On Thu, Nov 20, 2008 at 10:51 AM, Andreas Tille <tillea at rki.de> wrote:
>> So the ijg in gdcm is simply ijg (same as libjpeg62) with a well known
>> patch called the lossless jpeg from Ken Murchison of Oceana Matrix Ltd
>> (I had to patch that patch... )
>>
>> For more details, see the jpeg project I maintain on sf.net:
>>
>> http://gdcm.svn.sf.net/viewvc/jpeg/README?view=markup
>
> So if I understand you right you need a more feature rich libjpeg62 than the
> one it is provided in the Debian package.  There are two options to tackle
> this problem:
>
>   1. File a bug report against libjpeg62.
>   2. Maintain an alternate package that
>       Provides: libjpeg62
>       Replaces: libjpeg62
>       Conflicts: libjpeg62 (perhaps, if this is technical necessary)
>      and contains the needed features.
>
> I would start with option 1 - perhaps people just do not know about this
> problem.  The BTS does not say anything about this.  If it turns out that
> the maintainer has reasons to not fix this in the Debian package just
> continue with option 2.  I do not like the idea to "hide" a feature
> rich libjpeg62 implementation deeply inside a potential gdcm package.
> It should rather be a separate library package which might be used by
> other packages as well and gdcm should just depend from it explicitely.

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.

>> Anyway it should be technically possible to use libgdcmjpeg8.so.62.1.0
>> in place of the current libjpeg62.
>
> This really smells like option 2 ...

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.

>> But keep in mind that code path
>> were changed to support lossless, so file that would not be supported
>> in the past would now be supported. I did not invest any time in
>> benchmarking those two libs. Anyway in short: Tom Lane (the author of
>> ijg) made the choice of not including the lossless patch,
>
> Are the reasons documented anywhere plublicly?

http://www.creatis.insa-lyon.fr/~malaterre/jpeg/PatchingIJG.html
-> http://www.ijg.org/archives/jpeg-l.9903.txt

which has since desapered instead:
-> http://web.archive.org/web/20030317210505/www.ijg.org/archives/jpeg-l.9903.txt

>> I cannot
>> possibly be the one telling the whole community they now need the
>> lossless patch :)
>
> Well, that's probably not really the case and that's why I mentioned
> option 2.  But I also doubt that gdcm is the only project that might
> need it.

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.

>  If you hide the code inside the package other forks might
> arise which will lead to much confusion and even less acceptance of
> the lossless patch.

I will not argue for ever on that, but I think that J2K solve a couple
of issues with lossless jpeg. So even in the DICOM world we are seeing
more and more J2K lossless. I do not see a bright future for the old
lossless jpeg... but that's a different story.

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 ?

>> FYI, I have bcc: Tom Lane and Bill Allombert.
>
> Uhm Bcc.  I was easily able to detect Bill's address for my CC.  Just
> foreward my answer to Tom if you think this makes sense.

I only ever contact Tom when dealing with brain dead jpeg image
(invalid huffman table, broken 16 bits lossless implementation). He
has very little time for jpeg now, so I try to keep his noise level
very low.

Thanks.
-- 
Mathieu