Announcement

Collapse
No announcement yet.

Mozilla Comes Out Neutral On JPEG-XL Image Format Support

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

  • #51
    jxl seems pretty dope actually

    Comment


    • #52
      At the route Mozilla currently is (it's been on this path for a while) I guess it's not a matter of if, but rather when I will pick another browser. And that's shame. I've been using Firefox since I began using computers back in the day...
      What's worse - browser "market" doesn't seem to be in a state where I can say that I would just go and use browser X.

      Comment


      • #53
        Originally posted by ATLief View Post

        I often see variations of this argument regarding many different topics, and I think you're missing the point: users want compatibility with all of their devices, faster loading times, lower bandwidth usage*, and cheaper services. They don't need to know or care about the underlying technologies to appreciate those benefits, and it's stilly to ignore the preferences of literally millions or billions of people just because they can't articulate it in a way that you would prefer.

        *Even if users don't notice the bandwidth or speed differences on the majority of the networks that they use, the size difference will add up over time to noticeably less bandwidth used on metered connections.
        ​
        True. BUT...
        As long as not all major browser support a certain file format it's futile to use it on your webpages. WebP was introduced 12 years ago. How many webpages are you aware of that use it? Even nowadays my phone shoots JPEGs...
        As for the suffering of millions or billions: How many of these millions or billions use adblockers? A small minority. And that would really affect bandwidth.

        Comment


        • #54
          JPEG-XL lives in the same world as gold-plated HDMI cables. No different to any other image format, but lots of people claiming they can tell the difference!

          Comment


          • #55
            Sad to see it's potential left out.

            Comment


            • #56
              Maybe they should be neutral on more things. Usually when they take a stance, it's nothing but cringe.

              Comment


              • #57
                Funny seeing yet ANOTHER software company sucking at software.

                Maintenance shouldn't be an issue when it's just another format notched off once it's added. In reality, a few fixes over a few years is what it'll needed. If they can't even offer to support that for even only slightly better yet open formats, that's actually comically sad.

                They should include its support just to make sure Google can't as easily dictate their future. Literally, that's it, but that's a huge importance.

                Looking up comparisons, it's good enough to be added and the file size and quality is pretty good. Maybe not next-gen, but they're worried about even supporting the damn thing, maybe their ideas on not adding it are just plain stupid. Not like they are proposing an alternative, open, performant format themselves here.

                Just pathetic. What is Mozilla's goal, in anything?

                Comment


                • #58
                  Originally posted by OneTimeShot View Post
                  JPEG-XL lives in the same world as gold-plated HDMI cables. No different to any other image format, but lots of people claiming they can tell the difference!
                  With a comment like this you obviously completely miss the point of compression formats. There is a difference, the difference is in the file size.

                  Comment


                  • #59
                    Originally posted by pkese View Post
                    Sad.
                    JPEG-XL is currently the only format that's actually friendly for developers.

                    When somebody pastes a bunch of pixels to your software, the current procedure is to first test if it needs to be compressed with a lossy (jpeg) or lossless (png) format before proceeding (or else you either get a screenshot image with fuzzy text, or a huge size photo crop).

                    JPEG-XL is currently the only format that does a decent job for all, lossy, lossless and nearly lossless image compression.
                    In addition it can produce a single file for multiple resolutions.
                    I have no idea what you mean by "friendly for developers" in this context. Supporting all those highly unique features requires huge amounts of work. Let's also consider the end-user: he sees a nice image on the web and downloads it. The image software on his computer doesn't necessarily support all those quirks of JPEG-XL, so the downloaded image might appear as lower resolution or lower quality than what the user saw on the web. It might also be unclear how to extract the best quality image for archival purposes. Dragging and dropping the image file into, say, a spreadsheet can yield varying results.

                    I don't see what the real-life benefit is for a single format supporting both lossy and lossless compression. It probably requires twice the amount of code, e.g. amounts to an equal burden of maintenance for the developers as having JPEG and PNG separately...

                    While the technical aspects of JPEG-XL might seem exciting for some HC programmers or techjunkies, they most likely pose a challenge for regular users to be able to understand what is going on under the hood. These features also might even require custom UI implementations to e.g. support switching between the embedded image files.

                    Embedding multiple versions of an image into a single file is also really bad for the web. Web wants to minimize the amount of downloaded data, not bundle unnecessary junk together.

                    Comment


                    • #60
                      Originally posted by abott View Post
                      Funny seeing yet ANOTHER software company sucking at software.

                      Maintenance shouldn't be an issue when it's just another format notched off once it's added. In reality, a few fixes over a few years is what it'll needed. If they can't even offer to support that for even only slightly better yet open formats, that's actually comically sad.
                      Any new code is a security risk. It isn't all that surprising to see image decoding libraries contain proper vulnerabilities that allow an attacker to execute arbitrary code on the compromised computer.

                      Adding a big chunk of code will also increase compilation time and execution time for test suites and so on. All these things cost Mozilla money and human resources, so it isn't just about pouring some new code into the app and forgetting about it.

                      Comment

                      Working...
                      X