search

google / brunsli

Practical JPEG Repacker
MIT License
731 stars 51 forks source link

Arithmetic coded JPEG support #82

Open vrubleg opened 4 years ago

vrubleg commented 4 years ago

Arithmetic coding is a part of the JPEG standard. All the related patents are expired years ago. Most of the software don't support such JPEGs, but still it would be nice if it will be supported as input for lossless conversion from JPEG to JPEG XL, just to be sure that any valid JPEG can be converted losslessly.

As far as I understand, it won't be possible to restore original JPEG file in this case, because all the stored information about original JPEG file is Huffman related. But I think, it would be enough to preserve just image data without possibility to restore exactly original JPEG file (like in #80).

I posted some examples of arithmetic coded JPEGs here.

schnaader commented 4 years ago

Slightly off-topic: Sad to see here that both Google Chrome and Firefox said "WontFix" to arithmetic coded JPEGs. I can understand most of the reasoning (more CPU power needed, lack of suspension). But as it's not even much effort (setting a compiler flag in libjpeg-turbo), why don't break this chicken-egg-scenario by just doing it, even if only with a setting that the user has to opt-in?

More on topic: That said, I hope (and also feel confident) that both JPEG XL and brunsli will keep on the state-of-the-art track here and support conversion of arithmetic coded JPEGs.

eustas commented 4 years ago

Thanks for the FR. Going to add support of arithmetic->baseline transcoding later,... currently we recommend to use jpegtran for preparing files to be encoded by Brunsli.