GNOME Bugzilla – Bug 389072
Improve brush subsampling
Last modified: 2018-05-24 12:06:38 UTC
The current subsampling has noticeable quality problems at small sizes and with fully hard-edged brushes -- that is, the antialiasing already around the edges of nominally hard-edged brushes disguises the lack of subsampling quality.
GIMP provides less quality than it could, and I think this could be remedied with adaptive behaviour -- depending on the brush size, subsample more or less.
Lets say the maximum is 16x16 -- I've tested various SUBSAMPLE values and THRESHOLD values (see kernelgen) and I think normally you would need no more than this, even for completely hard-edged brushes. Then you could subdivide that, like:
A really huge brush gets at most only 4x4 subsampled versions
A medium sized brush gets 8x8 subsampled versions
A really tiny brush gets all 16x16 subsampled versions.
That's a fairly simple improvement. Another possible might be interpolating between two subsampled brushes during painting -- this would easily double the subsampling quality even if only done as a fast ((A+B) >> 1) 50% mix calculation.
Anyway, before any such improvements can be made,
there is a bug in either tools/kernelgen.c or the subsampled-version-generator in app/paint/gimpbrushcore.c;
It causes 1 of the subsampled versions to be wrong, to have all fully opaque pixels become fully transparent, if SUBSAMPLE <> 4. It seems independent of THRESHOLD value (I've tried several in combination with different SUBSAMPLE values: 0.125, 0.25, 0.33, 0.50; In my opinion, when SUBSAMPLE > 4, 0.33 is the best threshold, that produces a result both crisp and smooth.)
An image showing the bug is attached.
Another image, comparing different subsampling settings used with big and tiny (1px) brushes, is attached too. I concluded SUBSAMPLE = 16, THRESHOLD = 0.33 produces the nicest results, though even SUBSAMPLE = 8 produces a significant improvement in clarity over SUBSAMPLE = 4. I haven't tried SUBSAMPLE = 12; It might be worth trying, later.
Created attachment 78843 [details]
Show the rare bug occurring when SUBSAMPLE > 4
I just tested with SUBSAMPLE = 3 Threshold = 0.100; that worked OK.
Created attachment 78844 [details]
compare different subsampling settings
(also includes a 'benchmark' version stroked via vectors with width=1.0)
note, this may not be a bug.. as long as threshold is low enough it doesn't occur. but it still seems entirely wrong that it should do that.gilgamesh.dnsalias.org:8080/wiki/ohrrpgce/index.php/Special:Recentchanges
Can we please try to concentrate on GIMP 2.4 for now? No one has the time the deal with such changes now. It would help if you could postpone such enhancement requests until after the release.
Certainly, my filing of this request is not meant to indicate anything about when it would be good to implement or even investigate. I simply view bugzilla as a place where worthwhile and actual bug reports or enhancement requests should be filed, when sufficiently well defined, so they don't get lost, forgotten, or mislaid. If there is some particular timing that's best, it should probably be mentioned at www.gimp.org/bugs/
Sorry about the clipboard-junk (?) in my prev comment.
We should probably check if this is still an issue.
Personally I am desperately waiting and wanting this much more than the 16 bits per channel.
Not only is GIMP's current brush subsambling rather poor in comparision to Paint Tool SAI or Photoshop, but it also serverly limits the pressure levels available for a brush's size.
A clearly visual example being with an Intuos3's 1024 levels, a 3 pixel brush will only have 2 pressure levels available (0px,1px,3px), a 5 pixel brush 3 pressure levels, a 7 pixel brush 4 pressure levels and so on.
Even without a tablet, stroking a path with a "Paintbrush" and "Emulate brush dynamics" enabled still clearly shows the limitation.
If there is a concern about speed then an option to adjust the subsampling quality would be nice.
I highly doubt it would have any proformance hit anyway, as i've never had any kind of speed issues even on my old hardware.
-- GitLab Migration Automatic Message --
This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.
You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/227.