On Thu, Nov 20, 2008 at 10:51 AM, Andreas Tille <[EMAIL PROTECTED]> 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 _______________________________________________ debian-med-commit mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/debian-med-commit
