Announcement

Collapse
No announcement yet.

Could JPEG2000 Finally Take Off In 2020? It's A Possibility With High Throughput HTJ2K

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

  • #11
    I'm not super convinced that AVIF is the future, either. There are competing specs that are very good, for instance FUIF, PIK and JPEG XL. These are properly optimized for still images and not just a container for AV1 I-frames. They are royalty-free, too.

    Comment


    • #12
      Originally posted by birdie View Post
      AVIF is the future. JPEG2000 is too late for the game.
      I, at least, hope so.

      Comment


      • #13
        Originally posted by brent View Post
        I'm not super convinced that AVIF is the future, either. There are competing specs that are very good, for instance FUIF, PIK and JPEG XL. These are properly optimized for still images and not just a container for AV1 I-frames. They are royalty-free, too.
        HEIF has a better chance than JPEG2000 and AVIF or any of those others for one simple reason: I had to install support for it so my mother could open the photos from her damn iPhone.

        Comment


        • #14
          Originally posted by ssokolow View Post

          HEIF has a better chance than JPEG2000 and AVIF or any of those others for one simple reason: I had to install support for it so my mother could open the photos from her damn iPhone.
          Not a chance. It's based on HEVC, which is an unholy mess as far as intellectual property is concerned. That is why so many companies proactively try to avoid using it. This mess was one of the reasons for building AOMedia.

          JPEG XL has a real killer feature going for it, on the other hand: interoperability with JPEG. The JPEG XL encoding tools are a superset of JPEG, so you can re-encode a JPEG image with no quality loss to JPEG XL, while saving some 20% space. The other way around is possible, too: most JPEG XL files can be re-encoded as JPEG files very efficiently, without a full decode. It's good enough for doing it in realtime on the fly.

          Comment


          • #15
            Originally posted by ssokolow View Post

            HEIF has a better chance than JPEG2000 and AVIF or any of those others for one simple reason: I had to install support for it so my mother could open the photos from her damn iPhone.
            In addition to what brent already said, I just wanted to point out that even Apple joined AOMedia, albeit later than other main contributors. I guess that is a sign that even Apple thinks that AV1 and AVIF are the way forward.

            Comment


            • #16
              Originally posted by atomsymbol View Post
              There is no support for automatically extending web browser's list of image decoders (when an unknown image format is encountered) by pointing it to an URL containing packaged code implemented on top of a safe virtual machine.
              You could check a browsers list of supported image formats and if Jpeg2k isn't supported, display the image as a bitmap decoded by a WebAssembly package.

              At least I'm assuming that's what "emScripten-based JavaScript decoder", because emScripten is a WebAssembly compiler

              Comment


              • #17
                Originally posted by brent View Post
                I'm not super convinced that AVIF is the future, either. There are competing specs that are very good, for instance FUIF, PIK and JPEG XL. These are properly optimized for still images and not just a container for AV1 I-frames. They are royalty-free, too.
                FUIF + PIK = JPEG XL and yes it's a very very good format for images. I really hope it will be adapted, but I don't see much excitement sadly.

                As for JPEG 2000 it's a solid format even for today's standards. The biggest obstacles, why it wasn't adapted were not that much the efficiency (which is better than JPEG in almost all cases) and the features, but speed and patents. Patents aren't problem anymore and speed is solved largely with HTJ2K. If it will take of I don't think so, but it did find itself into some standards (PDF for example) and usages (as a format for digital cinema).

                I wouldn't be too sad if JPEG 2000 takes off instead of other formats, but I think the best scenario would be JPEG XL, worst HEIF. AVIF would also be fine, but the thing that bugs me is that it supports lossless, but only for YUV, not RGB. Also AVIF and HEIF have a limited bit depth to 12-bits (more likely 10-bits) per channel and I don't know why a "future proof" image format would need to be limited just that (camera sensors capture 14-bits).

                Comment


                • #18
                  Originally posted by Syfer View Post
                  You could check a browsers list of supported image formats and if Jpeg2k isn't supported, display the image as a bitmap decoded by a WebAssembly package.

                  At least I'm assuming that's what "emScripten-based JavaScript decoder", because emScripten is a WebAssembly compiler
                  I agree, via Javascript/WebAssembly a website developer can internally use any kind of image compression method. A downside is that it won't be possible for the user to save the image to disk, at least not in the same way a JPG/PNG/etc image can be saved to disk, because there is no method (as far as I know) to tell the web browser from Javascript that there exists a save-able image in the rendered web page.

                  Comment


                  • #19
                    Originally posted by ms178 View Post
                    First, there is certainly a need for better picture compression. Just try to upload all your documtens for a job application with a reasonable quality and a hard limit on 2 or 4 MB (as mandated by a lot of public employers over here and that is not per file but for EVERYTHING combined - and don't laugh at me, ancient workflows and legacy IT are still a thing in my sector).
                    Working around that by creating new stuff is funny.

                    Comment


                    • #20
                      These WebAssembly/JavaScript fallback hacks are not going to fly. Not only are they inconvenient for the people that create websites, they are also terrible for battery life and user experience.

                      Comment

                      Working...
                      X