3 ms·
a sw that does not know what jpeg xl is, will not be able to open jxl files. How would it? Not sure what the previous poster meant with “backward compatible” h
by illiac786 1y ago
a sw that does not know what jpeg xl is, will not be able to open jxl files. How would it?
Not sure what the previous poster meant with “backward compatible” here. jxl is a different format. It can include every information a jpeg includes, which then maybe qualifies as “backward compatible” but it still is a different format.
- liuliu 1y agoJPEG XL has the mode that in layman's word, allow bit-by-bit round-trip with JPEG. Original JPEG -> JPEG XL -> Recreated JPEG. Sha256(Original JPEG) == Sha256(Recreated JPEG). That's what people meant by "backward compatible".
- colejohnson66 1y agoThat’s not “backwards compatible”, but “round tripable” or “lossless reencode”
- illiac786 1y agoexactly, it is absolutely not backward compatible. It is lossless-at-bit-level conversion of JPEG, but that doesn’t help older SW in any way.
- BobaFloutist 1y agoAh, got it. I assumed it was a losselessly compressed JPEG with metadata telling modern software not to compress differently but that older software would open as a normal JPEG, but I guess they meant something else with "backward compatible".
- pmarreck 1y agoI guess I meant losslessly round-trippable. In other words, you can go from jpeg -> jxl -> jpeg without any loss in quality, potentially (although with jxl -> jpeg -> jxl, you will lose space while it is a jpeg, and you'd probably have to pick a high compression quality in order to not lose information... you may also lose information such as metadata that jxl accommodates but jpeg does not, like transparency) So backwards-compatible in the sense that the jpeg-xl algorithm spec can read jpg and store the same pixel data more efficiently as jxl if you like. You gain space and lose nothing (except perhaps encode/decode speed).