search

google / brunsli

Practical JPEG Repacker
MIT License
730 stars 51 forks source link

File signature #110

Closed vrubleg closed 3 years ago

vrubleg commented 3 years ago

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?

eustas commented 3 years ago

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

vrubleg commented 3 years ago

@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.

eustas commented 3 years ago

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.

vrubleg commented 3 years ago

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.

eustas commented 3 years ago

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

vrubleg commented 3 years ago

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.