Pre-multiplied alpha and sRGB color spaces.

384 views
Skip to first unread message

Samuel Williams

unread,
Jul 26, 2017, 12:05:00 AM7/26/17
to WebP Discussion
In Vulkan, you can use 8-bit sRGB textures, with a blending mode assuming pre-multiplied pixels, rendering into a sRGB frame buffer, which by nature of the blending, contains pixels with associated alpha.

Ideally I'd like to be able to load such textures using WebP, and then save the frame buffer using WebP.

Ideally, the input textures are using the sRGB color space - but if not - I'd either reject them or convert them to sRGB. Is this something WebP can do?

Ideally, the input textures are loaded into a buffer containing pixels with associated alpha, and such a buffer can then be saved to disk using WebP. 

Looking at `decode.h` I see

typedef enum WEBP_CSP_MODE {
  MODE_RGB = 0, MODE_RGBA = 1,
  MODE_BGR = 2, MODE_BGRA = 3,
  MODE_ARGB = 4, MODE_RGBA_4444 = 5,
  MODE_RGB_565 = 6,
  // RGB-premultiplied transparent modes (alpha value is preserved)
  MODE_rgbA = 7,
  MODE_bgrA = 8,
  MODE_Argb = 9,
  MODE_rgbA_4444 = 10,
  // YUV modes must come after RGB ones.
  MODE_YUV = 11, MODE_YUVA = 12,  // yuv 4:2:0
  MODE_LAST = 13
} WEBP_CSP_MODE;

However it's not clear to me how to use `MODE_rgbA` (or any other pre-multiplied mode) for encoding.


It converts linear inputs to sRGB, and it ensures the alpha in the user buffer is associated.

Is this the same for WebP?

James Zern

unread,
Jul 26, 2017, 9:27:13 PM7/26/17
to WebP Discussion
Hi,
The above are decode only, for encoding we assume the source is non-premultiplied. Have a look at tiffdec.c [1].

 

Samuel Williams

unread,
Jul 26, 2017, 10:17:14 PM7/26/17
to WebP Discussion
Is there any way to specify that the source IS pre-multiplied so we can save data directly from frame-buffer?

Strangely enough, I generated a pixel buffer containing RGBA8{128, 128, 128, 128} and saved it as both PNG and WebP using the default settings.

I then used ImageMagick to composite these files by dropping the alpha channel, and the result was identical. Is that odd? They also both look the same in Chrome.

Given that libpng states it's interpreting the PNG data as associated, and you've stated that WebP interprets the data as unassociated, I would have imagined the WebP composite would have been darker.

James Zern

unread,
Jul 28, 2017, 1:51:39 AM7/28/17
to WebP Discussion


On Wednesday, July 26, 2017 at 7:17:14 PM UTC-7, Samuel Williams wrote:
Is there any way to specify that the source IS pre-multiplied so we can save data directly from frame-buffer?


Not explicitly. You could pass the premultiplied samples, but you'd need to share that knowledge on the decode side.
 
Strangely enough, I generated a pixel buffer containing RGBA8{128, 128, 128, 128} and saved it as both PNG and WebP using the default settings.

I then used ImageMagick to composite these files by dropping the alpha channel, and the result was identical. Is that odd? They also both look the same in Chrome.

Given that libpng states it's interpreting the PNG data as associated,

libpng can produce premultiplied in recent versions, but it treats the samples as unassociated [2][3][4].
 
and you've stated that WebP interprets the data as unassociated, I would have imagined the WebP composite would have been darker.

The above are decode only, for encoding we assume the source is non-premultiplied. Have a look at tiffdec.c [1].

 

Samuel Williams

unread,
Jul 30, 2017, 9:42:05 AM7/30/17
to webp-d...@webmproject.org
Within the simplified API, the input and output pixels are considered
pre-multiplied. The internal PNG data is not pre-multiplied though, as
you correctly point out. So, it's odd that it shows up with the same
value as WebP and composites the same way using ImageMagick.

On 28 July 2017 at 17:51, 'James Zern' via WebP Discussion
> --
> 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 post to this group, send email to webp-d...@webmproject.org.
> Visit this group at
> https://groups.google.com/a/webmproject.org/group/webp-discuss/.
> For more options, visit
> https://groups.google.com/a/webmproject.org/d/optout.

Samuel Williams

unread,
Jul 30, 2017, 8:20:10 PM7/30/17
to webp-d...@webmproject.org
Correct me if I'm wrong, but assuming the documentation on libpng
simple API is correct:

PNG associated input RGBA8{128, 128, 128, 128} input is stored as
RGBA8{255, 255, 255, 128} unassociated in file format.

WebP (unassociated?) input RGBA8{128, 128, 128, 128} input is stored
as RGBA8{128, 128, 128, 128} unassociated in file format.

When ImageMagick loads these values and blends them, the output should
be different?


On 31 July 2017 at 01:42, Samuel Williams

James Zern

unread,
Jul 31, 2017, 8:43:26 PM7/31/17
to WebP Discussion


On Sunday, July 30, 2017 at 5:20:10 PM UTC-7, Samuel Williams wrote:
Correct me if I'm wrong, but assuming the documentation on libpng
simple API is correct:

PNG associated input RGBA8{128, 128, 128, 128} input is stored as
RGBA8{255, 255, 255, 128} unassociated in file format.


I've seen that as a recommendation for PNG encoders, but to be sure it's probably worth looking at the PNG source.
 
WebP (unassociated?) input RGBA8{128, 128, 128, 128} input is stored
as RGBA8{128, 128, 128, 128} unassociated in file format.

When ImageMagick loads these values and blends them, the output should
be different?


On 31 July 2017 at 01:42, Samuel Williams

Samuel Williams

unread,
Jul 31, 2017, 9:40:05 PM7/31/17
to webp-d...@webmproject.org
Right - so I'm looking at the latest libpng and assuming the
documentation for the API is correct. I will try to make a structured
test case and compare it against manually loading the pixels from the
lower level API.

On 1 August 2017 at 12:43, 'James Zern' via WebP Discussion
<webp-d...@webmproject.org> wrote:
>
>
> On Sunday, July 30, 2017 at 5:20:10 PM UTC-7, Samuel Williams wrote:
>>
>> Correct me if I'm wrong, but assuming the documentation on libpng
>> simple API is correct:
>>
>> PNG associated input RGBA8{128, 128, 128, 128} input is stored as
>> RGBA8{255, 255, 255, 128} unassociated in file format.
>>
>
> I've seen that as a recommendation for PNG encoders, but to be sure it's
> probably worth looking at the PNG source.
>
>>
>> WebP (unassociated?) input RGBA8{128, 128, 128, 128} input is stored
>> as RGBA8{128, 128, 128, 128} unassociated in file format.
>>
>> When ImageMagick loads these values and blends them, the output should
>> be different?
>>
>>
>> On 31 July 2017 at 01:42, Samuel Williams
>> >> email to webp-discuss...@webmproject.org.
>> >> To post to this group, send email to webp-d...@webmproject.org.
>> >> Visit this group at
>> >> https://groups.google.com/a/webmproject.org/group/webp-discuss/.
>> >> For more options, visit
>> >> https://groups.google.com/a/webmproject.org/d/optout.
>
> --
> 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.
Reply all
Reply to author
Forward
0 new messages