GNOME Bugzilla – Bug 97433
Random pixel changes
Last modified: 2003-04-30 12:50:58 UTC
When I try to change the color of individual pixels using the pencil ( with the smallest *point*) the pixel may or may not actually change; sometimes, actually quite often, the pixels are changed in a seemingly random order, substituting the surrounding pixels instead of the one that I clicked on (if I drag the pencil, then blocks of pixels are randomly changed). This also happens when using the eraser tool. It is not an actual problem with The Gimp because if I minimise, then restore the graphic's window then the actual changes made are seen rather than the *apparent* changes as seen when working on the graphic. It would seem then that the problem is a rendering one rather than a bug in The Gimp itself. I have the exact same problem on my Toshiba laptop (also with Mandrake 9.0) - so it's not a problem with the video card - but never experienced it before using Mandrake 8.2 on either computer.
Do you see this problem when you work at the 1:1 zoom factor, or only at higher zoom levels? Also, does it happen with RGB images without alpha channel (no transparency) or only if the image has an alpha channel? This may be a display problem similar to bug #99672.
I suspect that this may be connected to the fact that when you click in a pixel, you actually get fractional co-ordinates. So if the brush is 1x1, it'll draw like this... +---+---+---+ | | | | | #|## | | +---+---+---+ | #|*# | | | #|## | | +---+---+---+ I click on *... all the partial pixels # are within the brush radius, so all get coloured, leaving 4 gray pixels instead of 1 black one This is a guess, given similar issues that we've seen before (see the "thin lines" bug reports). Why this corrects itself after a refresh, I don't know. That would suggest that the drawing gets done correctly, as someone said. Anyway, it's just some food for thought... Cheers, Dave.
Created attachment 12798 [details] Rendering distortion screenshot
I think that it is indeed related to bug #99672. it would seem to be a rendering problem. Try this: Open a random graphic, choose any magnification, then dag an open window (i.e. the 'Brush Selection' one) the window of the graphic. Play around a little and you will see a one pixel distortion (see attatched screenshot). I re-did the origional problem by taking the 'pencil' (on the smallest point) using white, opened a .jpg (RGB), increased the mag to 1600, then proceeded to 'play' in a corner where there was a very dark blue area. As I dragged the pencil around the pixels were changed to white ok. but then the pixels started to change, not so much in a random manner but rather I could move the pencil back and forth (I suppose it was one pixel's worth) and watch the pixels about 3 'squares' change alternately between the white of the pencil and the dark blue of the graphic - kind of like "now you see me now you don't", The Gimp seemingly not 'remembering' that the pixels were already changed to white by the pencil. Any of the above are simply 'corrected' by pressing the 'plus' or 'minus' keys - the 'rendering is then shown as it should be.
Created attachment 12799 [details] Rendering distortion sreenshot
I can reproduce the bug described by Nigel using Gimp 1.2.3 (mandrake package gimp-1.2.3-17mdk) on my desktop-PC or my laptop (both Mandrake 9.0 systems). If you select the "pencil" tool, zoom a picture in and draw a pixel sometimes the pixel itself and the pixels around it change in a not wanted way (they seem to shift or something like that). I have made 2 screenshots to show what I mean. On the first you can see a red point on the picture. I tried to use the pencil to change the color of this point to blue (as the background). The second screenshot shows the result. It seems that this doesn't happen with the pencil-tool only but with other tools (like paintbrush) as well.
Created attachment 13003 [details] Picture before painting a blue pixel on the red point
Created attachment 13004 [details] Picture after trying to paint a blue pixel on the red point
This looks like a duplicate of bug #109933 and bug #111468.
*** This bug has been marked as a duplicate of 109933 ***