JPEG lossless in zune-jpeg

[Enet4]

I am reaching out to discuss the possibility of including support for JPEG lossless in the zune-jpeg crate.

The context is that jpeg-decoder is currently the only known library in pure Rust that can handle the decoding of images in JPEG lossless (ISO/IEC 10918-1 Annex H), a standard capability with very little support in the ecosystem, but with a prominent presence in medical imaging. However, after the image-rs project's interest in migrating to zune-jpeg, jpeg-decoder itself turned into maintenance mode, which puts this capability in a bit of a rough spot. The way I see it, bringing support for JPEG lossless into zune-jpeg would be the best way forward in the long term to ensure that JPEG lossless images can be decoded reliably and efficiently in Rust.

A few options are available here, but the most intuitive one would be migrating the lossless module from jpeg_decoder, which was already designed to be disentangled with the rest of the code. One would mostly have to replace some portions so as to depend on the existing implementation of Huffman coding (arithmetic encoding entropy coding is not supported by jpeg-decoder anyway). There may be other implications to the high level API that I am not yet aware of (do the current data structures consider the possibility of images having a bit precision other than 8 bits per sample?).

What are your thoughts on this?

[etemesi254]

hi

as usual support for additional formats comes with it's own wrinkles and I usually have two of them

1. Security, tho this can be alleviated by fuzzing

2. API , supporting lossless means we support 16 bit data, i particularly don' like 16 bit data due to endianess shenanigans and there is no way to mix it with 8 bit data.

this always leads to the question what decode should return, an enum with variants and how that makes it unegornomic for 99% of users.

Or we could provide a separate decoding routine, I don't think lossless jpegs have post transfoms like normal lossy( idct,color conversion), something like 'if decoder.is_losless() {decoder.decode_lossless()}which returnsVec` by default

I'm more likely to support the latter than the former

[fintelia]

The least bad option we've found in image-rs for dealing with a mixture of 8-bit and non 8-bit image data is to have the user always pass in a &mut [u8] and write the output into that. If they want to write into a &[u16] or whatever, it is simply a matter of using bytemuck or some other library to transmute the slice.