WebM

Actually, I take back the lossy not having a problem. They both (lossless & lossy webp) have a problem. So this might be an issue with how cwebp is reading the tiff file.

The original TIFF contains sample that are non-associated (ie: not premultiplied): the TIFFTAG_EXTRASAMPLES value is 'EXTRASAMPLE_UNASSALPHA' (=2).

Is that expected? Is your TIFF viewer taking this into account?

Because if i force the WebP tiff reader to unmultiply (as if the tag was EXTRASAMPLE_ASSOCALPHA), i get an output similar to your expectation (i think. See attachment).

Could you clarify if the input samples are premultiplied or not?

thanks!

I am not sure what is going on here and whether it is related to the ASSOCALPHA/UNASSALPHA thing.

My original test.tiff was created from scratch with GIMP.

Your image (test.tiff.unassoc.webp) does look like what I see when I open test.tiff with GIMP and what I expected the webp to look like.

I did some tests and it appears that different programs interpret test.tiff differently. If you look at side-by-side.png that I uploaded, I found that GIMP & ImageMagick display test.tiff like the left part of side-by-side.png, whereas GThumb & Eye of GNOME display it more like the right part. Also, cwebp produces a webp that looks like the right image whereas when I convert to webp using imagemagick I get the left image.

Thanks for the extra explanations.

First things first, i *think* there is a bug in ImageMagick.
I proposed a patch here:
   https://github.com/ImageMagick/ImageMagick/pull/1349

Let's see where it leads.

The ImageMagick patch has been accepted and merged[1].

It seems that the TIFF reader was buggy there. It should now be aligned to what WebP is doing.

Next: have a look at what GIMP is doing :)


[1] https://github.com/ImageMagick/ImageMagick/commit/93cb7fcfa30026f87fb8f0ccab9ad520a184cc6c

one more data point: Eye Of Gnome is based on gdk-pixbuf for image loading.
And it seems gdk-pixbuf is not supporting alpha properly during TIFF loading.
Will try to fix that by sending a patch.

[Comment Deleted]

Converting losslessly sample file above with 1.2.1rc2 to webp gave 236 colors instead of 1 in Irfanview, not to mention it looks different than original file

could you elaborate a bit? None of the bugs above were related to libwebp, but how the tools were decoding the TIF file. What commands did you use exactly?

If you asked me - "cwebp -quiet -pass 10 -alpha_method 1 -alpha_filter best -m 6 -mt -lossless "test.tiff" -o "test.webp"
And OK what viewer decodes this sample OK?

It sounds like https://crbug.com/webp/401#c8 is related to https://crbug.com/webp/536. Let's move the conversation there.

#11 i think the problem is actually different.

I've found this old conversation from 2012 [1] reporting that GIMP is saving badly formatted TIFF files, and ImageMagick is also erroneous.
Still investigating... The patch [2] i proposed is probably incorrect.

[1] https://lists.osgeo.org/pipermail/gdal-dev/2012-May/032984.html
[2] https://chromium-review.googlesource.com/c/webm/libwebp/+/3093999

I'm proposing https://github.com/GNOME/gimp/pull/34
Let's see...

Which version of GIMP did you use? Did you check the "save alpha" button?

This issue was migrated from crbug.com/webp/401?no_tracker_redirect=1