6 ms·
It’s always codecs. I don’t always buy into the $safelanguage cargo cult but come on, it’s apparent that memory unsafe languages are not appropriate for this p
by cedws 2y ago
It’s always codecs.
I don’t always buy into the $safelanguage cargo cult but come on, it’s apparent that memory unsafe languages are not appropriate for this purpose and desperately need replacing.
- oguz-ismail 2y ago[flagged]
- adzm 2y agoAlpha 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.
- oguz-ismail 2y ago>Alpha channels in a lossy image? Why? >Animated lossy image? It's called a video
- londons_explore 2y agoThere 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.
- oguz-ismail 2y ago>usually unnoticeable quality degregation Dunno I think it'd be too messy
- IshKebab 2y agoOnly 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 https://github.com/mozilla/standards-positions/pull/1064
- _mlbt 2y agoNo serious alternative? Apple could easily make a safe image handling library in Swift.
- ChocolateGod 2y agoSwift is underrated, I wish it had more traction outside Apples ecosystem. Easy to learn, fast and memory safe without a GC.
- cosmic_cheese 2y agoIt’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.
- necubi 2y agoAutomatic 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-garbage.pdf https://web.eecs.umich.edu/~weimerw/2012-4610/reading/bacon-... (except that ARC can't handle cyclic graphs)
- IshKebab 2y agoAnd it's more deterministic without random pauses.
- pebal 2y agoThe 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.
- Aloisius 2y agoWhat 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.
- actionfromafar 2y agohttps://github.com/google/wuffs https://github.com/google/wuffs <-- DSL created explicitly for wrangling fileformats safely
- jonatron 2y agoThank you, I spent a few minutes failing to google this.
- actionfromafar 2y agoI always do that, sometimes I succeed, sometimes I fail! :-D
- internetter 2y agoWritten in C? Unless I'm missing something this isn't better than other unsafe options
- codetrotter 2y agoFrom 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).
- yjftsjthsd-h 2y agoAnd - https://github.com/google/wuffs/blob/main/doc/std/image-decoders.md#implementations https://github.com/google/wuffs/blob/main/doc/std/image-deco... with a webp implementation.
- 2y ago
- greenavocado 2y agoJPEG-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 https://www.youtube.com/watch?v=qc2DvJpXh-A
- dev1ycan 2y agoYeah but Google goes out of their way to kill jpeg-xl, they really deserve to lose chrome
- latexr 2y agoI 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.
- derf_ 2y agoIt looks like a straight-up bug in chroma quantization. libaom has never had good chroma RDO tuning.
- jeroenhd 2y agoJPEG-XL works in even fewer programs than WebP does, though, which is almost impressive given WebP's reputation.
- voidUpdate 2y agoGood 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
- oguz-ismail 2y ago[flagged]
- voidUpdate 2y agoDepending on where you are and what mobile data plan you have, bandwidth is not always cheap. And I don't see the problem in trying to reduce the amount of data sent, which is one of the reasons I don't fill my website with megabytes of javascript libraries
- yjftsjthsd-h 2y ago> Storage is cheap, bandwidth is cheap, so who cares? That may be true sometimes, but it isn't true all the time. Even if it's "cheap", smaller files load faster.
- web007 2y ago> Storage is cheap, bandwidth is cheap, so who cares? This is a ridiculous assertion. They're both cheap in the commercial sense, but neither cheap nor infinite in the UX sense. Time and space matter in the real world. Google wouldn't have created WebP if there was no tangible, measurable cost benefit to using it over some alternative. Same goes for H.264 or HEVC or AV1, at scale bandwidth and storage are far from cheap. See the article on the FP today about Google's double-digit EXAbyte storage clusters with 50TB/s read volume each as a real-world example, there's nothing cheap about that.
- 01HNNWZ0MV43FF 2y agoWell the principle reason to use Rust is that it has good tagged unions But I don't even buy into the cargo cult cargo cult https://www.righto.com/2025/01/its-time-to-abandon-cargo-cult-metaphor.html?m=1 https://www.righto.com/2025/01/its-time-to-abandon-cargo-cul...
- deleted 2y ago[deleted]
- unit149 2y ago[dead]
- junto 2y agoThere always been an issue here with files reporting to be one thing but being another. Trusting the file extension is amateur to say the least. ‘Magic strings’ in the header of the file is the usual way, but even then, you can’t really trust it. What we really need is some way to guarantee that the contents are in a valid format as defined by the header, and haven’t been tampered with and signed as such, and embeds that in the file itself. Then I can take the contents of the file after the header, hash it and compare it with the embedded sig. Back porting this to standard formats though would be a nightmare.
- klabb3 2y agoSo an attacker should sign their malicious webp or jpeg files beforehand? That doesn’t help at all. No, I agree very much with parent here. I think compile time safety and rust fanatism has been oversold, but let’s face it this is the perfect use case, a match made in heaven. Decoding in C/C++ has a Dunning Kruger deceitful appeal. People think they can do it, but time and time again, we find critical holes, even when written by 10x wizard Nobel laureate engineers. At the same time, decoding needs to be crazy performant. So, this is the moment to shine for languages like Rust. I am 100% in support of this.