GNOME Bugzilla – Bug 139343
RLE compressed TGA is saved properly yet is not loaded that way
Last modified: 2004-06-15 07:57:06 UTC
I am geting lot's of random stripes aligned ins strange patterns. I have tried removing all the instances of zlib.dll from my system and reinstalling GIMP yet it did not work.
I can confirm that (on win2000).
And as the title already suggests: the TGA file seems to be ok, since I can read it back with ImageMagick.
I can't reproduce it here on XP. Can someone please provide more information about the kind of image that triggers the problem (indexed/rgb/gray, alpha/alphaless, noisy/flat, size, number of colors...) or even better, attach a (preferably small) failing image?
Created attachment 26499 [details] Image to reproduce problem Sample image to reproduce bug
This is a PNG file...
I can open the png successfully ... so i am attaching another tga.
Could you attach the TGA to this bug, plus a screenshot showing the stripes? I don't see anything strange, btw...
Created attachment 26507 [details] TGA gimp can't load Hope i am modyfying the right bug
Created attachment 26508 [details] The result The rsult i get after opening the tga
Michael: I just added the sample png file which I used to save as .tga and then tried to open again. Probably any example will do. For me that caused the same strange pattern as the file that Ignas added. Can anyone check in the meantime if this is a windows-only problem?
I can't reproduce this problem with current CVS on WinXP.
Same here. I can also add that the tga plug-in is valgrind-clean on Linux with that image. Could this be somehow specific to Windows 2000? Can the reporter specify which Windows version he's using? (the OS details field of Bugzilla is gone)
Confirmed Win2K , fresh gtk+-2.2.4-20040124-setup and gimp-2.0.0-i586-setup, same on XP. Linux version works flawlessly.
My friends computer Win2K - no previous GTK or GIMP installations (I thought that various alpha instalations might be the cause of the bug) reproduced the bug successfully. Maybe anyone who is not experiencing the bug could post the plugin binary in here ? I could check whether there is something wrong with the test systems or the plugin in the installer.
I get this problem on windows 98. Same exact symptoms, saved image with RLE compression and it loads in other programs (Blender) but will not load back in Gimp. Works fine with RLE turned off. Using Gimp 2.0.0 from the windows packages.
I have tried gimp 2.0 pre1 and 2.0 pre2 both versions load tga properly, yet 2.0 pre4 has the bug too. I guess someone made some bug when porting tga plugin from the old plugin API to the new one. I have tried using pre2 tga plugin with 2.0 and it said that the plugin is using deprecated api (or interface) can't recall exactly. Lot's of my images are stored as lzw compressed tga so i would be really glad if someone would post a recompiled working version of the plugin as a quick fix. Michael Schumacher told he's got a working version of the plugin and i guess it should work with the current Gimp.
This is just wild guessing. Why don't you just look at the CVS history of the file: cvs diff -r GIMP_1_3_24 -r GIMP_2_0_0 plug-ins/common/tga.c You will notice that there are two tiny changes between 2.0pre2 and 2.0.0. None of these changes can possibly cause the problem.
After looking at the bytes of the .png file showing the messed up image, I think I understand what the problem must be, although not having access to Windows I can't test it. The plug-in code contains the following at line 670: head = getc (fp); if (head == EOF) { return EOF; } However the code that called this does not check whether an EOF was returned, it just keeps going blithely on. Now it happens that the first data byte in your RLE-encoded .tga file is a 255. It also happens that EOF is generally defined as -1, which is equal to 255 if you view it as a signed char. So my belief is that the implementation of getc on the offending systems is returning -1 rather than 255, or that something similar is going on. This would completely account for the way the file looks. (Note that for this type of Targa file, the beginning of the file corresponds to the lower left corner of the image.) In any case, it becomes important to know how the programs were compiled for the people who are having problems.
Created attachment 26713 [details] Working gimp-2.0.0 windows plugin version I have managed to compile the plugin myself, it is working now yet it displays a console window while loading, saving or generating a thumbnail (sorry it's the best i could do). Still it's better than being unable to load rle Targas at all.
Created attachment 26716 [details] Working gimp-2.0.0 windows plugin version (no console) Fixed the bug with the console apearing
IMHO it would have been better to put the plug-in on your website than attaching it to bugzilla... However, the fact that it is working seems to indicate a bug in the build environment used to create the GIMP version that comes in the installers. BTW, how did you compile the plug-in? The console window is an indication that it might not have been compiled as an windows app, but the Makefiles that come with GIMP take care of this.
I tried using gimptool-2.0 yet pkg-config was not working properly so i had to rewrite the compilation string myself and i forgot to add -mwindows the first time. Sorry for attaching the plug-in in here. Now you can get it in here too: http://www.voriukai.net/~igrovod/downloads/tga.exe http://www.mif.vu.lt/~igmi1451/tga.exe
This clearly indicates that the problem is not in the GIMP code but in the environment used to build the Win32 executable. Is Jernej aware of this problem? If not, someone please tell him. Closing this report as NOTGNOME.
The problem is caused by a bug in the implementation of getc() in version 3.2 of Mingw-runtime; see bug #138178 for more info.
whenever I try to download it the download page closes out
Your download problems are not related to this bug-report. Closing the report again.
*** Bug 144374 has been marked as a duplicate of this bug. ***