Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Graphics

Can JPEG XL Become the Next Free and Open Image Format? (jpeg.org) 106

Posted by EditorDavid from the Joint-Photographic-Experts-Group dept.
"JPEG XL looks very promising as a next gen replacement for JPEG, PNG and GIF," writes icknay (Slashdot reader #96,963): JPEG was incredibly successful by solving a real problem with a free and open format. Other formats have tried to replace it, notably HEIF which will never by universal due to its patent licensing.

JPEG XL combines all the modern features, replacing JPEG PNG and GIF and has free and open licensing. The linked slides from Jon Sneyers review the many other attempts at replacing JPEG plus the obligatory XKCD standards joke.
This discussion has been archived. No new comments can be posted.

Can JPEG XL Become the Next Free and Open Image Format? More

Can JPEG XL Become the Next Free and Open Image Format?

Comments Filter:

  • You mean like JPEG 2000? (Score:4, Insightful)

    by Going_Digital ( 1485615 ) on Saturday August 17, 2019 @03:44PM (#59097502)
    Nothing to see here.

    • JPEG2k (Score:4, Insightful)

      by JBMcB ( 73720 ) on Saturday August 17, 2019 @04:00PM (#59097522)

      I thought JPEG 2000 was only meant to replace lossless formats for professional photography, like TIFF. I think JPEG XR is meant to replace JPEG for photos, along with PNG for graphical elements.

      • JPEG2000 included some improvements in compression as well. It was designed as an all around replacement for JPEG with the benefit of 16bit colour support, and optional lossless compression level.

      • Is JPEG XL a format to allow Americans to take selfies?
      • JPEG-2000 had both lossless and lossy modes of operation (citation: I personally implemented a JPEG-2000 encoder/decoder in C++). The "big breakthrough" on lossy compression was the use of wavelets instead of blocks for compression. This allowed a hierarchical storage scheme that made it easier to gently degrade the entire image to reach the desired bitrate instead of taking a "best guess" average on 8x8 blocks.

        It is also imminently flexible, allowing you to provide your own wavelet transforms, colorspac

    • and JPEG XR

    • Re:You mean like JPEG 2000? (Score:4, Insightful)

      by AmiMoJo ( 196126 ) on Saturday August 17, 2019 @05:01PM (#59097620) Homepage Journal

      No. As TFA points out, this isn't like JPEG 2000.

      JPEG 2000 had numerous issues. No open source reference implementation at first. It was slow and the compression wasn't that much better than JPEG, and the visual quality wasn't great. It couldn't replace other image formats like PNG and GIF well either.

      • Re: (Score:2)

        by theCoder ( 23772 )

        JPEG2000 is a very capable format. It has a numerical lossless compression, so it could replace PNG. The visual quality greatly depends on the amount of compression used, and that is very configurable. More bits/pixel tends to result in better quality, but even at low bpp rates, the images are generally quite good.

        Importantly, the images can be absolutely huge. Much bigger than JPEG or PNG compressions. It allows for up to 2^32-1 pixels (2.1 billion!) in each dimension. JPEG is limited to 2^16-1 (65535

        • I don't know much about its animation support, but you can encode multiple images in a single J2K codestream.

          For video, Digital Cinema Initiatives (DCI) uses JPEG 2000, and thereâ(TM)s also Motion JPEG2000.

    • Re: (Score:2)

      by dwywit ( 1109409 )

      JPEG2000 is used extensively for Digital Cinema distribution. Every digital cinema is using it.

      • I admit, it's been about 15 years since I looked at the standard, but did they extend it to include video? The standard that I was given to develop against was strictly still images.

        • Re: (Score:2)

          by dwywit ( 1109409 )

          Each frame of the video is compressed to JPEG2000 in xyz colour space, then those frames are wrapped into an MXF container. Ditto audio,

          Editing suites like Premiere Pro can convert the MPEG2 frames of video directly into JPEG2000, but there are open-source tools that can do the conversion. Use ffmpeg to extract the video frames to uncompressed TIFF frames, then Imagemagick to convert to JPEG2000, then a tool called OpenDCP can do the rest.

  • The fact we have a number of image formats isn't a big problem. A new image format has to solve a problem. JPEG took off because it was the "best" photographic compressor at the time when we needed one.

    • Re:Sure, just like anyone can become president (Score:4, Funny)

      by phantomfive ( 622387 ) on Saturday August 17, 2019 @03:56PM (#59097516) Journal
      And PNG took off because it was a replacement for GIF at a time when people were getting sued for using GIF.

      Can you imagine if we were still using a format JPG 2000? I would feel like it was the .com era again. "Fund my company, our web property is covered with JPEG2000!" "Oh, that's advanced."

      • Re:Sure, just like anyone can become president (Score:5, Informative)

        by Dutch Gun ( 899105 ) on Saturday August 17, 2019 @07:51PM (#59097878)

        And PNG took off because it was a replacement for GIF at a time when people were getting sued for using GIF.

        "Took off" is sort of relative. It's pretty ubiquitous and well-supported today, but you might recall that it was a major slog getting the format adopted by all the major browsers. In particular, Internet Explorer dragged their heels for many years - no surprise there I guess. And png support in some otherwise prominent image editors was half-assed for quite a while.

        • That in itself is a roadblock but not a great driver for support. WebP is also supported by all major browsers and many (most?) image editors, but more rare than a GIF on the modern internet despite its obvious advantages over JPEG.

          • WebP is also supported by all major browsers

            Edge didn't support WebP until version 18, released in November 2018. Firefox didn't support WebP until version 65, released in January 2019, and Debian is still shipping version 60 (but should be updating to 68 by sometime in October). Apple Safari, with 41% usage share in the United States according to caniuse [caniuse.com], still doesn't.

      • JPEG-2000 is still extremely useful for one particular niche: large satellite or aerial imagery. You can store the entire thing in a massive single 4-10GB file, but have it tiled out in such a way that your viewer can just decode the piece you're looking at and avoid loading the whole thing into memory. Most previous formats required you to load and decode the entire image.
    • Comment removed based on user account deletion

      • and this one does - not only is it "legacy friendly" (ie it will take the old image formats, recode them and will always make smaller image sizes due to the way it recognises each old format) but it creates "responsive" images - ie you can download only part of the file and get a progressively bigger image. The slides showed the same image in different sizes, the more you download the better image you get - not the more your download the less fuzzy the image gets as with current progressive jpeg.

        Might be th

  • You mean it will work on my Commodore 64 and Amiga?

    • Re: (Score:3, Interesting)

      by ShanghaiBill ( 739463 )

      You mean it will work on my Commodore 64 and Amiga?

      Yes. RTFA.

      There is a fast server-based auto-downgrader. So if you connect to a site with an older browser, the server will convert the JPEG-XL to a legacy format on the fly.

  • "Other formats have tried to replace it, notably HEIF which will never by universal due to its patent licensing."

    Patents expire, right? I know that 20 years is a long time, but some of that has elapsed already, and look how long the other formats listed here (JPEG, GIF, PNG) have lasted.

    • Re: (Score:2)

      by tepples ( 727027 )

      Are you willing to wait for 2033 to launch your product?

    • You mean just like we all switched to DjVu already? FLIF would have better odds, but it seems interest fell off a couple of years ago.

      • Re: (Score:1)

        by quikee ( 6171646 )
        Jpeg XL is based on PIK and FIUF, where FIUF is the successor of FLIF. Jpeg XL will contain the technologies developed in FLIF and later in FIUF - the efficient progressive mode is from FLIF. The problem with FLIF and why the author later created FUIF is that FLIF doesn't have a lossy mode (well it was lossy if you just downloaded part of the data but it was very inefficient). A nice thing of FUIF is that it can losslessly transform a JPEG file into a FUIF file (well it uses just a subset of features) which

        • Re: (Score:2)

          by more ( 452266 )
          JPEG XL is more efficient than AVIF and HEIF in the medium to high bits-per-pixel and less efficient in the lowest end. See: https://www.reddit.com/r/AV1/c... [reddit.com] for a medium bits-per-pixel example. I'd never use low bits-per-pixel (0.1 BPP) to publish my images, so I like JPEG XL better. I believe half decent quality with progression is a better compromise for a publisher than going for crappy quality as the only option.
        • Thanks for the pointers! FUIF is at least roughly described in a blog post [cloudinary.com]. One would think, if it's supposed to be a successor to FLIF, it would have a mention anywhere in the FLIF project. But then, it was only dumped as a prototype 7 months ago, with apparently no public development. I guess he decided to go for the committee option with JPEG. I'm still not sure they can replicate the success of the initial codec, what with now seemingly pushing 9 different formats, most of which are overcomplicated.

      • Re: (Score:2)

        by Dwedit ( 232252 )

        DjVu's compression scheme JB2 is known to have issues similar to JBIG2. Improper use of JBIG2 caused Xerox Scanners to change numbers [dkriesel.com] on scanned documents, and I wouldn't want to touch a similar compression scheme that could substitute similar looking symbols to save space.

        • That's simply abusing the lossless detail algorithm to do lossy compression, and would apply to any format where symbol replication is recognized. When comparing to JPEG, the DjVuPhoto (aka IW44) form is more relevant, and it is completely independent of the JB2 codec. Are you avoiding PDF for this reason?

  • We already have webP (Score:5, Insightful)

    by Srin Tuar ( 147269 ) <zeroday26@yahoo.com> on Saturday August 17, 2019 @03:56PM (#59097514)

    And webp already has fairly wide support in browsers

    https://caniuse.com/webp [caniuse.com]

    https://en.wikipedia.org/wiki/... [wikipedia.org]

    • Re:We already have webP (Score:4, Informative)

      by AmiMoJo ( 196126 ) on Saturday August 17, 2019 @05:05PM (#59097628) Homepage Journal

      WebP isn't good for general purpose image encoding though. It's limited to 8 bits per pixel, 16kx16k resolution and only supports 4:2:0. It doesn't support progressive decoding either, which is becoming more and more of a big deal as 4k displays get more common and web sites want to offer images that work for everything from low resolution smarphones up.

      • Re: (Score:2)

        by Dwedit ( 232252 )

        WebP does have the "Fancy Upscale" chroma mode, and that really does look a lot better than vanilla 4:2:0 subsampling, provided you give it enough bits.

        Older versions of the program did not support it, and it might not be obvious how to turn that feature on.

        The classic test case for how good chroma subsampling is a red circle on a white background. If you have bad subsampling, you get dark edges around the place where they intersect. When you use the default 4:2:0 subsampling, you get the nasty edge artif

        • Re: (Score:2)

          by more ( 452266 )
          JPEG XL design philosophy is built around robustness and least surprise. It should not require the use of flags to get decent performance from the encoder. The format is built in a way that it degrades naturally and consistently - although sharply when you move into the area of verynoticeable differences. The encoder quality parameter defines how many multiples you want of just noticeable difference.

    • Re: (Score:1)

      by Average ( 648 )

      "Supported - but not on Safari/iOS" is not supported. As much as I wish we could ignore Safari, or that Apple would get their butts in gear, neither is the case.

      Lossy + Alpha is a combination I very much need for GIS reasons. If WebP were up at 99% browser support, we'd switch to it. Since it's not, a lot of GIS software for raster overlay does a hack of tiling where fully-filled tiles come across as JPG (since we're fine with lossy) and the tiles that are partially-filled (irregular edge cuts) come out

      • Re: (Score:2)

        by tepples ( 727027 )

        Instead of waiting for Apple to support a lossy-with-alpha file format, you could produce your own decoder for a lossy-with-alpha format in C++ and include it in a GIS viewer as a native iOS application that you develop and submit to Apple for approval. Users of all operating systems other than iOS would get the WebP, and users of iOS would get a link to the App Store.

    • Re:We already have webP (Score:4, Interesting)

      by Waccoon ( 1186667 ) on Saturday August 17, 2019 @07:33PM (#59097862)

      WebP is well supported because it was made by Google, and Google forces support in Chrome, the world's most popular web browser. However, nobody actually uses the damn format.

      It's a massive PITA to support. I tried adding support for WebP for my image board, which involves getting the dimensions of an image. This is not trivial by any stretch of the imagination, and requires a lot of low-level bit twiddling. Also, WebP has multiple ways (at least 3) to encode the size even when there's only one image in a file. When just getting the x and y dimensions of an image requires pulling teeth, you know someone really screwed up.

      WebP is another typical Google project. It was thrown together with little thought and is a total mess, and doesn't even have compression much better than JPEG, which is why nobody uses it.

      • Google forces support in Chrome

        Did they also force support in IE and Firefox or did it's incredible market share do that?

        Support is easy, but it doesn't mean anything for an image format. ... Lack of support does mean something.

      • Re: (Score:2)

        by more ( 452266 )
        It is more complex than that. While at highest (camera/art/high level e-commerce) quality old jpeg wins over WebP, at medium and low quality WebP wins with a margin. WebP lossless is a clear winner over other lossless codecs (including avif lossless) until Jpeg xl comes around.

  • Obligatory XKCD is obligatory (Score:3, Funny)

    by TheInsaneSicilian ( 134631 ) on Saturday August 17, 2019 @03:58PM (#59097518)
    Obligatory XKCD: https://xkcd.com/927/ [xkcd.com] ...or slide 15 if you actually read the summary and follow the link.
  • now that the video and text formats finally have settled, picture formats need confusion again! At least, before there had been patent issues before which motivated the introductioni of new image formats like PNG. Cutting the photo size by 60 percent (as claimed) could help a new standard, but bandwith is less and less an issue. Already the question, how the extension of will be called. JPGX ? jIt needs to be different to avoid confuction. But already the DOC to DOCX transition was awkward.

    • Re: (Score:3, Insightful)

      by ShanghaiBill ( 739463 )

      Already the question, how the extension of will be called. JPGX ?

      RTFA. The extension will be .JPG, same as now.

      Web servers will look at the brower's header, and determine if they can handle JPEG-XL. If so, that is what they get. If not, the server will auto-downgrade to an older/bigger/slower legacy format.

      This avoids the chicken-or-egg problem. Servers and browsers can upgrade asynchronously. Using the same extension ensures that adoption will happen quickly.

      • The extension will be .JPG, same as now.

        Ugh. That's annoying. Old OSes can handle new extensions, it should have a new extension. I'm sure something already uses .JXL, but I've never seen it, so it can piss off.

      • How about applications that work with local files? I didn't get from the slides whether a JPEG-XL .jpg file could be understood by a non-JPEG-XL-aware application.

        • yes and no, while you can;t read a jxl file with a standard applicaton, they do have "automatic" conversion back to jpeg for legacy apps. I'm sure it works, but not sure of the logistics of getting it.

          Still, if jxl is free and open source, codecs will become available for all OSes in no time, and then it won't matter for anything other than image editors, who will no doubt get updates.

      • Re:No. (Score:4, Informative)

        by AmiMoJo ( 196126 ) on Sunday August 18, 2019 @03:19AM (#59098474) Homepage Journal

        Actually TFA is suggesting .jxl as the file extension.

    • bandwith is less and less an issue

      I disagree. I contend that with the shift from desktop browsing over wired (or Wi-Fi with a wired uplink) to mobile browsing over cellular, the $5 to $10 per GB overage fees that cellular providers in the United States charge become even more significant.

      • Bandwidth is also a significant issue in developing countries. Even when there aren't billing caps, there are practical limitations associated with the number of devices per tower, which can spike randomly, overwhelming the available uplink.

    • Re: (Score:3)

      by Misagon ( 1135 )

      In the slides, the file extension is ".jxl".

      But I think there will be confusion between
      * Lossy .jxl
      * Lossless RGB .jxl
      * Lossless indexed .jxl, and
      * Animated .jxl

      I propose .jxl for lossy, .jxll for lossless, .ixl for indexed, and everything preceded by 'a' for animated.

      • why? All the info is in the same file, so lossless, lossy can all have the same extension. just like a jpg can be compressed or not, or both plain or animated gifs are still just gif.

        • Re: (Score:2)

          by tepples ( 727027 )

          All the info is in the same file

          Info inside the file is not available to a file manager's "sort by extension" feature unless the file manager's publisher has chosen to update it to open each of possibly thousands of .jxl files in a folder and scan its contents.

    • Re: (Score:2)

      by jimbo ( 1370 )

      Any large scale host serving images would love keeping their bandwidth usage in check. Google have done work in improving image compression for this reason.

  • Please yes (Score:3, Insightful)

    by locater16 ( 2326718 ) on Saturday August 17, 2019 @04:02PM (#59097526)
    Finally? Please?

    This is a major fucking headache for artists, for websites, for etc. Let's just declare it, JPEG XL is it, it's the standard. Hold the fuckers down at gunpoint until they implement it. Just take Satya and Tim hostage. The standard looks fine, that's not the challenge, the challenge is getting egotistical fuckwits called engineers to just implement it.

    • Re: (Score:2, Insightful)

      by phantomfive ( 622387 )

      Finally? Please?

      Why do you want it? What do you like about the new standard?

      This is a major fucking headache for artists, for websites, for etc.

      There's a 90% chance that artists and websites don't care about nonlinear Haar transforms that are introduced by JPEG XL.

      • Re: (Score:2, Flamebait)

        by locater16 ( 2326718 )
        I'm an artist halfwit, jpeg compression sucks balls, hdr is amazingly fun to play with, getting to three times the compression ratio would make instagram stop double compressing images to save half a penny. Engineers that don't know and don't care what users want is why we can't have nice standards, they don't need it so it doesn't matter.
        • You're clearly one of those bitter artists. So you want better compression? Why not say that? Engineers don't like to talk to you because if you're bitter and miserable, no one likes to talk to you.

        • Re: (Score:3, Funny)

          by Zero__Kelvin ( 151819 )

          "I'm an artist halfwit"

          But I'm guessing English is not your first language. In English we say that you are a "halfwit artist".

          • Perhaps he was just trying to prove his own statement, or would that be giving an artist too much credit?
            I have nothing against artists, they make excellent waiters.
            • If all artists were halfwits it would be redundant to say he is a halfwit artist. Many artists are brilliant, and some are even geniuses. Literally every good software engineer is part artist, as software development involves a blend of art and science. This does not mean, conversely, that every artist is an engineer, as our halfwit artist has shown. Finally, while I have never been a waiter, that job would not be easy for someone with low IQ.

        • Re: (Score:1)

          by AHuxley ( 892839 )
          Should the user be able to extract the images that made the artists HDR for "free"?
          Should the GPU, OS, smartphone, network be able to "do" extra math to the HDR to change the final "artist" created HDR image?
          So it displays well in a dark room? On a slow network? For a company trying to save on network costs?
          So it looks good on a lcd? The AI-enhanced TV? Local dimming not doing enough?
          Can the artist set how the HDR will look on different HDR display tech?
          On a smartphone, 4K/8K consumer "TV", the we

          • Re: (Score:2)

            by Jmc23 ( 2353706 )
            it's for copypasta artists, who need details in photos because looking at reality or imagination is hard. They lost me at 'visually' lossless.

      • There's a 90% chance that artists and websites don't care about nonlinear Haar transforms that are introduced by JPEG XL.

        But they do care about having an alpha channel, and images that are 60% smaller ... and 60% faster to load or transmit.

      • There's a 100% chance that artists care about wide gamut colours, and JPEG don't deliver. They also don't care about formas, they just want to use one and have done with it - not be told that they must use format X for this, format Y for that, and format Z if they want some other feature.

        this supports them all, and offers some pretty cool features like progressive streaming. JPEG is a standard almost everyone uses unless they need things like alpha or lossless, this gives it them.

    • Not much ambiguity in your post.

      What are you going to do when something better comes along (and something better will come along) - are you going to say again that the new image format is THE STANDARD and "Hold the fuckers down at gunpoint until they implement it." again?

      Why don't we see more than a 48 slide presentation and hear what the bosses of the "egotistical fuckwits" has to say.

    • I agree with you on your first part about implementing it, but not on your last part about "egotistical fuckwits called engineers".

      I am myself an engineer working with software development since 1992 when I graduated with an M.Sc. in it, and still doing it.

      Unfortunately us 'egotistical fuckwits called engineers' don't usually decide much regarding what will eventually be used or included in a product.
      That may be decided by a totally non engineering type manager, or a manager that used to be an engineer but

    • This is a major fucking headache for artists, for websites, for etc.

      Defend that statement. How is it a major headache for artists?

      Artists have many lossless formats to support their workflow and storage. JPEG is visual indistinguishable for publication purposes. There's no benefit to be had here because even if there was another format the workflow is still the same.

      What about websites? What is such a problem with JPEGs for websites?

  • "Responsive by Design" aspect where the image is "squeezed" (to use the presentation's terms) so that only a certain amount of the image's file needs to be used to best show the image on the current display. Now, the problem is for apps (and browsers) to take advantage of this feature and minimizing downloading for the specific device display being used.

    Otherwise... I think people have already asked, what problem does it solve and I'm not sure that the "Responsive by Design" feature is good enough for thi

  • Does anybody know how to convert Google's new html photo package to ordinary JPEG? No help at support.google.com

  • Maybe JPEG-XL could meet the demand for better compression and higher dynamic range, but it has a lot of other things: It supports both lossy and lossless compression, progressive encoding and animation: so that it could replace both JPEG, PNG and animated GIFs.

    The slides don't describe how exactly the progressive decoding works, but the "squeeze" slides makes it look like wavelet encoding in addition to DCT encoding.

    I also don't see how color-indexed images would fit into a model using colour spaces ... Is

    • Re: (Score:3)

      by tepples ( 727027 )

      If a file is a PNG file you know it is lossless.

      You don't know whether a PNG file has been converted from high color depth to 8 bits per channel or from 8 bits per channel to indexed color to save space.

  • This looks like a good, standardized way to archive jpeg files. If I can find the promised utilities to convert directly between standard jpeg and XL.

  • I think it's a bad idea to brand like that when it can lead to astonishingly similar extensions and confusing MIME types. The last thing I want is seven different flavors of jpeg. Not everyone is going to be an expert.

    I know folks want to ride on the coattails of the JPEG name, but please, for the love of Christ, name it something distinctive if and when it's implemented.

    No. I think .jpx, or .jpgxl, or .jpgx won't be confusing to me, but you'd be surprised, you might get *all three*, and these things always

  • What about MNG? Was supposed to be very advanced.

    • What about MNG? Was supposed to be very advanced.

      It was. So advanced nobody implemented all the features, and the implementations were all full of security holes.

  • An older press release [jpeg.org] says that the software to handle this format won't be available until at least October.

  • ... and how much more complexity does it take?

    There have been plenty of JPEG "competitors" which are "much" better on select images, and something like 10-30% better on randomly selected images. However they add a lot more complexity to it.

    JPEG has set rather high standards, and so far nobody has been able to be significantly better than it. Since switching to a new standard is expensive, files would have to be an order of magnitude smaller to cover the cost of complexity.

    It's not like the web today is slow

    • I can tell you one thing... its not the size of the files that will matter.

      How do I know? Because ZIP, 7ZIP, and RAR are much worse at compression than the top compressors are, yet still people only use these. When I say much better, I am not talking about only a 10% to 30% savings. I'm talking about a 50% to 80% savings, and this isnt "something new." Much better compressors have been around for DECADES.

      • Well ZIP is mostly used for compatibility, RAR is mostly used by what's known as idiots, even though the problem with RAR is now much less than it used to be before FOSS implementations came about.

        JPEG has the big advantage that it's compression is perfectly adequate, yet everybody supports it. It's not like video codecs where every generation improves around 30% over the previous one.

      • Re: (Score:2)

        by ytm ( 892332 )

        How do I know? Because ZIP, 7ZIP, and RAR are much worse at compression than the top compressors are, yet still people only use these. When I say much better, I am not talking about only a 10% to 30% savings. I'm talking about a 50% to 80% savings, and this isnt "something new." Much better compressors have been around for DECADES.

        And what are those? Just being curious.

        • Re: (Score:1)

          by quikee ( 6171646 )

          And what are those? Just being curious.

          Considering 7Zip uses LZMA, which is one of the most efficient algorithms we have today, the only one that comes to my mind would be PAQ. But the efficiency depends greatly on the type of the content.

        • Re: (Score:2)

          by more ( 452266 )
          The best research compressors are those built by Alexander Rhatushnyak. http://prize.hutter1.net/ [hutter1.net] He was also one of the leads of the JPEG XL standardization work: https://arxiv.org/abs/1908.035... [arxiv.org]

          • Re: (Score:2)

            by Dwedit ( 232252 )

            PAQ is also over 1000 times slower than 7-zip to compress and decompress, making it impractical for most use cases.

      • Re: (Score:2)

        by more ( 452266 )
        btw, 7zip has the 'brunsli' part of JPEG XL in it's M-filter package. https://encode.su/threads/15-7... [encode.su]
      • Comment removed based on user account deletion
  • I don't the relative strenghts of each format but AVIF (image format based on AV1 video compression) is also available and patent-free (because AV1 is).

    • Re: (Score:2)

      by more ( 452266 )
      https://www.reddit.com/r/AV1/c... [reddit.com] JPEG XL is faster to decode (10x?), faster to encode (20x?) and looks quite a lot better. JPEG XL is more compatible with image encoding by having progression, responsive features and support for multi-threaded decoding. AVIF has better SSIM and PSNR scores but looks worse by a hefty margin.

    • Re: (Score:2)

      by Dwedit ( 232252 )

      I've heard that while AVIF does support a lossless mode, you need to get the color depth up to 10-bit YUV with no chroma subsampling in order to encode full range 8-bit RGB losslessly. And once you are at 10-bit YUV with no subsampling, your file size is worse than WebP's lossless mode, and it takes much more processing power to encode and decode the image.

  • I thought that PNG was a "next gen replacement" for GIF about 20 years ago?
  • JPEG is now almost 30 years old. Compared to other standards, it has done incredibly well. At this point, however, we have gigantic 8K screens and tiny wristwatch screens, and everything in between. We have displays that are very common an very widely deployed that are much better than the best displays of the early 90s when JPEG was introduced. Still images need higher image quality as compared to moving images. A format like GIF attempts to do both. What we are looking for in a JPEG replacement is: all

  • When will the camera manufactures and photography suites begin to support this?

    Nothing will happen in the photography world until Adobe, Corel, Phase One, Serif (Affinity Photo). etc. start supporting this format. Also, the camera manufactures need to abandon their default JPEG engines to support this new format.

    Until this "format" has been approved, blessed and standardized by the ISO - then nothing will happen.

  • My perfect would be image format includes an embedded checksum! I hate coming across corrupted images. Hell, even any file format other than plain text should have embedded checksums. A tiny 32 extra bytes for an image or video that is going to be kept forever is nothing!
  • Hey jerks @ everywhere these days, if I wanted my animated gifs to have the compression artifacts of jpegs I'd be saving them as mp4s. I'm saving gifs as gifs for a reason. If I wanted my shit to be a webm I'd be uploading a webm.

Slashdot Top Deals

Understanding is always the understanding of a smaller problem in relation to a bigger problem. -- P.D. Ouspensky

Close