Announcement

Collapse
No announcement yet.

Google Continues Pushing Its WebP Image Format

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

  • #11
    Originally posted by brent View Post
    Furthermore, JPEG already includes some of the advertised advantages of WebP in the standard as optional features, such as a lossless mode and arithmetic coding.
    Which only libjpeg supports and all other (like the most used library for jpeg decoding - libjpeg-turbo) will never support.

    Comment


    • #12
      Originally posted by quikee View Post
      Which only libjpeg supports and all other (like the most used library for jpeg decoding - libjpeg-turbo) will never support.
      why it will never support them? (honest question)

      Comment


      • #13
        Originally posted by psychoticmeow View Post
        I'd rather Xiph.org was in charge, that's for sure.
        All I read was this and it was enough for me to totally agree with you.

        Comment


        • #14
          Originally posted by profoundWHALE View Post
          All I read was this and it was enough for me to totally agree with you.
          Opus and Dalaa seem be proving great competency on Xiphs part to just toss out 30 years of cruft and figure out modern ways to get great balances of compression, latency, and decode time. I'd love to see what they could do with static images.

          Comment


          • #15
            Originally posted by psychoticmeow View Post

            A few years ago I was involved in creating doctorwho.tv for BBCWW. This website currently has huge banner images that use alpha transparency, and I know for a fact that they'd like to have more elaborate images still. The problem with this is that these images are absolutely huge to download: one of the banners is 850KB alone, using WebP this same image would be served at roughly 150KB. You just can't do that with JPEG.

            Now it's true that you can get pretty decent compression with PNG these days using some fairly neat tools. But the problem with these tools is that they either require a human to check the results, or they require integration into existing software (in the case of BBCWW, into PHP extensions). Either the BBCWW ditches automatic image processing in favour of having humans curate all images at a huge cost, or they adopt WebP or another similar format.

            Is the BBC not able to work pngout, or zopfli into their workflow? I wonder, because using pngout on your image saves 3%, and zopfli saves 6% both losslessly. They are missing out on a 50KB savings , simply because they can't run a command line program? Here is a losslessly compressed version of your banner http://i.imgur.com/NUhAsrA.png I made it completely automatically.

            Comment


            • #16
              Originally posted by zanny View Post
              Opus and Dalaa seem be proving great competency on Xiphs part to just toss out 30 years of cruft and figure out modern ways to get great balances of compression, latency, and decode time. I'd love to see what they could do with static images.
              They've been applying their compression to static images as a way of testing it, but I think I might ask them about it as an image format.

              Comment


              • #17
                Originally posted by bondTongue View Post
                Is the BBC not able to work pngout, or zopfli into their workflow? I wonder, because using pngout on your image saves 3%, and zopfli saves 6% both losslessly. They are missing out on a 50KB savings , simply because they can't run a command line program? Here is a losslessly compressed version of your banner http://i.imgur.com/NUhAsrA.png I made it completely automatically.
                I just saw this message, but no, it just doesn't make sense to install additional unofficial software onto multiple servers so that we can reduce the image sizes slightly, especially since we already have access to WebP as a part of PHP. The problem we want to solve isn't our bandwidth costs, but the cost in website responsiveness from having 5MB of banner images and lots of people having poor internet connections. 50KB isn't going to cut it.

                I should also point out that I no longer work for R&B Creative who are responsible for the BBCWW websites, so I won't actually be doing anything

                Comment


                • #18
                  Originally posted by NomadDemon View Post
                  give me jpeg with transparency, and i will use it again
                  It's called JNG. At its peak it had more support than webp has now, though now it's mostly been removed since adoption didn't take up.

                  Comment


                  • #19
                    Originally posted by tomato View Post
                    why it will never support them? (honest question)
                    OK, I was wrong about arithmetic which is supported by libjpeg-turbo but rarely anybody enables it (there were also patent problems with arithmetic but I think all patents have now expired).. Even so, when you use jpeg with arithmetic you never know if the user will be able to see it or not - which makes this really useless.

                    As for other features see http://www.libjpeg-turbo.org/About/Jpeg-9. In short.. they are non-standard extensions and rejected by ITU-T.

                    Comment


                    • #20
                      Originally posted by quikee View Post
                      OK, I was wrong about arithmetic which is supported by libjpeg-turbo but rarely anybody enables it (there were also patent problems with arithmetic but I think all patents have now expired)..
                      It's likely disabled in many implementations for historic patents reasons, unfortunately. As you noticed, the patent expired (many years ago). Arithmetic coding is part of the JPEG standard. Toggling the switch to enable it ought to be much simpler than introducing a completely new format!

                      Even so, when you use jpeg with arithmetic you never know if the user will be able to see it or not - which makes this really useless.
                      WebP already has the same issue, it's not fully backwards compatible and some features are optional.

                      As for other features see http://www.libjpeg-turbo.org/About/Jpeg-9. In short.. they are non-standard extensions and rejected by ITU-T.
                      The older JPEG-LS format extension is standard (ITU) and popular in some domains. The SmartScale stuff is rather strange, yeah, but I wasn't talking about that.

                      Comment

                      Working...
                      X