Arithmetic coding in Fedora libjpeg (bug #639531) I want libjpeg packages in future Fedora distributions to support reading arithmetic coded JPEG files. Huffman coding and arithmetic are two different bit coding methods that are available in the JPEG standard. Huffman is simpler to implement than arithmetic coding and historically hasn't suffered from software patents. Arithmetic coding (as used in JPEG) had been covered by software patents, but these patents have now apparently expired. [Fedora legal could check this.] The vast majority of JPEG files so far used Huffman coding because of the software patents issue. libjpeg version 7 (one of the forks of the old IJG software) and newer enable support for arithmetic coding by default. With older versions of libjpeg (such as the ones bundled by Fedora up to release 13), support can be added in the form of a patch. No application code modifications are required. (I'm not sure if it's ABI compatible though, but on a re-reading of the libjpeg headers, it might well be.) Arithmetic coding is in every case a superior bit coding method than Huffman, because arithmetic coding doesn't use an integral number of bits to represent codes like Huffman does. So JPEG files created with arithmetic coding are always smaller than those created with Huffman coding. Software such as jpegtran (as distributed with libjpeg 7 and above) can losslessly convert Huffman coded images to arithmetic coded and vice versa. The lossy behavior of JPEG does not happen at this (bit coding) layer of the format. The libjpeg package maintainer seems to be satisfied in closing the bug rather than providing a good rationale for doing so. But I will be the devil's advocate myself. You see, .jpg files are assumed to be an ubiquitous file format. They _just work_ everywhere. If you have a .jpg file, it is understood you aren't going to have problems when using it. But arithmetic coded files do not open everywhere. In fact, they rarely work in most applications, devices, etc. today, because pretty much everyone is using an old libjpeg with no support for it due to the historical software patents issue. As an example, in the context of GIMP creating such files, there were some comments that people would start losing faith in JPEG if they see incompatibilites, that such files are crippled JPEGs [sic], that people who use devices such as digital photo frames will suffer, that I should instead blog about free software and the evils of software patents, that this option should never be available in a dialog to the end-user, etc. * Fedora is not the only software that creates JPEG files. The nearest first implementation of a .jpg file creator program is cjpeg which is a part of libjpeg (the fork at ijg.org), and even that allows creating arithmetic coded files now. It would be arrogance to think that just because Fedora creates these files, the world of JPEG is going to suffer. Or that if Fedora doesn't do it, nobody else would. * The situation with arithmetic coding in the context of incompatibility with existing embedded decoders is just like H.264 and profiles. The iPhone for example does not play all kinds of H.264 files (it supports only the baseline profile). But MPEG content creation software does allow you to create files that use baseline as well as other profiles. It doesn't say "Hey, you the user are pretty stupid, so I'm not just turning this option off, but I'm not making it available to you." It would be arrogance to not provide an option to the end-user, just because I think the user may not know what he/she is doing. * Due to the patents issue, we had to assume that Huffman was the only bit coding method of this standard, whereas it isn't so. Arithmetic coding has been in the standard all these umpteen years, and some people used it. There was always the odd JPEG content that used arithmetic coding and which still complied with the standards. These are not broken JPEGs. Also quoting from the bug: > In any case, there are practical and political reasons not to encourage the > spread of the arithmetic-coding variant of JPEG. It's not compatible with most > implementations and it doesn't offer enough benefit to be worth creating an > enormous compatibility problem. So even if the code existed I would resist > turning it on. I think the author of libjpeg 8 has made a very serious error > by adding support for it. I have replied on the bug about it. Some of the text in my initial bug description is incorrect, and I have corrected it in this email. It is not upto Fedora to make political decisions when there is no good reason for it. This goes against the values of free software. "You shall not create images with arithmetic coding" is like saying "You shall not create images of the flying sphagetti monster." It's not up to Fedora to make this choice for me. As libjpeg is a shared library on the system, if it can support arithmetic coding, it should. Fedora doesn't have to decide about this file compatibility issue. It is up to applications and users to make these choices. The default is Huffman coding with libjpeg. Applications explicitly need to turn on arithmetic coding by setting cinfo.arith_code. But this doesn't really concern Fedora. Neither do Fedora have to, nor should they make this decision for everyone. The only relevant change that Fedora will influence is the implicit support for _decoding_ JPEG files which use arithmetic coding. By adding support, applications compiled against a libjpeg supporting arithmetic coding can decode such images which are part of the standard. By not doing it, some images compliant with the standard cannot be opened by Fedora applications. OTOH, if Fedora does not include support for arithmetic coding, and an application wants it, it will bundle a local copy of libjpeg, and will suffer from all of the static library issues. It will not affect the creation of arithmetic coded images, which are bound to increase now that the patents have expired. If there is a standards compliant .jpg file, what currently remains incompatible for a Fedora user is the libjpeg library package that stops every application using it from decoding such an image. Many people care about compatibility. I have had arguments with some GIMP co-developers about GIMP's support for it. Because I am a Fedora user, I had to create that bug for Fedora, and also present my case here, because the bug was getting closed with every response. :) I care about compatibility too, but I feel this is not a decision that software has to make for end-users. But I am tired of arguing on this topic, so please excuse me if I don't say more. I have written about everything relevant in this email. PS: Despite what the bug says, for libjpeg 6b (the current libjpeg in Fedora 13), there is a patch by Guido Vollbeding that implements arithmetic coding. It is by goes by the name "libjpeg6-arith.patch". Mukund -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
