Subject: Re: r2712 - trunk/packages/gdcm/trunk/debian (jpeg)
Newsgroups: gmane.linux.debian.devel.medical.scm
Date: 2008-11-20 09:51:29 GMT (1 year, 11 weeks, 4 days, 13 hours and 9 minutes ago)
On Thu, 20 Nov 2008, Mathieu Malaterre wrote: > Hum. I cannot find the discussion I had with Bill Allombert a while > ago. Anyway here is goes again. For most people libjpeg62 implements > the JPEG ISO/IEC IS 10918-1. Well it does not, the binary only provide > support for 8bits lossy. > While in DICOM we need: > * 8 bits lossy > * 12 bits lossy > * 8 bits lossless > * 12 bits lossless > * 16 bits lossless Ahh, OK. > 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. > 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 ... > 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? > 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. 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. > 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. Kind regards Andreas. -- http://fam-tille.de