Review Request: add kimgio WebP image format plugin

[Christoph Feck]

Hi, I will reply in a single mail. Please do not forget to CC the 
list, if you don't choose to reply via the RB interface.

On Sunday 02 September 2012 15:42:03 Martin Koller wrote:
> On Sunday, 2. September 2012 02:07:06 you wrote:
> > Additionally, I would like the loader to return a Format_RGB32
> > image, when the data did not contain an alpha component.
> > If your version has no way to detect alpha component, then use a
> > newer version. If the newest libwebp does not return that
> > information, then wait until its developers wake up (a joggle
> > them).
(NB: I meant "or joggle them" here)
> I could install a newer version - but do you think it is wise to
> depend on code which is not even in the newest openSuse
> distribution ?

Since this is a new feature, it will be for KDE 4.10 anyway.

> Another idea: what if I simply check if all pixels in the image have
> an alpha value = 255, and if so, there is no transparency defined,
> right ?

Sure, but I do not believe that webp requires applications to check 
the pixel data to determine if it actually has alpha, especially since 
webp format was initially without any alpha support. This information 
must be stored in the header, and (again), if there is no way to get 
this information, webp developers need to go back to the drawing 
board.

> A general question: why would you like that ?
> Both formats are stored using 32bits per pixel, so where is the
> advantage ?
> I'm considering if it wouldn't be best to return the format
> QImage::Format_ARGB32_Premultiplied as the doc says
> "Certain operations (such as image composition using alpha blending)
> are faster using premultiplied ARGB32 than with plain ARGB32."

What the Qt docs compare here is premultiplied alpha vs. non-
premultiplied alpha, but I am comparing alpha vs. opaque data. It 
should be obvious that handling images with alpha data is slower than 
without.

Regarding the premultiplied alpha, I don't know, if the webp pixel 
data is premultiplied with alpha in the first place. If it is, it 
would certainly make sense to return it premultiplied, but only if the 
webp library interface allows to get that data unmodified.

The general rule of thumb is to have only one conversion if 
neccessary, so the loader should return the data stored in the file 
unmodified, and if an application works faster with premultiplied data 
(e.g. in case it composes using QPainter), it can opt to convert to 
premultiplied alpha.

Christoph Feck (kdepepo)