How is bit depth represented in zune-jpeg?

[Shnatsel]

I'm trying to integrate zune-jpeg into image and I have a question about color spaces.

zune-core has the ColorSpace enum that doesn't specify the bit depth. Meanwhile image has a ColorType enum that does specify the bit depth - Rbga8 and Rgba16 are distinct values.

How can I convert from the zune representation to the image representation when using zune-jpeg? Is the bit depth always assumed to be 8 bit per pixel, or is it communicated through some property I didn't discover?

[etemesi254]

Bit depth is a long story.

There is another enum called BitDepth in core.

zune-image/zune-core/src/bit_depth.rs

Lines 12 to 53 in 712360e

	pub enum BitDepth
	{
	/// U8 bit depth.
	///
	/// Images with such bit depth use [`u8`] to store
	/// pixels and use the whole range from 0-255.
	///
	/// It is currently the smallest supported bit depth
	/// by the library.
	///
	/// For images with bit depths lower than this, they will be scaled
	/// to this bit depth
	Eight,
	/// Ten bit depth
	///
	/// Images with such bit depth use [`u16`] to store values but they
	/// only use 10 bits, i.e from 0-1024.
	///
	/// Preserved across image operations
	///
	/// This is provided as a compatibility to allow decoding and encoding of av1 images
	/// (when fully supported)
	///
	/// Data is stored and processed in native endian
	Ten,
	/// Twelve bit depth
	///
	/// Images with such bit depths use [`u16`] to store values but they
	/// only use 12 bits.
	///
	/// Data is stored and processed in native endian
	Twelve,
	/// U16 bit depth
	///
	/// Images with such bit depths use [`u16`] to store values and use the whole range
	/// i.e 0-65535
	///
	/// Data is stored and processed in native endian.
	Sixteen,
	/// Bit depth information is unknown
	Unknown
	}

The only one of importance now is BitDepth::Eight and BitDepth::Sixteen, but for jpeg since we do not currently have support for lossless images, we only use BitDepth::Eight.

The reason I didn't do it like image is that when we want to extend it, it becomes an issue, e.g since they now support F32, you need Rgba32, Rgb32 ans so on and so forth, I saw it fit to be separated.