Earlier quoted context omitted.
honestly hate webp so happy about this
I don't know much about webp. Just have checked the wiki, it looks nice. So for which reason you hate it?
[deleted]
Google unkills JPEG XL?
61–70 of 283 posts
Re: Google unkills JPEG XL?
#62Re: Google unkills JPEG XL?
#63Isn't this due to the 100M+ line C++ multi-threaded dependency being a potential nightmare when you are dealing with images in browsers/emails/etc. as an attack surface? I think both Mozilla and Google are OK with this - if it is written in Rust in order to avoid that situation. I know the linked post mentions this but isn't that the crux of the whole thing? The standard itself is clearly an improvement over what we'…
100M+ is a bit more than i would expect for an image format. have i not been paying attention
Re: Google unkills JPEG XL?
#64Starting to feel like this whole "standards" thing is a giant farce
Which standard requires support of JXL?
Re: Google unkills JPEG XL?
#65Earlier quoted context omitted.
The only practical way to work with such large images is if they are tiled and pyramidal anyway
what does pyramidal mean in this context?
Probably, multiple resolutions of the same thing. E.g. a lower res image of the entire scene and then higher resolution versions of sections. As you zoom in, the higher resolution versions get used so that you can see more detail while limiting memory consumption.
Re: Google unkills JPEG XL?
#66Earlier quoted context omitted.
Which other parties? Because Mozilla's stance on JPEG XL and XSLT are identical to Google's. They don't want to create a maintenance burden for features that offer little benefit over existing options.
Which is why Firefox is steadily losing market share. If Mozilla wanted Firefox to succeed, they would stop playing "copy Chrome" and support all sorts of things that the community wants, like JpegXL, XSLT, RSS/Atom, Gemini (protocol, not AI), ActivityPub, etc. Not to mention a built-in ad-blocker...
With all due respect, this is a completely HN-brained take.
No significant number of users chooses their browser based on support for image codecs. Especially not when no relevant website will ever use them until Safari and Chrome support them.
And websites which already do not bother supporting Firefox very much will bother even less if said browser by-default refuses to allow them to make revenue. They may in fact go even further and put more effort into trying to block said users unless they use a different browser.
Despite whatever HN thinks, Firefox lost marketshare on the basis of:
A) heavy marketing campaigns by Google including backdoor auto-installations via. crapware installers like free antivirus, Java and Adobe, and targeted popups on the largest websites on the planet (which are primarily google properties). The Chrome marketing budget alone nearly surpasses Mozilla's entire budget and that's not even accounting for the value of the aforementioned self-advertising.
B) being a slower, heavier browser at the time, largely because the extension model that HN loved so much and fought the removal of was an architectural anchor, and beyond that, XUL/XPCOM extensions were frequently the cause of the most egregious examples of bad performance, bloat and brokenness in the first place.
C) being "what their cellphone uses" and Google being otherwise synonymous with the internet, like IE was in the late 1990s and early 2000s. Their competitors (Apple, Microsoft, Google) all own their own OS platforms and can squeeze alternative browsers out by merely being good enough or integrated enough not to switch for the average person.
Re: Google unkills JPEG XL?
#67> Yes, right, “not enough interest from the entire ecosystem”. Sure.
Well tbf, the only time I ever hear about JPEG XL is when people complain about Chrome not having it. I think that might be its only actual use case.
Re: Google unkills JPEG XL?
#68Earlier quoted context omitted.
The only practical way to work with such large images is if they are tiled and pyramidal anyway
what does pyramidal mean in this context?
Replicated at different resolutions depending on your zoom level.
One patch at low resolution is backed by four higher-resolution images, each of which is backed by four higher-resolution images, and so on... All on top of an index to fetch the right images for your zoom level and camera position.
Re: Google unkills JPEG XL?
#69A full-resolution, maximum-size JPEG XL image (1,073,741,823 × 1,073,741,824): Uncompressed: 3.5–7 exabytes Realistically compressed: Tens to hundreds of petabytes Thats a serious high-res image
At 600DPI that's over a marathon in each dimension. I do wonder if there are any DOS vectors that need to be considered if such a large image can be defined in relatively small byte space. I was going to work out how many A4 pages that was to print, but google's magic calculator that worked really well has been replaced by Gemini which produces this trash: Number of A4 pages=0.0625 square meters per A4 page * 784 squ…
> I do wonder if there are any DOS vectors that need to be considered if such a large image can be defined in relatively small byte space.
You can already DOS with SVG images. Usually, the browser tab crashes before worse things happen. Most sites therefore do not allow SVG uploads, except GitHub for some reason.
Re: Google unkills JPEG XL?
#70Earlier quoted context omitted.
The only practical way to work with such large images is if they are tiled and pyramidal anyway
what does pyramidal mean in this context?
I think it means encoded in such a way that you first have low res version, then higher res versions, then even higher res versions etc.