GNOME Bugzilla – Bug 673729
tiff plug in not working 2.8.0-RC1 windows install
Last modified: 2013-12-08 13:36:01 UTC
I can not open or save tiff files as the plugin will not write or read the files.These same files work fine on GIMP 2.7.5 and 2.6.12.
I think, it's a matter of libtiff. I got the same problem, but the code in 2.7.5 and 2.8.0 RC1 didn't change. I tried the older libtiff-3(.dll) and renamed it to libtiff-5(.dll). the error is gone. Maybe you also have a mixture of libtiff libraries?
*** Bug 674190 has been marked as a duplicate of this bug. ***
*** Bug 673798 has been marked as a duplicate of this bug. ***
I also have this bug.
(In reply to comment #1) > I think, it's a matter of libtiff. > I got the same problem, but the code in 2.7.5 and 2.8.0 RC1 didn't change. > I tried the older libtiff-3(.dll) and renamed it to libtiff-5(.dll). > the error is gone. Maybe you also have a mixture of libtiff libraries? I can also confirm that this method works!
Created attachment 213224 [details] [review] TIFF load/save with libtiff-5.dll
There seems to be a problem opening/saving files in libtiff-5 by file descriptor, at least in win32. With the patch attached, TIFF-files are opened/saved with libtiff-5.dll
Does that work for files and directories with special characters - äöüß, chinese, japanese, ... - too?
Will this work when the path contains non-ASCII characters - specifically, try naming a file ★.tif (copy-and-paste the character; I chose this one because it almost certainly isn't in your ANSI codepage) and opening it.
I think this was an incompatible change in libtiff, see: http://bugzilla.maptools.org/show_bug.cgi?id=1941 To be able to im/export tiff files on Windows I had to configure and build tiff-4.0.1 with ac_cv_header_windows_h=no ../tiff*/configure --host=x86_64-w64-mingw32 ... ac_cv_header_windows_h=no this forces the usage of tif_unix.c instead of tif_win32.c and probably produces a libtiff incompatible with the rest of the world. But TIFFFdOpen in tif_win32.c does not expect a libc file descriptor, but a win32 HANDLE converted to int. One solution could be to get the handle from the file descriptor with _get_osfhandle, but since a HANDLE is a pointer I fear that on 64 bits, it is truncated in the call to TIFFFdOpen Another solution would be (#ifdef G_OS_WIN32) to use TIFFFOpenW in the plug-ins after converting the filename with g_utf8_to_utf16.
No, the patch does not work for filenames wuth non-ascii-characters.
*** Bug 672469 has been marked as a duplicate of this bug. ***
I made a new patch. With this one, gimp loads/saves also unicode tiff files (also the ★.tif) with libtiff-5. tested on Win 7 64Bit and Win XP 32Bit
Created attachment 214887 [details] [review] load/save unicode named tiff with libtiff-5
Isn't it possible to do this without that much Windows-specific code?
Don't think so, but I'm no very expert. Libtiff-5 has a special win_32 code, which is used, when compiled in a windows environment. I didn't want to compile libtiff so I had to deal with in the plug-in. In windows environment, libtiff uses windows file handle to open with TIFFFdOpen, and windows file handles are completely different to posix file descriptors, which is created by g_open. So I had to get a file handle. Windows uses wide-character unicode, glib uses multibyte unicode, so the filename has to be converted. I'm no expert, I just want to help - sorry.
This sounds entirely reasonable, but I'd like a review from our windows experts before we push this.
*** Bug 674196 has been marked as a duplicate of this bug. ***
Created attachment 215262 [details] [review] proposed patch I waited to attach a patch here because I wanted to test it. The problem is that in tif_win32.c all possible code paths (TIFFOpen, TIFFOpenW, TIFFFdOpen) truncate a HANDLE to an int and then reassign the int to a HANDLE, and even though this could be problematic on 64 bit, it doesn't seem to be in practice. Obviously the correct solution would be to fix libtiff. I reduced the Windows-specific code using glib's string conversion utilities and TIFFOpenW, that is available from both tif_win32.c and tif_unix.c. I tested the patch, with filenames containing non ASCII-characters, on Windows. One thing I noticed that is still wrong is that if you try to export as a tiff with JPEG compression, a RGBA image (with alpha channels), it fails, but creates a file (8 bytes long) that is saved in the history and then trying to reload it, clearly fails. Probably, when exporting an image RGBA, JPEG compression should be disabled as it is for Fax CCITT Gr. 3 and 4.
Fixed in master and gimp-2-8. Many thanks to Hartmut for finding out the bug and for the patches contributed. commit 0ba99a05ff162a6894686035398b0a82a348a5d7 Author: Massimo Valentini <mvalentini@src.gnome.org> Date: Sat Jun 9 15:36:35 2012 +0200 Bug 673729: tiff plug in not working 2.8.0-RC1 windows install implement win32 filename Unicode management in the plug-ins to work-around a problem in libtiff TIFFFdOpen. Based on a patch from Hartmut Kuhse.