After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 389072 - Improve brush subsampling
Improve brush subsampling
Status: RESOLVED OBSOLETE
Product: GIMP
Classification: Other
Component: General
git master
Other All
: Normal enhancement
: ---
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2006-12-24 00:42 UTC by david gowers
Modified: 2018-05-24 12:06 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Show the rare bug occurring when SUBSAMPLE > 4 (8.69 KB, image/png)
2006-12-24 00:53 UTC, david gowers
Details
compare different subsampling settings (98.57 KB, image/png)
2006-12-24 00:55 UTC, david gowers
Details

Description david gowers 2006-12-24 00:42:21 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.
Comment 1 david gowers 2006-12-24 00:53:33 UTC
Created attachment 78843 [details]
Show the rare bug occurring when SUBSAMPLE > 4

I just tested with SUBSAMPLE = 3 Threshold = 0.100; that worked OK.
Comment 2 david gowers 2006-12-24 00:55:01 UTC
Created attachment 78844 [details]
compare different subsampling settings

(also includes a 'benchmark' version stroked via vectors with width=1.0)
Comment 3 david gowers 2006-12-24 05:59:31 UTC
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
Comment 4 Sven Neumann 2006-12-24 11:39:07 UTC
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.
Comment 5 david gowers 2006-12-25 09:31:48 UTC
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.
Comment 6 Michael Schumacher 2013-03-30 23:07:47 UTC
We should probably check if this is still an issue.
Comment 7 Casey Stanley 2013-09-02 23:46:19 UTC
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.
Comment 8 GNOME Infrastructure Team 2018-05-24 12:06:38 UTC
-- 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.