Description of problem: I had reported this against libjpeg product at first, not knowing that Fedora was moving to libjpeg-turbo. Please see the thread at: http://lists.fedoraproject.org/pipermail/devel/2010-October/143688.html This could also be helpful: http://lists.fedoraproject.org/pipermail/devel/2010-October/143701.html Adding support for just _decoding_ arithmetic coded files should not stand in anyone's way due to philosophical reasons. Ideally I'd like support for encoding too, but we can argue on that later. I'm going to attach a patch for this against libjpeg-turbo. Will also ask upstream on the Sourceforge patch tracker for its developers to merge it. I don't know how to set this bug to block "FE_LEGAL" as asked by a poster on the list. If anyone else knows, please set it so.
Created attachment 451249 [details] Patch against libjpeg-turbo HEAD to add support for decoding arithmetic coded content This is based on a patch by Guido Vollbeding <guivol>, which included code to both encode and decode arithmetic coded content. This patch only adds the decoding portion. No new arithmetic coded content can be produced, but existing arithmetic coded content can be decoded. libjpeg-turbo with this patch has been tested with some arithmetic coded images (digital photographs).
Upstream patch: https://sourceforge.net/tracker/?func=detail&aid=3080268&group_id=303195&atid=1278160
(In reply to comment #0) > I don't know how to set this bug to block "FE_LEGAL" as asked by a poster on > the list. If anyone else knows, please set it so. It's "FE-LEGAL". There's a "Blocks:" field in Bugzilla. Done now.
Upstream says they're blocked on Fedora legal team. As soon as Fedora legal team decides the patents have expired and it is safe to include support for arithmetic coding, they are ready to add support. To help the legal team, here is a PDF of the relevant patent numbers for arithmetic coding in the context of the JPEG standard: http://www.itu.int/rec/T-REC-T.81-200401-I!Cor1/en
In addition to patents, the copyright licensing might also be a problem. I see "See the accompanying README file for conditions of distribution and use.", but said README file does not give any license grant at all, there's only a "DISCLAIMER" section with a warranty disclaimer and a disclaimer about patents, but no copyright license.
I will mail Guido Vollbeding and ask about it.
Reply from Guido Vollbeding: Message-ID: <4CA9B76E.6629B3EE> Date: Mon, 04 Oct 2010 13:15:58 +0200 From: Guido Vollbeding <[snip]> MIME-Version: 1.0 To: Mukund Sivaraman <[snip]> Subject: Re: Use of jpeg-ari patch with libjpeg-turbo (license clarification) References: <20101004104555.GA11259@jurassic> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1274 Dear Mukund Thank you very much for your inquiry. Please note that I do not recommend and not support libjpeg-turbo, because it is obsolete, and hence do not recommend distributions like Fedora which use this stuff. The author(s) of libjpeg-turbo did never ask me what I think about their make. The answer would be that I consider this ugly stuff done by ignorant and stupid people who don't understand what they are doing. I know how to make performance improvements by assembly language programming, and I have done such work in projects based on the new libjpeg code. But for publication this must be done rightfully, or it must not be done at all. What the libjpeg-turbo folks did is simply rubbish, it is a shame for the quality work that IJG is commonly known for. Doing it rightfully for publication requires tremendous effort, and as long as I don't have the means to spend this effort, I leave it. That said, I don't care what you are doing with libjpeg-turbo and jpeg-ari. This is already rubbish, and I don't waste my time with it. Please consider the code public domain and do what you want with it, I don't care. If you have any question about the true libjpeg code, please let me know. Kind regards Guido Vollbeding Organizer Independent JPEG Group
Reply 2 from Guido Vollbeding: Message-ID: <4CA9BFB4.36A8910E> Date: Mon, 04 Oct 2010 13:51:16 +0200 From: Guido Vollbeding <[snip]> MIME-Version: 1.0 To: Mukund Sivaraman <[snip]> Subject: Re: Use of jpeg-ari patch with libjpeg-turbo (license clarification) References: <20101004104555.GA11259@jurassic> <4CA9B76E.6629B3EE> <20101004114445.GA11293@jurassic> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 667 Hi Mukund > Thank you for the quick reply! Do you mind if I post your reply in > full to the bug, for the benefit of others to see? You have said > things in this email that other people relevant to this libjpeg-turbo > inclusion should see (and understand) rather than me. Yes, I would love if you post my reply in full for others to see, because until now they have been ignorant for my opinion. > I am merely interested in seeing arithmetic coding support in Fedora :) And I am interested to see true libjpeg support in Fedora, which includes that for arithmetic coding. As long as they use this fake version, I cannot take Fedora seriously. Regards Guido
(In reply to comment #5) > In addition to patents, the copyright licensing might also be a problem. I see > "See the accompanying README file for conditions of distribution and use.", but > said README file does not give any license grant at all, there's only a > "DISCLAIMER" section with a warranty disclaimer and a disclaimer about patents, > but no copyright license. It seems the last paragraph of comment #7 allows us to use that code in libjpeg-turbo. And the rest of the comment #7 reassure me that it was correct decision to use libjpeg-turbo instead of libjpeg in Fedora.
On the topic of copyright: 1) "Please consider the code public domain and do what you want with it, I don't care." Guido is German (I'm pretty sure), so he can't actually abandon his copyright and place that work into the Public Domain. However, his follow-up comment of "do what you want with it" is pretty clearly a permissive license, so we will treat it as a "copyright only" license. I see no other legal issues here, lifting FE-Legal.
(In reply to comment #10) > On the topic of copyright: > > 1) "Please consider the code public domain and do what you want > with it, I don't care." Guido is German (I'm pretty sure), so he can't actually > abandon his copyright and place that work into the Public Domain. However, his > follow-up comment of "do what you want with it" is pretty clearly a permissive > license, so we will treat it as a "copyright only" license. > > I see no other legal issues here, lifting FE-Legal. The FE-Legal has to do with patents, not copyright. Someone in Red Hat legal has to verify that the relevant patents have indeed expired and say so here.
(In reply to comment #11) > The FE-Legal has to do with patents, not copyright. Someone in Red Hat legal > has to verify that the relevant patents have indeed expired and say so here. I chose my words carefully. There are no other legal concerns here at this time.
Lifting FE-Legal again.
OK cool :) I guess the ball is in the libjpeg-turbo maintainers' court now.
Arithmetic coding support has been committed into libjpeg-turbo upstream but I would like to test that code. Can you attach some arithmetic coded JPEG, please? Thank you in advance.
Created attachment 455019 [details] Test arithmetic coded JPEG image (generated by ijg.org implementation)
Adam, which repository is upstream btw? I am unable to see the update in the sourceforge.net SVN repo.
(In reply to comment #17) > Adam, which repository is upstream btw? I am unable to see the update in the > sourceforge.net SVN repo. Ah, right you are, I saw there is something related to arithmetic decoding in upstream repo but it is not fully complete, yet.
Fixed in libjpeg-turbo-1.0.1-3.fc15.
Hi. I am working to get this into libjpeg-turbo 1.1. Is there any objection (legal or otherwise) to including arithmetic encoding support as well? It seemed like there was, from reading the threads on the mailing list.
AFAIK: * legal objections, no, * practical objections, probably: can you support it without breaking the API/ABI? I'd venture it'll have to be disabled at least in libjpeg.so.62 mode. * philosophical objections, maybe, this is subjective. Some people argue you should support all JPEG features you can, others argue you should avoid generating files which cannot be decoded by many current decoders.
(In reply to comment #20) > Hi. I am working to get this into libjpeg-turbo 1.1. Is there any objection > (legal or otherwise) to including arithmetic encoding support as well? It > seemed like there was, from reading the threads on the mailing list. It's been indicated in this bug that there are no longer any legal issues. There are philosophical issues though. Baseline profile is more or less so prevalent, that most people assume any file.jpg is a baseline profile file. Adding arithmetic decoding support is transparent and won't affect anyone negatively, but adding arithmetic encoding support means that some applications linking against old versions of libjpeg may not be able to open some .jpg files. Nobody expects that a file.jpg won't open universally. This case has been argued both publicly and privately. IMHO, you should adopt the arithmetic coding patch and leave it to application developers and end-users to make this choice for themselves. i.e., don't make policy decisions in libjpeg-turbo as it is merely a library. The patch in this bug which has gone into the Fedora libjpeg-turbo RPM only implements arithmetic decoding. If you want a separate patch for encoding too, I'm happy to make one for you if you get the decoding patch in first. (In reply to comment #21) > AFAIK: > * legal objections, no, > * practical objections, probably: can you support it without breaking the > API/ABI? I'd venture it'll have to be disabled at least in libjpeg.so.62 mode. > * philosophical objections, maybe, this is subjective. Some people argue you > should support all JPEG features you can, others argue you should avoid > generating files which cannot be decoded by many current decoders. There should be no API/ABI issues with libjpeg 6.2. libjpeg has implemented a future-compatible API for a long time now.
My inclination is to include arithmetic encoding and simply make it a configure option that can be disabled by those who don't want to include it in their build of libjpeg-turbo. jpeg-7 and jpeg-8 let the arithmetic coding genie out of the bottle, and there are already some prominent applications and Linux distros that use jpeg-7 or jpeg-8 (meaning that those apps/distros can be used to generate an arithmetic-encoded .jpg file.) I'm not sure if I agree that .jpg implies baseline. Progressive-encoded JPEGs also usually bear the .jpg extension, and those have been around for decades.
Both arithmetic encoding and decoding have been implemented in the libjpeg-turbo SVN trunk and will be in LJT 1.1. These features can be individually disabled using configure or CMake options.