Open Enet4 opened 8 months ago
hi
as usual support for additional formats comes with it's own wrinkles and I usually have two of them
Security, tho this can be alleviated by fuzzing
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 returns
Vec
I'm more likely to support the latter than the former
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.
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 tozune-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 intozune-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 fromjpeg_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 byjpeg-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?