One downside is that you cannot tell if format lossy or lossless by looking at its extension.

You can’t really do that with PNG today either, because of all the PNG optimizers that quantize images before encoding them to PNG for better compression.

▲

unglaublich 3 hours ago | parent [-]

Independent preprocessing doesn't make PNG itself lossy.

▲

spider-mario 2 hours ago | parent | next [-]

The point is that you can’t tell whether it’s a lossless image by looking at the extension.

	▲	mnw21cam 39 minutes ago \| parent [-]
		It's not the PNG encoding that causes the loss. The optimisers are literally creating a different image and then losslessly encoding it as PNG. But it's also a valid point.

▲

arthur-st 2 hours ago | parent | prev [-]

Yes, but a lossless encode of a lossy copy of an image results in a lossy image functionally.

▲

AshleysBrain 4 hours ago | parent | prev | next [-]

That's true of WebP and AVIF as well. I think all modern image codecs have both lossy and lossless modes - the separation between JPEG for lossy and PNG for lossless seems to be a historical oddity.

	▲	spider-mario 3 hours ago \| parent [-]
		And a nominally “lossless” image may have been reencoded from a lossy source.

▲

yhjc2692 33 minutes ago | parent | prev | next [-]

This is something that can be addressed by file managers - showing a metadata entry on whether it's lossy or lossless. File extension (along with the bifurcated mainstream adoption of JPEG and PNG) has been a great proxy to do this, but like others noted, can be deceptive, which is arguably worse.

▲

eviks an hour ago | parent | prev | next [-]

You cannot tell it just from the extension either. If you like extensions, you can use a '.lossless.jxl'. And in general for most formats, you can use metadata to store that info (also doesn't guarantee anything)

▲

adzm 4 hours ago | parent | prev | next [-]

This is indeed frustrating, though realistically not that big of a deal for most users, especially if you consider lossless as just highest quality. Though personally I think it makes sense to have different extensions by convention for lossless and animated images.

	▲	nananana9 2 hours ago \| parent [-]
		It's a big deal :( JPEG artifacts are literally a meme, normal people are aware of this stuff. I hold the extremist view that had we decided to use .png for lossless webps, it would have been an overall net gain - in people's minds "png" maps roughly to "whoever last touched this image didn't do anything evil to it" - very few people care how the data is actually encoded.

▲

pmarreck 4 hours ago | parent | prev | next [-]

ah, that's a good point.

perhaps use .ll.jxl to indicate "lossless jpegxl" informally?

prior art: I've been using .frontmatter.md or .fm.md for markdown files with frontmatter

▲

chaosharmonic 4 hours ago | parent | next [-]

I've been wishing for years that all of these codecs with hybrid lossless/lossy modes would just add a single l to their file extensions, purely for the annoyance of it.

Like, you can do this individually, but it's not the same thing as actually having it in the standard.

▲

rozab 3 hours ago | parent [-]

Does the L stand for lossy, or lossless? Or large, as in this case?

	▲	chaosharmonic 2 hours ago \| parent \| next [-]
		See I would think lossless is the one you have to specify. (Also, it stops being "large" when you extend this gripe to similar formats like AVIF and WebP.)
	▲	kps 2 hours ago \| parent \| prev [-]
		One L for Lossy, two for LossLess. Does the one at the end of .JXL count toward the total? Nobody knows what it stands for anyway.

▲

Levitating 2 hours ago | parent | prev [-]

Multiple extensions typically denote nested filetypes.

Like files.tar.xz may be decompressed with xz and then extracted with tar to get the directory "files".

I think in your case .md.fm would be a greater fit, as the front matter is read first. Or just .fmd

▲

Levitating 2 hours ago | parent | prev [-]

I can't really think of a scenario where that would be useful? File-size is more indicative of quality anyway.