You must log in or register to comment.

pfaccioxx t1_iuagpku wrote

Oh look, yet another reason people should stop using that browser :P


leo_sk5 OP t1_iuahxt3 wrote

Reason for deprecation could entirely be docile, but given the recent events, my first instinct was to conclude that it must be to benefit competing standards where google is involved in development


C1ickityC1ack t1_iuaimmy wrote

What does this mean for laymen googlers who have no idea what deprecating jpegs means? Does this mean horribly compressed jpegs?


Konukaame t1_iualktz wrote

JPEG-XL (.jxl) is a new image format, and can be loosely understood to be an update to JPEG (.jpg/.jpeg).

Depreciation Deprecation means that they're dropping support for it, so if Chrome encounters a .jxl file, it won't know what to do with it.

That said, only Chromium and Firefox Nightly even had support for it in the first place, so unless you were using one of those and going somewhere that actually had .jxl content, this makes no difference in your life.


C1ickityC1ack t1_iuam9ni wrote

Thank you kind computer person.


Thirpunasorec t1_iuapnsn wrote



Ialwaysassume t1_iubh95h wrote

“Give him the stick”……..




Yokhen t1_iue6vmh wrote

Excuse me? I'm not doing anything to you, lady.


streakermaximus t1_iuanltf wrote

So it's a new format that didn't take off. Groovy.


leo_sk5 OP t1_iuar7bo wrote

That would have been seen when it would be properly supported by browsers. Chrome pushed webp support and made it commonplace across net, even though it finds no usage elsewhere. JPEG-XL to be fair took a significant time in development, but axing it in the monopoly browser means that any chance of adoption on web is fairly slim, and that would affect further adoption even if it is used in other cases, such as smartphone images (android is also google though)


zoinkability t1_iuaty8s wrote

The part that makes people skeptical is the fact that Google has their own competing next gen format. The fact that they went to the trouble of supporting it, then axed support, is a very fishy look.


TronKiwi t1_iuar9p4 wrote

Barely relevant but it's deprecate not depreciate (in this usage).


angrathias t1_iucy29m wrote

You described Obsoletion not deprecation. Deprecate means ‘do not use any more’ usually because it’s replaced with something better. Still supported though.


TronKiwi t1_iuanndm wrote

Deprecating something means dropping support for it.

JPEG XL is an extension of the familiar JPEG standard that provides better compression ratios and quality; that is to say, for the same file size, a JPEG XL is going to be much better quality than a JPEG.

This means that JPEGs as we know them are unaffected, but for whatever reason Google appears to have decided that it's not pushing forward the revolutionary JPEG XL, probably in favour of WebP.


Jakanapes t1_iuar3nc wrote

In favor of webp? That is a shockingly cynical and completely accurate assumption.


leo_sk5 OP t1_iuas5oh wrote

>probably in favour of WebP

I think it would be avif. WebP can't compete with jpeg-xl in terms of feature set. But compared to avif, jpeg-xl allows seamless transition to jpeg (for compatibility), progressive decode, higher bit depth HDR, and ability to use common encode/decode pathways with jpeg.


Active-Beginning3679 t1_iui414s wrote

Right. In terms of pure bit rate, jpeg is awful, webp is better, and avif and jpeg-xl are better still. The thing is that avif has a lot of weird quirks due to it being a hack of a video codec: AV1. JPEG-XL is a much better image format just in terms of feature set, definitely better for high quality images. I use avif because it was out first, but I planned to switch to jpeg-xl once browser support was better.


pfaccioxx t1_iuanax9 wrote

Most likely google is working on something that would complicate with JPEG-XL in some way


typesett t1_iuaoirt wrote

Use multiple browsers y’all

earmark chrome as the browser to use for the google stuff

use Firefox for surfing and most stuff

maybe safari for specific websites to mix things up


fgdfghdhj5yeh t1_iuav6jm wrote

use user agent randomizer and be a different person every refresh!


pfaccioxx t1_iuaqwim wrote

A decent soloson for people who need to use a chromium browser, but that can create a minor inconvenience that will prevent meany people from doing so

Thoth I personally feel that the slight Google Chrome convenience of being able to integrate directly with some Google services is not worth it considering all the downsides that come with that browser combined with the fact that pretty much all google services that I know of can be used without that sapific browser.

Almost any other chromium browser is better then Google Chrome.


qtx t1_iuchdqe wrote

Next time use Chrome when writing a comment, it has spellcheck.


pfaccioxx t1_iueab7q wrote

My browser has a built in spell check, and yes I do use it, I have a spelling impairment that makes it hard to spell things correctly even with it and I don't have hours to spend on typing comments to perfect spelling that realistically a very tiny number of people will ever read

Also no one should use Google Chrome, even for people who don't like Firefox / Safari (for some reason) almost any other chromium browser is better then Google Chrome.


Bangaladore t1_iuajhzd wrote

What browser do you use? This is a chromium feature, so unless you are using Firefox, you have been conned.


pfaccioxx t1_iuan3vk wrote

I'm well aware that prity much everything besides Firefox, Safari, forks of those 2 browsers, and a few other super obscure browsers that almost no one uses everything is based of Google's chromium engine. I persanalay beleave people in general should switch away from chromium browsers in order to prevent Google from forming a browser monopoly, but I understand that for some people that's not realistic. But even for those people who need to use a chromium browser, there is literally 0 reason to use Google Crome besides laziness ^(if it was pre-set as the default browser on there computer), and the slight convenience of being able to integrate directly with some Google services ^(almost all of witch have just as as viable if not better alternatives) as most chromium browsers are better then Google Chrome, and individual web browser maintainers can alter there browser beyond the base code of chromium to implement things base chromium dos not or to retain things that Google is removing ^(although that requires extra work on those browser's maintainers, most of witch realistically are not going to do so beyond what they have to)


patrys t1_iuat1sf wrote

Chromium is not a rendering engine, it’s a “chrome” (another word for user interface) engine. Chromium browsers are based on Blink which itself is a WebKit fork. WebKit is the Safari fork of KHTML which was an open source rendering engine created for KDE.


thenerdal t1_iub7r99 wrote

Chromium isn't an engine, Blink is. And it's not Google's but it's developed by 80 different companies.


[deleted] t1_iubdi2d wrote



thenerdal t1_iubfpu7 wrote

Nah chromium is a project, Blink is the engine to it but it's developed by more companies.


ReformedPC t1_iuaowpr wrote

If it's not supported for Chrome, that means you won't see it anywhere and any browser because most people use Chrome.


fgdfghdhj5yeh t1_iuawt5e wrote

apng was around on sites for 10 years before chrome supported it :^) the chromers just got a static dead image lmao


ReformedPC t1_iuaxs0z wrote

We live in a complete different era my dude, everything is monetized now and I can guarantee you that popular sites won't have any JPEG-XL knowing they could lose money if their sites have empty spots.

Look at Flash when it got discontinued, yeah there are still ways to enable Flash but look at all the popular Flash sites that switched to HTML5 to make sure their sites don't die.


fgdfghdhj5yeh t1_iub1pbe wrote

The browser sends a header saying which images it supports and websites can send back the best format that it does support. (I say can there cuz some only have jpeg, but now many have jpeg, webp, avif, and will send accordingly)

flash got killed due to terrible security and being able to access the underlying system, same reason java got killed off on web. Same reason web assembly is so slow to adopt anything, even threading, because of security


thenerdal t1_iub6v7t wrote

I keep trying Firefox but for some reason, it's never as smooth as Chrome and I don't like the way it looks. Plus I like the features.

Same for Android, no tabbed browsing on Firefox for tablets is stupid.


[deleted] t1_iubdv5w wrote



thenerdal t1_iubfjwz wrote

I don't have a windows laptop with it on me right now but last I tried, it had a white square on the top left that kept bugging me even with add ons.

VERY SMALL thing to be annoyed by I know, but that looked ugly to me. I use browsers in Windowed mode and it's hidden in full screen.


pfaccioxx t1_iubqn6b wrote

You know you can customize what buttons appear in the toolbars and were right? (right click on an empty space, click "customize toolbar" from the dropdown menu and then drag the button were you want it or out of the toolbar before clicking the "Done" button to finalize the changes.)


thenerdal t1_iubs6jz wrote

No it's not a button. It can't be removed.


pfaccioxx t1_iue9qw0 wrote

have you tried? cos I have never found something with Firefox's interface that can't be customized


petesapai t1_iuc19eu wrote

Used Firefox for ages. Even with all its issues. Biggest one being that adding comments in reddit and other text form fields simply don't work. It was annoying.

But the cherry on the cake was i had to reinstall my os. Made an export of my Firefox bookmarks into an HTML file (exported from Firefox).

Wasn't able to import it back into Firefox. But it worked in chrome. Good bye Firefox.


pfaccioxx t1_iue8yo8 wrote

That sounds like you screwed something up on your end as opposed to the fault of Firefox as a program, cos I have never run into those issues when I have used Firefox

But even if you do feel the need to switch away from Firefox, you still shouldn't use Google Chrome compared to literally any other chromium browser (witch not counting Firefox / Safari forks, or super obscure browsers almost no one uses) is unforcently all of them


petesapai t1_iuge23r wrote

I've been fighting the Firefox good fight for years. Always stuck by it. Spent so much time looking up the text area issue (happens during cut/copy/paste). Still stuck with it. But the export (been doing exports since Netscape, it's not complicated) issue was enough.

So nope, not from my end.

And I jump from chrome and edge on my pc now. They're all chromium based anyways.

Still use Firefox as my default android browser though.


fgdfghdhj5yeh t1_iuawfyb wrote

Google was a big part of JPEG XL and is actively working on libjxl as well... and JPEG XL is also based on FLIF and google's pik: so pretty weird.

On the chromium project there are many things that get added and pushed back for years but the commit and notes are there. Even the support for JPEG XL flag on by default itself keeps getting pushed back in it's thread. You can go here and ctrl+f for "expiry_milestone" to see that it has been pushed back many times. Might be the case with the depreciation or something.

edit: they are seemingly finished and abandoning webp2 as well. All image formats seem out the window.


swistak84 t1_iucva61 wrote

Only a person who has no experience with google whatsoever would think it's weird. They do tend to cut things that don't become massive hits quite often


ryan_umad t1_iuavcb1 wrote

It was never more than a feature flag, this is not a big deal

“Google Chrome has offered JPEG-XL (JXL) image support via a feature flag (chrome://flags/#enable-jxl) since Chrome 91 while with Chrome 110, Google is looking at deprecating this still-fresh-and-new image format.”


kogasapls t1_iub1q1m wrote

What? It's a big deal because it was a promising format that was gaining support and is now being killed. The fact that it wasn't a full feature before it was deprecated makes it worse, not better.


RecognitionOwn4214 t1_iuccvyg wrote

Where can u use it? When is it better than wepb?

jpeg-xl is neither broadly used not is it any advantage above the newer formats that are developed.


bitflag t1_iucevgc wrote

It's always better than WebP. AVIF has a small edge at very low bitrate though.


ApertureNext t1_iuhxrg1 wrote

How can anyone use it when browsers won't support it? WebP and AVIF are shit compared to JPEG-XL.


littleMAS t1_iub7zfl wrote

Since TIF, JPEG, BMP, and GIF, it has been hard to get traction on new formats. Part of the problem has been related to patents. Part of it is the fact that the existing de facto standards seem to be enough for most to get by on for now. Another part is that every camera manufacturer has its own 'raw' format, largely based upon the silicon they are using for their image sensor, and that includes Apple's iPhones. Long ago, I thought that JPEG2000 might succeed JPEG. Nope. Some might blame that on lack of backward compatibility, but I believe it was for reasons not unlike JPEG-XL.


IAmTaka_VG t1_iufgf3z wrote

Webm and Webp have been taking the industry by storm. If you're betting on a standard to win, my money is those.


happyscrappy t1_iub89vg wrote

WebP seems like the smarter play by far. You already have the hardware to decode it on so many platforms.

So JPEG-XL doesn't fly. It'll join JPEG-2000 on the pile. No big deal.


candreacchio t1_iub9dpt wrote

Jp2000 actually has quite a bit of adoption, just not in the spaces you may realize.

All digital cinemas use jp2000 as their compression method (wrapped in a mxf container in xyz colour space)


happyscrappy t1_iubaplq wrote

Your picture is stored in the chip on your passport using JPEG-2000 (US passports).

It's still not much though.


DirectControlAssumed t1_iud7fru wrote

However, as I said in another comment, if you store your images as JP2, there are much better chance to be able to open them in 20 or 30 years than AVIF/JPEG XL/HEIF and other newborn megacorp-backed standards because JPEG 2000 is 20 years old, alive and even is still being developed (e.g. ISO/IEC 15444 Part 15 and Part 16 were published in 2019)!

Have you ever heard of JPEG XR? It was Microsoft's attempt at JPEG replacement that was standardized by ISO too and I'm not sure you can even open such images on anything but Windows (and I am not even sure latest Windows versions still support it). There is a reference codec on that wasn't updated since 2012 and that's it.


emfiliane t1_iufg1po wrote

The good thing about dead formats is that they're frozen where they stood, instead of having dozens of proprietary and incompatible variations. (Cough, anything IFF-based.) Unless they already made it that far before dying, like PCX. It's the proprietary ones that really painfully disappear, like exclusive Adobe-only formats.

I doubt JPEG XL (or XR or maybe XT/XS, or any other also-rans) will end up in that situation, since they're incorporated into the main Swiss army knife libraries, so some utility or another will be around to deal with them as long as the C language survives. It may not be convenient, let alone integrated into your favorite tools, but nor are most dead formats.


DirectControlAssumed t1_iufhbtu wrote

>some utility or another will be around to deal with them as long as the C language survives

...or some nasty security vulnerability is found and related code would be easier to throw away to reduce attack surface rather than maintain because nobody either wants or knows how to deal with it.

It was a lesser problem with historical dead formats that are basically as dumb as P(B,G,P)M (like BMP) but the new ones are very complex because of their advanced compression algorithms, metadata and stuff and require a lot of code to work.


emfiliane t1_iufo7gc wrote

That's not how kitchen sink libraries work, though; they support a lot of obscure and dead formats with known security problems in the implementation, but none of them are enabled by default. If you want to make a tool that's an everything-to-anything, you turn on all the compile options, and if you make it public, hopefully point out that here there be dragons.

Some binary-only remains might very well require virtualization in the future, the way accessing and converting old Pagemaker files does, but that's something retro enthusiasts seem to relish.


DirectControlAssumed t1_iufqu7f wrote

Well, compiling stuff with appropriate flags isn't easy for people who are not programmers. Most of them probably would just give up.

Even if that wasn't a problem I still don't like the idea of putting my precious images into the shaky state of dependence on some format that is susceptible to whims of a single company.

In the end of the day Google didn't really wanted ultimate-rule-them-all image format, they just need something that requires less bandwidth from their networks than JPEG. AVIF and WebP seem to be good enough for that role now. But this is basically endless battle - tomorrow they'll start thinking about even more compact formats and will declare JPEG XL/AVIF/WebP obsolete effectively abandoning them. If nobody else takes the burden of their maintenance in their hands, the files using these formats will become a large PITA for their owners.

JPEG 2000 is already here and one of its primary usages is exactly digital preservation, e.g it is one of the preferred formats of Library of Congress (with TIFF, JPG and PNG)


RIP JPEG XL, even your own creator hasn't really liked you.


emfiliane t1_iufs7yq wrote

Sure, I use j2k (and djvu) every day. They're one possible format to transfer archived files and scans to, although being business, PDF/A is preferred over any raw image format in this group.

I'm just saying that major public formats don't just disappear, even if they become inconvenient to use; most major obsolete undocumented formats are still usable in some inconvenient way or another.


DirectControlAssumed t1_iuftz7f wrote

>I'm just saying that major public formats don't just disappear, even if they become inconvenient to use; most major obsolete undocumented formats are still usable in some inconvenient way or another.

I agree with that.

> They're one possible format to transfer archived files and scans to, although being business, PDF/A is preferred over any raw image format in this group.

AFAIK, PDF/A-2+ allows J2K images, so it works there too (if you want it) and, as you obviously know, PDF/A exists precisely for digital preservation.

Also, AFAIK, Adobe hasn't allowed any other "JPEG successors" in their PDF standard, either.


ApertureNext t1_iuhy78x wrote

JPEG XL allows lossless conversion between JPEG and JPEG XL, it quite literally can't become more compatible.


DirectControlAssumed t1_iui0sle wrote

>it quite literally can't become more compatible.

BTW, it can. There is JPEG XT that is just JPEG + additional data that adds new features. The existing JPEG software that doesn't know about JPEG XT still can read its plain old JPEG part.


DirectControlAssumed t1_iuhz5ou wrote

You can't open JPEG XL re-compressed JPEGs with the code that supports JPEGs (that is basically omnipresent and will be supported for foreseeable future without any doubt). If you want your JPEG back, you have to decompress it with djxl first.

So, you still have to rely on JPEG XL specific code which can start to "rot" (due to various reasons) with time if nobody maintains it.


ApertureNext t1_iui0xvy wrote

Exactly, so you aren't losing quality if JPEG XL ends up flopping and you need to transfer back to a more compatible format.

Browsers not supporting the format and now dropping support aren't helping.


DirectControlAssumed t1_iuji4g1 wrote

You are not wrong, I was talking about the "some long forgotten DVD on the attic" scenario when you suddenly find that you used some unusual image format to store your data for archival purpose because, e.g., you wanted to put more images on that DVD and now you don't know how to get it back because the only software that supports it is some Linux CLI tool that requires compilation with right flags to make it work. Or something even more arcane, who knows.

See digital dark age, though I am not talking about intergenerational problem - seeing how fast technology changes today and how more complex it becomes every day makes me think that such problems can happen even within our lifetime.


Leiryn t1_iubr89t wrote

Fuck webp, I always have to rename it to jpeg because a bunch of apps refuse to work with it (notably Google voice)


gurenkagurenda t1_iubsvnb wrote

That has nothing to do with webp specifically. It’s just a typical transition pain for a new format.


FineAunts t1_iuc2eaq wrote

If you make apps at scale there is a clear advantage of webp. Many of the @2x files we serve get an instant 50% weight reduction with zero noticeable quality loss (as compared to the tweaked jpeg). Most are in the 20-30% range but that's still pretty great. It's like going from ttf to woff2 or gzip to brotli.

I wish it was the standard over jpeg at this point. At least on the consumer/user side of things.


siscorskiy t1_iuc5sa6 wrote

Is this a Shopify thing? I notice a lot of the images I scrape from Shopify pages are resized with names like that appended to their filename


swistak84 t1_iucvvz1 wrote

It's more of an iPhone thing. Or anything else with retina display, for those you can choose to serve higher resolution images then you would normally do at the cost of bandwidth


DirectControlAssumed t1_iud43ru wrote

>It'll join JPEG-2000 on the pile.

IMHO, JPEG-2000 seems to be the safest bet among all these "JPEG replacements" in a sense that if you store some photos with it for a long time you will not going to find yourself in a situation where the format is abandoned and there will be literally no software to open or transcode the photos in the future

JPEG-2000 is already 20 years old (i.e. U.S. patents on core coding have expired in addition to the fact that it was supposed to be royalty-free since the beginning), there are many codec implementations out there; there are image viewers supporting the format and there are industries that use it very extensively - digital cinema, medical imaging, geographic information systems, digital archives, etc. JPEG/ISO keeps publishing new parts (new features) for the format standard and that means there are people who actually care about it.

It is mostly absent on the consumer devices, yes, but who knows, maybe it will become more prominent since the patents are dead. It is also vendor-neutral unlike AVIF/JPEG XL/HEIF - there is no megacorporation behind it who constantly try to overtake its competitors in format wars. Google (who is the main sponsor of JPEG XL) is especially notorious for ruthlessly killing stuff people use.

I have recently played with JPEG-2000 and found that it has some very nice features. E.g. unlike plain JPEG you can make your image fit into specific size constraints - want to get 1Mb image out of 5Mb JPG? Easy! I also found that its lossless compression consistently beats PNG.

My very limited test also made me question JPEG XL superiority. While lossless JPEG XL constantly beated lossless JPEG 2000, I am not so sure about lossy compression. There are two modes of JPEG 2000 lossy compression (integer/real or reversible/irreversible). While default integer (reversible) lossy JPEG-2000 compression was usually worse than lossy JPEG XL for the same size, real (irreversible) was much better according to PSNR/NCC/AE metrics and directly competed with AVIF (though AVIF was usually better). JPEG-2000 artifacts also looked less ugly than JPEG XL's (though that may be due to the JPEG XL codec immaturity).

I don't know what JPEG-2000 lossy mode people use to make comparisions but I wouldn't be surprised if one of the reason why they find JPEG-2000 lossy performance lacking is that they use default compression settings.

There is also a very interesting thing named "arithmetic coded JPEG". It is a plain JPEG that has its lossless stage (Huffman coding) replaced with more efficient arithmetic coding. It demonstrates significant disk usage improvements over plain JPEG, especially for large images. You can convert JPEGs between Huffman and arithmetic coding without any quality losses - the images would be mathematically equal. This is similar to JPEG XL lossless JPEG re-compression but unlike JPEG XL it is not a brand new format - it is a part of JPEG specification since very long times! The reasons it wasn't used widely are patents that have long expired. Reference codecs like libjpeg supported it for a long time but the feature was often omitted by app developers because of patents so many image viewers still do not support it directly. The lossless nature of such recompression (and the fact that it is a part of plain old JPEG specification) means that you can use it to truly losslessly compress JPEGs for long storage.

I have done limited comparison of arithmetic coding and JPEG XL's JPEG recompression and haven't found absolute winner - sometimes it was arithmetic JPEG who was better, sometimes it was JPEG XL


[deleted] t1_iubfudl wrote



marumari t1_iubgnzv wrote

Since when does google make money from licensing WebP?


mrtompeti t1_iubj26w wrote

I don't even get to know that JPEG- XL is and they are deprecating it


guzhogi t1_iudcf8o wrote

I guess in Apple’s new macOS Ventura, the default PDF & image app Preview no longer opens postscript and encapsulated postscript images. Rumor is due to security


aeolus811tw t1_iub4ji9 wrote

JPXL came from JPEG committee

i guess google just doesn't like standard developed by other


ImUrFrand t1_iucns7v wrote

people still use chrome in 2022



odilasa t1_iub27jm wrote

Do we really need jpeg anymore at all, I only use .png nowadays.


Ultra_HR t1_iub4vnn wrote

> I only use .png nowadays.

??? why? this is a terrible idea. PNG is not a suitable format for photographs - it doesn't compress them well, the file size will be massively bloated.

use webp.


cxGiCOLQAMKrn t1_iubhny6 wrote

PNG is technically lossless, but you can run images through a function which degrades their quality to improves PNG compression efficiency. The results generally aren't quite as good as JPEG compression, but they are close — much better than a totally lossless PNG photo. Search for "lossy png compression," to find several open source tools.


gnocchicotti t1_iubn2a5 wrote

Can't have my photo collection too big, it will fill up my Iomega Zip disks in no time amirite /s


odilasa t1_iub5cg6 wrote

From what I've understood it's meant to be portable like an app, not compressed like an mp3...


Ultra_HR t1_iub5l90 wrote

idk what you mean by "portable", but yes, PNGs are lossless. this is typically a bad thing for photographs - when you are transmitting photographs on the internet in 99.9% of use cases doing so losslessly is a waste of bytes. it is better to compress, to save bandwidth and make things load faster. and even your own disk space.

my collection of photos is ~500GB. it would be more than double this if they were all PNGs.

don't use lossless for photos.


odilasa t1_iub6l7g wrote

Last time I checked there was innumerable amount of hard drive space available for purchase at Walmart, Target, Best Buy, Staples...and as for the bandwidth even on 10 Mbit connection you wouldn't see negative effects unless your data is some type of 'Proprietary' format. After all, an image is worth a thousand weirds...I mean words.


happyscrappy t1_iub8hcx wrote

I find attaching a hard drive to my phone makes it less portable.

And yes, on a 10 mbit connect you'll find transfer times to be annoying long for PNGs of photographs.

If you like lossless you can use PNG and RAW. No one is stopping you.


Ultra_HR t1_iub6rgs wrote

aside from all this, the vast majority of photos from modern smartphones will be saved as JPG. if you are then converting that jpg to png, you aren't going to increase the quality.

bored of this conversation now, have fun wasting your own bandwidth and disk space. just please don't get into web development


[deleted] t1_iuapej8 wrote



leo_sk5 OP t1_iuaq2fw wrote

opera is also based on chromium. Basically, its just reskinned chrome with opera's proxy and vpn thrown in the mix


ReformedPC t1_iuaq4pv wrote

I have bad news for you, Opera is Chromium-based which means you're essentially using Chrome too.

Most of the changes done to Chrome will be done to Opera and other Chromium browsers. Firefox is the only big web browser that isn't Chromium-based.