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?
> 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?)
It's worth noting that Firefox is willing to adopt JPEG-XL[1] as soon as the rust implementation[2] is mature And that rust impl is a direct port from the reference C++ implementation[3]. Mac OS and Safari already support JPEG-XL [4]. And recently Windows picked up JPEG-XL support. The only blockers at this point are Firefox, Chromium, and Android. If/when Firefox adopts JPEG-XL, we'll probably see google follow suit if only out of pressure from downstream Chromium platforms wanting to adopt it to maintain parity.
So really if you want to see JPEG-XL get adopted, go throw some engineering hours at the rust implementation [2] to help get it up to feature parity with the reference impl.
g**gle is hellbent on killing JPEG-XL support in favor of WebP. assuming they'll capitulate to downstream pressure is a stretch. this article [0] sums it up nicely:
What this [removal of support for JPEG-XL in Chromium] really translates to is, “We’ve created WebP, a competing standard, and want to kill anything that might genuinely compete with it”. This would also partly explain why they adopted AVIF but not JPEG XL. AVIF wasn’t superior in every way and, as such, didn’t threaten to dethrone WebP.
I'm not assuming they capitulate under just pressure. Rather I'm assuming they'll capitulate if a majority of or even all of the big third party chromium browsers push for adding it to mainline chromium.
This is less just blind pressure but rather the risk that google becomes seen as an untrustworthy custodian of chromium and that downstreams start supporting an alternate upstream outside of google's control.
Jxl is certainly a hill that google seems intent to stand on but I doubt it's one they'd choose to die on. Doubly so given the ammo it'd give in the ongoing chrome anti-trust lawsuits.
Chrome is a "free funnel" into Google services, just like Android.
That 20B a year that Google pays to Apple, think of that but a bigger traffic stream. That is Chrome, so Chrome is worth MORE than 20B a year to Google.
The risks and downsides of exposing an image decoder to the entire web are very real, especially a relatively new/untested one written in a language like C++. There's been vulnerabilities in pretty much every other image decoder and I fully expect jpeg-xl to be no different. You can't just brush that aside. Hell, article doesn't even acknowledge it. Google has no real stake in webp vs. jpeg-xl either. You may disagree with the decision, this this kind of stuff doesn't make much sense.
OS support includes Windows 10 v1083, Android 10+, Ubuntu 20.04, Debian 10, Fedora 36. Lots of cameras and smartphones support it as well.
There's nothing Apple-specific about it. Apple went through the process of licensing H.265, so they got HEIC 'for free' and use it as the default image format because over JPEG it supports: HDR, >8-bit colour, etc.
†Like WebP was similar to an image/frame from a VP8 video.
Support is virtually non-existent. Every year or so, I try to use my Windows PC to convert a RAW photo taken with a high-end Nikon mirrorless camera to a proper HDR photo (in any format) and send it to my friends and family that use iDevices.
This has been literally impossible for the last decade, and will remain impossible until the heat death of the universe.
Read-only support is totally broken in a wide range of apps, including Microsoft-only apps. There are many Windows imaging APIs, and I would be very surprised if more than one gained HEIC support. Which is probably broken.
Microsoft will never support an Apple format, and vice versa.
Every single new photo or video format in the last 25 years has been pushed by one megacorp, and adoption outside of their own ecosystem is close to zero.
JPEG-XL is the only non-megacorp format that is any good any got and got multi-vendor traction, which then turned into "sliding backwards on oiled ice". (Google removed support from Chromium, which is the end of that sad story.)
Also good to know, the ff nightly feature for jpeg xl currently does NOT use the aforementioned decoder, it uses something else, hence it's worthless for testing at the moment...
> Every year or so, I try to use my Windows PC to convert a RAW photo taken with a high-end Nikon mirrorless camera to a proper HDR photo (in any format) and send it to my friends and family that use iDevices.
> This has been literally impossible for the last decade, and will remain impossible until the heat death of the universe.
It's possible right now with gainmap jpegs. Adobe can create them, Android captures in them now, and Apple devices can view them even. Or if they can't yet they can very soon, Apple announced support at the recent WWDC (Apple brands it "adaptive HDR")
There's something kinda hilariously ironic that out of all these new fancy image codecs be it HEIC, AVIF, or JPEG-XL, it's humble ol' JPEG that's the first to deliver not just portable HDR, but the best quality HDR of any format of any kind
Create a HDR HEIC file on anything other than an Apple Device.
Upload it to an Apple Device.
Now use it any way: Forward it, attach it to a message, etc...
This won't work.
It won't ever work because the "standard" is not what Apple implements. They implement a few very specific subsets that their specific apps produce, and nothing else.
Nobody else implements these specific Apple versions of HEIC. Nobody.
For example, Adobe Lightroom can only produce a HEIC file on an Apple device.
My Nikon camera can produce a HDR HEIC file in-body, but it is useless on an Apple device because it's too dark and if forwarded in an iMessage... too bright!
It's a shit-show, comparable to "IPv6 support" which isn't.
That's not an argument. HEIC is to HEVC what WebP is to WebM. The lack of support in other products is due to developers not picking up the pace and sticking with "GIF, JPEG and PNG is good enough".
Confusingly, there are two different MPEGs in this context.
MPEG the standards group is organized by ISO and IEC, along with JPEG.
The one you’re thinking of - MPEG LA, the licensing company - is a patent pool (which has since been subsumed by a different one[1]) that’s unaffiliated with MPEG the standards group.
5203 active patents for HEVC, 1480 for H.264. That's just plain insane! I get that video formats are complex, but complex enough to consist of 5000+ distinct, nontrivial inventions?
As far as I know, that's only support for the container format. You can't actually decode HEIC without also installing libde265, which you are supposed to have a license for. I'm not even sure how you'd go about getting an individual license.
> You can't actually decode HEIC without also installing libde265, which you are supposed to have a license for. I'm not even sure how you'd go about getting an individual license.
> 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.
Say what? A random scan across the internet will reveal more videos in MP4 and H.264 format than av1. Perhaps streaming services have switched, but that is not what regular consumers usually use to make and store movies.
New compressed media formats always travel a decade-long path from either (1) obscurity → contender → universal support or (2) obscurity → contender → forgotten curiosity. AV1 is on one path, WebP is on another.
WebP remains fairly esoteric after 15 years, has always been a solution in search of a problem, and isn’t even universally supported in products by its owner.
AV1 was created and is backed by many companies via a non-profit industry consortium, solves real problems, and its momentum continues to grow. https://bitmovin.com/blog/av1-playback-support/
Funnily enough, JPEG2000-support was eventually removed everywhere. I assume the only reason this didn't happen with WebP as well is Google pushing and keeping it in Chrome.
Only support for decoding and from A17 Pro and M3 onwards, I believe? Going to be a few years before that's commonly available (he says from the work M1 Pro.)
Yeah, I think I only just found out about av1 a few weeks ago with a video file that wouldn't play. Thought it was corrupted at first it's been so long since I saw something like that.
From what I've seen WebP is probably the strongest contender for a JPEG replacement. It's pretty common in the indie game scene for example to re-encode a JPEG game to WebP for better image quality and often a significant (25% or more) savings on installer size. Support is coming, albeit somewhat slowly. It was pretty bad in Ubuntu 22, but several apps have added support in Ubuntu 24. Windows 11 supports WebP in Photos and Paint for another example.
I hate webp. Not for any legitimate technical reason like, but I often just want to download an image from the web for an image board or drop it in a diagram or ppt or for a joke and nothing works with that format. Nothing. Google image search is useless because of it.
Cmd+shift+4 is now the only way to grab an image out of a browser. Which is annoying.
It has made my life needlessly more complicated. I wish it would go away.
Maybe if browsers auto converted when you dragged ann image out of the browser window I wouldn’t care, but when I see webp… I hate.
Often (in my experience) WebP is served as a bait-and-switch even if the link ends with .jpg. So I use Curl to fetch the file, and since Curl doesn't send "Accept: image/webp" unless you tell it to, the server just gives you what you ask for.
I once edited Firefox config to make it pretend to not support WebP, and the only site that broke was YouTube.
My working model is that WebP images are generally a lossy copy of a PNG or a generation-loss transcoding of a JPG image. I know that lossless WebP technically exists but nobody uses it when they're trying to save bandwidth at the cost of the user.
That's true of any new format. Until everything supports it it's not so great. iPhone saves .HEIC which I have to convert to something else to be useful. It's not everywhere (not sure it ever will be).
Windows didn't use to show .jpgs in the window explorer. I know becase I wrote a tool to generate thumbnail HTML pages to include on archive CDs of photos.
To solve this problem, some format has to "win" and get adopted everywhere. That format could be webp, but it will take 3-10 years before everything supports it. It's not just the OS showing it in it's file viewer. It's it's preview app supporting it. It's every web site that lets you upload an image (gmail/gmaps/gchat/facebook/discord/messenger/slack/your bank/apartment-rental-companies, etc..etc..etc..) I just takes forever to get everyone to upgrade.
WebP gets pushed into your series of tubes without your consent, and the browser that you're most likely to use to view them just happens to be made by the same company that invented the codec. It's DivX and Real Media all over again.
Worst case you can open it up in Paint and save as JPEG.
Also, I just checked and Powerpoint has no problem dropping in a webp image. Gimp opens it just fine. You are right that web forums are often well behind the times on this.
On the classic macs they’re was a program called DropDisk. You could drag a disk image to it and it auto mounted it. That suggests a tool for you. Make a desktop app that you can drag and drop images on that converts them to jpeg and saves them in a folder.
It's a constant battle though to keep those browser extensions updated, especially since Google decided that extensions cut into their profits and they essentially made them useless.
That's such a weak argument. If I was an indie game developer, I would use whatever obscure format would offer me the most benefit, since I control the pipeline from the beginning (raw TIFF/TGA/PNG/... files) to the end (the game that needs to have a decoder and will uncompress it into GPU memory). 20 minutes extra build-time on the dev machine is irrelevant when I can save hundreds of MBs.
However, that is not the benchmark for a format widely used on the internet. Encoding times multiply, as does the need to search for specialized software, and literally everyone else needs to support the format to be able to view those files.
The last major browser to add support was Safari 16 and that was released on September 12, 2022. I see pretty much no one on browsers older than Safari 16.4 in metrics on websites I run.
Yeah, after seeing the logs I made the switch to webp earlier this year. As much as I hate to admit it (not a fan of Google), it’s a pretty big bandwidth savings for the same (or better) quality.
I switched to webp on my forum for avatars and other user image uploads.
With one format you get decent filesize, transparency, and animation which makes things much simpler than doing things like conditionally producing gifs vs jpegs.
I'd love to see a comparison of the computational expense of avif compared to webp. I know av1, which avif is based off, is pretty hard on the hardware.
I think most photography nerds who want to save edited images to a lossless format will use TIFF, which is very different from the proprietary "raw" files that come out straight out of the camera.
The file as it comes out of the camera, so-called raw, is a family of formats. Usually such files are kept untouched and any edits are saved in a lightweight settings file (in the format of your editing app) alongside the original.
I'm not even really a hobbyist photographer anymore, but when I was, the full lossless edit was a .psd and that was generally exported to (high quality) jpg for distribution. I have folders full of carefully curated raws. For the relatively few that were ever edited they have an accompanying psd. The jpgs are ephemeral and don't get saved long term.
I've never seen JPEG artifacts on images modified/saved 5 or fewer times. Viewing on a monitor including at 100%, printing photos, whatever - in practice the artifacts don't matter.
jpeg artifacts mainly show up on drawings. where they seriously degrade masking operations. which is a hobby of mine. so I always appreciate it when a drawing is a png. rather than a bunch of jpeg goop.
JPEG artifacts are less disturbing because they're so obviously artificial. WEBP and similar artifacts look more natural, which makes them harder to ignore.
For non-photographic images, I'm horribly sensible to the ringing artifacts. Thankfully, there's waifu2x (in denoise mode only) to remove those when textures don't confuse it too much and I use MozJPEG to encode, which really improves the result.
There's something to be said about this. A high quality JPEG after cleanup can sometimes be larger than an ARW (sony RAW) on export and it makes no sense to me.
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.
You're confusing jpg>jxl>jpg, which can be done losslessly via a special mode, and jxl > jpg, which can't (even ignoring all the extra features of jxl that jpg doesn't support)
> 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.
Yes, JPG to JPEG XL and back is lossless, but the reverse is nowhere mentioned.
Trying around with some jpg and jxl files I cannot convert jxl losslessly to jpg files even if they are only 8bit. The jxl files transcoded from jpg files show "JPEG bitstream reconstruction data available" with jxlinfo, so I think some extra metadata is stored when going from jpg to jxl to make the lossless transcoding possible. I can imagine not supporting the reverse (which is pretty useless anyway) allowed for more optimizations.
> 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.
A lot of those features (non-8×8 DCTs, Gaborish and EPF filters, XYB) are enabled by default when you compress a non-JPEG image to a lossy JXL. At the moment, you really do need to compress to JPEG first and then transcode that to JXL if you want the JXL→JPEG direction to be lossless.
> 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.
So he was not wrong about this. You have perfect JPEG -> JPEG XL conversion, but not the other way around.
default jpeg-xl uses a different color space (XYZ), bigger transform (up to 256x256), rectangular transforms, etc. if you go from jpg to jxl, you can go back (but your jxl file will be less efficient), but if you compress directly to jxl, you can't losslessly go to jpg
People often forget that PNG images can be compressed in a lossy manner to keep the filesize down, not quite as well as jpegs but still quite substantially.
Tiff if you want to archive them and they started as raw or tiff, jpeg for everything else. If the file is already jpeg, there is no point in covering it to a new better quality format, the quality won't get better than it already is.
It may be obsolete, but it is ubiquitous. I care less about cutting edge tech than I do about the probability of being able to open it in 20+ years. Storage is cheap.
Presentation is a different matter and often should be a different format than whatever your store the original files as.
And jpg isn’t that bad when encoded at high quality, and not saved repeatedly.
I took a tiff and saved it high quality jpg. Loaded both into photoshop and “diffed” them (basically subtracted both layers). After some level adjustment you could see some difference but it was quite small.
AV1's advantage narrows to ~5% over H.265 at very high data rates, in the same way that MP3 at 320 kbps is competitive with AAC at 320 kbps. But AV1 is never worse than H.265 from a VMAF/PSNR perspective at any bitrate, and of course H.265 is heavily patent encumbered in comparison. https://chipsandcheese.com/p/codecs-for-the-4k-era-hevc-av1-...
>AV1's advantage narrows to ~5% over H.265 at very high data rates.... But AV1 is never worse than H.265 from a VMAF/PSNR perspective at any bitrate,
There is a whole discussions that modern codec, or especially AV1 simply doesn't care about PSY image quality. And hence how most torrents are still using x265 because AV1 simply doesn't match the quality offered by other encoder/ x265. Nor does the AOM camp cares about it, since their primarily usage is YouTube.
>in the same way that MP3 at 320 kbps is competitive with AAC at 320 kbps.
It is not. And never will be. MP3 has inherent disadvantage that needs substantial higher bitrate for quite a lot of samples, even at 320kbps. We have been through this war for 10 years at Hydropgenaudio with Data to back this up, I dont know why in the past 2-3 years the topic has pop up once again.
MP3 is not better than AAC-LC in any shape or form even at 25% higher bitrate. Just use AAC-LC, or specifically Apple's Quick Time AAC-LC Encoder.
> There is a whole discussions that modern codec, or especially AV1 simply doesn't care about PSY image quality.
In early AV1 encoders, psychovisual tuning was minimal and so AV1 encodes often looked soft or "plastic-y". Today's AV1 encoders are really good at this when told to prioritize psy quality (SVT-AV1 with `--tune 3`, libaom with `--tune=psy`). I'd guess that there's still lots of headroom for improvements to AV1 encoding.
> And hence how most torrents are still using x265 because…
Today most torrents still use H.264, I assume because of its ubiquitous support and modest decode requirements. Over time, I'd expect H.265 (and then AV1) to become the dominant compressed format for video sharing. It seems like that community is pretty slow to adopt advancements — most lossy-compressed music <finger quotes>sharing</finger quotes> is still MP3, even though AAC is a far better (as you note!) and ubiquitous choice.
My point about MP3 vs. AAC was simply: As you reduce the amount of compression, the perceived quality advantages of better compressed media formats is reduced. My personal music library is AAC (not MP3), encoded from CD rips using afconvert.
svt-av1 has come a long ways recently; I tried it a few weeks ago.
It still (maddeningly
!) defaults to PSNR, but you can change that. There are some sources where I find it now can significantly improve over H.265 at higher data rates, and, while my testing was limited, I couldn't find sources any where H.265 clearly won based on my mark-1 eyeball. This is in contrast to when I tried multiple av1 encoders 2-ish years ago and they, at best, matched H.265 at higher bitrates.
I don't care about VMAF or PSNR, I care about looking with my eyes. With x265 on veryslow and AV1 on preset 0/1, and the source being a UHD BD I was downscaling to 1080p, AV1 looked worse even while using a higher bitrate than x265. Current AV1 encoders have issues with small details and have issues with dark scenes. People are trying to fix them (see svt-av1-psy, being merged into SVT-AV1 itself) but the problems aren't fixed yet.
>see svt-av1-psy, being merged into SVT-AV1 itself
Part of it being merged for now.
It is unfortunate this narrative hasn't caught on. Actual quality over VMAF and PSNR. And we haven't had further quality improvement since x265.
I do get frustrated every time the topic of codec comes up on HN. But then the other day I only came to realise I did spend ~20 years on Doom9 and Hydrogenaudio I guess I accumulated more knowledge than most.
> How in the world do people store images / photos nowadays?
I had some high resolution graphic works in TIFF (BMP + LZW). To save space, I archived them using JPEG-2000 (lossless mode), using the J2k Photoshop plug-in ( https://www.fnord.com/ ). Saved tons of GBs. It has wide multi-platform support and is a recognized archival format, so its longevity is guaranteed for some time on our digital platforms. Recently explored using HEIF or even JPEG-XL for these but these formats still don't handle CMYK colour modes well.
>are nigh-unworkable on desktops, support is very spotty
I use .webp often and I don't understand this. At least on Windows 10 I can go to a .webp and see a preview and double-click and it opens in my image editor. Is it not like this elsewhere?
I recognize it as beating a dead horse now, but JPEG XL did what was needed to be actually adopted. AVIF has not been widely adopted given the difficulty of a leap to a new format in general and the computational cost of encoding AVIF specifically.
One of JPEG XL's best ideas was incorporating Brunsli, lossless recompression for existing JPEGs (like Dropbox's Lepton which I think might've been talked about earlier). It's not as much of a space win as a whole new format, but it's computationally cheap and much easier to just roll out today. There was even an idea of supporting it as a Content-Encoding, so a right-click and save would get you an OG .jpg avoiding the whole "what the heck is a WebP?" problem. (You might still be able to do something like this in a ServiceWorker, but capped at wasm speeds of course.) Combine it with improved JPEG encoders like mozjpeg and you're not in a terrible place. There's also work that could potentially be done with deblocking/debanding/deringing in decoders to stretch the old approach even further.
And JXL's other modes also had their advantages. VarDCT was still faster than libaom AVIF, and was reasonable in its own way (AVIFs look smoother, JXL tended more to preserve traces of low-contrast detail). There was a progressive mode, which made less sense in AVIF because it was a format for video keyframes first. The lossless mode was the evolution of FUIF and put up good numbers.
At this point I have no particular predictions. JPEG never stopped being usable despite a series of more technically sophisticated successors. (MP3 too, though its successors seemed to get better adoption.) Perhaps it means things continue not to change for a while, or at least that I needn't rush to move to $other_format or get left behind. Doesn't mean I don't complain about the situation in comments on the Internet, though.
> 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.
Yea, how is this still the case in 2025?
My family has a mix of Apple and Samsung devices and they move/backup their pictures to their Windows machines whenever they run out of space but once they move them, they can't easily view or browse them.
I had to download a 3rd party app and teach them to view them from there.
> 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?)
I've done several tests where I lowered the quality settings (and thus, the resulting file size) of JPEG-XL and AVIF encoders over a variety of images. In almost every image, JPEG-XL subjective quality fell faster than AVIF, which seemed mostly OK for web use at similar file sizes. Due to that last fact, I concede that Chrome's choice to drop JPEG-XL support is correct. If things change (JPEG-XL becomes more efficient at low file sizes, gains Chrome support), I have lossless PNG originals to re-encode from.
I've done a few shootouts at various times in the last 10 years. I finally decided WebP was good for the web maybe two years ago, that is, I have 'set it or forget it' settings and get a good quality/size result consistently. (JPEG has the problem that you really need to turn the knob yourself since a quality level good for one image may not be good for another one)
I don't like AVIF, at least not for photos I want to share. I think AVIF is great for "a huge splash image for a web page that nobody is going to look at closely" but if you want something that looks like a pro photo I don't think it's better than WebP. People point out this example as "AVIF is great"
but I think it badly mangles the reflection on the left wing of the car and... it's those reflections that make sports cars look sexy. (I'll grant that the 'acceptable' JPEG has obvious artifacts whereas the 'acceptable' AVIF replaced a sexy reflection with a plausible but slighly dull replacement)
At least there's JPEG-XL support in recent Windows 11 updates.
I've found that sometimes WebP with lossless compression (-lossless) results in smaller file sizes for graphics than JPEG-XL and sometimes it's the other way around.
I see no reason not to use JPEG-XL for archival storage. It is (IMO) the best all-rounder of the current formats, and 20 years from now imagemagick will still be able to convert it to whatever you want.
> HEIC is good, as long as you pinky promise to never ever leave Apple's ecosystem, ie HEIC sucks.
Not really true in my experience, I have no problems using it in Windows 11, Linux, or with my non-Apple non-Google cloud photos app.
The iPhone using it in an incredibly widespread way has made it a defacto standard.
If you're having trouble in Windows, I wonder if you're running Windows 11 or 10? Because 11 seems a lot better at supporting "modern things" considering that Microsoft has been neglecting Windows 10 for 3 years and is deprecating it this year.
My problem with HEIC is that if you convert it to another format, it looks different from the original, for reasons that I don't understand. I switched my iPhone back to JPEG to avoid that.
RAW? Storage is becoming cheeper, why discard the originals?
When looking for a format to display HQ photos on my website I settled with a combination of AVIF + JPG. Most photos are AVIF, but if AVIF is too magical comparatively to JPG (like 3x-10x smaller) I use a larger JPG instead. "Magic" means that fine details are discarded.
WebP discards gradients (like sunset, night sky or water) even at the highest quality, so I consider it useless for photography.
It's not. Support is still surprisingly patchy, and it takes a second or so to decode and show the image even on a modern M* Mac. Compared to instant PNG.
> 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.
HEIC for photos taken by my iPhone. Apple stuff seems to do a mostly ok job auto-converting to JPG when needed (I assume, since I haven’t manually converted one in ages).
And JPG for photos taken on a “real” camera (including scanned negatives). Sometimes RAW, but they’re pretty large so not often.
I found that if you plug a iphone into a windows PC and copy the photos off it will convert to jpg. However it makes copying very slow, and the quality is worse, so I'd advise to turn off the setting on the phone (I think its compatibility mode or similar)
Assuming you are asking about archiving: Use the original format it came in. If you're going to transcode it should be to something lossless like J2K or PNG.
You’re right, for a lot of scenario which is exactly what a standard is there to do, encapsulating the broad strokes.
> Alternatives like WebP might be good for browsers but are nigh-unworkable on desktops, support is very spotty.
Right again, and WebP is the enrichment that goes with the backend when dealing with web. I wouldn’t knock it for not being local compatible, it was designed for the web first and foremost, I think it’s in the name.
>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.
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.
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.
uBlock Origin Lite works perfectly fine on Chrome, with the new Manifest v3. Blocks basically all the ads uBlock Origin did previously, including YouTube. But it uses less resources so pages load even faster.
There's an argument that adblocking could theoretically become less effective in the future but we haven't seen any evidence of that yet.
Because uBO Lite uses a newer Chrome function call (declarativeNetRequest) that didn't exist previously (original uBO was based on webRequest).
webRequest is slower because it has to evaluate JavaScript for each request (as well as the overhead of interprocess communication), instead of the blocking being done by compiled C++ code in the same process like declarativeNetRequest does.
uBO also has a bunch of extra features like zapping that the creator explicitly chose not to include in uBO Lite, in the interests of making the Lite version as fast and resource-light as possible. For zapping, there are other extensions you can install instead if you need that.
They're two different products with two different philosophies based on two different underlying architectures. The older architecture has now gone away in Chrome, but the new one supports uBlock Origin Lite great.
I think you're overstating it a bit. There were definitely features that couldn't be implemented due to MV3 limitations rather than because the developer chose to leave them out.
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?