Announcement

Collapse
No announcement yet.

JPEG Library Update Raises Compatibility Concerns

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • JPEG Library Update Raises Compatibility Concerns

    Phoronix: JPEG Library Update Raises Compatibility Concerns

    This week brought the release of IJG's libjpeg v9 library, which brought noticeable lossless JPEG compression improvements so that it can even surpass PNG images on the compress lossless image size. While the improvements are nice, backwards incompatible changes with this JPEG library are causing concern for some users and developers...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Canon

    Question is what will Canon, Nikon, Adobe, Microsoft, Apple, and Android do?

    Comment


    • #3
      This is apparently hotter than it seems. JPEG lacks animation, transparency, quality compression and it embeds metadata so deep that it is rather useful for suing and stalking than to be a help for the image owner.
      Also, the "-turbo" version is a community version, hence its accelerated, and upstream version (which turned v9 now) is coming from committee.

      Also, WebP has long established as much more efficient picture compression, spotting every feature JPG lacks, including much better yet readable (not blocky) compression.
      WebP is being bashed and WONT FIX on Mozilla - the single browser that actively prevents its adoption since years. Many conclude its only to piss Google.
      By the way, Mozilla is accused to kill motion-JPEG exactly the same way, and now they leave developers with either no-alpha JPG or huge alpha PNG.
      Just read the comments.


      Also, see this comparison


      So, in my opinion, the developer is correct. Because JPG9 breaks compatibility, but does not bring anything worth the effort, it is better switch to WebP instead.

      Originally posted by uid313 View Post
      Question is what will Canon, Nikon, Adobe, Microsoft, Apple, and Android do?
      Why should we care?
      Sony(Konica), Nikon, Canon, Fuji shoot RAW and JPG. The JPG ends up either stored or transcoded anyway.
      Microsoft, Apple, and Android. One is only affected if one uses solutions from these vendors. Rewind IE6 days, just use WebP if your OS supports it. If it does not, make them support it.
      Last edited by crazycheese; 16 January 2013, 08:10 AM.

      Comment


      • #4
        Originally posted by crazycheese View Post
        This is apparently hotter than it seems. JPEG lacks animation, transparency, quality compression and it embeds metadata so deep that it is rather useful for suing and stalking than to be a help for the image owner.
        I don't think anyone cares about JPEG animation or transparency.
        JPEG is for photographs. Photographs don't use animation or transparency. If you want animation, there is MPEG.

        Originally posted by crazycheese View Post
        WebP is being bashed and WONT FIX on Mozilla - the single browser that actively prevents its adoption since years.
        I don't think Internet Explorer, Safari, Opera, etc support WebP either.
        I guess its only Google Chrome that supports WebP?

        Originally posted by crazycheese View Post
        WebP is being bashed and WONT FIX on Mozilla - the single browser that actively prevents its adoption since years.
        Why should we care?
        Sony(Konica), Nikon, Canon, Fuji shoot RAW and JPG. The JPG ends up either stored or transcoded anyway.
        Microsoft, Apple, and Android. One is only affected if one uses solutions from these vendors. Rewind IE6 days, just use WebP if your OS supports it. If it does not, make them support it.[/QUOTE]

        But no OS supports WebP. What OS, what browser, what software supports it?
        If you take a photo, then you want to share it with your friends on the Internet, with JPEG everyone can see it, with WebP nobody can see it.

        Also, it's not only about OS, it's also about which devices support it.

        If camera manufactures all of a sudden started saving the photos as this new JPEG v9 then I guess every browser will need to support that.
        So it is important what Sony, Nikon, Canon, Fuji do.
        Also, now most people don't have cameras from Sony, Nikon, Canon, Fuji, they have smartphones running Android or iOS with built-in camera.
        If Android and iOS started saving to JPEG v9 then when kids with smartphones are posting their photos on the Internet, then the browsers must support it.

        Comment


        • #5
          Originally posted by uid313 View Post
          I don't think anyone cares about JPEG animation or transparency.
          JPEG is for photographs. Photographs don't use animation or transparency. If you want animation, there is MPEG.
          RAW is for photographs, JPEG is for archiving and internets
          RAW does not damage the luminosity, the luminosity is a critical factor due to EV. If you shot DLC in manual, you would understand..

          WebP is highly demanded by hosters, web designers, archiving services, photographers and normal users, because it simply has everything. Its only con is a high computational requirement, but only for compression.
          Compare it to h264 vs MPEG1, or LZMA vs ZIP and you get the same idea.

          Originally posted by uid313 View Post
          I don't think Internet Explorer, Safari, Opera, etc support WebP either.
          I guess its only Google Chrome that supports WebP?
          Please follow the Firefox bugzilla link I provided.
          Only IE(which is completely and utterly non-relevant browser of permanent suckage) does not support it, as Microsoft pushes its own format JPEG XR (happy days and surprise, EEE welcomes everyone).
          Opera was early adopter of webp. Overall all browsers except Mozilla either adopted WebP early or later.
          Its patent free, opensource, x-platform, very advanced and mature already. Only lobbysts would deny it, happily the IE6 days are over.

          Originally posted by uid313 View Post
          But no OS supports WebP. What OS, what browser, what software supports it?
          If you take a photo, then you want to share it with your friends on the Internet, with JPEG everyone can see it, with WebP nobody can see it.
          Just follow the links and be surprised.

          Originally posted by uid313 View Post
          Also, it's not only about OS, it's also about which devices support it.
          If camera manufactures all of a sudden started saving the photos as this new JPEG v9 then I guess every browser will need to support that.
          So it is important what Sony, Nikon, Canon, Fuji do.
          Also, now most people don't have cameras from Sony, Nikon, Canon, Fuji, they have smartphones running Android or iOS with built-in camera.
          If Android and iOS started saving to JPEG v9 then when kids with smartphones are posting their photos on the Internet, then the browsers must support it.
          Hence the point. JPEG9 deviated from the old specification and hence a new specification. WebP is a completely new specification.
          However WebP > JPEG9 many times on features, the licensing is open on both, so its a battle of "good reputation" vs "technological advantage". Politics vs computing.

          Also, you don't really shoot photo for internets, so browser is not related.
          However, the low-budget versions do shoot photo straight for internets and in this case its completely irrelevant what they use because every browser supports old JPG.
          Old JPG is tried and true, so no crime using it further till the format has settled (its mature already).

          iOS/Android and all OSes support WebP.

          Comment


          • #6
            Would like to see the focus of the library on continue focusing on baseline and coming up with new ways to make it faster.

            Comment


            • #7
              Haha, btw.... Microsoft "relacement" of JPEG, the JPEG XR is:
              * patented, usage allowed only via "Promise" ("I give promise, I take promise back." Haha)
              * prohibited to use on copyleft software (proof that MONO developers are BLIND)
              * works only on windows (all software, even GIMP plugin are bound to windows imaging service)
              * compresses worse than WebP

              .... and its result of cooperation between MS and JPEG group itself.

              I am going to recompress every single picture I have with WebP tomorrow

              Comment


              • #8
                I wanted to update you guys on what has occurred since the events described in this article took place. For starters, the future of libjpeg-turbo is not up in the air at all. My message to the libjpeg-turbo list was simply to solicit feedback on whether the community felt like it was worthwhile to continue viewing the IJG as our "upstream." I think that the answer was a resounding "no" (read on to find out why.)

                After posting that message, I engaged in a pro bono research project to attempt to evaluate the general usefulness of SmartScale and DCT scaling as features. Bear in mind that those features are what necessitated the backward-incompatible ABI change in jpeg-7 and jpeg-8. Specific to jpeg-9, my research compared the lossless SmartScale format introduced in jpeg-8 (and enhanced in jpeg-9) with other popular lossless codecs:



                In fact, even the new, improved iteration of lossless SmartScale only compressed better than PNG on one case that we tested (which happened to be the same case that the IJG used for its testing.) On two of our test cases, it compressed about the same as PNG. On another, it was decidedly worse. Further, webp compressed better than jpeg-9 across the board, and JPEG-LS compressed better in all but one case (and, to wit, I wasn't even using the best compression settings. I was using the highest-performance settings.) The performance of lossless SmartScale in jpeg-9 was also decidedly not compelling when compared to PNG or even when compared to JPEG-LS in most cases.

                Regarding fragmentation, the SmartScale format introduced in jpeg-8 is not a standard. According to the current IJG maintainer, it was proposed to the ITU-T and rejected (see comments here: http://blog.kaourantin.net/?p=116. Also note the part where he accuses the ISO of being corrupt.) We have always been hesitant to implement this new format because it is not part of the official JPEG spec, so it is unclear that any software other than the IJG's software will ever support it, and it is also unclear whether the format may change arbitrarily in the future. In fact, jpeg-9 introduced an enhancement to the SmartScale format that made lossless files compressed with jpeg-9 incompatible with prior releases of libjpeg.

                uid313's comment regarding support of jpeg-9 is spot-on. Before the format is adopted on the consumer end, it will have to first be adopted on the producer end-- by devices. And they're not going to adopt anything that isn't an official standard. If Mozilla or Google came to me tomorrow and said, "please support this", I would do so, because I know that they wouldn't ask unless they felt like it was enough of an accepted standard that their browsers needed to decode it. Until/unless that happens, though, I'm not going to get behind a non-standard format that may change at any point in the future. Arithmetic coding actually is part of the JPEG spec and is no longer a patent concern, and yet no browsers support that, either-- despite the fact that libjpeg-turbo does support it and libjpeg-turbo is used by two of the most popular browsers out there and all they'd have to do to support arithmetic coding would be to flip a switch.

                Back to jpeg-9. To add insult to injury, the ABI incompatibility introduced in this latest release was, in fact, not even necessary. Rather than introduce a new field in the exposed jpeg_compress_struct, enabling the new color transform could have just as easily been done by way of a new JPEG colorspace constant, which would have preserved ABI compatibility with jpeg-8.

                After I posted my research article to the libjpeg-turbo lists, they basically exploded, and a full read of the thread that ensued is illuminating:



                I'll summarize:

                -- One of the ARM developers did some research of his own, and his research is what prompted me to extend my original research to cover webp and JPEG-LS. Whereas I was already under the belief that jpeg-9 wasn't very compelling when compared to PNG, the addition of webp and JPEG-LS made it even less compelling.

                -- The ARM developer in question CC'ed the current IJG maintainer on one of the messages regarding the new colorspace transform in jpeg-9. The current IJG maintainer responded with very inflammatory remarks regarding webp and basically said that the jpeg-9 format is better because it's JPEG (but it actually isn't, if you define "JPEG" to mean something conformant to the JPEG spec.)

                -- My research, as well as the inflammatory comments from the IJG maintainer, prompted the Fedora developer responsible for integrating libjpeg-turbo to retract his project that sought to upgrade Fedora to the jpeg-8 API/ABI. That project was prompted solely by one library (libkdcraw) that required jpeg_mem_dest() and jpeg_mem_src(), so we will be implementing those functions on top of the existing (jpeg-6b-compatible) API/ABI to preserve backward compatibility for programs that don't use them.

                -- It was decided to reject any emulation of the jpeg-9 ABI. It is our belief that insufficient technical justification exists for software to upgrade from jpeg-8 to jpeg-9, and anyone doing so is doing so only because of a desire to be on the bleeding edge. Personally, I have yet to see any software take advantage of the jpeg-8 features, other than the in-memory source/destination managers. Minimally, such software is rare.

                In short, I think it's safe to say that libjpeg-turbo is in the process of splitting from libjpeg.

                To answer some of the comments:

                -- Regarding Android, Linaro is working hard to get libjpeg-turbo integrated as the default JPEG library in Android, and the performance gains on ARM platforms are similar (2-4x) to those on x86 platforms. No idea about Apple, Nikon, etc., but there should be no technical or legal issues preventing them from using libjpeg-turbo. I use a Mac as my primary machine, and libjpeg-turbo works fantastically well with it.

                -- The IJG's software does not come from a committee. The IJG is basically one guy and really always has been. It's just a different guy now, and he basically hates our guts. Tom Lane, on the other hand, is the original IJG maintainer and has publicly offered up words of support for our efforts.

                Our focus definitely will continue to be baseline JPEG. I find it puzzling that the current IJG maintainer goes out of his way to declare in his README file that people should not use an "incompatible file format", and yet, that is precisely what SmartScale is. The original charter for libjpeg was to encourage the community to rally around a common standard JPEG format, and Tom Lane did so by making the software freely available. We believe that we are continuing this tradition by making the format much faster, and therefore enabling it to be used to classes of applications that might not have been able to use JPEG previously because of performance.

                Feedback and questions are most welcome.

                DRC

                Comment


                • #9
                  Originally posted by DRC42 View Post
                  *snip*
                  Feedback and questions are most welcome.

                  DRC
                  Thanks for that.

                  Comment


                  • #10
                    Well, having finally found an image viewer that uses libjpeg-turbo, I'm definitely a convert. I just wish more image viewers/image editors were using it.

                    Comment

                    Working...
                    X