Image encoding from bgra results in solid color

[Adam Bennett]

I have the following code that attempts to write a webp image from a fixed size bgra frame (always the same resolution) to a file. The resulting file is a solid color (#e6e6e6) of the correct resolution.

How am I botching the encoding?

```

uint8_t *image_data = nullptr;
int image_data_size = WebPEncodeLosslessBGRA(frame->data(), frame->size().width(), frame->size().height(), frame->stride(), &image_data);

std::ofstream image_file("screenshot.webp");
for (int i = 0; i < image_data_size; i++) {
    image_file << image_data[i];
}
image_file.close();

```

Thanks,

Adam

[Pascal Massimino]

Hi Adam,

On Thu, Apr 22, 2021 at 2:22 AM Adam Bennett <adam.m...@gmail.com> wrote:

I have the following code that attempts to write a webp image from a fixed size bgra frame (always the same resolution) to a file. The resulting file is a solid color (#e6e6e6) of the correct resolution.

How am I botching the encoding?

as a precaution, could you print the values of frame->size().width(),  frame->size().height(), frame->stride() and also maybe the content

of frame->data() ?

Just to verify you're really compressing what you expect to...

skal/

```

uint8_t *image_data = nullptr;
int image_data_size = WebPEncodeLosslessBGRA(frame->data(), frame->size().width(), frame->size().height(), frame->stride(), &image_data);

std::ofstream image_file("screenshot.webp");
for (int i = 0; i < image_data_size; i++) {
    image_file << image_data[i];
}
image_file.close();

```

Thanks,

Adam

--
You received this message because you are subscribed to the Google Groups "WebP Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webp-discuss...@webmproject.org.
To view this discussion on the web visit https://groups.google.com/a/webmproject.org/d/msgid/webp-discuss/d8a4b173-ed08-4624-be44-cbc0c9446f22n%40webmproject.org.

[Pascal Massimino]

Hi Adam,

On Fri, Apr 23, 2021 at 5:25 AM Adam Bennett <adam.m...@gmail.com> wrote:

The source data is legit (it's a webrtc::DesktopFrame image) and I've used it to encode video frames with ffmpeg.

I assumed it wasn't rendering the image because I was writing the image bytes without any metadata or a header. Will `uint8_t *image_data` include everything required to write a valid webp file?

yes,  the bitstream returned has all the necessary headers needed to be a genuinely decodable WebP image.

Maybe the next step is to fill frame->data() with controlled values (like: pure black, pure white, no transparency) and see if the resulting bitstream is ok.

skal/

`

[James Zern]

On Thu, Apr 22, 2021 at 11:30 PM Adam Bennett <adam.m...@gmail.com> wrote:

The source data is legit (it's a webrtc::DesktopFrame image) and I've used it to encode video frames with ffmpeg.

I assumed it wasn't rendering the image because I was writing the image bytes without any metadata or a header. Will `uint8_t *image_data` include everything required to write a valid webp file?

Yes the return is a full webp image. The order of the channels is important too. BGRA expects that order in memory [1], but depending on the source on a little endian machine you may have ARGB.

[1] https://developers.google.com/speed/webp/docs/api#simple_encoding_api

 

`

On Thursday, April 22, 2021 at 1:19:55 AM UTC-5 pascal.m...@gmail.com wrote:

To view this discussion on the web visit https://groups.google.com/a/webmproject.org/d/msgid/webp-discuss/800a4dcb-1671-4d40-8efb-e43702ff8c69n%40webmproject.org.

[Adam Bennett]

Thanks for the diagnostic help. Everything looks good on the webp encoding. I can create images manually created pixels and they encode correctly.

Webrtc's desktop capturer when ran from a google test returns 65,63,60,255 for every pixel even though all the definitions/compiler features are the same as the exe that previously was correctly capturing screen data. Peculiar. Back to the drawing board for me.

[James Zern]

On Fri, Apr 23, 2021 at 3:42 PM Adam Bennett <adam.m...@gmail.com> wrote:

Thanks for the diagnostic help. Everything looks good on the webp encoding. I can create images manually created pixels and they encode correctly.

Webrtc's desktop capturer when ran from a google test returns 65,63,60,255 for every pixel even though all the definitions/compiler features are the same as the exe that previously was correctly capturing screen data. Peculiar. Back to the drawing board for me.

I'm not familiar with the test you're referring to. If you have questions around that, then maybe the webrtc forum would be a good place to start: https://groups.google.com/g/discuss-webrtc