RSS/Atom feed Twitter
Site is read-only, email is disabled

Non-incremental painting

This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

11 of 11 messages available
Toggle history

Please log in to manage your subscriptions.

Non-incremental painting Cedric Sodhi 28 Jan 14:33
  Non-incremental painting Michael Natterer 28 Jan 15:07
  Non-incremental painting Alexandre Prokoudine 28 Jan 15:39
   Non-incremental painting Cedric Sodhi 28 Jan 16:51
    Non-incremental painting gespertino@gmail.com 28 Jan 17:21
    Non-incremental painting Richard Gitschlag 28 Jan 17:44
    Non-incremental painting Mukund Sivaraman 28 Jan 18:14
     Non-incremental painting Liam R E Quin 28 Jan 18:57
      Non-incremental painting Mukund Sivaraman 28 Jan 19:38
       Non-incremental painting Liam R E Quin 29 Jan 02:07
  Non-incremental painting Martin Renold 31 Jan 06:27
Cedric Sodhi
2012-01-28 14:33:20 UTC (almost 13 years ago)

Non-incremental painting

As I've been asked, I'll just quote what I already submitted to bugzilla, minus the typos:

I see no use in non-icremental paiting. It appears to exist only because it was easier to implement than normal painting, which does not work properly, as I've filed in at least one other bug report.

Not only should incremental paiting urgently be fixed, as described there, but non-incremental painting, or the option to choose between the two, should be removed as a whole.

If anyone can think of a usecase where that non-intuitive, unpredictable painting mode is actually useful, please prove me wrong.

Until then, I interpret the mere existance of that painting mode as an excuse to not admit one of the most serious flaws in gimp with regard to painting.

To be blunt, as long as there is no way for a painter to properly anticipate the color in which he draws unless he draws in short, non-self-overlapping strokes (which, admittedly, is typical for water-color et al), gimp may be a powerful graphics-editor but remains nothing but a toy for painting (and all efforts related to painting such as providing well-designed presets remain futile).

Michael Natterer
2012-01-28 15:07:03 UTC (almost 13 years ago)

Non-incremental painting

Your tone, sucks, as always. It sucks so much that I ask you to leave us alone in the future. Please go away.

--mitch

On Sat, 2012-01-28 at 15:33 +0100, Cedric Sodhi wrote:

As I've been asked, I'll just quote what I already submitted to bugzilla, minus the typos:

I see no use in non-icremental paiting. It appears to exist only because it was easier to implement than normal painting, which does not work properly, as I've filed in at least one other bug report.

Not only should incremental paiting urgently be fixed, as described there, but non-incremental painting, or the option to choose between the two, should be removed as a whole.

If anyone can think of a usecase where that non-intuitive, unpredictable painting mode is actually useful, please prove me wrong.

Until then, I interpret the mere existance of that painting mode as an excuse to not admit one of the most serious flaws in gimp with regard to painting.

To be blunt, as long as there is no way for a painter to properly anticipate the color in which he draws unless he draws in short, non-self-overlapping strokes (which, admittedly, is typical for water-color et al), gimp may be a powerful graphics-editor but remains nothing but a toy for painting (and all efforts related to painting such as providing well-designed presets remain futile). _______________________________________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Alexandre Prokoudine
2012-01-28 15:39:35 UTC (almost 13 years ago)

Non-incremental painting

On Sat, Jan 28, 2012 at 6:33 PM, Cedric Sodhi wrote:

If anyone can think of a usecase where that non-intuitive, unpredictable painting mode is actually useful, please prove me wrong.

Until then, I interpret the mere existance of that painting mode as an excuse to not admit one of the most serious flaws in gimp with regard to painting.

To be blunt, as long as there is no way for a painter to properly anticipate the color in which he draws unless he draws in short, non-self-overlapping strokes (which, admittedly, is typical for water-color et al), gimp may be a powerful graphics-editor but remains nothing but a toy for painting (and all efforts related to painting such as providing well-designed presets remain futile).

Dude,

Replacing lack of technical expertise with trolling doesn't work. Not everyone is as generous as las to spend two friggin hours explaining you how automation on MIDI events works, while facing your, frankly speaking, arrogant behaviour. The trick isn't going to work every time, and definitely not in GIMP lists.

You are more than welcome to ask question and even question decisions, but don't expect everyone to just rush having a conversation with you.

Alexandre Prokoudine http://libregraphicsworld.org

Cedric Sodhi
2012-01-28 16:51:40 UTC (almost 13 years ago)

Non-incremental painting

Mitch & "Dude",

I did not ask for your generousity. I reported this flaw on the bugtracker, was asked to bring it up on the list, did so, and, frankly, don't give a tiny bit about how emotionally sensitive you are over it.

And if you are unable to discuss the point at hand and are only capable of returning insults, be my guest, but don't expect any response other than this because I've better things to do with my time than leading this kind of stupid argument.

Anyone else willing to comment on the actual technical issue, irrespective of how "arrogant" I sound or how much my "tone sucks", I'd welcome it.

However, Michael is maintaining this list and "politely" asked me to leave, hence, I will only reply to you in private for not to offend him any further.

On Sat, Jan 28, 2012 at 07:39:35PM +0400, Alexandre Prokoudine wrote:

On Sat, Jan 28, 2012 at 6:33 PM, Cedric Sodhi wrote:

If anyone can think of a usecase where that non-intuitive, unpredictable painting mode is actually useful, please prove me wrong.

Until then, I interpret the mere existance of that painting mode as an excuse to not admit one of the most serious flaws in gimp with regard to painting.

To be blunt, as long as there is no way for a painter to properly anticipate the color in which he draws unless he draws in short, non-self-overlapping strokes (which, admittedly, is typical for water-color et al), gimp may be a powerful graphics-editor but remains nothing but a toy for painting (and all efforts related to painting such as providing well-designed presets remain futile).

Dude,

Replacing lack of technical expertise with trolling doesn't work. Not everyone is as generous as las to spend two friggin hours explaining you how automation on MIDI events works, while facing your, frankly speaking, arrogant behaviour. The trick isn't going to work every time, and definitely not in GIMP lists.

You are more than welcome to ask question and even question decisions, but don't expect everyone to just rush having a conversation with you.

Alexandre Prokoudine http://libregraphicsworld.org
_______________________________________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

gespertino@gmail.com
2012-01-28 17:21:21 UTC (almost 13 years ago)

Non-incremental painting

2012/1/28 Cedric Sodhi

Mitch & "Dude",

I did not ask for your generousity. I reported this flaw on the bugtracker, was asked to bring it up on the list, did so, and, frankly, don't give a tiny bit about how emotionally sensitive you are over it.

And if you are unable to discuss the point at hand and are only capable of returning insults, be my guest, but don't expect any response other than this because I've better things to do with my time than leading this kind of stupid argument.

Cedric:
You could have reported the same issue without adding your personal thoughts about why they didn't implement things the way you consider correct, calling the program "nothing but a toy" and calling collaborations "futile".
That's not polite and you can't expect a good reaction when you put things in that way.
You're addressing to human beings who coincidentally work on an application you can use freely, using their spare time. Expect some emotion. Don't play the victim if you're not being treated well. You started it.

Richard Gitschlag
2012-01-28 17:44:46 UTC (almost 13 years ago)

Non-incremental painting

Cedric, the problem is that the only vibe your intiial post gave off is a "this is wrong" and a "this is totally wrong". You need to explain the problem in detail (e.g. provide a contrived scenario to demonstrate it) and then suggest (again, in detail) what the proper result should have be instead. You did neither.

As for me, the one problem I have with the "incremental" tool option is that it does not mix with alpha-blending. If I specify an opacity of 50% and use the incremental option, (due to the way GIMP internally processes brush strokes) the end result is brush strokes painted with 99% or so opacity because, with the default brush spacing of 15%, the pixels within the stroke area are receiving about 6 strokes of 'paint'. Yes this is technically correct behavior, but the end result is neither correct nor intuitive (bug #588984) in the eyes of the end user. This is less of an issue when you are painting with 100% opacity to begin with, but it still means that fuzzy brushes end up with very hard edges because along the brush's edge those same pixels are getting painted several times over.

Non-incremental painting is at least intuitive: The entire stroke receives a specified, uniform opacity (brush dynamics notwithstanding) and if you need to make multiple strokes over the same area then you can do so in, well, separate strokes.

I, too, would like to see an option where you can paint strokes that are of a predictable opacity (as non-incremental painting already does) but simultaneously allows them to overlap with previous strokes, a la Corel Painter. But I'm at a loss, even conceptually, on how that could be done.

On a tangent, one trick I found with painting straight lines is that since you need to click to set a starting point before using the Shift modifier, if you Undo the initial click you can still use the Shift modifier to paint a straight line with a single stroke without that original poin being applied to the canvas. This can be useful in some cases for single lines at a time....

-- Stratadrake strata_ranger@hotmail.com
--------------------
Numbers may not lie, but neither do they tell the whole truth.

Date: Sat, 28 Jan 2012 17:51:40 +0100 From: manday@gmx.net
To: alexandre.prokoudine@gmail.com
CC: gimp-developer-list@gnome.org
Subject: Re: [Gimp-developer] Non-incremental painting

Mitch & "Dude",

I did not ask for your generousity. I reported this flaw on the bugtracker, was asked to bring it up on the list, did so, and, frankly, don't give a tiny bit about how emotionally sensitive you are over it.

And if you are unable to discuss the point at hand and are only capable of returning insults, be my guest, but don't expect any response other than this because I've better things to do with my time than leading this kind of stupid argument.

Anyone else willing to comment on the actual technical issue, irrespective of how "arrogant" I sound or how much my "tone sucks", I'd welcome it.

However, Michael is maintaining this list and "politely" asked me to leave, hence, I will only reply to you in private for not to offend him any further.

On Sat, Jan 28, 2012 at 07:39:35PM +0400, Alexandre Prokoudine wrote:

On Sat, Jan 28, 2012 at 6:33 PM, Cedric Sodhi wrote:

If anyone can think of a usecase where that non-intuitive, unpredictable painting mode is actually useful, please prove me wrong.

Until then, I interpret the mere existance of that painting mode as an excuse to not admit one of the most serious flaws in gimp with regard to painting.

To be blunt, as long as there is no way for a painter to properly anticipate the color in which he draws unless he draws in short, non-self-overlapping strokes (which, admittedly, is typical for water-color et al), gimp may be a powerful graphics-editor but remains nothing but a toy for painting (and all efforts related to painting such as providing well-designed presets remain futile).

Dude,

Replacing lack of technical expertise with trolling doesn't work. Not everyone is as generous as las to spend two friggin hours explaining you how automation on MIDI events works, while facing your, frankly speaking, arrogant behaviour. The trick isn't going to work every time, and definitely not in GIMP lists.

You are more than welcome to ask question and even question decisions, but don't expect everyone to just rush having a conversation with you.

Alexandre Prokoudine http://libregraphicsworld.org
_______________________________________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

_______________________________________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Mukund Sivaraman
2012-01-28 18:14:50 UTC (almost 13 years ago)

Non-incremental painting

Hi Cedric

On Sat, Jan 28, 2012 at 05:51:40PM +0100, Cedric Sodhi wrote:

Mitch & "Dude",

I did not ask for your generousity. I reported this flaw on the bugtracker, was asked to bring it up on the list, did so, and, frankly, don't give a tiny bit about how emotionally sensitive you are over it.

And if you are unable to discuss the point at hand and are only capable of returning insults, be my guest, but don't expect any response other than this because I've better things to do with my time than leading this kind of stupid argument.

Anyone else willing to comment on the actual technical issue, irrespective of how "arrogant" I sound or how much my "tone sucks", I'd welcome it.

However, Michael is maintaining this list and "politely" asked me to leave, hence, I will only reply to you in private for not to offend him any further.

You were kick banned from IRC. It doesn't mean you can come back in other ways on mailing lists, bugzilla, etc. We banned you because you were rude and didn't want you around.

Kind regards,

Mukund

Liam R E Quin
2012-01-28 18:57:52 UTC (almost 13 years ago)

Non-incremental painting

On Sat, 2012-01-28 at 23:44 +0530, Mukund Sivaraman wrote: [..]

You were kick banned from IRC. It doesn't mean you can come back in other ways on mailing lists, bugzilla, etc. We banned you because you were rude and didn't want you around.

Let's be clearer - the problem is not the person but the behaviour; coming back in a polite and respectful manner might be just fine.

Mukund Sivaraman
2012-01-28 19:38:12 UTC (almost 13 years ago)

Non-incremental painting

Hi Ankh

On Sat, Jan 28, 2012 at 01:57:52PM -0500, Liam R E Quin wrote:

On Sat, 2012-01-28 at 23:44 +0530, Mukund Sivaraman wrote: [..]

You were kick banned from IRC. It doesn't mean you can come back in other ways on mailing lists, bugzilla, etc. We banned you because you were rude and didn't want you around.

Let's be clearer - the problem is not the person but the behaviour; coming back in a polite and respectful manner might be just fine.

Definitely. He can begin by apologizing for how he insulted Bat'O who was trying to help him.

https://encrypted.google.com/search?q=cedric+sodhi+troll

His behavior has not changed. There are better ways to say things constructively than the way this thread was begun.

Kind regards,

Mukund

Liam R E Quin
2012-01-29 02:07:19 UTC (almost 13 years ago)

Non-incremental painting

On Sun, 2012-01-29 at 01:08 +0530, Mukund Sivaraman wrote:

Definitely. He can begin by apologizing for how

[...]

The way forward is always to forgive, as long as the miscreant clearly makes a conscious effort to improve, and of course does not wear shoes or white socks :-) It is of no avail to set people to a higher standard than they can achieve. The child must learn to crawl before dancing.

Sometimes mailing lists and IRC bring out the aspergers' syndrome in us all: a lack of empathy, a tendency to forget that on the other end of the wire are people just like us, with feelings and needs.

Of course, sometimes no amount of working with someone will get them to change, and at some point yes, we all run out of patience, but then perhaps it is we who are at fault, who have also failed to meet our own impossible standards of perfection.

Or to put it another way, "never stop loving" :-)

Liam

Martin Renold
2012-01-31 06:27:27 UTC (almost 13 years ago)

Non-incremental painting

On Sat, Jan 28, 2012 at 03:33:20PM +0100, Cedric Sodhi wrote:

I see no use in non-icremental paiting. [...]

If anyone can think of a usecase where that non-intuitive, unpredictable painting mode is actually useful, please prove me wrong.

Now that's funny. I'm a MyPaint developer, and I know this discussion, but with opposite signs. MyPaint only supports what GIMP calls incremental painting, and users are asking again and again that we implement non-incremental painting. Just look at the recent discussion here:

http://forum.intilinux.com/mypaint-help-and-tips/same-stroke-overlap/

Btw. I completely and heartily agree with the "predictability" argument. But it would be complete nonsense to remove this feature from GIMP, it's oviously something very useful also for painting.