is it a formatting step that an image goes through when uploaded? I’m tired of converting image after image back into jpg, so if there’s like a step I can take to avoid it being a webp, it would help to know

  • willya@lemmyf.uk
    link
    fedilink
    English
    arrow-up
    215
    arrow-down
    7
    ·
    edit-2
    1 year ago

    The compression to quality ratio of webp is amazing, especially webm. Some instances have this conversion happen upon upload would be my guess to save a crazy amount of space.

    • setVeryLoud(true);@lemmy.ca
      link
      fedilink
      arrow-up
      32
      arrow-down
      2
      ·
      1 year ago

      Don’t forget that JPEG-XL is better, yet Google refused to implement it in Chrome to push their own webp format so it’s basically DOA.

      • Vanon@lemmy.world
        link
        fedilink
        English
        arrow-up
        23
        ·
        edit-2
        1 year ago

        It’s super impressive, and not DOA. Apple (unbelievably) announced it will support JXL on Safari and all-the-things. I wish Mozilla would have led the way, but OK. Hopefully this finally pushes Microsoft and Google to support it.

        I’m using XnView to easily batch convert (90-98 quality, 7-8 compression), and have been loving it. Just needs browser and OS support.

    • BorgDrone@lemmy.one
      link
      fedilink
      arrow-up
      26
      arrow-down
      6
      ·
      1 year ago

      WebP is a tiny bit better on small images and slightly worse overal than JPEG, when using a good encoder library (mozjpeg). It is better than standard libjpeg but that’s not really a fault of the format as much as of the specific encoder.

      • idunnololz@lemmy.world
        link
        fedilink
        arrow-up
        31
        arrow-down
        3
        ·
        edit-2
        1 year ago

        JPEG compression is standardized. The only part of the algorithm that is configurable is the quantization matrix which is essentially a control of what information to throw away and how much. So unless you are throwing away a huge amount of information (really shitty image), there is no way a different library will somehow save you a bunch of space.

      • MHLoppy@fedia.io
        link
        fedilink
        arrow-up
        28
        ·
        edit-2
        1 year ago

        It depends a lot on what’s being encoded, which is also why different people (who’ve actually tested it with some sample images) give slightly different answers. On “average” photos, there’s broadly agreement that WebP and MozJpeg are close. Some will say WebP is a little better, some will say they’re even, some will say MozJpeg is still a little better. Seems to mostly come down to the samples tested, what metric is used for performance, etc.

        I (re)compress a lot of digital art, and WebP does really well most of the time there. Its compression artifacts are (subjectively) less perceptible at the level of quality I compress at (fairly high quality settings), and it can typically achieve slightly-moderately better compression than MozJpeg in doing so as well. Based on my results, it seems to come down to being able to optimize for low-complexity areas of the image much more efficiently, such as a flatly/ evenly shaded area (which doesn’t happen in a photo).

        One thing WebP really struggles with by comparison is the opposite: grainy or noisy images, which I believe is a big factor in why different sets of images seems to produce different results favoring either WebP or JPEG. Take this (PNG) digital artwork as an extreme example: https://www.pixiv.net/en/artworks/111638638

        This image has had a lot of grain added to it, and so both encoders end up with a much higher file size than typical for digital artwork at this resolution. But if I put a light denoiser on there to reduce the grain, look at how the two encoders scale:

        • MozJpeg (light denoise, Q88, 4:2:0): 394,491 bytes (~10% reduction)
        • WebP (light denoise, Picture preset, Q90): 424,612 bytes (~29% reduction)

        Subjectively I have a preference for the visual tradeoffs on the WebP version of this image. I think the minor loss of details (e.g., in her eyes) is less noticeable than the JPEG version’s worse preservation of the grain and more obvious “JPEG compression” artifacts around the edges of things (e.g., the strand of hair on her cheek).

        And you might say “fair enough it’s the bigger image”, but now let’s take more typical digital art that hasn’t been doused in artificial grain (and was uploaded as a PNG): https://www.pixiv.net/en/artworks/112049434

        Subjectively I once again prefer the tradeoffs made by WebP. Its most obvious downside in this sample is on the small red-tinted particles coming off of the sparkler being less defined, [see second edit notes] probably the slightly blockier background gradient, but I find this to be less problematic than e.g., the fuzz around all of the shooting star trails… and all of the aforementioned particles.

        Across dozens of digital art samples I tested on, this paradigm of “WebP outperforms for non-grainy images, but does comparable or worse for grainy images” has held up. So yeah, depends on what you’re trying to compress! I imagine grain/noise and image complexity would scale in a similar way for photos, hence some of (much of?) the variance in people’s results when comparing the two formats with photos.


        Edit: just to showcase the other end of the spectrum, namely no-grain, low complexity images, here’s a good example that isn’t so undetailed that it might feel contrived (the lines are still using textured [digital] brushes): https://www.pixiv.net/en/artworks/112404351

        I quite strongly prefer the WebP version here, even though the JPEG is 39% larger!

        Edit2: I’ve corrected the example with the sparkler - I wrote the crossed out section from memory from when I did this comparison for my own purposes, but when I was doing that I was also testing MozJpeg without chroma subsampling (4:4:4 - better color detail). With chroma subsampling set to 4:2:0, improved definition of the sparkler particles doesn’t really apply anymore and is certainly no longer the “most obvious” difference to the WebP image!

        • Franzia@lemmy.blahaj.zone
          link
          fedilink
          arrow-up
          3
          ·
          1 year ago

          You are like an evil genius? Can you make your own posts about image recompression and how I can get in on this special interest?

          • MHLoppy@fedia.io
            link
            fedilink
            arrow-up
            2
            ·
            edit-2
            1 year ago

            Hahaha, I think you’re giving me a bit too much credit - I was just curious enough to run some tests on my own, then share the results when I saw a relevant post about it!

            My interest in image compression is only casual, so I lack both breadth and depth of knowledge. The only “sub-field” where I might quality as almost an actual expert is in exactly what I posted about - image compression for sharing digital art online. For anything else (compressing photos, compressing for the purpose of storage, etc) I don’t really know enough to give recommendations or the same level of insight!

            Edit: fixed typo and clarified a point.

    • damian101@discuss.tchncs.de
      link
      fedilink
      arrow-up
      15
      arrow-down
      1
      ·
      1 year ago

      Webm is just a video container, not a format. WebP uses quite outdated image compression from the VP8 video codec, which may perform quite a bit better than JPEG at very low quality, but at near-transparent quality, which images are usually encoded to, it very often doesn’t even beat JPEG.