google/brunsli

File signature

vrubleg opened this issue · 6 comments

Usual JPEG XL files start with bytes ff 0a. As far as I understand, it follows ISOBMFF as other modern ISO formats do. Brunsli files start with 0a 04 42 d2 d5 4e. Why is it so different? If both of these codecs are under the same umbrella name, MIME type and file extension, why they don't share a similar signature? Why Brunsli signature is so long?

Lossless encoding inside JPEG XL has evolved from Brunsli. Now those are separate fully incompatible projects.

@eustas I understand, but when Brunsli became part of JPEG XL, why you didn't consider changing the signature to make it conforming each other? It's OK to break compatibility before it becomes a standard.

Brunsli has already had users (e.g. 7zip) at the time JPEG XL integration happened.
Also, signature could not be changed to support initial design decision - any Brunsli file is a "protobuf" to allow lightweight meta-information parsing.

So, different modes of JPEG XL require absolutely different code for parsing meta-information, and it doesn't make things easier. It wouldn't be weird if these formats weren't advertised under one name.

As far as I understand, usual 7zip doesn't support archives with Brunsli, it is just some non-standard extension.

As I've mentioned, it is no longer true; meta-information / pixel data is now stored the same way as other JXL, and extra information required for bit-precise JPEG restoration is stored in a different "box" that is described in "Part 2" of specification

Oh, sorry, I didn't understand your first message right. I thought that you meant that two different modes of JPEG XL are these "incompatible projects" =)

Thank you for the explanation.