Allow MODE_bgrA for advanced Encoding

[Pierre Joye]

Hello,

Has it been considered to add similar configuration for the advanced encoder than for the encoder?

Almost projects using libwebp and premultiplied (or other non supported format) have to manually do the conversions. It could make sense as most of the code is in there already (as well as the SIMD versions). It would reduce the boiler plate in the callers.

What do you think?

Best,

Pierre

[Pascal Massimino]

Hi,

(let me do a quick historical recap!)

A lot of the internal work in the encoder relies on a very specific ARGB 32b input (found as 'uint32_t* WebPPicture::argb').

Unlike the decoder, the encoder uses uint32_t* for pointing to the input samples (with -agreed- potential endianness problem if the user casts an uint8_t* memory chunk toward uint32_t*).

It was chosen (long ago) to stick to one only input format, to simplify the encoder's internals, but also to supply a lot of ready-made conversion functions to this

input format, in the form of  WebPPictureImportXXXX() and such. There's no premultiply version of them, for simplicity of the API.

Back to your question: to handle pre-multiply format, there is an (already optimized) function WebPUnmultiplyARGB() in extras/extras.h:59.

The function is so simple it can even be copy-pasted as is, if linking to the (not-distributed) 'extras' library is not an option.

hope it helps!

skal/

 

What do you think?

Best,

Pierre

--
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/596c49f4-a15e-45ab-af2a-6907a36a0b6fn%40webmproject.org.

[Pierre Joye]

Good morning,

On Tue, Aug 10, 2021 at 11:11 PM Pascal Massimino
<pascal.m...@gmail.com> wrote:
>
> Hi,
>
> (let me do a quick historical recap!)
>
> On Tue, Aug 10, 2021 at 8:52 AM Pierre Joye <pierr...@gmail.com> wrote:
>>
>> Hello,
>>
>> Has it been considered to add similar configuration for the advanced encoder than for the encoder?
>>
>> Almost projects using libwebp and premultiplied (or other non supported format) have to manually do the conversions. It could make sense as most of the code is in there already (as well as the SIMD versions). It would reduce the boiler plate in the callers.
>
>
> A lot of the internal work in the encoder relies on a very specific ARGB 32b input (found as 'uint32_t* WebPPicture::argb').
> Unlike the decoder, the encoder uses uint32_t* for pointing to the input samples (with -agreed- potential endianness problem if the user casts an uint8_t* memory chunk toward uint32_t*).
>
> It was chosen (long ago) to stick to one only input format, to simplify the encoder's internals, but also to supply a lot of ready-made conversion functions to this
> input format, in the form of WebPPictureImportXXXX() and such. There's no premultiply version of them, for simplicity of the API.
>
> Back to your question: to handle pre-multiply format, there is an (already optimized) function WebPUnmultiplyARGB() in extras/extras.h:59.
> The function is so simple it can even be copy-pasted as is, if linking to the (not-distributed) 'extras' library is not an option.

Exactly :)

A little change to preprocess inputs before passing to the encoder
could be handy and avoid users to reinvent the wheel. From a libgd
point of view, we do have our own (classic and SIMD), so we are not
really affected. I was only thinking it could be nicer :).

No big thing anyway, simple enough and docs can provide pointers to
the required code if needed.

Best,
--
Pierre

@pierrejoye | http://www.libgd.org