That used to be what Microsoft (Internet Explorer) was famous for. I guess Chrome has lived long enough to be the villain, but Firefox is still the hero to me.
This article gives some information on why some have abandoned hope for Firefox and Mozilla. AI focus, changing its stance on selling user data, and the overall loss of focus. It's still better than most, IMO, but some of its forks better represent those who feel that way.
"we would welcome contributions to integrate a performant and memory-safe JPEG XL decoder in Chromium. In order to enable it by default in Chromium we would need a commitment to long-term maintenance."
No. They increased the max "canvas" size and increased encoding efficiency. You'd want the file size to be smaller but the file itself to be larger (and consequently more detailed)
In my personal tests of jxl, it manages filesizes 1/9th that of png while remaining visually identical (unless looking VERY closely). It's a massive improvement over jpeg and honestly a replacement for png in most cases.
Like I'm saying 8MB for a 8000x6000 file at max quality (estimating from memory)
I assume you mean AVIF? Because AV1 is not an image (file) format but a video compression format (that needs to be wrapped in container file formats to be storable).
I would be more excited about JPEG XL if it was backward compatible. Not looking forward to yet another image standard that requires OS and hardware upgrades simply so servers can save a few bytes.
How would a new format be backwards-compatible? At least JPEG-XL can losslessly compress standard jpg for a bit of space savings, and servers can choose to deliver the decompressed jpg to clients that don't support JPEG-XL.
Also from Wikipedia:
Computationally efficient encoding and decoding without requiring specialized hardware: JPEG XL is about as fast to encode and decode as old JPEG using libjpeg-turbo
Being a JPEG superset, JXL provides efficient lossless recompression options for images in the traditional/legacy JPEG format that can represent JPEG data in a more space-efficient way (~20% size reduction due to the better entropy coder) and can easily be reversed, e.g. on the fly. Wrapped inside a JPEG XL file/stream, it can be combined with additional elements, e.g. an alpha channel.
All you have to do is add a small traditional JPEG image at the start of the file. It doesn’t have to be high resolution or more than a couple of kb. The new format decoder would know this, and skip the traditional jpeg “header”, rendering the newer file format embedded in the image.
If you’re really saving 20% in file size with XL, adding back a very compressed preview image that takes up one or two percent isn’t going to cost you much.
Maybe this should come with a warning. The purpose of WebP is to quickly serve images to the user without grabbing the entire image data. Without WebP all images will be fully loaded, in the right conditions a page could load real slow.
I love webp, but your explanation is a bit confused. Webp is typically lossy, just as jpeg — only, it's more efficiently compressed, meaning smaller size for the same image quality. So there's no 'entire image data', there are only different approximations of the original image and different compressed files. Full-blown lossless images in PNG or other formats take several times more data.
Disabling webp in favor of jpeg would use like 20-40% more data, in comparison. Which still sucks, but not as much.
Edit: maybe more than 40%, actually. Iirc I've seen webps that were half the size of jpegs. It's a good format, shame it's adopted rather poorly.
I wasn't going to get into the whole lossyness of the formats and just simplified to full image instead of compressed formatted.
That is interesting that it is only saving 20%-40%. I was under the impression that the page only rendered the image size necessary to fit the layout and not the full resolution image. Forcing it to less lossy or lossless would mean that the larger image would always be available to be served to be rendered without any web request.
That's a rather interesting consideration as to whether rendering at smaller sizes skips decoding parts of the image.
First, the presented file is normally always loaded in full, because that's how file transfer works over the web. Until lately, there were no different sizes available, and that only became widely-ish spread because of Apple's 'Retina' displays with different dots-per-inch resolution, mostly hidpi being two times the linear size of the standard dpi. Some sites, like Wikipedia, also support resizing images on the fly to some target dimensions, which results in a new image of the JPEG or other format. In any case, to my somewhat experienced knowledge, JPEG itself doesn't support sending every second row or anything like that, so you always get a file of a predetermined size.
First-and-a-half, various web apps can implement their own methods for loading lower- or higher-res images, which they prepare in advance. E.g. a local analogue to Facebook almost certainly loads various prepared-in-advance low-res images for viewing in the apps or on the site, but has the full-res images available on request, via a menu.
Second, I would imagine that JPEG decoding always results in the image of the original size, which is then dynamically resized to the viewport of the target display — particularly since many apps allow zooming in or out of the image on the fly. Specifically, I think decoding the JPEG image creates a native lossless image similar to BMP or somesuch (essentially just a 2d array of pixel colors), which is then fed to the OS's rendering capabilities, taking quite a chuck of memory. Of course, by now this is all accelerated by the hardware a whole lot, with the common algorithms being prepared to render raw pixels, JPEG, and a whole bunch of other formats.
It would be quite interesting if file decoding itself could just skip some part of the rows or columns, but I don't think that's quite like the compression works in current formats (at least in lossy ones, which depend on the previous data to encode later data). Although afaik JPEG encodes the image in rectangles like 16x16 or something like that, so it could be that whole chunks could be skipped altogether.
Because I'm tired of all this nonsense where just because a thing is a mature technology, it's considered obsolete. Stop constantly pushing for the next thing. Keep the things that work.
It's unreasonable to stop further software development just because there's a 'mature' solution around. Besides, just because a solution is 'mature' doesn't make it good.
And considering that it seems like you can still use the original, about 30 year old format, doesn't look like there's any harm for the folks not needing or able to use the new stuff.
Webp is a smaller file size than jpeg for the same image quality in almost all circumstances - so it’s more efficient and quicker to load. It also supports lossless compression, transparency, and animation, none of which jpeg do. And the jpeg gets noticable visual artefacts at a much higher quality than webp does.
People didn’t adopt it to annoy you. It’s started to replace jpeg for the same reason jpeg started to replace bmp - it’s a better, more efficient format.
Webp is a smaller file size than jpeg for the same image quality in almost all circumstances
For lower quality images sure, for high quality ones JPEG will beat it (WebP, being an old video format, only supports a quarter of the colour resolution than JPEG does, etc.) JPEG is actually so good that it still comes out ahead in a bunch of benchmarks, it's just it's now starting to show it's age technology wise (like WebP, it's limited to 8bpc in most cases)
It also doesn't hurt that Google ranked sites using WebP/AVIF higher than ones that aren't (via lighthouse).
Edit: I should clarify, this is the lossy mode. The lossless mode gives better compression than PNG, but is still limited to 8bpc, so can't store high bit depth, or HDR images, like PNG can.
70 Comments
ExLisper@lemmy.curiana.net · 136 pts · 279d
Poor Google doesn't have the manpower to implement it. They can only accept contributions from volunteers.
ZoteTheMighty@lemmy.zip · 44 pts · 278d
Google is just a small indie company after all.
bigfondue@lemmy.world · 2 pts · 278d
6nk06@sh.itjust.works · 134 pts · 279d
Those idiots waited for 4 years because they followed the hype of the moment. I'm glad I removed Google from my life.
panda_abyss@lemmy.ca · 56 pts · 279d
This must be your first time seeing what Google support looks like
This is pretty standard unless you can get an exec’s personal attention.
ICastFist@programming.dev · 1 pts · 274d
https://killedbygoogle.com/
panda_abyss@lemmy.ca · 1 pts · 274d
Beyond this, even if you can get engineers to look at a bug ticket, this is how long it takes. It's months just to get a follow up.
umbrella@lemmy.ml · 38 pts · 279d
SkyeStarfall@lemmy.blahaj.zone · 8 pts · 278d
Absolutely, google does that shit constantly, well known within the internet standards community
ramjambamalam@lemmy.ca · 6 pts · 278d
That used to be what Microsoft (Internet Explorer) was famous for. I guess Chrome has lived long enough to be the villain, but Firefox is still the hero to me.
GreyEyedGhost@lemmy.ca · 4 pts · 278d
Sorry to break it to you, but you might want to start looking at Firefox forks.
ramjambamalam@lemmy.ca · 1 pts · 277d
Why?
GreyEyedGhost@lemmy.ca · 3 pts · 277d
This article gives some information on why some have abandoned hope for Firefox and Mozilla. AI focus, changing its stance on selling user data, and the overall loss of focus. It's still better than most, IMO, but some of its forks better represent those who feel that way.
eskuero@lemmy.fromshado.ws · 91 pts · 279d
"we would welcome contributions to integrate a performant and memory-safe JPEG XL decoder in Chromium. In order to enable it by default in Chromium we would need a commitment to long-term maintenance."
yeah
ryannathans@aussie.zone · 11 pts · 278d
I.e. the existing implementation is not usable because it's not written in rust
captain_aggravated@sh.itjust.works · 8 pts · 278d
Or would they demand it in Go? Or have they abandoned that?
ryannathans@aussie.zone · 4 pts · 278d
That might work but didn't think go was
Kolanaki@pawb.social · 23 pts · 279d
The name of the format makes me think it's regular jpeg, but bigger. Wouldn't it be better to be smaller? 🤔
Cort@lemmy.world · 26 pts · 279d
No. They increased the max "canvas" size and increased encoding efficiency. You'd want the file size to be smaller but the file itself to be larger (and consequently more detailed)
bhamlin@lemmy.world · 10 pts · 278d
It's even more confusing than that; the
Xis for revision 10, and theLis for long term.It's an update to the JPEG standard intended to cover expected future uses and capabilities.
Brahvim@lemmy.kde.social · 4 pts · 278d
"10 LTS"?Sunrosa@lemmy.world · 2 pts · 277d
In my personal tests of jxl, it manages filesizes 1/9th that of png while remaining visually identical (unless looking VERY closely). It's a massive improvement over jpeg and honestly a replacement for png in most cases.
Like I'm saying 8MB for a 8000x6000 file at max quality (estimating from memory)
dormedas@lemmy.dormedas.com · 13 pts · 279d
Finally.
JoshsJunkDrawer@lemmy.ml · 7 pts · 278d
I just want a picture of a got-dang hot dog.
jaykrown@lemmy.world · -6 pts · 278d
Everyone should just be using AV1 at this point. https://en.wikipedia.org/wiki/AV1
Starfighter@discuss.tchncs.de · 20 pts · 278d
I assume you mean AVIF? Because AV1 is not an image (file) format but a video compression format (that needs to be wrapped in container file formats to be storable).
jaykrown@lemmy.world · 10 pts · 278d
"AVIF is an image file format that uses AV1 compression algorithms." yes i mean that
GraveyardOrbit@lemmy.zip · 13 pts · 278d
Strawberry@lemmy.blahaj.zone · 2 pts · 277d
please god no
reddig33@lemmy.world · -18 pts · 279d
I would be more excited about JPEG XL if it was backward compatible. Not looking forward to yet another image standard that requires OS and hardware upgrades simply so servers can save a few bytes.
Laser@feddit.org · 58 pts · 279d
How would a new format be backwards-compatible? At least JPEG-XL can losslessly compress standard jpg for a bit of space savings, and servers can choose to deliver the decompressed jpg to clients that don't support JPEG-XL.
Also from Wikipedia:
reddig33@lemmy.world · -27 pts · 279d
All you have to do is add a small traditional JPEG image at the start of the file. It doesn’t have to be high resolution or more than a couple of kb. The new format decoder would know this, and skip the traditional jpeg “header”, rendering the newer file format embedded in the image.
wischi@programming.dev · 49 pts · 279d
Would completely defeat the purpose of making a new smaller file format if we prefix if with the old format.
Laser@feddit.org · 15 pts · 279d
That would have been a brilliant move with wav vs MP3
reddig33@lemmy.world · -18 pts · 279d
If you’re really saving 20% in file size with XL, adding back a very compressed preview image that takes up one or two percent isn’t going to cost you much.
monk@lemmy.unboiled.info · 2 pts · 272d
but the anger of those looking at whatever they wanted to see, but deep-fried
LordKitsuna@lemmy.world · 10 pts · 279d
It requires neither of those upgrades though? Unless you're still using Windows XP I guess for some reason. It's just an update to the image decoder
REDACTED@infosec.pub · 7 pts · 279d
What does backward compability in image format even means? Being able to open it in windows image viewer?
Endymion_Mallorn@kbin.melroy.org · -38 pts · 279d
I just use old JPEGs. Not JPEG2000, not PNG, not WebP, not JPEG XL.
wischi@programming.dev · 68 pts · 279d
Feel free to use floppy disks. Btw if you are online, you use WebP and PNG all the time 🤣
Prove_your_argument@piefed.social · 26 pts · 279d
Sir, don't you dare encroach on those Lynx and W3M users. They don't need no stinking images!
Endymion_Mallorn@kbin.melroy.org · 7 pts · 279d
Lynx is the best browser.
ArsonButCute@lemmy.dbzer0.com · 1 pts · 278d
I prefer offpunk.
Archer@lemmy.world · 7 pts · 278d
Not if they use wget to only download the HTML!
Aequitas@feddit.org · 4 pts · 279d
If you are using Firefox:
SleeplessCityLights@programming.dev · 3 pts · 278d
Maybe this should come with a warning. The purpose of WebP is to quickly serve images to the user without grabbing the entire image data. Without WebP all images will be fully loaded, in the right conditions a page could load real slow.
SlurpingPus@lemmy.world · 2 pts · 278d
I love webp, but your explanation is a bit confused. Webp is typically lossy, just as jpeg — only, it's more efficiently compressed, meaning smaller size for the same image quality. So there's no 'entire image data', there are only different approximations of the original image and different compressed files. Full-blown lossless images in PNG or other formats take several times more data.
Disabling webp in favor of jpeg would use like 20-40% more data, in comparison. Which still sucks, but not as much.
Edit: maybe more than 40%, actually. Iirc I've seen webps that were half the size of jpegs. It's a good format, shame it's adopted rather poorly.
SleeplessCityLights@programming.dev · 1 pts · 278d
I wasn't going to get into the whole lossyness of the formats and just simplified to full image instead of compressed formatted. That is interesting that it is only saving 20%-40%. I was under the impression that the page only rendered the image size necessary to fit the layout and not the full resolution image. Forcing it to less lossy or lossless would mean that the larger image would always be available to be served to be rendered without any web request.
SlurpingPus@lemmy.world · 1 pts · 278d
That's a rather interesting consideration as to whether rendering at smaller sizes skips decoding parts of the image.
First, the presented file is normally always loaded in full, because that's how file transfer works over the web. Until lately, there were no different sizes available, and that only became widely-ish spread because of Apple's 'Retina' displays with different dots-per-inch resolution, mostly hidpi being two times the linear size of the standard dpi. Some sites, like Wikipedia, also support resizing images on the fly to some target dimensions, which results in a new image of the JPEG or other format. In any case, to my somewhat experienced knowledge, JPEG itself doesn't support sending every second row or anything like that, so you always get a file of a predetermined size.
First-and-a-half, various web apps can implement their own methods for loading lower- or higher-res images, which they prepare in advance. E.g. a local analogue to Facebook almost certainly loads various prepared-in-advance low-res images for viewing in the apps or on the site, but has the full-res images available on request, via a menu.
Second, I would imagine that JPEG decoding always results in the image of the original size, which is then dynamically resized to the viewport of the target display — particularly since many apps allow zooming in or out of the image on the fly. Specifically, I think decoding the JPEG image creates a native lossless image similar to BMP or somesuch (essentially just a 2d array of pixel colors), which is then fed to the OS's rendering capabilities, taking quite a chuck of memory. Of course, by now this is all accelerated by the hardware a whole lot, with the common algorithms being prepared to render raw pixels, JPEG, and a whole bunch of other formats.
It would be quite interesting if file decoding itself could just skip some part of the rows or columns, but I don't think that's quite like the compression works in current formats (at least in lossy ones, which depend on the previous data to encode later data). Although afaik JPEG encodes the image in rectangles like 16x16 or something like that, so it could be that whole chunks could be skipped altogether.
SleeplessCityLights@programming.dev · 1 pts · 278d
Your name is amazing
PrimeMinisterKeyes@leminal.space · 2 pts · 279d
AVIF started heavily creeping in, too.
popcar2@programming.dev · 3 pts · 279d
I've yet to see any AVIF in the wild. I think support for it is not quite there yet, everybody is still relying on WEBP.
pipes@sh.itjust.works · 3 pts · 278d
I've seen a lot of avifs masquerading as jpegs lol (I know because KDE Dolphin for some reason isn't showing a preview for those until I rename them)
Endymion_Mallorn@kbin.melroy.org · -12 pts · 279d
No, I have WebP blocked in my about:config. And I use Pale Moon, which actually blocks the things unlike modern FF. And I don't load PNG either.
eager_eagle@lemmy.world · 25 pts · 279d
lmao
SlurpingPus@lemmy.world · 16 pts · 278d
Do you also hit yourself in the nuts every morning to show the world how tough you are?
crimsonpoodle@pawb.social · 6 pts · 279d
I find this interesting there an advantage to the older formats or is this just for compatibility with custom photo editing tools?
Endymion_Mallorn@kbin.melroy.org · -4 pts · 279d
Compatibility is an advantage.
NotSteve_@piefed.ca · 13 pts · 279d
Why though
Endymion_Mallorn@kbin.melroy.org · -29 pts · 279d
Because I'm tired of all this nonsense where just because a thing is a mature technology, it's considered obsolete. Stop constantly pushing for the next thing. Keep the things that work.
cornshark@lemmy.world · 50 pts · 279d
"How dare they invent a more efficient image encoding! Back in my day we had bmp and we liked it!" - grandpa simpson
tauonite@lemmy.world · 15 pts · 279d
So I tied an onion to my belt, which was the style at the time
Endymion_Mallorn@kbin.melroy.org · -3 pts · 279d
I mean, BMP does still work as an uncompressed, artifact-free format.
BunScientist@lemmy.zip · 15 pts · 279d
you can have uncompressed png too
01189998819991197253@infosec.pub · 11 pts · 278d
Sure. But you use bmp when you want to nuke your drive space for no real reason.
ryannathans@aussie.zone · 6 pts · 278d
Wdym? This guy is still using punch cards
Fifrok@discuss.tchncs.de · 19 pts · 279d
It's unreasonable to stop further software development just because there's a 'mature' solution around. Besides, just because a solution is 'mature' doesn't make it good.
And considering that it seems like you can still use the original, about 30 year old format, doesn't look like there's any harm for the folks not needing or able to use the new stuff.
SaraTonin@lemmy.world · 17 pts · 279d
Webp is a smaller file size than jpeg for the same image quality in almost all circumstances - so it’s more efficient and quicker to load. It also supports lossless compression, transparency, and animation, none of which jpeg do. And the jpeg gets noticable visual artefacts at a much higher quality than webp does.
People didn’t adopt it to annoy you. It’s started to replace jpeg for the same reason jpeg started to replace bmp - it’s a better, more efficient format.
Aequitas@feddit.org · 6 pts · 279d
It is controlled by google tho
The_Decryptor@aussie.zone · 6 pts · 278d
For lower quality images sure, for high quality ones JPEG will beat it (WebP, being an old video format, only supports a quarter of the colour resolution than JPEG does, etc.) JPEG is actually so good that it still comes out ahead in a bunch of benchmarks, it's just it's now starting to show it's age technology wise (like WebP, it's limited to 8bpc in most cases)
It also doesn't hurt that Google ranked sites using WebP/AVIF higher than ones that aren't (via lighthouse).
Edit: I should clarify, this is the lossy mode. The lossless mode gives better compression than PNG, but is still limited to 8bpc, so can't store high bit depth, or HDR images, like PNG can.
Edit 2: s/bpp/bpc/
eager_eagle@lemmy.world · 10 pts · 279d
you know, using a better encoding is better for your dial-up internet too
GreenKnight23@lemmy.world · -1 pts · 278d
these damn kids will wake up on day and go, "why do you need xpg? jpgxl is just fine!"
they don't realize it yet that the only reason why jpeg xl exists is to silently slip that corpo collar around their necks.
🤷 only time can feed wisdom and cure stupid.
shishka_b0b@lemmy.zip · 7 pts · 279d
Oh yeah? Well I named my firstborn child JPEG!