webp images show up as black about geeqie

[caclark]

@kullfar

I think this may be relevant:
aruiz/webp-pixbuf-loader#73

From the Geeqie point of view, I see that the "update area" signal is not happening - therefore no data.

[tsutsui]

It looks my webp-pixbuf-loader patch in aruiz/webp-pixbuf-loader#73 doesn't fix this geeqie issue.
After several try-and-errors, it looks geeqie assumes:

• PixbufModulePreparedFunc should be called after pixbuf is prepared and before loaded data is copied into the pixbuf
• PixbufModuleUpdatedFunc should be called after loaded data is copied into the pixbuf

My patch in aruiz/webp-pixbuf-loader#73 calls PixbufModulePreparedFunc after loaded data is decoded into the pixbuf so it doesn't help the geeqie case. (though I have not checked API documents of GdkPixbuf)

The attached patch against webp-pixbuf-loader 0.2.4 seems to fix geeqie this "webp images show up as black" problem. Could anyone try this? (not sure what's should be done in is_animation case)

diff --git a/io-webp.c b/io-webp.c
index c67e0a9..de2f83a 100644
--- a/io-webp.c
+++ b/io-webp.c
@@ -143,6 +143,8 @@ stop_load (gpointer data, GError **error)
         {
           if (context->prepare_func)
             context->prepare_func (pb, GDK_PIXBUF_ANIMATION (anim), context->user_data);
+          if (context->update_func)
+            context->update_func (pb, 0, 0, context->width, context->height, context->user_data);
           ret = TRUE;
         }
 
@@ -174,6 +176,9 @@ stop_load (gpointer data, GError **error)
           return FALSE;
         }
 
+      if (context->prepare_func)
+        context->prepare_func (pb, NULL, context->user_data);
+
       if (icc_data)
         {
           gdk_pixbuf_set_option (pb, "icc-profile", icc_data);
@@ -187,10 +192,8 @@ stop_load (gpointer data, GError **error)
                                          context->buffer->len, &config);
       if (status == VP8_STATUS_OK)
         {
-          if (context->prepare_func)
-            context->prepare_func (pb, NULL, context->user_data);
-
-          g_clear_object (&pb);
+          if (context->update_func)
+            context->update_func (pb, 0, 0, context->width, context->height, context->user_data);
 
           ret = TRUE;
         }
@@ -198,6 +201,8 @@ stop_load (gpointer data, GError **error)
         g_set_error (error, GDK_PIXBUF_ERROR, GDK_PIXBUF_ERROR_FAILED,
                           "WebP decoder failed with VP8 status code: %d", status);
       }
+
+      g_clear_object (&pb);
     }
 
   if (context->buffer)

Thanks,

[Safari77]

It looks my webp-pixbuf-loader patch in aruiz/webp-pixbuf-loader#73 doesn't fix this geeqie issue. After several try-and-errors, it looks geeqie assumes:

• PixbufModulePreparedFunc should be called after pixbuf is prepared and before loaded data is copied into the pixbuf
• PixbufModuleUpdatedFunc should be called after loaded data is copied into the pixbuf

My patch in aruiz/webp-pixbuf-loader#73 calls PixbufModulePreparedFunc after loaded data is decoded into the pixbuf so it doesn't help the geeqie case. (though I have not checked API documents of GdkPixbuf)

The attached patch against webp-pixbuf-loader 0.2.4 seems to fix geeqie this "webp images show up as black" problem. Could anyone try this? (not sure what's should be done in is_animation case)

diff --git a/io-webp.c b/io-webp.c
index c67e0a9..de2f83a 100644
--- a/io-webp.c
+++ b/io-webp.c
@@ -143,6 +143,8 @@ stop_load (gpointer data, GError **error)
         {
           if (context->prepare_func)
             context->prepare_func (pb, GDK_PIXBUF_ANIMATION (anim), context->user_data);
+          if (context->update_func)
+            context->update_func (pb, 0, 0, context->width, context->height, context->user_data);
           ret = TRUE;
         }
 
@@ -174,6 +176,9 @@ stop_load (gpointer data, GError **error)
           return FALSE;
         }
 
+      if (context->prepare_func)
+        context->prepare_func (pb, NULL, context->user_data);
+
       if (icc_data)
         {
           gdk_pixbuf_set_option (pb, "icc-profile", icc_data);
@@ -187,10 +192,8 @@ stop_load (gpointer data, GError **error)
                                          context->buffer->len, &config);
       if (status == VP8_STATUS_OK)
         {
-          if (context->prepare_func)
-            context->prepare_func (pb, NULL, context->user_data);
-
-          g_clear_object (&pb);
+          if (context->update_func)
+            context->update_func (pb, 0, 0, context->width, context->height, context->user_data);
 
           ret = TRUE;
         }
@@ -198,6 +201,8 @@ stop_load (gpointer data, GError **error)
         g_set_error (error, GDK_PIXBUF_ERROR, GDK_PIXBUF_ERROR_FAILED,
                           "WebP decoder failed with VP8 status code: %d", status);
       }
+
+      g_clear_object (&pb);
     }
 
   if (context->buffer)

Thanks,

This patch fixed the issue for me. Thanks.

[gusnan]

Embedded libraries are not good:

https://wiki.debian.org/UpstreamGuide#No_inclusion_of_third_party_code

If you do include your patched libwebp, please make an option to build without it and use the users local version.
I fully understand that you want to fix the problem (and as soon as possible), but a problem in webp should be solved in webp, and not in geeqie.

[caclark]

Yes, it is the 0.2.2 commit.

[caclark]

The version I have is 0.0.5-5 - which the one installed by default for Ubuntu.

Running gdk-pixbuf-query-loaders, which installed on my computer at;

/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders

will tell you if webp is supported.

[Safari77]

as I said, test program works, which means I have webp support in pixbuf.
webp is enabled in geeqie Preferences > File types.

[caclark]

Is webp in the list in Edit/Preferences/Advanced/Usable File Types?

Is the black background the value you have set in Edit/Preferences/Image/Appearance/Border Color?

[Safari77]

Yes, webp is in Usable File Types.
I had black as the Border Color. If I change to purple, webp images look like this in full screen:

[caclark]

The problem starts at 0.2.2 of webp-pixbuf-loader - that does not help much as I do not see where the problem is.

[Safari77]

did you attempt git bisect to find the first troublesome commit?

[kullfar]

Any news about this?
I can confirm, 0.2.1 is working well, 0.2.2 and 0.2.4 doesn't work (black screen)

[openemitter]

Can this bug also be fixed on V2.1 by cherry-picking 4b15931?
How far is current master from being considered stable / worthy of a V2.2 release?

[caclark]

Commit 4b15931 does not show webp animations (but webp-pixbuf-loader does).

v2.1 was released in June, so maybe it is too soon for v2,2.

I do not know how the package maintainers feel about issuing v2.1.1 for this problem. @gusnan is the Debian maintainer for Geeqie - maybe he has an opinion.

[caclark]

There is the possibility to include the webp-pixbuf-loader as a meson sub-project.
A sub-project does not include additional code, but uses a link the the additional project.
It is then possible to patch the sub-project to fix this bug, prior to compiling.
Webp animations would then be displayed.

A slight problem is that the webp-pixbuf-loader project has increased the required version of libwebp to 1.3. This has been done because of a vulnerability in libwebp.
That gives a problem for Geeqie, because Geeqie uses GitHub Actions which run on Ubuntu 20.04 and does not have this library version.

It is possibly to patch the webp-pixbuf-loader meson file to use an earlier version. I do not see this as a problem because Geeqie uses libwebp 1.2.4 anyway.

Maybe I will include this in the source anyway - then users who compile from sources or use AppImages will have webp animations.

[gusnan]

@caclark Well, my opinion is - release early, release often. If a new version requires an increased version of libwebp, that's fine - in worst case I cannot build (on stable) with the webp, but packaging is on unstable, and there libraries come (if not at once, then pretty soon depending on the library). We wouldn't want upstreams to avoid features just to make the package build on older library versions to make them easier to backport - It might be fine in some cases to avoid increasing library version requirements, but I fully understand that you'll want new (modern?) features into the program.

[caclark]

@gusnan
Commit 29f5a35 uses https://github.com/aruiz/webp-pixbuf-loader.git as a subproject, and then patches the sources to fix this bug. Animated webp files are displayed also.
It was necessary to mess around with the installation process because Geeqie goes under /usr/local but the pixbuf loader goes under /usr.
This patch can be put in a v2.1.1 release, or not, or whichever....

[caclark]

@gusnan Sorry - I was aware of that paragraph but misinterpreted the words "inside your source archive,"

Commit 69929c6 is yet another attempt. There is an additional option -Dsubprojects=true|false, which defaults to "true".

There will be a problem for people who have loader version 0.24 but who will not use subprojects. Webp images will not be displayed.

The only way to fix this (other than the loader source being updated) is to include the image-load-wepp.cc source again - that just gets more complicated to include use of that as an option. I can do that if necessary.

[caclark]

The webp loader:
https://github.com/aruiz/webp-pixbuf-loader
is still the sticking point.

Individual users can get webp images (but not animated) displayed via the external preview option in Edit/Preferences/Advanced.

e.g. Using ImageMagick's convert or mogrify.

[mina86]

FYI, Eye of GNOME (which, based on Debian bug report, is using webp-pixbuf-loader) can display webp images. Perhaps looking at its source code can be helpful.

[caclark]

Fixed in commit b765d90