Programming

17313 readers

253 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Follow the programming.dev instance rules
Keep content related to programming in some way
If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities [email protected]

founded 2 years ago

MODERATORS

[email protected]

217

Which protocol or open standard do you like or wish was more popular? (lemmy.ml)

submitted 2 months ago* (last edited 2 months ago) by [email protected] to c/[email protected]

264 comments fedilink hide all child comments

There are a couple I have in mind. Like many techies, I am a huge fan of RSS for content distribution and XMPP for federated communication.

The really niche one I like is S-expressions as a data format and configuration in place of json, yaml, toml, etc.

I am a big fan of Plaintext formats, although I wish markdown had a few more features like tables.

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 9 points 2 months ago (2 children)

What's so good about it?

[–] GamingChairModel 56 points 2 months ago (3 children)

Existing JPEG files (which are the vast, vast majority of images currently on the web and in people's own libraries/catalogs) can be losslessly compressed even further with zero loss of quality. This alone means that there's benefits to adoption, if nothing else for archival and serving old stuff.
JPEG XL encoding and decoding is much, much faster than pretty much any other format.
The format works for both lossy and lossless compression, depending on the use case and need. Photographs can be encoded in a lossy way much more efficiently than JPEG and things like screenshots can be losslessly encoded more efficiently than PNG.
The format anticipates being useful for both screen and prints. Webp, HEIF, and AVIF are all optimized for screen resolutions, and fail at truly high resolution uses appropriate for prints. The JPEG XL format isn't ready to replace camera RAW files, but there's room in the spec to accommodate that use case, too.

It's great and should be adopted everywhere, to replace every raster format from JPEG photographs to animated GIFs (or the more modern live photos format with full color depth in moving pictures) to PNGs to scanned TIFFs with zero compression/loss.

[–] Angry_Autist 21 points 2 months ago

This is why I fucking love the internet.

I mean, I'll never take the time to get this knowledgable about image formats, but I am ABSOLUTELY fuckdamn thrilled that at least SOMEONE out there takes it seriously.

Good on you, pixel king

[–] [email protected] 8 points 2 months ago* (last edited 2 months ago)

Existing JPEG files (which are the vast, vast majority of images currently on the web and in people’s own libraries/catalogs) can be losslessly compressed even further with zero loss of quality. This alone means that there’s benefits to adoption, if nothing else for archival and serving old stuff.

Funny thing is, there was talk on the Chrome bug tracker of using just this ability transparently at the HTTP layer (like gzip/brotli compression), but they're so set on pushing their AVIF format that they backed away from it.

[–] [email protected] 7 points 2 months ago (2 children)

The format works for both lossy and lossless compression, depending on the use case and need. Photographs can be encoded in a lossy way much more efficiently than JPEG and things like screenshots can be losslessly encoded more efficiently than PNG.

Someone made a fair point that having a format being both lossy and lossless is not necessarily a great idea. If you download a jpeg file you know it will be compressed, if you download png it will be lossless. Shifting through jxl files to check if it's lossy or not doesn't sound very fun.

All in all I'm a big supporter of jxl though, it's one of the only github repos I actively follow.

[–] [email protected] 10 points 2 months ago

While I agree that it's somewhat bad that there is no distinction between lossless and lossy jxl in the file extension, I think it's really not a big deal compared to the present situation with jpg/png.

The reason being that if you download a png file you have no idea if its been converted from jpg, if it's a screenshot of a jpg, or if it's been subjected to lossy reencoding by a tool or a website upload process.

The only thing you can really do to try and see if the file you've downloaded has suffered encoding loss is to do an image search on it and see if there are any better quality versions out there. You'd do the exact same thing with a jxl file.

[–] GamingChairModel 4 points 2 months ago

Functionally speaking, I don't see this as a significant issue.

JPEG quality settings can run a pretty wide gamut, and obviously wouldn't be immediately apparent without viewing the file and analyzing the metadata. But if we're looking at metadata, JPEG XL reports that stuff, too.

Of course, the metadata might only report the most recent conversion, but that's still a problem with all image formats, where conversion between GIF/PNG/JPG, or even edits to JPGs, would likely create lots of artifacts even if the last step happens to be lossless.

You're right that we should ensure that the metadata does accurately describe whether an image has ever been encoded in a lossy manner, though. It's especially important for things like medical scans where every pixel matters, and needs to be trusted as coming from the sensor rather than an artifact of the encoding process, to eliminate some types of error. That's why I'm hopeful that a full JXL based workflow for those images will preserve the details when necessary, and give fewer opportunities for that type of silent/unknown loss of data to occur.

[–] [email protected] 18 points 2 months ago (1 children)

Basically smaller file sizes than JPEG at the same quality and it also automatically loads a lower quality version of the image before it loads a higher quality version instead of loading it pixel by pixel like an image would normally load. Google refuses to implement this tech into Chrome because they have their own avif format, which isn't bad but significantly outclassed by JPEG-XL in nearly every conceivable metric. Mozilla also isn't putting JPEG-XL into Firefox for whatever reason. If you want more detail, here's an eight minute video about it.

[–] [email protected] 13 points 2 months ago

I'm under the impression that there's two reasons we don't have it in chromium yet:

Google initially ignored jpeg-xl but then everyone jumped on it and now they feel they have to create a post-hoc justification for not supporting it earlier which is tricky and now they have a sunk cost situation to keep ignoring it
Google today was burnt by the webp vulnerability which happened because there was only one decoder library and now they're waiting for more jpeg-xl libraries which have optimizations (which rules out reference implementations), good support (which rules out libraries by single authors), have proven battle-hardening (which will only happen over time) and are written safely to avoid another webp style vulnerability.

Google already wrote the wuffs language which is specifically designed to handle formats in a fast and safe way but it looks like it only has one dedicated maintainer which means it's still stuck on a bus factor of 1.

Honestly, Google or Microsoft should just make a team to work on a jpg-xl library in wuffs while adobe should make a team to work on a jpg-xl library in rust/zig.

That way everyone will be happy, we will have two solid implementations, and they'll both be made focussing on their own features/extensions first so we'll all have a choice among libraries for different needs (e.g. browser lib focusing on fast decode, creative suite lib for optimised encode).