How in the world do people store images / photos nowadays?
Just as there is a clear winner for video - av1 - there seems to be nothing in the way of "this is clearly the future, at least for the next few years" when it comes to encoding images.
JPEG is... old, and it shows. The filesizes are a bit bloated, which isn't really a huge problem with modern storage, but the quality isn't great.
JPEG-XL seemed like the next logical step until Google took their toys and killed it despite already having the support in Chrome, which pretty much makes it dead in the water (don't you just love monopolies making decisions for you?)
HEIC is good, as long as you pinky promise to never ever leave Apple's ecosystem, ie HEIC sucks.
AVIF seems computationally expensive and the support is pretty spotty - 8bit yuv420 might work, but 10b or yuv444 often doesn't. Windows 10 also chokes pretty hard on it.
Alternatives like WebP might be good for browsers but are nigh-unworkable on desktops, support is very spotty.
PNG is cheap and support is ubiquitous but filesizes become sky-high very quick.
So what's left? I have a whole bunch of .HEIC photos and I'd really like if Windows Explorer didn't freeze for literal minutes when I open a folder with them. Is jpeg still the only good option? Or is encoding everything in jpeg-xl or avif + praying things get better in the future a reasonable bet?
hengheng · 7m ago
Normal people use jpeg. It's good enough, much like mpeg-2 was good enough for DVDs. Compatibility always beats storage efficiency.
Photography nerds will religiously store raw images that they then never touch. They're like compliance records.
martin_a · 2h ago
> How in the world do people store images / photos nowadays?
Well, as JPEGs? Why not? Quality is just fine if you don't touch the quality slider in Photoshop or other software.
For "more" there's still lossless camera RAW formats and large image formats like PSD and whatnot.
JPEG is just fine.
afiori · 21m ago
I wonder how much of JPEG good quality is that we are quite accustomed to its artefacts.
SAI_Peregrinus · 2h ago
I store Raw + PSD with edits/history + whatever edited output format(s) I used.
MallocVoidstar · 2h ago
AV1 is not the clear winner for video. Currently-existing encoders are worse than x265 for high-bitrate encodes.
tristor · 2h ago
For my extensive collection of photography, I export to JPEG-XL and then convert to JPEG for use online. Most online services, like Flickr, Instagram, et al don't support JPEG-XL, but there's almost no quality loss converting from JPEG-XL to JPEG vs exporting to JPEG directly from your digital asset management system, and storing locally in JPEG-XL works very well. Almost all desktop tools I use support JPEG-XL natively already, conversely almost nothing support WEBP.
Zardoz84 · 2h ago
There is NO quality loss when converting from JPEG XL to JPEG and vice versa. It was done by design. Not an accident.
adgjlsfhk1 · 20m ago
this isn't true. there's no loss from jpeg to jpeg-xl (if you use the right mode), but the reverse is not true
Zardoz84 · 6m ago
I sorry to say that you are wrong about this.
> Key features of the JPEG XL codec are:
> lossless JPEG transcoding,
> Moreover, JPEG XL includes several features that help transition from the legacy JPEG coding format. Existing
JPEG files can be losslessly transcoded to JPEG XL files, significantly reducing their size (Fig. 1). These can be
reconstructed to the exact same JPEG file, ensuring backward compatibility with legacy applications. Both
transcoding and reconstruction are computationally efficient. Migrating to JPEG XL reduces storage costs
because servers can store a single JPEG XL file to serve both JPEG and JPEG XL clients. This provides a smooth
transition path from legacy JPEG platforms to the modern JPEG XL.
If you need more profs, you could transcode a JPEG to JPEG XL and convert against to JPEG. The result image would be BINARY IDENTICAL to the original image.
However, perhaps are you talking about an image on JPEG XL, using features only in JPEG XL (24 bit, HDR, etc...) that obviously couldn't be converted in a lossless way to a JPEG.
tristor · 1h ago
That's good to know. I'm not an image format expert, but I couldn't see any loss that was visually discernible at any rate.
NoMoreNicksLeft · 2h ago
>JPEG-XL seemed like the next logical step until Google took their toys and killed it despite already having the support in Chrome,
Why would I ever care about Chrome? I can't use adblockers on Chrome, which makes the internet even less usable than it currently is. I only start up chrome to bypass cross-origin restrictions when I need to monkey-patch javascript to download things websites try to keep me from downloading (or, like when I need to scrape from a Google website... javascript scraper bots seem to evade their bot detection perfectly, just finished downloading a few hundred gigabytes of magazines off of Google Books).
Seriously, fuck Chrome. We're less than 2 years away from things being as bad as they were in the IE6 years.
codazoda · 1h ago
I think we're there, not 2 years away.
I have software that won't work quite right in Safari or Firefox through a VPN every single day. Maybe it's the VPN and maybe it's the browser but it doesn't matter. We're at IE levels it's just ever so slightly more subtle this time. I'm still using alternatives but it's a battle.
NoMoreNicksLeft · 54m ago
VPN's layer 2... I suppose it could be resizing packets in such as way as to make it glitch out, but that just seems improbable.
Some of the warez sites I download torrents from have captchas and other javascripticles that only work on Chrome, but I've yet to see it with mainstream sites.
Fight the good fight.
bob1029 · 3h ago
Beyond the compression (which is amazing), JPEG is also extremely fast when implemented well. I'm not aware of any other image format that can encode at 60fps+ @ 1080p on a single CPU core. Only mild SIMD usage is required to achieve this. With dedicated hardware, the encode/decode cost quickly goes to zero.
I struggle to understand the justification for other lossy image formats as our networks continue to get faster. From a computation standpoint, it is really hard to beat JPEG. I don't know if extra steps like intra-block spatial prediction are really worth it when we are now getting 100mbps to our smartphones on a typical day.
You might be getting 100 Mbps to your smartphone; many people – yes, even within the United States – struggle to attain a quarter of that.
bob1029 · 2h ago
What is the likelihood of experiencing precisely marginal network conditions wherein webp improves the user experience so dramatically over jpeg that the user is able to notice?
If jpeg is loading like ass, webp probably isn't going to arrive much faster.
MrDOS · 2h ago
I'm sorry, I misunderstood your doubt of the usefulness of other lossy formats as criticism of using lossy formats in general in the face of higher bandwidth. Reading too fast, never mind me... :)
wizardforhire · 2h ago
Exactly! It’s like asking why we still use wheels when hovercrafts exist.
If humans are still around in a thousand years they’ll be using jpegs and they’ll still be using them a thousand years after that. When things work they have pernicious tendency to stick around.
pbhjpbhj · 2h ago
Can JPEG do 3D somehow (I'm thinking VR/AR)? DVDs lasted well, until the medium itself moved to cheap NAND flash and then various SSD technologies.
When/if simple screens get usurped then we'll likely move on from JPEG.
I'm sure you were being a little flippant but your last sentence shows good insight. Someone said "we just need it to work" to me the other day and the "if it works there will be little impetus to improve it"-flag went off in my brain.
adgjlsfhk1 · 12m ago
depends what you mean by 3d. jpeg-xl does let you add arbitrary channels, so you could add a depth channel, but it's not going to do a good job for full 3d (e.g. light field/point cloud).
one place I think jxl will really shine is PBR and game textures. for cases like that, it's very common to have color+transparency+bump map+normal map, and potentially even more. bundling all of those into a single file allows for away better compression
wizardforhire · 1h ago
Thanks, thats a great insight!
Idk about 3d, but I’ll assume someone probably will tape something out necessity if they haven't already.
…and yes, very flippant! But not without good reason. If we are to extrapolate; the popularity of jpeg, love it or hate it, will invariably necessitate it’s continued compatibility contributing to my pervious statement. That compatibility will invariably lead to plausible hypothetical circumstances where future developers out of laziness, ignorance, or just plain conformity to norms will lead to its choice and use perpetuating the cycle. The tendency as such is that short of a radical mass extension level like event brought about by mass wide spread technological adoption such as what you describe is why I don’t see it going away anytime soon. Not to say it couldn’t happen, I just feel it’s highly improbable because of the contributing human factors.
That jpeg gets so many complaints is I feel for two reasons. One, its ubiquity and two, that we actually see it!
Some similar situations that don’t get nearly as much attention but are far more pervasive are tcp/ip, bash, ntpd, ad nauseam. All old pervasive protocols so embedded as to be taken for granted, and also not able to be seen.
I’ll leave with this engineering truism that I feel should be more widely adhered to in software development, especially by UI designers: if it ain’t broke don’t fix it!
JacobiX · 3h ago
I loved the article, but it overlooks one important point: although the JPEG format is frozen, encoders are still evolving !
Advances such as smarter quantization, better perceptual models, and higher-precision maths enables us achieve higher compression ratios while sticking to a format that's supported everywhere :)
cogman10 · 2h ago
This is true, but there are limits. It's a little bit like DEFLAT. Sure, very advanced compressors like Zopfi exist which can get better compression ratios. But then, there's also just Zstd which will get a better compression ratio and compression speed trivially.
edflsafoiewq · 2h ago
I guess you're thinking of jpegli? Do you know how big a difference this actually makes?
ksec · 2h ago
Anywhere from 5-15% if I remember correctly depending on source material. I was at one point thinking this would make JPEG-XL and AV1F moot because all of a sudden JPEG became good enough again. But the Author of JPEG-XL suggest there is still so much JPEG-XL encoder can do to further optimise bit / quality especially in the bpp below 1.0 range.
JacobiX · 2h ago
MozJPEG, Guetzli and also Jpegli
reddalo · 3h ago
The article only briefly mentions the real problem: outside of browsers, proper support for .webp files is very, very low. That's why JPEG is still king and probably still be for a long time.
AshleysBrain · 3h ago
WebP seems pretty widely supported to me - on Windows at least, Explorer shows thumbnails for them, Paint can open them, other editors like Paint.NET have built-in support... I haven't come across software that doesn't support WebP for a while.
frollogaston · 2h ago
Google Docs, of all things, does not support webp. Preview on Mac can open it but not edit. Those are my two most common use cases.
coryrc · 10m ago
I celebrated the anniversary of the (internal) bug asking for SVG support in Google slides. I think it's up to 15 years now?
So, uh, don't get your hopes up.
frollogaston · 2m ago
Well SVGs I understand being harder to support, those aren't really images.
jhoechtl · 2h ago
Right so on Linux/KDE.
Is missing WebP support a meme?
freedomben · 13m ago
Yep, on Gnome we have both eog and GIMP that support webp completely, and have for many years. I don't think I've even tried with other apps but haven't needed to. I didn't even realize this was a problem for some platforms
CM30 · 2h ago
Case in point, DaVinci Resolve. Incredibly popular with people creating videos for YouTube and TikTok, still doesn't support webp in 2025.
This becomes an issue if you're creating content about trending topics, since lots of marketing sites love using webp for every image.
nemomarx · 3h ago
if I want to even download webp and look at the file I need to convert it. barely functional in basic image galleries outside of mobile?
k__ · 3h ago
Sometimes you upload a jpeg, they convert it to webp, and then don't allow uploading webps.
palmfacehn · 2h ago
I had uploaded lossless webp images, the 3rd party site cached the images from my server and re-encoded them as lossy format of a higher file size and lower fidelity.
edflsafoiewq · 2h ago
They'll do that to large PNGs too.
Acrobatic_Road · 3h ago
Also missing from popular browsers is support for the new JPEG XL format.
Looks like a mixture of runtime and compiler flags are needed except for Safari.
legitster · 3h ago
This takes me back to when the goal of a webpage was to be less than 1Mb. At the time, the only reason to use PNG (such luxury) was when you needed transparency.
The variable compression of JPEG was very important. In Photoshop you could just grab an image and choose the file size you needed and the JPEG quality would degrade to match your design constraints.
no_wizard · 3h ago
EDIT: I was wrong, and had PNG and JPEG formats backward. As others correctly pointed out PNG is lossless where as JPEG is lossy. PNG is better for marketing / UI / artistic imagery and JPEG for photographs due to the tolerance for JPEGs lossy encoding with photographs, seems to be the generally accepted opinion now.
Regardless, since the picture tag[0] was introduced I’ve used that for most image media by default with relevant fallbacks, with WebP as default. Also allows loading relevant sized images based on media query which is a nice bonus
JPEG is lossy, in ways that were initially optimized for photographs. The details it loses are often not details photographs are good at providing in the first place. As the upside for losing some data, it gets to pick the data it gets to compress, and it chooses it in such a way as to minimize the size of the compressed data.
PNG is a lossless format. It's practically mandatory when you need 100% fidelity, as with icons or other graphics that are intended to have high contrast in small areas. It's able to optimize large areas of the same color very well, but suffers when colors change rapidly. It's especially unsuitable for photographs, as sensor noise (or film grain, if the source was film) create subtle color variations that are very difficult for it to encode efficiently.
You basically never have a situation where either one is appropriate. They are for different things, and should be used as such.
MrDOS · 3h ago
PNGs for line art and text, JPEGs for photorealistic images.
> When I came up in the IE era
In the IE era I recall, the battle was between GIF and JPEG because IE supported alphatransparent PNGs very poorly :)
> if I recall correctly JPEG as a format can encode an image with a higher fidelity than PNG
The other way around: JPEGs are “lossy” – they throw away visual information to save file size. PNGs, on the other hand, are “lossless”, and decode back to exactly the same pixels that were fed into the encoder.
no_wizard · 3h ago
It’s been so darn long since I looked into these formats I got it backward. Thank you!
Tobani · 3h ago
They're different beasts.
JPEGS are great for photographs, where lossy compression is acceptable.
PNGs can have transparency and lossless compression, so they're great for things like rasterized vector graphics, UI-element parts of a web page, etc.
kevingadd · 3h ago
PNGs are also ideal for color accuracy since one of the things you lose quickly when converting to JPEG is the ability to have an exact RGB value flow from input to output, even at a high quality level. So if you want i.e. a banner graphic to seamlessly blend in with your site's background color, JPEG is worse for that.
martin_a · 2h ago
Sorry, but that sounds more like a problem with your color management systems and workflows and not so much with JPEG itself.
roelschroeven · 3h ago
It depends on the use case.
For archival purposes, where you care about not losing details is more important than image size, PNG is better (though often TIFF is used for that use case). For images with large blocks of solid colors and sharp edges (text, line drawings), PNG is arguable better (though JPEG can be acceptable if you're careful with quality settings). If you need alpha support, go for PNG since JPEG doesn't support that.
For photograph-like images, where image size is important, JPEG is preferred over PNG.
uses · 3h ago
PNG should be used for some types of graphics, like whenever you have big areas of solid color (like logos) or any time you need translucency / transparency. Although, nowadays you can and should use SVG in most of those cases.
JPEG should be used for everything else.
adgjlsfhk1 · 10m ago
if your software supports it, lossless jpeg-xl supports all of these and should give you better compression
ghssds · 2h ago
JPEG and PNG don't work the same way. JPEG is lossy - it removes information from the original image, and PNG is lossless. For distribution, like on a website, with JPEG you can compress the image much more than PNG without the users noticing IF the image is photographic. If the JPEG represents a drawing, a screenshot, or contains labels, the lossy compression will be noticeable and PNG is much more appropriate. To keep as master for further modifications and compressions, keeping an image in JPEG format is a bad idea, again because JPEG is lossy. You can't ever encode an image with higher fidelity in JPEG vs PNG but both are useful.
sapiogram · 3h ago
> (if I recall correctly JPEG as a format can encode an image with a higher fidelity than PNG, at least in some circumstances)~
PNG is a lossless format, so I don't think that's possible, unless there's some specific feature that is not available in PNG.
addaon · 3h ago
> if I recall correctly JPEG as a format can encode an image with a higher fidelity than PNG, at least in some circumstances
24-bit color PNGs are lossless, to the extent that the input image is encodable in 24 bits of RGB (which is pretty much everything that's not HDR). There's no higher fidelity available for normal input images. If file size limits would force palettized PNGs, it's quite possible for a JPEG at the same file size to have higher fidelity (since it makes a different set of trade-offs, keeping color resolution but giving up spatial resolution instead); but this isn't really a common or particularly valid comparison in the PNG era, was more of an issue when comparing to GIFs.
tl;dr: Nope, PNG is perfect. JPEG can approach perfect, but never get there. Comparison is only interesting with external (e.g. file size) constraints.
This submission was originally shown as [dead]. I have no idea why, I read some of the content and seems decent enough, especially in the current state of things when JPEG-XL is blocked because of AOM / Google Chrome. I vouched for it and upvoted, then somehow it is on the front page.
I wonder if dead means somehow flagged it. If so, then why? If not, why is it dead?
poisonborz · 1h ago
The actual issue is that this is not an issue for the users. Only global providers, so they were the ones pushing "obscure" solutions. Music fidelity was more of a consumer problem, so formats like FLAC found a foothold besides the go-to one.
hungryhobbit · 2h ago
I love how the article implies there's something flawed about webp at the end ... but if you click the link the only "flaw" reported is that webp isn't ubiquitous enough yet, so some sites don't support it
Perfect logic: let's not switch to webp because it's bad. Why is it bad? Not everyone has switched to it yet.
frollogaston · 2h ago
The lack of support makes me suspicious of it. If even Google Docs finds it too difficult to prioritize webp support, idk if there's some hidden problem with ease of implementation.
msabalau · 2h ago
As an enduser, I hate, hate, hate webp, because I cant' easily use the images in a wide range of ways.
Maybe it's vaguely more flexible and compresses well. I don't care. If someone uses it, I despise them.
greenavocado · 3h ago
DO NOT USE WEBP
JPEG-XL is the superior format. The only reason WebP exists is not because of natural selection, but because of nepotism (Google Chrome).
JPEG-XL is supported by exactly 1 browser. WebP and AV1F are supported by just about every browser.
I'd love to use JPEG-XL, but I'm guessing the only way to do that is also bringing along a WASM decoder everywhere I want to use it.
caycep · 2h ago
due to above said nepotism...
standards require some politicking and money I suppose
Arnt · 1h ago
Standards do require that. Someone has to show up at the right meetings and conferences, and it's often necessary to contribute code too.
"Build it and they will come" doesn't work for products, and it doesn't work for standards either.
Arnt · 1h ago
... and I want to add that there's no need to assume nepotism.
If you get code merged into something like Chrome, and it's big and goes unused for a few years, at some point some security-minded person will come along and argue that your code is an unused attack surface and should be removed again.
ericmcer · 1h ago
Standardization is the most important feature a technology can have. Look at JS.
NoMoreNicksLeft · 2h ago
There are only two browsers, Safari and Firefox.
Acrobatic_Road · 2h ago
only Nightly
whywhywhywhy · 3h ago
Upload a JPEG, gets converted to WEBP
next person, downloads WEBP converts it to JPEG to actually edit it in software because even things like Photoshop/MacOS Preview can't edit one natively, saves to JPG and uploads, gets converted to WEBP
next person downloads the now JPEG's WEBP'd JPEG'd WEBP'd image
fast forward a decade the original quality versions of the images no longer exist just these degraded
blooalien · 2h ago
Even if you have image editing software that directly supports WEBP format input / output, you still have the exact same problem, because (like JPEG) it's a lossy format which will lose fidelity with each successive generation of load / save over time. If you intend to edit an image, then the original (if possible) and it's edit should both be saved in a lossless format even if the final published output is saved in a lossy format. If no lossless format of the original is available, then the highest quality version of the original should be converted to a lossless format for "archival" before editing, and that copy should always be used for editing purposes, rather than piling loss upon loss editing the lossy format and re-saving. It's kinda like copies of copies of copies of MP3 audio. Eventually it becomes a soupy mess not worth using.
vunderba · 13m ago
Well... kinda. WebP is a bit of an unusual format in that it supports both lossy and lossless forms of compression.
Most decent image editing software (Photoshop, Pixelmator, etc) will let you choose what you want.
So, what you are saying is that JPEG-XL is superior, as long as your use case is insensitive to whether the majority of web users can view your content?
alwillis · 2h ago
I get it but 2+ billion Apple device users is not nothin’.
They can render JPEG-XL; everything else will render the fall back format like JPEG or WebP.
throw_m239339 · 2h ago
Teams & developers will likely only chose a single format if they can, the one that most browsers support, because doing some content negotiation is more code, more work. It doesn't take away anything from the parent point though, if JPEG-XL is more performant it could reduce bandwidth requirements.
Zardoz84 · 2h ago
just fuking use a poly fill to add support of JPEG XL. Or store JPEG XL and convert on the fly to JPEG to supply it to browsers that don't support JPEG XL.
> just fuking use a poly fill to add support of JPEG XL. Or store JPEG XL and convert on the fly to JPEG to supply it to browsers that don't support JPEG XL.
Doesn't a polyfill imply more Javascript running on the device?
Zardoz84 · 3m ago
Tt's a WASM . And really isn't very big. So if you need to store and serve many images files, potentially big images like in an preservation & diffusion software (like the stuff that I'm working), I felt that I could afford to pay the extra few KiBs on that WASM.
BugsJustFindMe · 2h ago
Only until the browser gets updated and then the polyfill stops being invoked automatically. It's self-healing.
Spivak · 2h ago
I mean if you define superior not in terms of its technical merits but because of its blessed status by Google. It's not a terrible format but it is very much "what is the worst quality we can reasonably get away with to save on bandwidth." Such a thing does have its uses.
At some point you have to be pragmatic and meet users where they are but doesn't mean you have to like that Google did throw their weight around in a way that only they really can.
dragonwriter · 2h ago
> I mean if you define superior not in terms of its technical merits
“Technical merits” are rarely, for anything, the sole measurement of fitness for purposes.
Even for purely internal uses, internal social, cultural, and non-technical business constraints often have a real impact on what is the best choice, and when you get out into wider uses with external uses, the non-technical factors proliferate. That's just reality.
I understand the aesthetic preference to have decisions only require considering a narrow set of technical criteria which you think should be important, but you will make suboptimal decisions in the vast majority of real-world circumstances if you pretend that the actual decision before you conforms to that aesthetic ideal.
palmfacehn · 3h ago
I enjoy webp lossless mode
frollogaston · 2h ago
I'm not going to use webp or jpeg-xl.
RankingMember · 6m ago
Yeah they're both a pain in that there's friction at all to open/use them.
gjsman-1000 · 2h ago
JPEG XL is superior... just like how Betamax was visually superior.
greenavocado · 2h ago
The main problem with your argument is the people want JPEG-XL. The main reason it is not in is purely due to Jim Bankoski's limited judgement, intelligence, and foresight.
Just like how some people wanted Betamax. Politics drives adoption; not technical superiority.
greenavocado · 2h ago
Thankfully, unlike people and physical hardware, software and algorithms can lie in wait in perpetuity until they are resurrected when the political winds finally change course or favorable conditions for their spread emerge.
throw_m239339 · 2h ago
> Thankfully, unlike people and physical hardware, software and algorithms can lie in wait in perpetuity until they are resurrected when the political winds finally change course or favorable conditions for their spread emerge.
XHTML 2 is waiting on that one... Oh well...
izacus · 2h ago
"People" here are a tiny minority of techies that have emotional connection to the library they built and a group of OSSers which will take anything that bashes Google as a gospel.
Everyone else... is fine with JPEG. And occasionally shares HEIC pictures from their iPhones.
fastball · 3h ago
> These days, the format is similar to MP3 or ZIP files—two legacy formats too popular and widely used to kill.
While killing MP3 might be difficult, the vast majority of people aren't handling audio files themselves these days, so probably not hard to phase out fairly rapidly.
frollogaston · 2h ago
I do handle files myself, but almost nothing keeps me on MP3. The only time I've even seen an MP3 in the past few years was when trying to get music into an old car system, which also sucked so much (e.g. shuffle feature with replacement) that I went back to just using the aux.
Krasnol · 3h ago
The Western World perspective on this platform generates quite funny statements sometimes. Outside of it, mp3 is still quite popular and normal.
Even within the Western World, there are many people who like to own their digital music.
geerlingguy · 3h ago
I still encode everything in MP3. The files work on my 20 year old SanDisk player, my original iPod, my iPhone, Mac, Chromebook, Windows laptop, MP3 CDs in our 08 minivan...
It's nice to have that consistent ubiquity, something very hard to find these days. Especially if you're entire audio library (audio books, podcasts, songs) comes from some streaming service that requires an app!
frollogaston · 2h ago
The poor quality is a dealbreaker for me. Yes it's fine with a high enough bitrate, but there isn't ubiquitous support for that.
conradfr · 3h ago
Like when someone says spending $1000 to learn to code effectively using Claude or any other AI is nothing.
martin_a · 2h ago
As others have pointed out, JPEG is just fine. It's "enough" in the best sense of the word and gets its job done. It's supported on every device, in every browser, image viewer and whatnot. It. Just. Works.
Maybe there are formats that compress better or lossless, but thanks to advancements in disk space and transfer rates (I know, not everywhere but penetration and improvement will happen...) the disadvantages of JPEG can be handled and we can just enjoy a very simple file format.
In an era where enshitification lingers around every corner I'm just happy that I don't need to think about whether I have to convert _every digital picture I've ever taken_ into some next-gen format because some license runs out or whatnot. It just works. Let's enjoy that and hope it sticks around for 30 more years.
MallocVoidstar · 3h ago
JPEG: No active patents, universal support, good enough.
HEIC: Have fun licensing this.
WebP: Slightly better than JPEG maybe, but only supports 1/4 chroma resolution in lossy mode so some JPEGs will always look better than the equivalent WebP.
AVIF: Better than JPEG probably, but encoders for AV1 are currently heavily biased towards blurring, even at very high bitrates. Non-Chrome browser support took a while.
dylan604 · 3h ago
Sometimes a format is simply just good enough. The gains that WebP may or may not have definitely do not get it over the hump of being so tied to a browser. AVIF is still very new, but other than the anim stuff, is it enough of an improvement to get people to switch. And that brings me to the entire corpus of existing files. A JPEG decoder will always be necessary based on the amount of preexisting files requiring it. If you have to support JPEG for some, might as well continue making new in the same format as well.
llm_nerd · 3h ago
JPEG XL: Better than JPEG in every way aside from legacy support, while being royalty free and open.
You can even "losslessly" compress existing JPEGs to JPEGXL.
JPEG XL is the natural replacement for JPEG and it is perverse that Google backtracked on supporting it.
addaon · 2h ago
> JPEG XL: Better than JPEG in every way aside from legacy support, while being royalty free and open.
And decoder complexity. A software JPEG decoder is a weekend project. A hardware JPEG decoder not much more. Doing the same for arbitrary JPEG XL files is much, much more complicated. In any world where any of development cost, implementation complexity, expected code quality (especially when using first-order assumptions like constant number of defects per line of code), or decoder resources (especially for hardware implementations) are important, JPEG has serious advantages.
_kidlike · 3h ago
what about PNG?
kccqzy · 2h ago
Apples and oranges. PNGs aren't used for photographic images. It's good for line art, certain cartoons, pixel art and the like.
zargon · 2h ago
Entirely different category.
politelemon · 2h ago
The last part of the article about jpeg being outpaced seems anecdotal or unsubstantiated, it needs context.
77pt77 · 3h ago
How come jpeg 2000 never became popular?
izacus · 1h ago
In 99% cases of "Why wasn't this (better) format adopted?" the answer is:
* It's not actually better.
* It's patented/requires license/is owned by someone who wants a lot of royalties.
JPEG2000 is of the second variety.
SimplyUnknown · 3h ago
Multiple reasons, while technically better and more benign compression artifacts, it is computationally more expensive, limited quality improvements, encumbered by patents, poor Metadata format, poor colorspace support... In the end, the benefits aren't great enough compared to jpeg to change the default format
AshleysBrain · 3h ago
IIRC JPEG2000 was never supported by any browser other than Safari, and even Safari recently gave up and removed support (around the same time they added support for JPEG XL). As to why other browsers never supported it, I'm not sure.
Maken · 3h ago
JPEG 2000 used to be a patent minefield.
meindnoch · 2h ago
Greed. Wavelets used to be heavily patented.
llm_nerd · 3h ago
Orthogonal, but one fun thing about JPEG 2000 is that when you watch a movie at movie theatres now, odds are overwhelming that you are watching a sequence of JPEG 2000 encoded images.
77pt77 · 2h ago
So like mjpeg but for jpeg 2000?
That doesn't even make much sense because you lose inter-frame compressibility
meindnoch · 5m ago
Every frame is a keyframe in digital cinema. It's literally a bunch of JPEG2000 files, wrapped in an MXF container. A typical 2hr movie is in the 300-400GB ballpark.
echelon · 3h ago
Nothing supports WebP.
Most websites break with WebP. Desktop tools choke on WebP.
It sucks, because it's a good format.
JonnyReads · 3h ago
I've recently been battling with github not having support for WebP. Seems odd for a website not to support an image format when the browser does.
afavour · 3h ago
> Most websites break with WebP
That part at least isn't true.
edflsafoiewq · 3h ago
Probably they mean uploading WebPs where an image is expected often doesn't work.
echelon · 2h ago
Yes, I was referring to the backends.
A funny case in point: Sora.com produces WebP outputs, but you can't turn around and use them as inputs. (Maybe they've fixed that?)
Smaller websites almost always reject them. Even within big websites, support is fractured within the product surface area. You can't use them as Reddit profile icons, for instance.
One of the most apparent issues is that a lot of thumbnailing and CDN systems don't work natively with WebP, so you have to reject WebP outright until broader support is added.
Once the WebPs are in your systems, you have to make sure everything downstream can support them... it's infectious.
Really unfortunate that we haven't been able to move past this.
martin_a · 2h ago
You can think about WordPress what you want, but afaik it does not allow to upload WebP files to its media gallery without any additional plugins while being said to run large parts of the internet...
jmyeet · 3h ago
So there are two use cases for public image dissemination:
1. Lossy: JPEG fills this role;
2. Lossless: this was GIF but is now PNG; and
3. Animated: GIF.
So for a format to replace JPEG, it must bring something to the table for lossy compression. Now that JPEG is patent-free, any new format must be similarly unencumbered. And it's a real chicken-and-egg problem in getting support on platforms such that people will start using it.
I remember a similar thing happening with Youtube adding VP9 (IIRC) support as an alternate to H264, which required an MPAA patent license. The MPAA also tried to cloud VP9 by saying it infringed on their patents anyway. No idea if that's true or not but nobody wants that uncertainty.
Anyway, without total support for VP9 (which Apple devices didn't have, for example) Youtube would need to double their storage space required for videos by having both codecs. That's really hard to justify.
Same goes for images. You then need to detect and use a supported image format... or just use JPEG.
Just as there is a clear winner for video - av1 - there seems to be nothing in the way of "this is clearly the future, at least for the next few years" when it comes to encoding images.
JPEG is... old, and it shows. The filesizes are a bit bloated, which isn't really a huge problem with modern storage, but the quality isn't great.
JPEG-XL seemed like the next logical step until Google took their toys and killed it despite already having the support in Chrome, which pretty much makes it dead in the water (don't you just love monopolies making decisions for you?)
HEIC is good, as long as you pinky promise to never ever leave Apple's ecosystem, ie HEIC sucks.
AVIF seems computationally expensive and the support is pretty spotty - 8bit yuv420 might work, but 10b or yuv444 often doesn't. Windows 10 also chokes pretty hard on it.
Alternatives like WebP might be good for browsers but are nigh-unworkable on desktops, support is very spotty.
PNG is cheap and support is ubiquitous but filesizes become sky-high very quick.
So what's left? I have a whole bunch of .HEIC photos and I'd really like if Windows Explorer didn't freeze for literal minutes when I open a folder with them. Is jpeg still the only good option? Or is encoding everything in jpeg-xl or avif + praying things get better in the future a reasonable bet?
Photography nerds will religiously store raw images that they then never touch. They're like compliance records.
Well, as JPEGs? Why not? Quality is just fine if you don't touch the quality slider in Photoshop or other software.
For "more" there's still lossless camera RAW formats and large image formats like PSD and whatnot.
JPEG is just fine.
> Key features of the JPEG XL codec are: > lossless JPEG transcoding,
> Moreover, JPEG XL includes several features that help transition from the legacy JPEG coding format. Existing JPEG files can be losslessly transcoded to JPEG XL files, significantly reducing their size (Fig. 1). These can be reconstructed to the exact same JPEG file, ensuring backward compatibility with legacy applications. Both transcoding and reconstruction are computationally efficient. Migrating to JPEG XL reduces storage costs because servers can store a single JPEG XL file to serve both JPEG and JPEG XL clients. This provides a smooth transition path from legacy JPEG platforms to the modern JPEG XL.
https://ds.jpeg.org/whitepapers/jpeg-xl-whitepaper.pdf
If you need more profs, you could transcode a JPEG to JPEG XL and convert against to JPEG. The result image would be BINARY IDENTICAL to the original image.
However, perhaps are you talking about an image on JPEG XL, using features only in JPEG XL (24 bit, HDR, etc...) that obviously couldn't be converted in a lossless way to a JPEG.
Why would I ever care about Chrome? I can't use adblockers on Chrome, which makes the internet even less usable than it currently is. I only start up chrome to bypass cross-origin restrictions when I need to monkey-patch javascript to download things websites try to keep me from downloading (or, like when I need to scrape from a Google website... javascript scraper bots seem to evade their bot detection perfectly, just finished downloading a few hundred gigabytes of magazines off of Google Books).
Seriously, fuck Chrome. We're less than 2 years away from things being as bad as they were in the IE6 years.
I have software that won't work quite right in Safari or Firefox through a VPN every single day. Maybe it's the VPN and maybe it's the browser but it doesn't matter. We're at IE levels it's just ever so slightly more subtle this time. I'm still using alternatives but it's a battle.
Some of the warez sites I download torrents from have captchas and other javascripticles that only work on Chrome, but I've yet to see it with mainstream sites.
Fight the good fight.
I struggle to understand the justification for other lossy image formats as our networks continue to get faster. From a computation standpoint, it is really hard to beat JPEG. I don't know if extra steps like intra-block spatial prediction are really worth it when we are now getting 100mbps to our smartphones on a typical day.
You might be getting 100 Mbps to your smartphone; many people – yes, even within the United States – struggle to attain a quarter of that.
If jpeg is loading like ass, webp probably isn't going to arrive much faster.
If humans are still around in a thousand years they’ll be using jpegs and they’ll still be using them a thousand years after that. When things work they have pernicious tendency to stick around.
When/if simple screens get usurped then we'll likely move on from JPEG.
I'm sure you were being a little flippant but your last sentence shows good insight. Someone said "we just need it to work" to me the other day and the "if it works there will be little impetus to improve it"-flag went off in my brain.
one place I think jxl will really shine is PBR and game textures. for cases like that, it's very common to have color+transparency+bump map+normal map, and potentially even more. bundling all of those into a single file allows for away better compression
Idk about 3d, but I’ll assume someone probably will tape something out necessity if they haven't already.
…and yes, very flippant! But not without good reason. If we are to extrapolate; the popularity of jpeg, love it or hate it, will invariably necessitate it’s continued compatibility contributing to my pervious statement. That compatibility will invariably lead to plausible hypothetical circumstances where future developers out of laziness, ignorance, or just plain conformity to norms will lead to its choice and use perpetuating the cycle. The tendency as such is that short of a radical mass extension level like event brought about by mass wide spread technological adoption such as what you describe is why I don’t see it going away anytime soon. Not to say it couldn’t happen, I just feel it’s highly improbable because of the contributing human factors.
That jpeg gets so many complaints is I feel for two reasons. One, its ubiquity and two, that we actually see it! Some similar situations that don’t get nearly as much attention but are far more pervasive are tcp/ip, bash, ntpd, ad nauseam. All old pervasive protocols so embedded as to be taken for granted, and also not able to be seen.
I’ll leave with this engineering truism that I feel should be more widely adhered to in software development, especially by UI designers: if it ain’t broke don’t fix it!
So, uh, don't get your hopes up.
Is missing WebP support a meme?
This becomes an issue if you're creating content about trending topics, since lots of marketing sites love using webp for every image.
Looks like a mixture of runtime and compiler flags are needed except for Safari.
The variable compression of JPEG was very important. In Photoshop you could just grab an image and choose the file size you needed and the JPEG quality would degrade to match your design constraints.
Regardless, since the picture tag[0] was introduced I’ve used that for most image media by default with relevant fallbacks, with WebP as default. Also allows loading relevant sized images based on media query which is a nice bonus
[0]: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
JPEG is lossy, in ways that were initially optimized for photographs. The details it loses are often not details photographs are good at providing in the first place. As the upside for losing some data, it gets to pick the data it gets to compress, and it chooses it in such a way as to minimize the size of the compressed data.
PNG is a lossless format. It's practically mandatory when you need 100% fidelity, as with icons or other graphics that are intended to have high contrast in small areas. It's able to optimize large areas of the same color very well, but suffers when colors change rapidly. It's especially unsuitable for photographs, as sensor noise (or film grain, if the source was film) create subtle color variations that are very difficult for it to encode efficiently.
You basically never have a situation where either one is appropriate. They are for different things, and should be used as such.
> When I came up in the IE era
In the IE era I recall, the battle was between GIF and JPEG because IE supported alphatransparent PNGs very poorly :)
> if I recall correctly JPEG as a format can encode an image with a higher fidelity than PNG
The other way around: JPEGs are “lossy” – they throw away visual information to save file size. PNGs, on the other hand, are “lossless”, and decode back to exactly the same pixels that were fed into the encoder.
JPEGS are great for photographs, where lossy compression is acceptable.
PNGs can have transparency and lossless compression, so they're great for things like rasterized vector graphics, UI-element parts of a web page, etc.
For archival purposes, where you care about not losing details is more important than image size, PNG is better (though often TIFF is used for that use case). For images with large blocks of solid colors and sharp edges (text, line drawings), PNG is arguable better (though JPEG can be acceptable if you're careful with quality settings). If you need alpha support, go for PNG since JPEG doesn't support that.
For photograph-like images, where image size is important, JPEG is preferred over PNG.
JPEG should be used for everything else.
PNG is a lossless format, so I don't think that's possible, unless there's some specific feature that is not available in PNG.
24-bit color PNGs are lossless, to the extent that the input image is encodable in 24 bits of RGB (which is pretty much everything that's not HDR). There's no higher fidelity available for normal input images. If file size limits would force palettized PNGs, it's quite possible for a JPEG at the same file size to have higher fidelity (since it makes a different set of trade-offs, keeping color resolution but giving up spatial resolution instead); but this isn't really a common or particularly valid comparison in the PNG era, was more of an issue when comparing to GIFs.
tl;dr: Nope, PNG is perfect. JPEG can approach perfect, but never get there. Comparison is only interesting with external (e.g. file size) constraints.
This submission was originally shown as [dead]. I have no idea why, I read some of the content and seems decent enough, especially in the current state of things when JPEG-XL is blocked because of AOM / Google Chrome. I vouched for it and upvoted, then somehow it is on the front page.
I wonder if dead means somehow flagged it. If so, then why? If not, why is it dead?
Perfect logic: let's not switch to webp because it's bad. Why is it bad? Not everyone has switched to it yet.
Maybe it's vaguely more flexible and compresses well. I don't care. If someone uses it, I despise them.
JPEG-XL is the superior format. The only reason WebP exists is not because of natural selection, but because of nepotism (Google Chrome).
https://www.reddit.com/r/AV1/comments/ju18pz/generation_loss...
I'd love to use JPEG-XL, but I'm guessing the only way to do that is also bringing along a WASM decoder everywhere I want to use it.
standards require some politicking and money I suppose
"Build it and they will come" doesn't work for products, and it doesn't work for standards either.
If you get code merged into something like Chrome, and it's big and goes unused for a few years, at some point some security-minded person will come along and argue that your code is an unused attack surface and should be removed again.
next person downloads the now JPEG's WEBP'd JPEG'd WEBP'd image
fast forward a decade the original quality versions of the images no longer exist just these degraded
Most decent image editing software (Photoshop, Pixelmator, etc) will let you choose what you want.
https://www.adobe.com/creativecloud/file-types/image/raster/...
But if you're not a professional it would be easy to mix up the two and slowly end up with VHS level degradation.
They can render JPEG-XL; everything else will render the fall back format like JPEG or WebP.
In HTML, use `<picture>`: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
In CSS, use `image-set()`: https://developer.mozilla.org/en-US/docs/Web/CSS/image/image....
Doesn't a polyfill imply more Javascript running on the device?
At some point you have to be pragmatic and meet users where they are but doesn't mean you have to like that Google did throw their weight around in a way that only they really can.
“Technical merits” are rarely, for anything, the sole measurement of fitness for purposes.
Even for purely internal uses, internal social, cultural, and non-technical business constraints often have a real impact on what is the best choice, and when you get out into wider uses with external uses, the non-technical factors proliferate. That's just reality.
I understand the aesthetic preference to have decisions only require considering a narrow set of technical criteria which you think should be important, but you will make suboptimal decisions in the vast majority of real-world circumstances if you pretend that the actual decision before you conforms to that aesthetic ideal.
https://groups.google.com/a/chromium.org/g/blink-dev/c/WjCKc...
XHTML 2 is waiting on that one... Oh well...
Everyone else... is fine with JPEG. And occasionally shares HEIC pictures from their iPhones.
While killing MP3 might be difficult, the vast majority of people aren't handling audio files themselves these days, so probably not hard to phase out fairly rapidly.
Even within the Western World, there are many people who like to own their digital music.
It's nice to have that consistent ubiquity, something very hard to find these days. Especially if you're entire audio library (audio books, podcasts, songs) comes from some streaming service that requires an app!
Maybe there are formats that compress better or lossless, but thanks to advancements in disk space and transfer rates (I know, not everywhere but penetration and improvement will happen...) the disadvantages of JPEG can be handled and we can just enjoy a very simple file format.
In an era where enshitification lingers around every corner I'm just happy that I don't need to think about whether I have to convert _every digital picture I've ever taken_ into some next-gen format because some license runs out or whatnot. It just works. Let's enjoy that and hope it sticks around for 30 more years.
HEIC: Have fun licensing this.
WebP: Slightly better than JPEG maybe, but only supports 1/4 chroma resolution in lossy mode so some JPEGs will always look better than the equivalent WebP.
AVIF: Better than JPEG probably, but encoders for AV1 are currently heavily biased towards blurring, even at very high bitrates. Non-Chrome browser support took a while.
You can even "losslessly" compress existing JPEGs to JPEGXL.
JPEG XL is the natural replacement for JPEG and it is perverse that Google backtracked on supporting it.
And decoder complexity. A software JPEG decoder is a weekend project. A hardware JPEG decoder not much more. Doing the same for arbitrary JPEG XL files is much, much more complicated. In any world where any of development cost, implementation complexity, expected code quality (especially when using first-order assumptions like constant number of defects per line of code), or decoder resources (especially for hardware implementations) are important, JPEG has serious advantages.
* It's not actually better.
* It's patented/requires license/is owned by someone who wants a lot of royalties.
JPEG2000 is of the second variety.
That doesn't even make much sense because you lose inter-frame compressibility
Most websites break with WebP. Desktop tools choke on WebP.
It sucks, because it's a good format.
That part at least isn't true.
A funny case in point: Sora.com produces WebP outputs, but you can't turn around and use them as inputs. (Maybe they've fixed that?)
Smaller websites almost always reject them. Even within big websites, support is fractured within the product surface area. You can't use them as Reddit profile icons, for instance.
One of the most apparent issues is that a lot of thumbnailing and CDN systems don't work natively with WebP, so you have to reject WebP outright until broader support is added.
Once the WebPs are in your systems, you have to make sure everything downstream can support them... it's infectious.
Really unfortunate that we haven't been able to move past this.
1. Lossy: JPEG fills this role;
2. Lossless: this was GIF but is now PNG; and
3. Animated: GIF.
So for a format to replace JPEG, it must bring something to the table for lossy compression. Now that JPEG is patent-free, any new format must be similarly unencumbered. And it's a real chicken-and-egg problem in getting support on platforms such that people will start using it.
I remember a similar thing happening with Youtube adding VP9 (IIRC) support as an alternate to H264, which required an MPAA patent license. The MPAA also tried to cloud VP9 by saying it infringed on their patents anyway. No idea if that's true or not but nobody wants that uncertainty.
Anyway, without total support for VP9 (which Apple devices didn't have, for example) Youtube would need to double their storage space required for videos by having both codecs. That's really hard to justify.
Same goes for images. You then need to detect and use a supported image format... or just use JPEG.