GNOME Bugzilla – Bug 734378
Image manipulation (scale,rotate) may cause vertical image artefacts
Last modified: 2015-05-23 20:27:11 UTC
Created attachment 282737 [details] Image with visible artefacts (two vertical lines) Hi, For about month or so development version of gimp (2.9) usually, when using rotate tool, or scaling tool with nohalo or lohalo algorithm produces artefacts like in attached example. No matter if I work with 8,16,32,64 precession (both integer and float). Scaling with cubic is always fine. I'm working on up2date git compiled source. If you need any more information, tests please let me know.
Nothing has changed in GIMP here, but the GEGL samplers have seen cleanups.
That's what I've also thought - but I wanted to start from a top level, since I'm not fully aware of exact Gimp design/layers. Anyway, for me, it makes Gimp development release unusable - since I can live with cubic scaler, but I can't "change" rotate algorithm and it produces artefacts almost all the time. So I'm much willing to help solve the problem :)
So you are seeing these artifacts for rotating with *all* sampling methods, not just for nohalo and lohalo?
Created attachment 283143 [details] NoHalo rotation errors
Dah, my bad - sorry I was even not aware I could choose rotating sampling method also like in scaling. Cubic seems to be fine (I need do some more tests) - I've attached new sample with NoHalo rotation errors.
I'm having artifacts when scaling images of up to 60 x 60px with Lo or Nohalo too. Steps to reproduce: 1. Create a 60x60 image, 2. Fill the background layer with some color, 3. Add an alpha channel to the layer, to better see the artifact, 3. Scale up or down with one of the *Halo algorithms And witness the 'erase color' (transparency if you added an alpha channel) fill up part of the image.
*** Bug 735071 has been marked as a duplicate of this bug. ***
(In reply to Adrian Siemieniak from comment #0) > Created attachment 282737 [details] > Image with visible artefacts (two vertical lines) > For about month or so development version of gimp (2.9) usually, when using > rotate tool, or scaling tool with nohalo or lohalo algorithm produces > artefacts like in attached example. I've seen the same artifacts with nohalo (haven't tried lohalo). Cubic is fine. Also sometimes even when the rest of the image is fine, with nohalo there seems to be a blank row/column around the very edge of the image.
I just want to mention, that this bug is still present in current (8.04.2015) git gegl+gimp version - if anyone wonders ;)
Created attachment 302888 [details] jpeg showing error from current git, no error from git circa Jan 2014 I did "git checkout" to get babl/GEGL/GIMP back to around January 2014. For the one image that I've tested so far, rescaling using the Jan. 2014 versions of babl/GEGL/GIMP didn't produce a scaling error for nohalo. But the current version produced a scaling error, a sort of rip close to the right edge of the image. Scaling down with nohalo often produces a small rip close to the right edge, but the rest of the image looks fine. And sometimes there are other patterns randomly located throughout the image.
to add, yet another, unproductive comment to this bug which hasn't been closed, it still exists, people are welcome to try fixing the improved caching for samplers and the interactions the nohalo/lohalo samplers have with that caching.
Hmm, I was hoping to zero in on when the bug was introduced. I believe the process is call "bisecting". If you already know when and where the bug was introduced, why haven't you reverted the affected code to that point? The nohalo scaling algorithm is a truly excellent algorithm. It seems a shame to not be able to use it without maintaining a special babl/GEGL/GIMP prefix just for nohalo scaling.
*** Bug 743102 has been marked as a duplicate of this bug. ***
There is no single commit to revert, it is the nohalo/lohalo code not being able to keep up with improvement/changes to other parts of the code due to premature optimizations. The regressions were introduced either by changes to how the caching happens in the core caching infrastructure used by all resamplers, which also was changed by the addition of mipmap processing providing fast previews for LARGE images. I did my best in fixing things in lohalo/nohalo; as well as have alerted the author of lohalo/nohalo to the regressions. The *halo code has many premature optimizations making refactoring and reading difficult, there still code due to such optimizations which should be deleted/cleaned up even in gegl/operations/transform/transform-core.c The problem might be as simple as understanding what the actual needs of lohalo/nohalo are for available input pixels.
(In reply to Øyvind Kolås from comment #14) > There is no single commit to revert, it is the nohalo/lohalo code not being > able to keep up with improvement/changes to other parts of the code due to > premature optimizations. > > The regressions were introduced either by changes to how the caching happens > in the core caching infrastructure used by all resamplers, which also was > changed by the addition of mipmap processing providing fast previews for > LARGE images. > > I did my best in fixing things in lohalo/nohalo; as well as have alerted the > author of lohalo/nohalo to the regressions. The *halo code has many > premature optimizations making refactoring and reading difficult, there > still code due to such optimizations which should be deleted/cleaned up even > in gegl/operations/transform/transform-core.c > > The problem might be as simple as understanding what the actual needs of > lohalo/nohalo are for available input pixels. Hmm, all the GIMP "Tools/GEGL Operation" "percentile" NR algorithms (box percentile, disc percentile, etc) have been giving wrong results - similar to the *halo issues but a lot worse - for a long time now, but I don't know when the problem started. In the copy of babl/GEGL/GIMP that I reverted to January 2014, the percentile operations worked just fine. Is this perhaps related to the same issues that affect the lohalo/nohalo code? Or should I file a separate bug report with GEGL? or GIMP?
If I ever need any of those ops, I'll rewrite them, rather than let them bitrot where you get confused by them. commit 75b263aaa1b578eaad90f26a48d7511836336e0a Author: Øyvind Kolås <pippin@gimp.org> Date: Mon May 4 16:07:36 2015 -0400 remove broken ops from workshop Too many users do not understand the purpose of the workshop, a place to kee ops that are likely to bitrot - but might be useful for others, pending the release I am removing these remnants of experiments I was doing related to t development of the STRESS family of algorithms.
(In reply to Øyvind Kolås from comment #14) > There is no single commit to revert, it is the nohalo/lohalo code not being > able to keep up with improvement/changes to other parts of the code due to > premature optimizations. > > The regressions were introduced either by changes to how the caching happens > in the core caching infrastructure used by all resamplers, which also was > changed by the addition of mipmap processing providing fast previews for > LARGE images. > > I did my best in fixing things in lohalo/nohalo; as well as have alerted the > author of lohalo/nohalo to the regressions. The *halo code has many > premature optimizations making refactoring and reading difficult, there > still code due to such optimizations which should be deleted/cleaned up even > in gegl/operations/transform/transform-core.c > > The problem might be as simple as understanding what the actual needs of > lohalo/nohalo are for available input pixels. The problem is here: width is estimated first (1): https://git.gnome.org/browse/gegl/tree/gegl/buffer/gegl-sampler.c#n285 then it is used to compute how much to displace the rectangle with respect to the requested rectangle (2): https://git.gnome.org/browse/gegl/tree/gegl/buffer/gegl-sampler.c#n303 and finally it is clipped to the max allowed width (3): https://git.gnome.org/browse/gegl/tree/gegl/buffer/gegl-sampler.c#n326 but that results in possibly having displaced the rect too much in (2) Basically you cannot distribute the excess to the left or right until you're sure there is an excess and how much it is.
(In reply to Øyvind Kolås from comment #16) > If I ever need any of those ops, I'll rewrite them, rather than let them > bitrot where you get confused by them. I was under the impression that the purpose of the GEGL workshop was so GIMP users willing to work with experimental code could test new algorithms that might eventually be moved out of the workshop and made available for use by all GIMP users. Please correct my impression if it's not accurate. The percentile noise reduction algorithms are pretty nice, especially for certain artsy purposes. It seems a shame to shelve them. I hope they are not permanently gone. > In the copy of babl/GEGL/GIMP that I reverted to January 2014, the percentile > operations worked just fine. Is this perhaps related to the same issues that > affect the lohalo/nohalo code? Or should I file a separate bug report with > GEGL? or GIMP? I reset babl/GEGL/GIMP back to approximately June 1, 2014, at which point nohalo did work, but the percentile functions still did not work. So perhaps the problem with the percentile functions has nothing to do with what keeps nohalo from working? That's what I was trying to ask before, could the two issues be linked? Or are there two separate issues, in which case filing a separate bug report might have been appropriate?
This is hopefully fixed by a simplification of the caching infrastructure of the samplers, please re-open this bug if the issue still exists. commit 68d0d1e6fa9926f4cd8f3f3df3510edf31c1b9da Author: Øyvind Kolås <pippin@gimp.org> Date: Sat May 23 21:31:32 2015 +0200 buffer: make _gegl_sampler_compute_rectangle simpler and dumber To fix rendering bugs for nohalo/lohalo and possibly other samplers.