Hacker News Reader

Comment by oguz-ismail | Hacker News Reader

[flagged]

JPEG-XL is the future everything else is forced/shilled to the extreme without considering its merits. Don't even get me started how some website will show a URL to a JPEG and when you try to save it, it tries to save a WebP.

WebP suffers from excessive generation loss for a modern codec.

https://www.youtube.com/watch?v=qc2DvJpXh-A

I find it curious how the AVIF deterioration resembles an old physical photograph. I wonder why that is. Do you know of more comparisons like this? I’d like to observe the effect further but don’t have the availability right now to pursue it.

It looks like a straight-up bug in chroma quantization. libaom has never had good chroma RDO tuning.

JPEG-XL works in even fewer programs than WebP does, though, which is almost impressive given WebP's reputation.

Yeah but Google goes out of their way to kill jpeg-xl, they really deserve to lose chrome

https://github.com/google/wuffs <-- DSL created explicitly for wrangling fileformats safely

And - https://github.com/google/wuffs/blob/main/doc/std/image-deco... with a webp implementation.

From after this exploit was found.

Oh, you're right; I managed to miss that the vuln was from 2023. I do wonder how widely used the wuffs version is now that it exists, though.

wuffs has the same story as rlbox in firefox. They made the tool, they proved it could work with one library, and then proceeded to ignore it for all the other libraries.

https://hacks.mozilla.org/2020/02/securing-firefox-with-weba...

rlbox is used for more than one library: "Now, we’re bringing that technology to all supported Firefox platforms (desktop and mobile), and isolating five different modules: Graphite, Hunspell, Ogg, Expat and Woff2"

https://blog.mozilla.org/attack-and-defense/2021/12/06/webas...

I wouldn't be surprised if some security team at Apple was cooking up a bespoke DSL as well – NIH seems to happen once in a while.

They have some kind of safe dialect of C that they use for iBoot. Also they're increasingly using Swift for things.

Thank you, I spent a few minutes failing to google this.

I always do that, sometimes I succeed, sometimes I fail! :-D

Written in C? Unless I'm missing something this isn't better than other unsafe options

From the Wuffs readme:

> Wuffs the Language is safe with respect to buffer overflows, integer arithmetic overflows and null pointer dereferences. A key difference between Wuffs and other memory-safe languages is that all such checks are done at compile time, not at run time. If it compiles, it is safe, with respect to those three bug classes.

> […]

> Wuffs code is hermetic and can only compute (e.g. convert "compressed bytes" to "decompressed bytes"). It cannot make any syscalls (e.g. it has no ambient authority to read your files), implying that it cannot allocate or free memory (and is therefore trivially safe against things like memory leaks, use-after-frees and double-frees).

Good compression for web images. I converted the images on my website to webp and saw a huge reduction in filesizes with virtually no loss in quality, but it still keeps an alpha channel unlike jpg

Alpha channels in a lossy image? Animated lossy image?

Regardless, things like this really help explain the hesitation behind adopting jpegxl.

I'm a big fan of AVIF files though.

Only if they implement jpegxl decoders in C/C++. I would really hope that isn't the case.

Seems like they agree: https://github.com/mozilla/standards-positions/pull/1064

>Alpha channels in a lossy image?

Why?

>Animated lossy image?

It's called a video

There are loads of uses for alpha channels. Anything you want layered with other graphics without being surrounded by an ugly black square...

There are loads of uses for lossy images. Pretty much any image is probably best transmitted lossy, because the saved ram, CPU, bandwidth, load time is huge compared to the usually unnoticeable quality degregation.

So it stands to reason there are lots of uses for lossy alpha images.

>usually unnoticeable quality degregation

Dunno I think it'd be too messy

No serious alternative? Apple could easily make a safe image handling library in Swift.

Swift is underrated, I wish it had more traction outside Apples ecosystem.

Easy to learn, fast and memory safe without a GC.

Automatic reference counting is a form of GC, and optimized versions of it end up very similar to tracing GC: https://web.eecs.umich.edu/~weimerw/2012-4610/reading/bacon-...

(except that ARC can't handle cyclic graphs)

And it's more deterministic without random pauses.

The reference counting also causes pauses when freeing large object graphs. Fully concurrent GC does not cause any pauses and it's more efficient. It also has less memory overhead per object.

What GC doesn't cause any pauses?

I know of some who claim to be "pauseless", but it's b.s. marketing. They also tend to be memory hogs that don't play well with other processes in low memory environments with the kind of allocation behavior seen in UI applications.

And of course, the issue is not only stop-the-world pauses (though those are especially bad), but any pause in any thread period. A RC system lets you have consistent, predictable performance and often can be completely eliminated through static analysis.

Here you have a GC engine that is completely pauseless: https://github.com/pebal/sgcl

It is available as a C++ library, so you can easily compare its performance to the reference counting.

That's why I said random pauses.

RAII can also cause pauses when freeing large object graphs. It's not unique to RC. However in practice it's usually much less of an issue than GC pauses. It's only been an issue for me once in my entire career.

In C++ one can combine RAII with allocators in order to avoid calling alloc/frees in latency critical paths.

It’s very slowly starting to get a bit of traction outside of Apple now that the language has filled many gaps and Foundation is being re-written to be Swift-first and open source. I expect growth of adoption to continue to be slow for the time being though.

Reply on news.ycombinator.com