Announcement

Collapse
No announcement yet.

Darktable 4.2 Released With JPEG-XL Support

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

  • quikee
    replied
    Originally posted by Quackdoc View Post
    well, for quality, webp is limited to 8bit so even for the lossless compression which is admittedly fairly good, that only goes for 8bit images, which means high fidelity images will suffer...
    Lossy WebP is also limited to 4:2:0 only, which is IMHO a worse limitation than just being limited to 8-bit as even JPEG has 4:4:4 mode. Also isn't WebP using TV range YCrCb colorspace (same as JPEG), which is in reality only about 6.5 bit per channel...

    Leave a comment:


  • Quackdoc
    replied
    Originally posted by elatllat View Post

    Can you quantify that?
    well, for quality, webp is limited to 8bit so even for the lossless compression which is admittedly fairly good, that only goes for 8bit images, which means high fidelity images will suffer. this means that the physical quality ceiling of webp is far lower then JXL, and as for compression, it's already well known that webp vs an optimized jpeg (see mozjpeg) isn't really worthwhile and even often beats webp lossy. JXL will always be as small as or smaller then a jpeg when losslessly transcoding it. JXL in general has quality:size ratios that dward that of webp, beating even avif handily.

    So compression ratios and quality ceiling on JXL are better then webp, (still getting better as libjxl improves) lets talk about things webp just straight up doesn't do, things like progressive decoding, (critical for modern web IMO) it heas a neat feature where you can encode multiple size images into a single image so it can server multiple devices without needing multiple images. (Quite similar to how android handles assets too). it allows for increadibly high resolutions, the kinda that would make the fellas at nasa have wet dreams. it has 4000+ channels allowing for absurd amounts of additional data, vs webp's 4 channels.

    JXL is truely a next generation format.

    Leave a comment:


  • piotrj3
    replied
    Originally posted by elatllat View Post

    Can you quantify that?


    Look at comparisons made by WEBP/WEBP2 team of google.

    Also in feature set JXL looks really good. It offers pretty much everything, very high bit color depth, HDR etc.

    Also it has realtivly good encoding and decoding times. Eg. encoding and decoding times are actually faster on jpegxl then on webp. And with faster encoding/decoding times it is actually (at worst) metrics on par in quality and at best metrics far outpaces it.

    For me AVIF and JXL are perfect formats together. For low fidelity images with low bitrate AVIF is better for high fidelity images (and especially lossless encoding) JpegXL does better. JpegXL especially doesn't slow down with higher bitrates while pretty much every other format do significantly

    Leave a comment:


  • elatllat
    replied
    Originally posted by Quackdoc View Post

    loads. its better in every single way except for enc/dec speeds (even then they aren't bad at all) and animations, however file size, file fidelity, flexibility web use etc. its all better then webp
    Can you quantify that?

    Leave a comment:


  • Quackdoc
    replied
    Originally posted by elatllat View Post
    Is JPEG-XL offering any improvement over WebP?
    loads. its better in every single way except for enc/dec speeds (even then they aren't bad at all) and animations, however file size, file fidelity, flexibility web use etc. its all better then webp

    Leave a comment:


  • elatllat
    replied
    Is JPEG-XL offering any improvement over WebP?

    Leave a comment:


  • bug77
    replied
    Originally posted by schmidtbag View Post
    Just in time for Chrome to kill it off.
    Well, someone has to output the image if Chrome is to have something to ignore

    Originally posted by Hans Bull View Post
    Another great release, especially wrt to highlight reconstruction! And for those interested in image processing, three days ago was also released Hugin 2022.0.0.
    Ah, good ol' Hugin... That's good to know.
    Last edited by bug77; 22 December 2022, 11:02 AM.

    Leave a comment:


  • Quackdoc
    replied
    Originally posted by schmidtbag View Post
    Just in time for Chrome to kill it off.
    this has I believe actually wound up motiviating people to implement it. afterall google will implement what people use, people can absolutely force chrome to add support back.​

    Originally posted by Danny3 View Post
    Nice to hear that they're adding JPEG-XL support!
    Fuck Google and its monopoly!
    not like firefox is much better right now​

    Originally posted by ksec View Post
    It is sort of strange to see some JPEG-XL support on this site considering how many AOM supporters are here.
    most AV1 enthusiasts are also JXL enthusiasts. it's not AOM supporters, it's AV1 supporters. most people just want the best compression possible which is what JXL offered​

    Leave a comment:


  • Old Grouch
    replied
    Originally posted by Slartifartblast View Post
    I suppose what really matters is the major camera manufacturers supporting it otherwise I suspect it will end up toast.
    Not really: JPEG-XL stores jpeg files (on average) using less space than the originals, while producing bit-for-bit identical copies of the resultant image when expanded. This is useful when you are storing lots of jpeg files: it can save you monetarily significant amounts of space. Cameras don't have to support JPEG-XL for it to be useful.

    Leave a comment:


  • Slartifartblast
    replied
    I suppose what really matters is the major camera manufacturers supporting it otherwise I suspect it will end up toast.

    Leave a comment:

Working...
X