GNOME Bugzilla – Bug 791514
Cannot export to webp file
Last modified: 2017-12-24 18:04:35 UTC
Using the current 2.9.6 development version, when I try to export an image to a webp file, it simply fails, always with the message like: "Saving 'G:\Temp\test.webp' failed: Unable to open 'G:\Temp\test.webp' for writing" Saving to the same location as eg. a png file works just fine.
Is it any webp image, or with some specific options? In any case, I can't reproduce this on Linux. Maybe there are issues with g_fopen() (the function it apparently fails on) in Windows. Of course, I would also assume some permission issues, but since you say it works with other formats in the same directory, that seems less likely. Anyone to reproduce?
It makes no difference what kind of image (resolution, or otherwise) I try to save, or where. It always gives the same message "unable to open ... for writing". Saving to any other format (such as png or jpeg) works just fine. I'm guessing this problem is specific to the Windows version.
I am assuming you don't know how to compile GIMP for Windows, do you? I have added slightly more detailed error handling so with last master code, hopefully it will tell a little more information on the problem. If you can't build yourself the git code, maybe I can try and cross-compile just the webp plugin binary (will be untested by myself since I don't have a Windows available right now). I assume your Windows is 64-bit?
Other plug-ins don't use wb+ for the g_fopen mode, just wb - that's the only obvious difference I see.
(In reply to Michael Schumacher from comment #4) > Other plug-ins don't use wb+ for the g_fopen mode, just wb - that's the only > obvious difference I see. Yes I saw this and wondered about whether this specific mode may not be supported on win32 fopen. I even checked win32 fopen() doc, they have w+ and b flags. I don't see specific examples of the combination "wb+" but I don't see why it would not work (I don't see it in the Linux man either, yet it exists). But maybe this truncate/read/write/binary mode indeed does not exist in Windows. Unfortunately it seems this '+' is necessary in current code since I see a fread() done on outfile a few lines below, so just "wb" would not do (well I haven't checked the code in details for what it does precisely and why). If that is really the issue, workarounds can be found of course, but let's make sure first since it would make the code more complicated.
I suppose I could try some debug plugin if somebody compiles a version for this. (I must say I'm surprised no developer is testing the program on Windows.)
> I suppose I could try some debug plugin if somebody compiles a version for this. Ok. So I cross-compiled the plug-in. As usual, no warranty it will work, no warranty it won't make your computer explode, blablabla… No warranty of anything, at all! :P This being said, this is basically the same code as in 2.9.8 but with some logs added on the failing function. So I still expect the webp export to fail the same way, except that it should hopefully give slightly more detailed information in the error output. https://framadrop.org/r/YNnhTEfUAw#YcFpKwR8vRsORNhU1JVt1JWtchxlpOfUARmIjmdHWNI= On this link, you'll get a file called file-webp.exe for Windows 64-bit. There should be a file with the same name in your current installation of GIMP. Just replace it with this one, try again and tell us the new error output. Thanks! :-) > (I must say I'm surprised no developer is testing the program on Windows.) So are we! Or to be more accurate: with all the people who use GIMP on Windows, we are surprised to have so few Windows developers willing to contribute. This is Free Software and people are welcome to contribute code, time, design, etc. to improve it. We have actually a few recurrent contributors using Windows, but most of us, and in particular the most active ones, all use Linux. I sometimes take some of my time to set up a virtual machine to test things on Windows, but this is really not my favorite activity of the day, and I would appreciate that developers who want a working GIMP on Windows contribute. :-) Same for macOS which is not that much different in term of lacking of developers.
There's something wrong with that plugin executable. When I replaced the original with it, the webp format disappeared from the supported save file formats in gimp (it doesn't appear in the list of supported formats, and specifying an output file name with the .webp suffix gives an error about an unknown file extension. It may be indicative that the original file-webp.exe is over 500kB big, while that version is only 40kB (although this might have something to do with debugging information. I hope that if that's the case, such information isn't in the final version, as it makes the executable files really large.)
Hmmm… You are sure you use Windows 64-bit, and not 32-bit, are you? Also I have not really used Windows for a long time, and I think that there is no need to change properties of a file to make it executable. But maybe things changed since. Maybe the file properties have to be updated in order for the file to be executed? Maybe something about a dependency lib which was different from our official build (don't you have any error message appearing saying the plug-in crashed at GIMP startup for some reason?). Other than these, I don't know. Maybe I just fucked up though that's weird because I have cross-compiled GIMP for Windows dozens of time. And `file` tells me: > $ file file-webp.exe > file-webp.exe: PE32+ executable (console) x86-64 (stripped to external PDB), for MS Windows If none of these are helpful, then it will require someone to build and test directly our code in Windows. :-/
Argh ok, I just understood. In the build file, there is a ./plug-ins/file-webp/file-webp.exe but also ./plug-ins/file-webp/.libs/file-webp.exe. The one which is actually installed is actually the hidden one but I sent the other one. Sorry for the mess. So here for a second attempt. Hopefully the right one: https://framadrop.org/r/T-ap8DWMCa#ZzLHBxi1QyWs1yjeBPC4vpZJ9RH3uEC/AKPVyWBBAmQ= It's indeed a much bigger file.
It just says: Saving 'G:\Temp\test.webp' failed: Unable to open 'G:\Temp\test.webp' for writing: Invalid argument
> Unable to open 'G:\Temp\test.webp' for writing: Invalid argument Well it's not much nor very detailed but probably confirms that the fopen() implementation of win32 probably doesn't support the mode "wb+". I mean, there are only 2 arguments to the function: > g_fopen (filename, "wb+") And the description showed you used simple filenames, all ASCII, etc. I doubt that would be the problem. I guess I will have to have a look for an alternative code not needing "wb+" mode. I put this on my TODO list for 2.10 (i.e. setting for 2.10 blocker).
So I started to implement a more complicated version of the code (opening and closing the same files a few times, sometimes in binary read, sometimes in binary write…), but then I thought that maybe I should first try the "stupid" fix first, which is to try the "w+b" mode. "wb+" and "w+b" are aliases, they are the same. Cf. for instance: https://wiki.sei.cmu.edu/confluence/pages/viewpage.action?pageId=87152174 I even finally decided to fire a Windows VM to test myself and… it worked! Microsoft implementation simply did not define the alternative alias, that's all. The fix is pushed: commit 317f7fa5ca5c47920ea7dbef43b5c6fd6185a9e7 (HEAD -> master, origin/master, origin/HEAD) Author: Jehan <jehan@girinstud.io> Date: Fri Dec 22 19:25:11 2017 +0100 Bug 791514 - Cannot export to webp file. fopen() modes "wb+" and "w+b" are aliases of the same opening mode (truncate/create in binary read/write). But it turns out that Windows implementation does not understand "wb+". The alias "w+b" works fine in my tests. plug-ins/file-webp/file-webp-save.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) ------------------------------------------------- Note: I am closing this report as FIXED since I tested myself as well. But feel free to reopen the bug report if you still have the same issue. If you want to test yourself, here is my updated plug-in cross-built for Win 64-bit: https://framadrop.org/r/Ul1DLuGWpB#X6bs79vRWsLvpnMHVe/e/jiAEXDvmwlUqHmP9wesdZ4= As usual, no warranty, etc. :-)
It seems to work now.