In place pixel format translation

[johnbwang]

When decoding a JPG image, decode() gives me a Vec<u8> of components, where each component (R, G, B, A) is a byte. I then transform this vector into whatever pixel format I'm sending to a pixel buffer, for example RGB565. This increases memory usage in that each image I'm decoding, I need a byte per component per pixel for decoding and a 2 bytes (in the case of RGB565) per pixel for the end result.

We can save the byte per component per pixel during decoding if we can directly translate to the end pixel format inside of decode().

Maybe a closure added to DecoderOptions for the most flexibility in terms of translations?

[etemesi254]

While it makes sense yo have in place decoding, it complicates everything else.

So let's say we want to transform RGBA to RGB565 via a function

• What is the function definition? is it fn(pix:&[u8;4],out:u16) ?
• How does the API end up looking, will output be still in decode_into and decode? or do we need to create other apis?
• How do we handle grayscale images? (JPEG has support for one component image that are grayscale), and even CMYK images?(which jpeg supports)
• Will this complicate calculation of output size? yes
• Will this be a maintenance burden? (yes)
• Will this be well tested? Probably no

And other things you meet when you start implementing.

If you need RGB565, you can always use https://crates.io/crates/mozjpeg which supports outputting to RGB565, I probably will not support that or end up accepting a PR even if someone does the work(it adds maintenance burden to an already largely scoped project)

[johnbwang]

I was poking around the code more and saw scalars.rs which does conversion between YCbCr to RGBA and a few other conversions.

What do you think if ColorSpace::RGB565 is introduced and we use the conversion functions (or introduce a new conversion function) in scalars.rs to get it into the final RGB565 format? This would need start differentiating between ColorSpace::num_components() and ColorSpace::bytes_per_pixel() though.

This does complicate things slightly, but overall is relatively small and well scoped change.

[etemesi254]

Hi, what would the implication of this be when dealing with pixel transformations? e.g how does brighten work with rgb565?

imho thiis introduces a lot of complexity to justify saving memory (which btw transforming rgb to rb565 can be done in place with some manual indexing) and it's an additional burden

A sample code to convert rgb to rgb565

fn rgb888_to_rgb565(input:& mut[u8]){
  let mut   i=0;
  let mut  j =0;
  while j<= input.len(){
    let  r = input[j];
    let g = input[j+1];
    let b = input[j+2];
    let mut out:u16=0;

    out |= ((r as u16) & 0b11_111)<< 11;
    out |= ((g as u16) & 0b111_111) << 5;
    out |= ((b as u16). & 0b11_111);

    input[i..i+2].copy_from_slice(&out.to_ne_bytes());
     i+=2;
     j+=3;
}