▲ 127 ▼ JPEG-XL Image Support Returns To Latest Chrome / Chromium Code (www.phoronix.com) submitted 6 months ago by commander@lemmy.world to c/technology@lemmy.world 21 comments fedilink hide all child comments
[–] reddig33@lemmy.world 9 points 6 months ago (1 child) Just as many people don’t give a shit about jpeg XL. permalink fedilink source parent hideshow 2 child comments replies: [–] kadu@scribe.disroot.org 45 points 6 months ago (3 children) They don't have to. It's backwards compatible. You can ignore it and we can keep on happily using it. Fuck Google, fuck WebP. permalink fedilink source parent hideshow 6 child comments replies: [–] LodeMike@lemmy.today 8 points 6 months ago (1 child) How is JPEG XL backwards compatible? permalink fedilink source parent hideshow 2 child comments replies: [–] rjek@feddit.uk 37 points 6 months ago (1 child) It's "compatible" in that it can represent old JPEG/JFIF data more efficiently and in less space, and the transformation to JPEG XL and back to JPEG/JFIF is lossless (in that you don't lose any /more/ quality, you can get the same bits back out) and quick enough to be doable on-demand. You could, for example, re-encode all your old photos on your CDN as JPEG XL without loss of quality but save a bunch of disc space and bandwidth when serving to modern browsers, and translate dynamically back to the old format for older browers, all with no loss of quality. permalink fedilink source parent hideshow 2 child comments replies: [+] LodeMike@lemmy.today -22 points 6 months ago (2 children) So what you're saying is: both formats can encode image data permalink fedilink source parent hideshow 4 child comments replies: [–] reddig33@lemmy.world 9 points 6 months ago* (3 children) What they’re saying is that a web server can create a traditional jpeg file from a jpeg xl to send to a client as needed. So you’re saving backend storage space… sometimes. Until widespread adoption by browsers, you’re still creating and transmitting a traditional jpeg file. And now you’ve increased the server space needed because you’re having to create and store two copies of the file in two different formats. Developers are already doing this with webp and everyone hates webp (if your browser doesn’t support webp, the backend sends you the jpeg copy). I dont see any advantage here except some hand waving “but in the future” just like has been done for most new formats trying to win adoption. permalink fedilink source parent hideshow 6 child comments replies: [–] logi@lemmy.world 3 points 6 months ago The difference (claimed by the comment above) is in the words without loss of quality So you can convert back and forth without the photo copy of a photo copy problem. And you don't have to store the second copy of the file except for caching of frequently fetched files which I'm sure will just be an nginx rule. permalink fedilink source parent [–] adespoton@lemmy.ca 3 points 6 months ago And let’s not forget HEIF and JPEG-2000. permalink fedilink source parent [–] The_Decryptor@aussie.zone 2 points 6 months ago What they’re saying is that a web server can create a traditional jpeg file from a jpeg xl to send to a client as needed. Other way around, you can convert a "web safe" JPEG file into a JXL one (and back again), but you can't turn any random JXL file into a JPEG file. But yeah, something like Lemmy could recompress uploaded JPEG images as JXL on the server, serving them at JXL to updated clients, and converting back to JPEG as needed, saving server storage and bandwidth with no quality loss. permalink fedilink source parent [–] rjek@feddit.uk 2 points 6 months ago No, I'm saying that JPEG XL can perfectly represent old JPEG/JFIF data, so on the server side you can store all your image data once and more efficiently, and still support old clients without any lossy cascade or the CPU load of having to re-encode. That is what is meant about it offering backwards compatibility. permalink fedilink source parent [–] reddig33@lemmy.world 3 points 6 months ago* (last edited 6 months ago) (1 child) How is it backwards compatible? Everything I’ve read so far says the opposite — That it requires recoding the image into the new format, and keeping around or generating an old copy of the image in current jpeg format for older software. Are you saying a browser or app that currently only supports Jpeg can open and render a Jpeg-XL image? Edit: Yeah. It’s not backward compatible. And system admins are already doing the “make two copies of an image thing with webp and the current jpg format. permalink fedilink source parent hideshow 2 child comments replies: [–] limerod@reddthat.com 1 point 6 months ago The re-encoding requires less computation vs other formats. permalink fedilink source parent [–] aliser@lemmy.world 2 points 6 months ago why webp is bad? besides google forcing it apparently permalink fedilink source parent
[–] kadu@scribe.disroot.org 45 points 6 months ago (3 children) They don't have to. It's backwards compatible. You can ignore it and we can keep on happily using it. Fuck Google, fuck WebP. permalink fedilink source parent hideshow 6 child comments replies: [–] LodeMike@lemmy.today 8 points 6 months ago (1 child) How is JPEG XL backwards compatible? permalink fedilink source parent hideshow 2 child comments replies: [–] rjek@feddit.uk 37 points 6 months ago (1 child) It's "compatible" in that it can represent old JPEG/JFIF data more efficiently and in less space, and the transformation to JPEG XL and back to JPEG/JFIF is lossless (in that you don't lose any /more/ quality, you can get the same bits back out) and quick enough to be doable on-demand. You could, for example, re-encode all your old photos on your CDN as JPEG XL without loss of quality but save a bunch of disc space and bandwidth when serving to modern browsers, and translate dynamically back to the old format for older browers, all with no loss of quality. permalink fedilink source parent hideshow 2 child comments replies: [+] LodeMike@lemmy.today -22 points 6 months ago (2 children) So what you're saying is: both formats can encode image data permalink fedilink source parent hideshow 4 child comments replies: [–] reddig33@lemmy.world 9 points 6 months ago* (3 children) What they’re saying is that a web server can create a traditional jpeg file from a jpeg xl to send to a client as needed. So you’re saving backend storage space… sometimes. Until widespread adoption by browsers, you’re still creating and transmitting a traditional jpeg file. And now you’ve increased the server space needed because you’re having to create and store two copies of the file in two different formats. Developers are already doing this with webp and everyone hates webp (if your browser doesn’t support webp, the backend sends you the jpeg copy). I dont see any advantage here except some hand waving “but in the future” just like has been done for most new formats trying to win adoption. permalink fedilink source parent hideshow 6 child comments replies: [–] logi@lemmy.world 3 points 6 months ago The difference (claimed by the comment above) is in the words without loss of quality So you can convert back and forth without the photo copy of a photo copy problem. And you don't have to store the second copy of the file except for caching of frequently fetched files which I'm sure will just be an nginx rule. permalink fedilink source parent [–] adespoton@lemmy.ca 3 points 6 months ago And let’s not forget HEIF and JPEG-2000. permalink fedilink source parent [–] The_Decryptor@aussie.zone 2 points 6 months ago What they’re saying is that a web server can create a traditional jpeg file from a jpeg xl to send to a client as needed. Other way around, you can convert a "web safe" JPEG file into a JXL one (and back again), but you can't turn any random JXL file into a JPEG file. But yeah, something like Lemmy could recompress uploaded JPEG images as JXL on the server, serving them at JXL to updated clients, and converting back to JPEG as needed, saving server storage and bandwidth with no quality loss. permalink fedilink source parent [–] rjek@feddit.uk 2 points 6 months ago No, I'm saying that JPEG XL can perfectly represent old JPEG/JFIF data, so on the server side you can store all your image data once and more efficiently, and still support old clients without any lossy cascade or the CPU load of having to re-encode. That is what is meant about it offering backwards compatibility. permalink fedilink source parent [–] reddig33@lemmy.world 3 points 6 months ago* (last edited 6 months ago) (1 child) How is it backwards compatible? Everything I’ve read so far says the opposite — That it requires recoding the image into the new format, and keeping around or generating an old copy of the image in current jpeg format for older software. Are you saying a browser or app that currently only supports Jpeg can open and render a Jpeg-XL image? Edit: Yeah. It’s not backward compatible. And system admins are already doing the “make two copies of an image thing with webp and the current jpg format. permalink fedilink source parent hideshow 2 child comments replies: [–] limerod@reddthat.com 1 point 6 months ago The re-encoding requires less computation vs other formats. permalink fedilink source parent [–] aliser@lemmy.world 2 points 6 months ago why webp is bad? besides google forcing it apparently permalink fedilink source parent
[–] LodeMike@lemmy.today 8 points 6 months ago (1 child) How is JPEG XL backwards compatible? permalink fedilink source parent hideshow 2 child comments replies: [–] rjek@feddit.uk 37 points 6 months ago (1 child) It's "compatible" in that it can represent old JPEG/JFIF data more efficiently and in less space, and the transformation to JPEG XL and back to JPEG/JFIF is lossless (in that you don't lose any /more/ quality, you can get the same bits back out) and quick enough to be doable on-demand. You could, for example, re-encode all your old photos on your CDN as JPEG XL without loss of quality but save a bunch of disc space and bandwidth when serving to modern browsers, and translate dynamically back to the old format for older browers, all with no loss of quality. permalink fedilink source parent hideshow 2 child comments replies: [+] LodeMike@lemmy.today -22 points 6 months ago (2 children) So what you're saying is: both formats can encode image data permalink fedilink source parent hideshow 4 child comments replies: [–] reddig33@lemmy.world 9 points 6 months ago* (3 children) What they’re saying is that a web server can create a traditional jpeg file from a jpeg xl to send to a client as needed. So you’re saving backend storage space… sometimes. Until widespread adoption by browsers, you’re still creating and transmitting a traditional jpeg file. And now you’ve increased the server space needed because you’re having to create and store two copies of the file in two different formats. Developers are already doing this with webp and everyone hates webp (if your browser doesn’t support webp, the backend sends you the jpeg copy). I dont see any advantage here except some hand waving “but in the future” just like has been done for most new formats trying to win adoption. permalink fedilink source parent hideshow 6 child comments replies: [–] logi@lemmy.world 3 points 6 months ago The difference (claimed by the comment above) is in the words without loss of quality So you can convert back and forth without the photo copy of a photo copy problem. And you don't have to store the second copy of the file except for caching of frequently fetched files which I'm sure will just be an nginx rule. permalink fedilink source parent [–] adespoton@lemmy.ca 3 points 6 months ago And let’s not forget HEIF and JPEG-2000. permalink fedilink source parent [–] The_Decryptor@aussie.zone 2 points 6 months ago What they’re saying is that a web server can create a traditional jpeg file from a jpeg xl to send to a client as needed. Other way around, you can convert a "web safe" JPEG file into a JXL one (and back again), but you can't turn any random JXL file into a JPEG file. But yeah, something like Lemmy could recompress uploaded JPEG images as JXL on the server, serving them at JXL to updated clients, and converting back to JPEG as needed, saving server storage and bandwidth with no quality loss. permalink fedilink source parent [–] rjek@feddit.uk 2 points 6 months ago No, I'm saying that JPEG XL can perfectly represent old JPEG/JFIF data, so on the server side you can store all your image data once and more efficiently, and still support old clients without any lossy cascade or the CPU load of having to re-encode. That is what is meant about it offering backwards compatibility. permalink fedilink source parent
[–] rjek@feddit.uk 37 points 6 months ago (1 child) It's "compatible" in that it can represent old JPEG/JFIF data more efficiently and in less space, and the transformation to JPEG XL and back to JPEG/JFIF is lossless (in that you don't lose any /more/ quality, you can get the same bits back out) and quick enough to be doable on-demand. You could, for example, re-encode all your old photos on your CDN as JPEG XL without loss of quality but save a bunch of disc space and bandwidth when serving to modern browsers, and translate dynamically back to the old format for older browers, all with no loss of quality. permalink fedilink source parent hideshow 2 child comments replies: [+] LodeMike@lemmy.today -22 points 6 months ago (2 children) So what you're saying is: both formats can encode image data permalink fedilink source parent hideshow 4 child comments replies: [–] reddig33@lemmy.world 9 points 6 months ago* (3 children) What they’re saying is that a web server can create a traditional jpeg file from a jpeg xl to send to a client as needed. So you’re saving backend storage space… sometimes. Until widespread adoption by browsers, you’re still creating and transmitting a traditional jpeg file. And now you’ve increased the server space needed because you’re having to create and store two copies of the file in two different formats. Developers are already doing this with webp and everyone hates webp (if your browser doesn’t support webp, the backend sends you the jpeg copy). I dont see any advantage here except some hand waving “but in the future” just like has been done for most new formats trying to win adoption. permalink fedilink source parent hideshow 6 child comments replies: [–] logi@lemmy.world 3 points 6 months ago The difference (claimed by the comment above) is in the words without loss of quality So you can convert back and forth without the photo copy of a photo copy problem. And you don't have to store the second copy of the file except for caching of frequently fetched files which I'm sure will just be an nginx rule. permalink fedilink source parent [–] adespoton@lemmy.ca 3 points 6 months ago And let’s not forget HEIF and JPEG-2000. permalink fedilink source parent [–] The_Decryptor@aussie.zone 2 points 6 months ago What they’re saying is that a web server can create a traditional jpeg file from a jpeg xl to send to a client as needed. Other way around, you can convert a "web safe" JPEG file into a JXL one (and back again), but you can't turn any random JXL file into a JPEG file. But yeah, something like Lemmy could recompress uploaded JPEG images as JXL on the server, serving them at JXL to updated clients, and converting back to JPEG as needed, saving server storage and bandwidth with no quality loss. permalink fedilink source parent [–] rjek@feddit.uk 2 points 6 months ago No, I'm saying that JPEG XL can perfectly represent old JPEG/JFIF data, so on the server side you can store all your image data once and more efficiently, and still support old clients without any lossy cascade or the CPU load of having to re-encode. That is what is meant about it offering backwards compatibility. permalink fedilink source parent
[+] LodeMike@lemmy.today -22 points 6 months ago (2 children) So what you're saying is: both formats can encode image data permalink fedilink source parent hideshow 4 child comments replies: [–] reddig33@lemmy.world 9 points 6 months ago* (3 children) What they’re saying is that a web server can create a traditional jpeg file from a jpeg xl to send to a client as needed. So you’re saving backend storage space… sometimes. Until widespread adoption by browsers, you’re still creating and transmitting a traditional jpeg file. And now you’ve increased the server space needed because you’re having to create and store two copies of the file in two different formats. Developers are already doing this with webp and everyone hates webp (if your browser doesn’t support webp, the backend sends you the jpeg copy). I dont see any advantage here except some hand waving “but in the future” just like has been done for most new formats trying to win adoption. permalink fedilink source parent hideshow 6 child comments replies: [–] logi@lemmy.world 3 points 6 months ago The difference (claimed by the comment above) is in the words without loss of quality So you can convert back and forth without the photo copy of a photo copy problem. And you don't have to store the second copy of the file except for caching of frequently fetched files which I'm sure will just be an nginx rule. permalink fedilink source parent [–] adespoton@lemmy.ca 3 points 6 months ago And let’s not forget HEIF and JPEG-2000. permalink fedilink source parent [–] The_Decryptor@aussie.zone 2 points 6 months ago What they’re saying is that a web server can create a traditional jpeg file from a jpeg xl to send to a client as needed. Other way around, you can convert a "web safe" JPEG file into a JXL one (and back again), but you can't turn any random JXL file into a JPEG file. But yeah, something like Lemmy could recompress uploaded JPEG images as JXL on the server, serving them at JXL to updated clients, and converting back to JPEG as needed, saving server storage and bandwidth with no quality loss. permalink fedilink source parent [–] rjek@feddit.uk 2 points 6 months ago No, I'm saying that JPEG XL can perfectly represent old JPEG/JFIF data, so on the server side you can store all your image data once and more efficiently, and still support old clients without any lossy cascade or the CPU load of having to re-encode. That is what is meant about it offering backwards compatibility. permalink fedilink source parent
[–] reddig33@lemmy.world 9 points 6 months ago* (3 children) What they’re saying is that a web server can create a traditional jpeg file from a jpeg xl to send to a client as needed. So you’re saving backend storage space… sometimes. Until widespread adoption by browsers, you’re still creating and transmitting a traditional jpeg file. And now you’ve increased the server space needed because you’re having to create and store two copies of the file in two different formats. Developers are already doing this with webp and everyone hates webp (if your browser doesn’t support webp, the backend sends you the jpeg copy). I dont see any advantage here except some hand waving “but in the future” just like has been done for most new formats trying to win adoption. permalink fedilink source parent hideshow 6 child comments replies: [–] logi@lemmy.world 3 points 6 months ago The difference (claimed by the comment above) is in the words without loss of quality So you can convert back and forth without the photo copy of a photo copy problem. And you don't have to store the second copy of the file except for caching of frequently fetched files which I'm sure will just be an nginx rule. permalink fedilink source parent [–] adespoton@lemmy.ca 3 points 6 months ago And let’s not forget HEIF and JPEG-2000. permalink fedilink source parent [–] The_Decryptor@aussie.zone 2 points 6 months ago What they’re saying is that a web server can create a traditional jpeg file from a jpeg xl to send to a client as needed. Other way around, you can convert a "web safe" JPEG file into a JXL one (and back again), but you can't turn any random JXL file into a JPEG file. But yeah, something like Lemmy could recompress uploaded JPEG images as JXL on the server, serving them at JXL to updated clients, and converting back to JPEG as needed, saving server storage and bandwidth with no quality loss. permalink fedilink source parent
[–] logi@lemmy.world 3 points 6 months ago The difference (claimed by the comment above) is in the words without loss of quality So you can convert back and forth without the photo copy of a photo copy problem. And you don't have to store the second copy of the file except for caching of frequently fetched files which I'm sure will just be an nginx rule. permalink fedilink source parent
[–] adespoton@lemmy.ca 3 points 6 months ago And let’s not forget HEIF and JPEG-2000. permalink fedilink source parent
[–] The_Decryptor@aussie.zone 2 points 6 months ago What they’re saying is that a web server can create a traditional jpeg file from a jpeg xl to send to a client as needed. Other way around, you can convert a "web safe" JPEG file into a JXL one (and back again), but you can't turn any random JXL file into a JPEG file. But yeah, something like Lemmy could recompress uploaded JPEG images as JXL on the server, serving them at JXL to updated clients, and converting back to JPEG as needed, saving server storage and bandwidth with no quality loss. permalink fedilink source parent
[–] rjek@feddit.uk 2 points 6 months ago No, I'm saying that JPEG XL can perfectly represent old JPEG/JFIF data, so on the server side you can store all your image data once and more efficiently, and still support old clients without any lossy cascade or the CPU load of having to re-encode. That is what is meant about it offering backwards compatibility. permalink fedilink source parent
[–] reddig33@lemmy.world 3 points 6 months ago* (last edited 6 months ago) (1 child) How is it backwards compatible? Everything I’ve read so far says the opposite — That it requires recoding the image into the new format, and keeping around or generating an old copy of the image in current jpeg format for older software. Are you saying a browser or app that currently only supports Jpeg can open and render a Jpeg-XL image? Edit: Yeah. It’s not backward compatible. And system admins are already doing the “make two copies of an image thing with webp and the current jpg format. permalink fedilink source parent hideshow 2 child comments replies: [–] limerod@reddthat.com 1 point 6 months ago The re-encoding requires less computation vs other formats. permalink fedilink source parent
[–] limerod@reddthat.com 1 point 6 months ago The re-encoding requires less computation vs other formats. permalink fedilink source parent
[–] aliser@lemmy.world 2 points 6 months ago why webp is bad? besides google forcing it apparently permalink fedilink source parent