GNOME Bugzilla – Bug 164061
lighten only (layer mode)
Last modified: 2008-01-15 12:45:23 UTC
two layers background foreground mode lighten only the result is: the image with verticals lines of bad colors if apply different mode et return to lighten only the result is bad or ok
Please, add your CPU model and windows version. This is most certainly happening in the acelerated composite routines. Does it happen everytime? Try starting the GIMP from the command line, and add the option: --no-cpu-accel . Check if the problem persists.
window xp pro sp2 dell dimension 8100 intel P4 1,7Mh 256Mo does not happen everytime, but often with --no-cpu-accel: alway OK
Please start GIMP from a terminal and use the --verbose command-line option. It should output a line starting with "Processor instruction sets". Please paste that line here.
Microsoft Windows XP [version 5.1.2600] (C) Copyright 1985-2001 Microsoft Corp. C:\>cd "Program Files"\GIMP-2.2\bin C:\Program Files\GIMP-2.2\bin>gimp-2.2.exe --verbose C:\Program Files\GIMP-2.2\bin> Sorry no msgs, exactly "--verbose" ? (no documentation for debug)!
Try --help, but it will tell you that --verbose is the right option. There certainly is output, please check again.
Sorry, I have just been told that the standard Windows console window doesn't allow graphical applications to provide any output on the console. That is just sick as it makes it rather difficult to investigate this further. I am giving up and decided that I will not any longer respond to bug-reports for the Windows operating system. As a last action, I am reopening this report. The information you gave on processor type should be sufficient for Helvetix to deal with this problem.
This bug is also present on Fedora Core 3 plus Update respective Rawhide with gimp-2.2.2 on x86_64 machines. Using --no-cpu-accel works around the problem as well. I would set OS to "All" (but can't since I'm not the submitter) since it doesn't seem to be limited to one operating system, to me it seems to be limited to a set of CPUs which use different asm implementations which seem to be buggy. Running with --verbose gives these processor instruction sets: Processor instruction sets: +mmx +sse +sse2 -3dnow -altivec -vis I'm a bit baffled about "-3dnow" and checked, but it doesn't seem I forgot a configure option to enable that. Interestingly, it works as designed on 32bit x86 which has the same list of used instructions sets: Processor instruction sets: +mmx +sse +sse2 -3dnow -altivec -vis
Forgot the RH Bugzilla reference: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=145771
Setting OS to All and confirming on the basis of comment #7
-3dnow means that GIMP won't use any 3dnow functions. The reason is simply that noone contributed any 3dnow code yet.
Still happens in 2.2.6.
I'd guess the bad code is in SSE2 - as it is in both pentium IV and Athlon 64 . I do not even know what "SSE" is in chip implementation, let alone SSE2. But it shall be possible to see the code difference in both SSe and SSE2 code. Heck..I am just not familiar with GCC inline assembly sintax, but both SSE and SSE2 code seem to be using register mmx0 before it is loaded with any usefull value. (/me googles ) Wait....here it is! SSe2 uses 128 bit wide xmmN registers, but mmx0 (not xmm0) is loaded before the loop in line 593 of app/composite/gimp-composite-sse2.c asm volatile ("movq %0,%%mm0" : : "m" (*rgba8_alpha_mask_64) : "%mm0") ; I'd guess that changing this line to: asm volatile ("movq %0,%%xmm0" : : "m" (*rgba8_alpha_mask_64 << 64 | *rgba8_alpha_mask_64) : "%xmm0") ; Will fix this bug. Any of you who can reproduce the bug can recompile the GIMP changing this, to check if it gets fixed?
movdqu even. And no need to the << 64 voodoo - the rgba8_alpha_mask_64 is actually defined as two 64 bit quadword making up a 128 bit "octoword" in line 56. So, line 593 should be replaced with: asm volatile ("movdqu %0,%%xmm0" : : "m" (*rgba8_alpha_mask_64) : "%xmm0") ;
Yes, the change from comment #13 fixes it for me on this Opteron.
I was actually hoping for a comment from Helvetix but I've now committed the change anyway (to both branches): 2005-05-06 Sven Neumann <sven@gimp.org> * app/composite/gimp-composite-sse2.c (gimp_composite_lighten_rgba8_rgba8_rgba8_sse2): applied a patch from Joao S. O. Bueno Calligaris that changes the SSE2 code to load the proper register. Fixes bug #164061.
I'm still seeing problems with this in 2.2.9 under SSE2. This isn't the first version I've see these problems, I've just been waiting patiently for them to be fixed. I've worked around the problem currently by commenting out the SSE2 test in app/base/cpu-accel.c around line 188: //if (edx & ARCH_X86_INTEL_FEATURE_XMM2) // caps |= CPU_ACCEL_X86_SSE2; I assume this is forcing my copy of gimp to only use the SSE compositing code and not the SSE2 code. This eliminates the green vertically striped lines I normally get with a layer in Lighten Only composite mode. My /proc/cpuinfo output is: processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 2 model name : Intel(R) Pentium(R) 4 CPU 2.80GHz stepping : 7 cpu MHz : 2826.435 cache size : 512 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid xtpr bogomips : 5603.32
Thanks for the information. Waiting patiently is useless if nobody tells us that a problem exists :-).
Bah, I figured you guys were so good you could read all the users' minds, :-). Naw, actually, I think I saw the bug report on it already and thought it was covered. When I finally saw the bug was marked resolved, but I still had the problem, I spoke up. And yeah, I do see that its been marked resolved for over 5 months. What can I say ? I just don't use/need Lighten Only much and have trained myself to not even try to use it, :-). I did some more testing and figured I'd pass the info on. I'm running SuSE 9.3 with their supplementary GNOME Upgrades, most of the GNOME package version numbers are 2.12. Today I tested SuSE's build of gimp 2.2.9 and was able to reproduce the green stripes. So I tested the same image with the same image edits in my 2.3.5 GIMP build and I don't see the green stripes. I tried several other images to reproduce the problem in 2.3.5, but couldn't. It was easy to reproduce the problem on my system with the SuSE 2.2.9 build. I verified both were running with the cpu optimizations by running them with --verbose, getting: Processor instruction sets: +mmx +sse +sse2 -3dnow -altivec -vis from both the SuSE 2.2.9 and my 2.3.5 build. These tests were run on the same system/cpu as when I posted comment #16 which contains my /proc/cpuinfo output. Oh, and thanks for the effort guys. Even though I'm a developer, I tend to use GIMP quite a bit and find it very useful.
I mean -hmmm -- the problem __was__ the one I found out, and it is hard to think how it could happen in the same layer mode, after correcting that (tehre could be other faulty layer modes). What leave us with: had the patch been committed to the 2.2 branch, or just to HEAD? (/me without a 2.2 tree)
I am going to reopen this bug report because there are still issues, and it isn't good to have a continuing discussion in a FIXED bug report. If the issues turn out to be a result of confusion, easy enough to change back the resolution.
*** Bug 322939 has been marked as a duplicate of this bug. ***
*** Bug 314906 has been marked as a duplicate of this bug. ***
the problem appears for me two. here is a very easy recipie to reproduce the bug: create two monochrome layers: one black, one white. Stack the black one on top and set it's mode to lighten only (both layers visible): the result is an image with vertical green stripes. It should, however, be plain white. The error occurs on my desktop and my laptop (both Win XP Pro). I do not think that it is a hardware problem. Maybe someone can reproduce it on a different platform.
exactly the same bug with 2.2.9 . Original reporter: louis.timmermans@skynet.be (timmermans)
Created attachment 59383 [details] small XCF file for testing a stack of two layers. bottom is a black to white gradient, and top is a fuzzy red ball. Loaded into my gimp, with the top layer set as Lighten Only, green vertical stripes appear. the canvas is tiny to facilitate debugging.
Created attachment 59384 [details] image - how the XCF appears on my machine screen capture of the small XCF showing the problematic green stripes. the xcf test image is tiny - 16x16? - so for the screen capture i zoomed in a lot.
I've been seeing this problem for over a year. hoping it would clear up with updates. now running Fedora Core 4 on a fairly powerful machine. what does verbose gimp have to say? and /proc/cpuinfo? i have a full development system here, so could do some serious debugging with stack traces, whatnot, if someone can say where i should get started hammerhead tcsh> gimp --verbose *xcf & [1] 24681 hammerhead tcsh> INIT: gimp_load_config Parsing '/etc/gimp/2.0/gimprc' Parsing '/home/darenw/.gimp-2.2/gimprc' gimp_composite: use=yes, verbose=no Processor instruction sets: +mmx +sse +sse2 -3dnow -altivec -vis Adding theme 'Small' (/usr/share/gimp/2.0/themes/Small) Adding theme 'Default' (/usr/share/gimp/2.0/themes/Default) Writing '/home/darenw/.gimp-2.2/themerc' INIT: gimp_initialize INIT: gimp_real_initialize INIT: gui_initialize_after_callback INIT: gimp_restore INIT: gui_restore_callback GimpClipboard: writable pixbuf format: image/png GimpClipboard: writable pixbuf format: image/x-icon GimpClipboard: writable pixbuf format: image/bmp GimpClipboard: writable pixbuf format: image/x-bmp GimpClipboard: writable pixbuf format: image/x-MS-bmp GimpClipboard: writable pixbuf format: image/jpeg INIT: gimp_real_restore Starting extension: 'extension_script_fu' INIT: gui_restore_after_callback loading menu '/usr/share/gimp/2.0/menus/toolbox-menu.xml' for /toolbox-menubar loading menu '/usr/share/gimp/2.0/menus/image-menu.xml' for /dummy-menubar loading menu '/usr/share/gimp/2.0/menus/image-menu.xml' for /image-menubar --------------------------------------------- hammerhead tcsh> cat /proc/version Linux version 2.6.14-1.1656_FC4 (bhcompile@tweety.build.redhat.com) (gcc version 4.0.2 20051125 (Red Hat 4.0.2-8)) #1 Thu Jan 5 22:13:22 EST 2006 hammerhead tcsh> hammerhead tcsh> cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 0 model name : Intel(R) Pentium(R) 4 CPU 1700MHz stepping : 10 cpu MHz : 1695.101 cache size : 256 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm bogomips : 3393.80 hammerhead tcsh>
First of all we should probably update the version information of this bug-report. Does this still show up with release 2.2.10? If so, then the version field should be changed appropriately.
(In reply to comment #28) > First of all we should probably update the version information of this > bug-report. Does this still show up with release 2.2.10? If so, then the > version field should be changed appropriately. with 2.2.10 (window xp) test with 'small XCF file for testing' the problem still
I can reproduce this with GIMP 2.2.10, but not with GIMP 2.3.7 on the same Windows XP system.
IIRC I have applied the fix to both branches. But I guess we will have to take a closer look at the source and check if there are any differences between the 2.2 branch and CVS HEAD.
bash> gimp --version GIMP version 2.2.10 i will download the newest 2.3.x - or maybe even get risky and try cvs HEAD... 2.2.10 is the latest, bestest that fedora's package manager (yum) gives us. someone needs to give them a tickle so everyone can enjoy a fixed gimp. our sysadmin here will be interested, as we do a lot of serious image processing and graphics.
Note that 2.3.x are unstable development snapshots. Using them is as risky as using cvs HEAD.
So far nobody seems to have encountered this problem with a recent 2.3.x release. Since 2.4 is fast approaching, it may be time to declare this fixed unless it can be replicated that way -- in the meantime I will set to NEEDINFO.
*** Bug 342376 has been marked as a duplicate of this bug. ***
*** Bug 341018 has been marked as a duplicate of this bug. ***
guys, i have no clue what you are talking about. I have this same problem and im trying to understand what you mean by "running it on verbose" and all that other stuff. How do i fix it, can somebody walk me through it? Do i need to download something? Thanks.
*** Bug 347264 has been marked as a duplicate of this bug. ***
The change mentioned in comment #13 seems to have gone into the stable branch, as I said in comment #15. What is not mentioned at all in this bug report is that Helvetix did another commit for this in the HEAD branch and failed to add a comment here: 2005-05-09 Helvetix Victorinox <helvetix@gimp.org> * app/composite/gimp-composite-sse2.c: Repaired a latent bug in gimp_composite_lighten_rgba8_rgba8_rgba8_sse2 where setting up the alpha masks were not done correctly. A redundant (better?) fix to bug #164061 Use movntq instructions to avoid processor cache pollution. Some adjustments to register allocation specifications. We probably need to backport this change to the stable branch and check if any subsequent changes to the file should also be backported.
Created attachment 71438 [details] [review] the change that probably needs to be backported
This patch appears to apply cleanly in the stable branch but since I don't have hardware with SSE2 instructions, I can't really test it. I would appreciate if someone with access to such hardware could try to reproduce the problem with gimp-2.2, then apply the patch and check if it fixes it.
Ville tested this for us and reported that the change fixes the problem. 2006-08-23 Sven Neumann <sven@gimp.org> Merged a fix from the HEAD branch to fix bug #164061: * app/composite/gimp-composite-sse2.c: Repaired a latent bug in gimp_composite_lighten_rgba8_rgba8_rgba8_sse2 where setting up the alpha masks were not done correctly. Use movntq instructions to avoid processor cache pollution. Some adjustments to register allocation specifications.
*** Bug 354720 has been marked as a duplicate of this bug. ***
*** Bug 358789 has been marked as a duplicate of this bug. ***
*** Bug 382129 has been marked as a duplicate of this bug. ***