> > You know, I actually reread, and I find the thread highly confusing. > I'll try to help explain, if it's not going to upset you... > It starts with the hardness-parameter in the pencil tool, then goes on > to how paintbrush is so similiar to the pencil tool, how the pencil tool > can get removed, then pat getting confused that "hardness" would be the > relevant property here (hint: it isn't) I know, but from the user-perspective, it could be. However, I think it should be a checkbox instead, because it would be annoying to have to go to 99% to get an anti-aliased edge. :) then brush presets and then > Americo (wrongly) claiming, that (currently!) "anti-aliasing" is the unique > difference between pencil and paintbrush. Maybe it's not, but you didn't explain your position very well, instead suggesting that I try to use the brush tool to get the effect (which doesn't work). When I said it would not give the same results you thought it would, you got tetchy. Don't get "tetchy". This is after you seemed to understand what I was saying, which makes it even more confusing. Why get tetchy at all? :) > Which I disputed. Then you > proposed that a "pixel brush" (whatever that means - I read that as "a > 1x1 hard-edged brush) would be an adequate replacement for the pencil > tool (And no, a brush alone can't solve this problem). > Which I have explained 5 times now that this is only if it includes the (topic of this thread) proposed no anti-aliasing checkbox. Yet, I'm not getting tetchy back at you (except the once as an example of why we shouldn't). :) In fact, I'll be happy to repeat that however many times you like, in as many ways as I can think of: There should be no difference between a one-pixel brush (1x1, yes you are correct) and the current "snapping" behaviour. With other brushes, yes maybe. But not with that 1px brush. And now I am the one to blame for getting tetchy when all those weird > terms are thrown around and everybody seems to talk about different > things? > When I get frustrated to the point of becoming irritable, I generally back off, and take a break to think about the problem a bit more. We all get tetchy. It's important not to stay tetchy though for the purpose of collaboration. > You are describing the behaviour as "snapping". It's not snapping, it's > > just not averaging. > > The effect is the same, however. One click of the mouse, one pixel is > > coloured in. It does not matter what you call it. > > Ah, "averaging". Another term that yet has not been used in this thread > (I think). > Okay, then "thresholding". I think that's one you mentioned, use that instead. :) What does it mean to "average" a pixel brush on a drawable? > It could mean lots of things. For simplicity, let's take the Pencil tool as an example: 1. A fuzzy pencil brush could take the threshold you mentioned and apply a pixel-dithering algorithm across it to create a gradient, spanning that threshold simulates alpha across the threshold rather than actually using alpha. 2. A fuzzy pencil brush actually use alpha and use it across that threshold, since, as you mentioned it's not only using aliasing algorithm, it's applying a threshold to see which pixels are turned on or "snapped". 3. It could do a combination of 1 and 2. The question applies to what people use the Pencil tool for. So far there's two things that I can see from the list: 1. for making pixel art 2. for making pixel-perfect rectangles and horizontal and vertical lines. I'm willing to consider more, that's just what's been mentioned so far, and provides the context for which I'm basing possible ui changes (iff we decide it satisfies or improves the tools or the GIMP UI). Yes, that's "if and only if". Not a typo. :) > And why is it not snapping when the pixel grids of the bŕush and the > drawable keep getting aligned to pixel borders? > That's what anti-aliasing does... If you don't click directly in the center of a pixel, it will average 1 pixels worth of colour across four pixels, weighted by the click's proximity to the exact center of each of those four pixels. You turn anti-aliasing off, the whole pixel's worth of colour will be dumped into the pixel you clicked on. If you happen to click directly inbetween two or four pixels, nearest neighbor algorithm will pick one of them for you. It will not fill in two pixels or four pixels. If it did so, it would produce chunky lines which are more than one-px wide/thick. > The fun fact is, that neither the paintbrush nor the pencil tool "draw > lines" in the sense of a line in inkscape. They just repeatedly stamp > the brush onto the canvas (or an intermediate canvas for non-incremental > painting) at certain coordinates. "Anti-Aliasing" in the sense of > "rendering a vector polygon onto pixels cairo-style" does not apply here. > Another fun fact is that it doesn't matter. :) Correct if wrong, but no matter whether you click, click and drag, or click, then shift-click elsewhere to draw lines, GIMP has to decide where to put all the pixels. It either anti-aliases the results or it doesn't. > So what are we talking about when we're talking about "anti-aliasing" > for the paint brush? Just the resampling that happens when the > pixel-grids of brush and the drawable don't align properly? > Sure, if you like. Keep in mint though that anti-aliasing applies to image transformations and painting on the canvas as well. Here are a few excellent articles which covers the different kinds and applications: https://en.wikipedia.org/wiki/Spatial_anti-aliasing https://en.wikipedia.org/wiki/Supersampling https://en.wikipedia.org/wiki/Multisample_anti-aliasing -C > > Bye, > Simon > > -- > simon@xxxxxxxx http://simon.budig.de/ > _______________________________________________ > gimp-developer-list mailing list > List address: gimp-developer-list@xxxxxxxxx > List membership: > https://mail.gnome.org/mailman/listinfo/gimp-developer-list > List archives: https://mail.gnome.org/archives/gimp-developer-list > _______________________________________________ gimp-developer-list mailing list List address: gimp-developer-list@xxxxxxxxx List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
