Doc repository?

[Pierre Joye]

Hello,

I was looking to provide a patch against:

https://developers.google.com/speed/webp/docs/api#advanced_decoding_api

specifically to add a note about the endianness dependent MODE_* (it bites me again today :) for the advanced decoding API, fe., MODE_Argb vs MODE_bgrA, respectively big and little endian.

Any pointer?

Best,

Pierre

[Yannis Guyon]

Thank you for your question. The link you gave is managed internally, there is no public repository containing the sources. Feel free to suggest edits here for review.

Endianness was not specified because the memory buffer is supposed to be accessed as a uint8_t pointer. Using a higher bit depth than bytes will indeed have platform-dependent effects.

MODE_Argb will be "big endian", meaning the alpha will be stored in the most significant bits of a 32-bit integer, *only* when accessing the data as uint32_t* on a big-endian platform.

[Pierre Joye]

HI Yannis,

On Tue, Aug 10, 2021 at 2:59 PM Yannis Guyon <ygu...@google.com> wrote:
>
> Thank you for your question. The link you gave is managed internally, there is no public repository containing the sources. Feel free to suggest edits here for review.

Thanks for the quick response :)

> Endianness was not specified because the memory buffer is supposed to be accessed as a uint8_t pointer. Using a higher bit depth than bytes will indeed have platform-dependent effects.
> MODE_Argb will be "big endian", meaning the alpha will be stored in the most significant bits of a 32-bit integer, *only* when accessing the data as uint32_t* on a big-endian platform.

This is indeed correct. I was thinking it could add some clarity that
it behaves this way. Also for many users relying on libwebp and other
libraries with the classic independent behavior, it can create some
confusion especially as from their side, no int32_t interactions are
done. F.e. it bites me while I was updating libGd WebP support
(options and adding more formats), easy to figure out but it can be
less obvious for other users.

My thought was to add the explanation you wrote very well :) with a
piece of code:


#if IS_BIG_ENDIAN
config.output.colorspace = MODE_Argb;
#else
config.output.colorspace = MODE_bgrA;
#endif

config.output.u.RGBA.rgba = argb;
config.output.u.RGBA.stride = gdSurfaceGetStride(surface);
config.output.u.RGBA.size = gdSurfaceGetStride(surface) * height;

For clarity.

Best,
--
Pierre

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

[Pascal Massimino]

Hi,

On Tue, Aug 10, 2021 at 11:07 AM Pierre Joye <pierr...@gmail.com> wrote:

HI Yannis,

On Tue, Aug 10, 2021 at 2:59 PM Yannis Guyon <ygu...@google.com> wrote:
>
> Thank you for your question. The link you gave is managed internally, there is no public repository containing the sources. Feel free to suggest edits here for review.

Thanks for the quick response :)

> Endianness was not specified because the memory buffer is supposed to be accessed as a uint8_t pointer. Using a higher bit depth than bytes will indeed have platform-dependent effects.
> MODE_Argb will be "big endian", meaning the alpha will be stored in the most significant bits of a 32-bit integer, *only* when accessing the data as uint32_t* on a big-endian platform.

This is indeed correct. I was thinking it could add some clarity that
it behaves this way. Also for many users relying on libwebp and other
libraries with the classic independent behavior, it can create some
confusion especially as from their side, no int32_t interactions are
done. F.e. it bites me while I was updating libGd WebP support
(options and adding more formats), easy to figure out but it can be
less obvious for other users.

My thought was to add the explanation you wrote very well :) with a
piece of code:


#if IS_BIG_ENDIAN
    config.output.colorspace = MODE_Argb;
#else
    config.output.colorspace = MODE_bgrA;
#endif

On the decoder side, the API was careful to avoid using any uint32_t* for accessing a/r/g/b samples, preferring uint8_t* for access.

This avoids having to care about endianness. There's even an explicit mention of the memory order after decoding here.

Having these #ifdef XXX_ENDIAN wouldn't go in the right direction, i'd say...

skal/

    config.output.u.RGBA.rgba = argb;
    config.output.u.RGBA.stride = gdSurfaceGetStride(surface);
    config.output.u.RGBA.size = gdSurfaceGetStride(surface) * height;

For clarity.

Best,
--
Pierre

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

--
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/CAEZPtU5boCHw-8AsBxSW4SC7aVCajupOSd4-u7j%3D05nEg3ucGw%40mail.gmail.com.

[Pierre Joye]

Hi,

On Tue, Aug 10, 2021, 7:11 PM Pascal Massimino <pascal.m...@gmail.com> wrote:

#if IS_BIG_ENDIAN
    config.output.colorspace = MODE_Argb;
#else
    config.output.colorspace = MODE_bgrA;
#endif

On the decoder side, the API was careful to avoid using any uint32_t* for accessing a/r/g/b samples, preferring uint8_t* for access.

This avoids having to care about endianness. There's even an explicit mention of the memory order after decoding here.

Having these #ifdef XXX_ENDIAN wouldn't go in the right direction, i'd say...

Yes, I think so too. I got caught twice (last time  ;), once when I did the initial webp support for  libgd, php and some windows fixes for the libwebp (early webp days), and now while adding new gd internal formats.

It is not critically needed though, anyone working on a regular basis with images will figure it out quickly. However It may help other using webp with common libraries using endianness independent format, cairo or the underlying pixmap, agg etc.

--

Pierre