Arithmetic coded JPEG support

[vrubleg]

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]

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]

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.