[HN Gopher] JPEG XL against AVIF tested on ImageEngine
___________________________________________________________________
JPEG XL against AVIF tested on ImageEngine
Author : ksec
Score : 138 points
Date : 2023-06-11 17:26 UTC (5 hours ago)
(HTM) web link (mastodon.online)
(TXT) w3m dump (mastodon.online)
| toastal wrote:
| What's missing is the encoding time difference. AVIFs are _slow_.
| shmerl wrote:
| Can't GPU encoders be used for it? If they work for AV1 they
| should work for AVIF too.
|
| And software encoders are improving as well.
| brucethemoose2 wrote:
| Theoretically... But:
|
| - There are no implementations of this, AFAIK
|
| - They would suffer from the same adoption difficulty
| hardware video encoding suffers from.
|
| - They would suffer from the same quality issues and format
| limitations compared to software encoders (where intel/nvidia
| dGPU hardware AV1 maxes out at ~x265 medium last I checked)
| gyanreyer wrote:
| One of the biggest things I'm interested in is encode times. I
| have a static site where I automatically optimize and create a
| webp version of every image at build time and it's always very
| fast. When I tried adding avif into the mix as well, build times
| absolutely skyrocketed. Obviously I was able to resolve that
| problem with caching, but it just all becomes much more of a pain
| to manage.
| bscphil wrote:
| Objective metrics (like dssim) are not the best way to compare
| image codecs. This is in part for the obvious reason - that none
| of them are perfect and the human eye is better - but also for
| other reasons, including that some codecs use metrics
| _internally_ for bitrate targeting, and these metrics can
| _disagree_ with the metrics used by other codecs. Without a
| visual comparison, it 's impossible to say which metrics are
| better for a given set of images.
|
| JPEG XL was based (in part) on Google's "pik" codec, which used
| the Butteraugli metric for bitrate targeting.
|
| Use your eyes instead: https://afontenot.github.io/image-formats-
| comparison/#wasser...
| spider-mario wrote:
| True, but at least dssim is not the worst one to use.
| pornel wrote:
| Objective metrics have many weaknesses and pitfalls, but keep
| in mind that just eyeballing images is not necessarily better.
|
| Non-blind n=1 human test can be just as flawed. What you like
| in a particular scenario is not representative of codecs'
| overall performance.
|
| Testing with humans requires proper setup and a large sample
| size (which BTW JPEG XL has done!)
|
| The problem is that these codecs are close enough in
| performance to be below "noise" level of human judgement.
|
| You will not be able to reliably distinguish q=80 vs q=81 of
| the same codec, even though there is objectively a difference
| between them. And you can't lower quality to potato level to
| make your job easier -- that changes the nature of the
| benchmark.
|
| People also just differ in opinion whether blurry without
| detail is better than detailed but with blocking or ringing. If
| you ask people to rate images, stddev of their scores will be
| pretty large, so wide that scores of objective metrics can fit
| in 1-sigma.
|
| People also tend to pick "nicer" image, rather than the one
| that is closer to the original. That's a bit different task
| than codecs aim for.
|
| Codecs can allocate more or less of the file to color channels,
| so you can get different conclusions based on e.g. amount of
| bright red in the image.
|
| So testing is hard. Plenty of pitfalls. Showing a smaller file
| that "looks the same" is easy, but deceptive.
| class4behavior wrote:
| Hm, if you zoom in you can clearly see the difference between
| jxl and avif. The problem is rather the inconsistency of the
| results.
|
| For instance, at medium quality Jxl seems to be better at
| preserving fine details and structure like the mark on the
| door, the traces on the lower part of the bridge, but avif
| appears to be better at preserving clarity of complex
| details, like far-away windows, cars, a tennis racket.
| pornel wrote:
| Lossy codecs intentionally allow distortions that are too
| small to see with the naked eye (without zooming in).
| They're designed to operate at some "normal" viewing
| distance. If you zoom in, you defeat that technique.
|
| In case you actually wanted to compress images specifically
| for viewing when zoomed in, you should use different
| codecs, or higher quality, or configure codecs differently
| (e.g. in classic JPEG make quantization table preserve high
| frequences more).
|
| But for a benchmark that claims to compare codecs in
| general, you should only use normal viewing distance.
| Currently it's controversial whether the norm is still
| ~100dpi or whether it should be the "Retina"/2x resolution,
| but definitely it's not some zoomed-in 5dpi.
| YetAnotherNick wrote:
| To me, AVIF seems to be better for preserving sharp edges,
| JPEG XL seems better for preserving textures.
| bscphil wrote:
| Agreed that large double-blinded surveys with trained
| participants is pretty much the gold standard, and that
| there's no true objectivity about e.g. blurring vs blocking.
|
| > Showing a smaller file that "looks the same" is easy, but
| deceptive.
|
| It's much better to show same-sized files and let the viewer
| assess their quality (this is what the comparison I linked
| does), but there are deceptive ways to do even this.
|
| See also this great old blog post about doing comparisons for
| video codecs: https://web.archive.org/web/20141103202912/http
| ://x264dev.mu...
| jorvi wrote:
| > People also tend to pick "nicer" image, rather than the one
| that is closer to the original. That's a bit different task
| than codecs aim for.
|
| Samsung turns their screens and phone cameras to "vivid"
| processing by default (they do provide a "natural" toggle, to
| their credit).
|
| I think over 90% of people don't realize what they are seeing
| is not close to reality, and instead ask people with other
| phones, especially iPhones, why their screen or photo looks
| so washed out.
|
| There's many faults to BFDLs, but I love Apple providing
| "vivid" processing as an option and "natural" as the default.
| Sometimes the masses just don't know what's actually good for
| them.
| WithinReason wrote:
| AVIF looks better to me at low bitrates, JXL has much more
| visible block artifacts:
|
| https://afontenot.github.io/image-formats-comparison/#vid-ga...
| peppermint_gum wrote:
| On the other hand, AVIF smoothes out the fine details. It
| struggles to preserve the texture of the receipt and the tiny
| specks on the inside of the cup blend together.
|
| It's visible even in qualities higher than "tiny", which IMO
| is unreasonably small.
| ilyt wrote:
| For me coffee details look better on AVIF, spoon and
| receipt do lose some texture
|
| Frankly I can't really see much difference between AV1/Tiny
| and JPEGXL/Large on the [1] middle of the coffee one,
| everything else around (cup, receipt, spoon) clearly have
| more detail but not the coffee in the middle
|
| - [1] https://imgur.com/a/PeHlyE4
| bscphil wrote:
| I think this is definitely the most common response. AVIF, as
| a video intra-frame based codec, works best at very low
| bitrates. JPEG XL is _considerably_ better at high bitrates.
| WithinReason wrote:
| I'm guessing the reason is that for predicting video frames
| hallucinating detail is undesirable, so you would rather
| remove detail than add non-existent detail. AVIF also seems
| to have some kind of deblocking filter which JXL lacks, to
| my surprise.
| worldofmatthew wrote:
| You can also adjust that deblocking in AVIF.
| vitorsr wrote:
| The worst aspect of JXL is the chroma bleed:
|
| https://afontenot.github.io/image-formats-
| comparison/#catedr... (glasswork)
|
| https://afontenot.github.io/image-formats-comparison/#end-
| of... (teeth, fingernails)
|
| https://afontenot.github.io/image-formats-
| comparison/#steinw... (lights, pianos)
|
| https://afontenot.github.io/image-formats-comparison/#us-
| ope... (racket, fingernails, jewelry, watch)
| toastal wrote:
| At the cost of smoothing everything out losing a lot of
| texture and detail. In some cases it does look better because
| the artifacts are smoothed over, but it's not a clear-cut.
| Especially with photography where the ISO grain is often a
| part of the art, it's often completely washed away.
| worldofmatthew wrote:
| Are you using squoosh.app (That app is crap as it uses
| default settings optimized for AV1 video?
| Retr0id wrote:
| The sweet spot for jxl is generally in the more "normal"
| bitrates
| CodesInChaos wrote:
| That's a very photo heavy corpus. Which is fine if you're
| evaluating these formats for photo compression, but not very
| useful if you have a mix of photos, comics, memes,
| screenshots, etc.
| eis wrote:
| Interestingly in the latest FF on Linux for some reason for me
| the colors are washed out for AVIF and JPEGXL but not the other
| formats. Looking fine in Chromium though.
|
| When zooming in 3x I can say that AVIF looks significantly
| better than JPEGXL in the lower quality settings while being
| consistently a little bit smaller in filesize. There is better
| color retention, less noise and looks sharper. At the "tiny"
| setting the difference is night and day. At the highest setting
| they are so close enough that I wouldn't say there's a clear
| winner for me after going through all the images.
| spider-mario wrote:
| On the "Vid Gajsek" image posted elsewhere in the thread,
| AVIF consistently removes texture in the shadow between the
| receipt and the cup, even at size "large". At size "medium",
| it does so across the entire cup.
|
| Disclaimer: JPEG XL contributor.
| ilyt wrote:
| It does but the middle bit looks far better, AV1/tiny is
| comparable to JXL/large when only looking at middle bit,
| weirdly enough, everything around is of course worse
|
| https://imgur.com/a/PeHlyE4
| cycomanic wrote:
| Agreed, take the Steinway image for example, jpegxl makes a
| mess of it with the tiny setting, lots of artifacts much
| detail lost (e.g. the benches on the right, or the piano keys
| on the left).
| mpweiher wrote:
| > Objective metrics (like dssim) are not the best way to
| compare image codecs.
|
| Yep. It is ultimately a subjective experience. I found this out
| when implementing a color management system back in the early
| to mid 90s.
|
| There is a lot of math, and a lot of physics, of the light, of
| boundary conditions of ink, etc. But there is also a lot of
| perception and psychology that is very difficult to capture.
|
| As an example, my first attempts were quite accurate as
| measured, but looked horribly yellow-ish. The reason is that my
| software was successfully compensating for the blue-ish optical
| whiteners (UV+blue) in the paper. Which you can't do, because
| the eye will judge the brightest "nearly white" area in the
| field of view as white, and judge all the other colors relative
| to that.
|
| But you also can't _not_ do it, because then you ignore what
| the colors are actually supposed to be. And then it gets
| tricky...
| cubefox wrote:
| I looked through quite a few of these test images and it seems
| that AFIV is better overall than JPEG XL.
|
| Sometimes it's really clear. E.g. for the "US Open" Image, AVIF
| "tiny" (23.6 KB) looks as good as JPEG XL "medium" (46.3 KB),
| despite the substantial difference in bit rate:
|
| https://afontenot.github.io/image-formats-comparison/#us-ope...
|
| In some other cases it's less clear, and sometimes AVIF
| denoises too aggressively, e.g. in animal fur. JPEG XL has more
| problems with color bleed. Overall it seems to me AVIF is
| significantly better, especially on lower bit rates.
| tuxoko wrote:
| Yeah, whenever I see the image comparison. I more often then
| not find the result of webp or avif undesirable even against a
| good jpeg compression. webp and avif tends to blur out detailed
| textures too much and just looks worse than jpeg which while
| looks a bit rough and has some artifact, but you can still
| somewhat see the detailed textures.
| ChrisMarshallNY wrote:
| I worked for a storied Japanese imaging corporation.
|
| The final stage of their Image Quality QC was always "The Old
| Men With Good Eyes."
|
| There were some employees that were professional "eyballers."
| They had full veto power.
|
| I'm not sure if they still do that, but it would not surprise
| me, if they did.
| Dwedit wrote:
| Note that AVIF is badly broken on the stable version of Gimp
| (2.10.34). Chroma is upscaled using _NEAREST NEIGHBOR_. Gimp does
| not do that when you load a JPEG or other lossy file which uses
| chroma subsampling.
| tambourine_man wrote:
| JPEG and PNG are good enough. Encoders and decoders are heavily
| optimized and omnipresent. No patent issues (either patent-free
| or expired).
|
| We should focus on other more pressing issues. This one is
| basically solved.
| KronisLV wrote:
| > JPEG and PNG are good enough. Encoders and decoders are
| heavily optimized and omnipresent. No patent issues (either
| patent-free or expired).
|
| I think you're getting downvotes for the sentiment, but I'm
| inclined to agree with both this comment, as well as the one
| you made a bit further in the thread.
|
| > MP3 is also good enough. Modern compressors are on par with
| Opus, AAC or whatever is in fashion now. The format is sane,
| patents have expired, it run everywhere. It's not worth the
| trouble.
|
| Something like Ogg/Vorbis would also be under my consideration
| for audio files, but I find these established and somewhat out
| of date technologies to be surprisingly stable and reliable.
| The same way how for many folks out there the H.264 video codec
| will also suffice for almost any use case (sadly Theora never
| got big, but there's VP8/VP9 too). The same way how something
| like ZIP or 7z will be enough for most archiving needs.
|
| I think there is no harm in using these options and not
| sweating about having to serve every asset in whichever of the
| modern formats the user's browser in question might support
| (nor should you chase perfect quality), as well as be sure to
| actually convert the assets into a multitude of formats and
| include them in the page, as long as 90% of your hosting costs
| aren't caused by this very choice. Who cares if a few pixels
| are a bit off because you saved your JPG with a quality setting
| of 75 or 80? As long as your application/site does what it
| should, that's hardly something that most people care about, or
| will even notice.
|
| > We should focus on other more pressing issues. This one is
| basically solved.
|
| However, eventually something new is going to come out AND get
| stable enough to have the same widespread adoption as the
| current stable and dependable options. Whether that happens in
| a year, 5 years or a decade, only time will show (let's say,
| 95% of devices supporting AV1 and Opus). I think that then will
| be the right time to switch to these new technologies for most
| people, as opposed to being early adopters.
| tambourine_man wrote:
| Yes, I'm in a bad mood and it probably came across a bit
| fatalistic.
|
| > However, eventually something new is going to come out...
|
| The thing is, human eyes and ears aren't getting any better
| and computing performance seems to be plateauing. My guess is
| we have already reached the "good enough" point and I doubt
| we'll get formats 3-4X as efficient in the future.
| KronisLV wrote:
| > The thing is, human eyes and ears aren't getting any
| better and computing performance seems to be plateauing.
|
| My guess is that we'll ideally end up with something that
| isn't hard to use copyright/patent wise and offers
| "optimal" quality but at smaller file sizes when compared
| with the prior technologies, which would be a good thing
| for both storing your own video files, as well as when
| handling them en masse in most businesses. After all, if
| someone could reduce the bandwidth usage of their video
| hosting or streaming site by 10%, they'd be saving millions
| in hardware/networking expenses.
|
| Though I don't think that we're at that point yet, many of
| these more recent technologies are not widely supported, or
| just not good enough.
|
| For example, I rendered a ~6 minute 1080p video with
| Kdenlive with multiple codecs, to compare encode
| performance and resulting filesizes with the default
| settings: Codec Time Filesize H264
| 2:27 172 MB VP8 9:34 244 MB VP9 19:29
| 332 MB AV1 FAIL FAIL
|
| I probably should have figured out a way to get similar
| file sizes, but either way you can see that VP8 and VP9
| take way longer to process when compared to the version of
| H264 that's available to me. So the old H264 is indeed a
| good enough choice for me, at least for now.
| calpaterson wrote:
| The trouble is that images are a large fraction of the page
| size even for well optimised websites. Using smaller images via
| changing format often makes a significant difference in the
| page load time.
|
| It's also relatively easy for new formats to be adopted - the
| html picture tag makes it really easy to serve the same image
| in multiple formats to allow for backward compatibility.
|
| And of course image decoders are easily distributed - JXL's
| encoder/decoder are open source.
|
| The combination of those two factors probably means that this
| will never be a settled area now. It's fairly easy for websites
| to adopt a new format and there are strong reasons to. Means,
| motive and opportunity.
|
| I reckon Chrome will cave in eventually. The pressure on
| browser performance is intense. Unless they want to see Safari
| faster in benchmarks of image heavy pages they will have to
| adopt it.
| formerly_proven wrote:
| > The trouble is that images are a large fraction of the page
| size even for well optimised websites. Using smaller images
| via changing format often makes a significant difference in
| the page load time.
|
| Pepperidge farm remembers Google heavily pushing for WebP for
| this reason. _Look how much smaller it is!_ and Lighthouse
| giving demerits for every non-WebP image. Which, of course,
| is totally true, WebP images were almost always quite a bit
| smaller. They all looked like shit, too, of course.
| CharlesW wrote:
| > _The trouble is that images are a large fraction of the
| page size even for well optimised websites. Using smaller
| images via changing format often makes a significant
| difference in the page load time._
|
| That's true, but even savvy people don't seem to care much
| about this. For example, (open) podcasts are still
| universally MP3-based even though it's been possible for many
| years to halve their size using modern, ubiquitous audio
| formats.
|
| > _I reckon Chrome will cave in eventually. The pressure on
| browser performance is intense. Unless they want to see
| Safari faster in benchmarks of image heavy pages they will
| have to adopt it._
|
| What's curious about this to me is why Apple is single-
| handedly saving JPEG-XL from obscurity when AV1 is also a
| fine substitute for mainstream image compression use cases.
| [deleted]
| zilti wrote:
| The podcast (and audio in general) thing annoys me way more
| than it should. FFS, just use Opus, it is supported on
| virtually all devices out there and is massively smaller
| praisewhitey wrote:
| last I checked the iPhone podcasts app doesn't play opus.
| Have things changed?
| spiralpolitik wrote:
| My guess is the fact that existing jpeg images can be
| transcoded to jpeg-xl losslessly is the driving feature.
| This gives an easy migration path for existing sites that
| don't have high resolution masters that can be re-encoded
| into AV1 or webp.
|
| Also think of 20+ years of jpg digital camera photos that
| can now be transcoded to save space. For Apple that is also
| a huge win.
| Flimm wrote:
| I didn't know that about podcasts and audio formats. What
| format would you recommend? It would need to be well-
| supported by podcast players.
| CharlesW wrote:
| > _What format would you recommend? It would need to be
| well-supported by podcast players._
|
| HE-AAC. Support for HE-AAC and HE-AAC v2 has been
| universal on modern media platforms and operating systems
| for well over a decade.1 * All versions
| of Android support HE-AAC v2 playback2 - Google
| also added encoders in Android 4.1 (2012) * iOS
| introduced support for HE-AAC v2 playback in iOS 4
| (released 2010) * macOS introduced support for HE-
| AAC v2 playback with iTunes 9.2 (released 2010) *
| I'm not sure when Windows added support, but it was
| available in Windows 8 * All open source players
| support HE-AAC v2 playback via FAAD2
|
| FWIW, I distributed a reasonably-popular podcast (1.2M
| downloads over its lifetime) using HE-AAC v2 several
| years ago, and never received a complaint, or found a
| player it didn't work on.
|
| 1 I read the other comments recommending Opus before
| responding, and although Opus is very nice, it's not as
| efficient or as ubiquitous as HE-AAC.
|
| 2 https://developer.android.com/guide/topics/media/media-
| forma...
| gsich wrote:
| Opus
| jdiff wrote:
| Opus is pretty widely supported (still some holes though,
| for example very few Adobe products support Opus), and it
| can sound better than MP3 at less than half the bitrate.
| BlackLotus89 wrote:
| Normally aac and opus are used.
| tambourine_man wrote:
| MP3 is also good enough. Modern compressors are on par with
| Opus, AAC or whatever is in fashion now. The format is
| sane, patents have expired, it run everywhere.
|
| It's not worth the trouble.
| zerocrates wrote:
| Opus you'd get away with half the bitrate, or less, than
| MP3 for a podcast. Gets to be somewhat significant given
| the length of many podcasts, those 64kbps or so that you
| save add up over time.
|
| Though I agree, the "works everywhere" aspect is really
| the overriding factor: everyone can play it, all the
| services will accept it, etc. I think the only way you'd
| see it get used significantly is if a major service was
| transcoding to it, but I don't know that podcast
| bandwidth is a sufficient cost for anyone to bother.
| CharlesW wrote:
| HE-AAC is a bit better than Opus, plus has the benefit of
| MP3's "works everywhere" experience. I posted more detail
| elsewhere in the thread if you're interested.
| TacticalCoder wrote:
| > ... PNG are good enough.
|
| For a start it's 2023 and all browsers do support lossless webp
| [1].
|
| Lossless _webp_ ( _webp_ can be both lossy or lossless) is not
| only typically smaller than most optimized PNG files but also
| compresses faster than the optimized PNG encoders.
|
| So, basically, the main reason to use PNG in 2023 for anything
| Web related is if you like wasting bandwith. For 99.95% of the
| PNG files (something huge like that) are smaller when encoded
| with lossless _webp_.
|
| Heck, even my Emacs supports _webp_ images.
|
| Then other formats are already knocking on the door and promise
| even better compression than _webp_.
|
| https://caniuse.com/webp
| mlindner wrote:
| Unless you have a large image in which case you can't even
| store it in webp because of its abysmal max resolution. PNG
| continues to be the format of record for lossless image
| storage. Hopefully JPEG XL can replace it.
| tambourine_man wrote:
| Not if you use MozJPEG and a decent PNG compressor, like ECT,
| OxiPNG, PNGCrush, etc.
|
| Time and time again an article pops up showing how marginal
| the difference is, if at all.
| CodesInChaos wrote:
| PNG only produces reasonable image sizes for a very restricted
| category of image. And while JPEG is decent for photos, it does
| a pretty bad job compressing images which contain sharp edges
| or text.
|
| So neither is a good choice, unless you know a priori that all
| your images will fall into one of the categories where these
| formats do a decent job.
| devmor wrote:
| You are free to focus on whatever issues you find pressing.
| spider-mario wrote:
| High-quality HDR at reasonable bitrates is solved?
| Demmme wrote:
| Ah yes the ubundend fiber in rural areas around the globe.
|
| You do understand that this is not for you if you have high
| bandwidth and low latency right?
| Osiris wrote:
| Just as ZIP is a mediocre compression algorithm that is
| supported basically everywhere.
|
| Today we have larger storage and faster bandwidth than ever
| before so it's easy to trade off compression for ease.
|
| Same goes with mp3. Back in the day, Microsoft was touting that
| WMA could replicate the quality of MP3 128kbps at just 64kbps.
| I bought in and mass converted my entire library because of the
| high space savings. Now... I have a library of music that has
| so many artifacts in it, I can listen to it. At the time, the
| space saving may have been worth it but I now regret it.
| tredre3 wrote:
| Saying that DEFLATE is mediocre is absurd. There's a reason
| it's still in use after 30 years (and it's not merely
| inertia). Before zstandard arrived to the scene there was
| literally nothing able to achieve the same ratio as deflate
| without taking 10x longer.
|
| This is unlike WMA/WMV which, I agree, were pretty much
| already obsolete by the time they came out.
| xnx wrote:
| Visual quality, file size, compression time, decompression time,
| browser support, toolchain support, patent restrictions.
| Considering any one of those in isolation is insufficient for
| evaluating image formats.
| CharlesW wrote:
| > _Visual quality, file size, compression time, decompression
| time, browser support, toolchain support, patent restrictions.
| Considering any one of those in isolation is insufficient for
| evaluating image formats._
|
| Additionally, use cases are critical for understanding which of
| these and other properties matter, as well as their relative
| importance. Authoring formats (e.g. Apple ProRes, DNG) are
| evaluated much differently than distribution formats (e.g. AV1,
| JPEG).
| wongarsu wrote:
| And not to forget the third category: storage/archival
| formats. JPEG XL is unlikely to get widespread browser
| support, but that doesn't mean it isn't a good format to
| store high qualitiy originals. Either because they never
| touch a browser (my image viewer supports JXL) or because all
| images go through the resizing proxy anyways.
| bla3 wrote:
| Also features like alpha support, yuv444 support in addition to
| yuv420, progressive rendering are interesting. Do jxl and avif
| both have all of these?
| vanderZwan wrote:
| There's a neat table on https://jpegxl.info/ which shows all
| features of both formats. In general JXL has more features
| than AVIF, although some of them may be more important for
| special purposes like medical imaging.
| iLoveOncall wrote:
| And I'm sure we can expect a perfectly unbiased opinion
| regarding the matter from jpegxl.info.
| [deleted]
| vanderZwan wrote:
| In which world are technical features like "how many
| channels the format supports" or "maximum bit depth" or
| "progressive decoding" _opinions_ , exactly?
| jdiff wrote:
| You can pick and choose which facts to present or
| misrepresent which/what is important but... that's not
| going on here. JXL is actually just better by very many
| metrics. It's only lacking in adoption. There's not
| something that jpeg-xl.info is ignoring or glossing over.
| This is just lazy cynicism.
| iLoveOncall wrote:
| I was mostly joking, but you can compare a skateboard and
| a car and make the skateboard look better if you just
| mention weight and pollution but not top speed, autonomy,
| etc.
| krasin wrote:
| Also 16-bit colors support! The fact that AVIF does not have
| it is a bummer (although, understandable given the fact AVIF
| is for a video codec, not for editing HDR images).
| jdiff wrote:
| Honestly that plus the awful tiling behavior at relatively
| low resolutions should have been enough to disqualify it
| from being mangled into something resembling an image
| format. It was made and tuned for movies, not stills. But
| its image format gets to inherit all of the drawbacks of
| that initial use case, including awful encode/decode
| performance.
| brucethemoose2 wrote:
| There are some valid critiques, like dssim being an old and
| questionable metric, and AVIF using unoptimized settings, and
| maybe JXL having an "unfair" advantage depending on how the
| source images (jpegs?) were ingested.
|
| But this is a real world benchmark. If this is an example of how
| a seasoned backend dev would typically set up AVIF and JPEG XL,
| its extremely telling.
| praseodym wrote:
| For me, the most interesting property of JPEG XL is that it
| allows lossless recompression of JPEG images. This seems a great
| way to save storage in a photo library without any loss of
| quality.
| mortenjorck wrote:
| While I would prioritize other factors in a next-gen image
| format, the fact that JXL manages to lead in all those _plus_
| the ability to "upgrade library" is an incredible achievement.
| Szpadel wrote:
| interesting results, when i performed such tests i constantly was
| getting bigger file sizes with similar dssim in comparison with
| avif
| fyrn_ wrote:
| Not surprising, it's hard to compare image formats, it takes a
| lot of sample images before you can say anything, and even then
| it's hard to rule out sampling bias
| andybak wrote:
| I wanted to comment on one of the replies on my phone but
| Mastadon utterly defeated me.
| thund wrote:
| OT: had to uninstall mastodon to read the post. The alternative
| was to join the server, just to read... Pretty bad experience if
| you ask me.
|
| I was hoping someone would post a mirrored link
| brucethemoose2 wrote:
| That seems like a huge oversight.
|
| Why can't the app load it if browsers can get it through HTML?
| llm_nerd wrote:
| In prior discussions about JPEG XL on here, some didn't realize
| that modern browsers already let you pick the "best fit" image
| from a set of images in basic HTML.
|
| https://dennisforbes.ca/articles/jpegxl_just_won_the_image_w...
|
| So if a site decided to support JPEG XL (including recompressing
| their existing JPEG library, going forward high-quality encoding
| to best codec for new images) they can easily support it in a way
| that lets the browser choose. No weird reverse proxies or
| machinations or polyfills to support it.
|
| Another great aspect of JPEG XL is that it is a short circuit
| answer to almost any "what format should you store an image in?"
| question. Instead of the classic "is it comic book style? GIF or
| PNG. Photorealistic? JPEG. Need transparency....oof, is it
| photorealistic, because then things get ugly....", with JPEG XL
| it truly becomes the universal answer.
|
| At least outside of absurdly high compression rates on
| photorealistic content where it does suffer.
| kllrnohj wrote:
| > Another great aspect of JPEG XL is that it is a short circuit
| answer to almost any "what format should you store an image
| in?" question.
|
| WebP offered that as well. Nobody ended up caring. Animated
| WebP even exists! A truly universal container that also got
| basically no usage.
___________________________________________________________________
(page generated 2023-06-11 23:00 UTC)