Re: [Gimp-developer] feature: Set exclusive layer visibility within groups
Joao S. O. Bueno wrote: So, we could use a wiki page somewhere for getting this started. Like here: http://wiki.gimp.org/index.php/Specs/Visibility Hi, I posted descriptions of the current behaviour and the proposals in the wiki. No it's on you ;-) Best regards, grafxuser ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
[Gimp-developer] I want write a plugin and need help
http://hejiann.tumblr.com/post/24406851371/i-am-planning-to-write-a-gimp-plugin-this-is-my any suggestion is appreciated. Regards. -- hejian ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Incorrect Hue-Saturation results in obscure cases
> Date: Mon, 4 Jun 2012 09:43:39 -0300 > Subject: Re: [Gimp-developer] Incorrect Hue-Saturation results in obscure > cases > From: gwid...@mpc.com.br > To: strata_ran...@hotmail.com > CC: gimp-developer-list@gnome.org > > Hi Richard -- > > Could you open a bug report at bugzi...@gimp.org about this issue, and > attach the example images ? Already filed as bug #644032 and as a comment on #527085. Example screenshot is attached to the first one: http://bugzilla-attachments.gnome.org/attachment.cgi?id=215132 And the second case was specifically introduced by the way #527085 got patched, which is why I didn't file it as a new bug (yet). I haven't taken a screenshot of it, but I can do that pretty easily. I've attached a patch that implements the reworked algebra (interpolate first, then map to pixel), but I cannot actually test to verify if it works as I do not have an installed C compiler at this time. :( But it should fix both issues if it works. -- Stratadrake strata_ran...@hotmail.com Numbers may not lie, but neither do they tell the whole truth. > js > -><- > > On 3 June 2012 17:30, Richard Gitschlag wrote: > > (Apologies if this is a duplicate post; I tried sending it the other day but > > it didn't seem to go through) > > > > I've found some obscure conditions under which the Hue-Saturation tool > > produces incorrect results up to and including current 2.8.0 . > > > > The first one I encountered "in the wild" sometime in 2.6: I had recently > > finished a pencil drawing and scanned it into an image file, but the "pink" > > areas of the drawing were not a warm enough shade for my preference. At the > > time I felt the easiest method to fix this was via Hue-Saturation tool, so I > > went to the tool, slid the Overlap to 100%, then adjusted the Magenta hue by > > about +10º. (I chose the Magenta range instead of Red because the image > > also contained colors in the red/orange region, and I didn't want them > > affected.) Suddenly my pink pixels were now magenta and blue! As if GIMP > > was calculating it around the wrong side of the HSV wheel, but that was > > apparently reported, patched and fixed four years ago (bug #527085) so the > > explanation can't be that simple. > > > > I've also found another condition that, while it's so improbable a user > > might never encounter it in the wild, it is still incorrect: > > > > - Adjust the Cyan channel hue by +100º ( -> Magenta/blue) > > - Adjust the Blue channel hue by -100º ( -> Cyan/green) > > - Set Overlap to 100% > > > > So if a hue falls between Cyan and Blue ranges, it should get mapped to a > > Magenta -> Blue -> Cyan -> Green range, right? > > But instead, GIMP maps them to a Magenta -> Red -> Yellow -> Green range; > > here it IS going the wrong way around the circle. > > > > This is because of the way GIMP calculates the hue adjustment: > > > > mapped_primary_hue = (input_hue + primary_hue_adjustment) > > mapped_secondary_hue = (input_hue + secondary_hue_adjustment) > > ... > > final_hue = (mapped_primary_hue * primary_intensity) + (mapped_secondary_hue > > * secondary_intensity) > > > > A.k.a. it maps both ranges independently then interpolates the result > > between them. Meanwhile, GIMP ensures that mapped_primary_hue and > > mapped_secondary_hue are kept inside the (0.0 - 1.0) range, and if there is > > more than a 180º difference between them, GIMP wraps mapped_secondary_hue > > again to yield a "shortest circle" route. This is correct 99% of the time, > > but in the above case, it fails because there's a 200º difference between > > mapped_primary_hue and mapped_secondary_hue (regardless of the actual input > > value or master hue adjustement); GIMP assumes it is going the wrong way > > around the HSV circle when it actually isn't (the actual difference between > > blue and cyan after these adjustments is 140º, not 200º). > > > > Another testcase to confirm why it's a bug: > > - Cyan hue +90 > > - Blue hue -90 > > Result: Correct (overlap fades from magenta/blue -> cyan/green). > > > > - Cyan hue +91 > > - Blue hue -91 > > Result: Incorrect (overlap fades from blue/magenta -> red -> yellow -> > > green/cyan) > > > > Who knew a humble 2º made such difference? The patch that fixed #527085 > > cannot tell whether a difference of > 180º is due to crossing the > > red/magenta wraparound or if that was deliberate on the part of the user. > > (And it's not the tool's job to question whether the user's adjustments are > > sane.) > > > > I can submit a patch for this that may fix the issue permanently - but let > > me know if my algebra is correct first: > > > > Given that: > > mapped_primary_hue = input_hue + (master_hue_adjustment + > > primary_hue_adjustment) > > mapped_secondary_hue = input_hue + (master_hue_adjustment + > > secondary_hue_adjustment) > > (primary_intensity + secondary_intensity) = 1 > > > > And: > > final_hue = mapped_primary_hue * primary_intensity + mapped_secondary_hue *
Re: [Gimp-developer] Gimp 2.8 (and previously in 2.6) Color picker issue
On Sun, Jun 3, 2012 at 5:07 PM, Noel Stoutenburg wrote: > I can't tell at the moment whether there is an open bugzilla issue on this, > or not; when I attempt to access the Bugzilla page, I get a message that > there is a hardware issue with the server, but I thought that while I'm > waiting, perhaps someone else might be so kind as to either confirm the > behavior, or alternatively, to advise me what I am missing that I don't get > the behavior listed in the hint. IIRC there's a bug report for this issue on Windows and/or OSX. Chris ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Incorrect Hue-Saturation results in obscure cases
Hi Richard -- Could you open a bug report at bugzi...@gimp.org about this issue, and attach the example images ? js -><- On 3 June 2012 17:30, Richard Gitschlag wrote: > (Apologies if this is a duplicate post; I tried sending it the other day but > it didn't seem to go through) > > I've found some obscure conditions under which the Hue-Saturation tool > produces incorrect results up to and including current 2.8.0 . > > The first one I encountered "in the wild" sometime in 2.6: I had recently > finished a pencil drawing and scanned it into an image file, but the "pink" > areas of the drawing were not a warm enough shade for my preference. At the > time I felt the easiest method to fix this was via Hue-Saturation tool, so I > went to the tool, slid the Overlap to 100%, then adjusted the Magenta hue by > about +10º. (I chose the Magenta range instead of Red because the image > also contained colors in the red/orange region, and I didn't want them > affected.) Suddenly my pink pixels were now magenta and blue! As if GIMP > was calculating it around the wrong side of the HSV wheel, but that was > apparently reported, patched and fixed four years ago (bug #527085) so the > explanation can't be that simple. > > I've also found another condition that, while it's so improbable a user > might never encounter it in the wild, it is still incorrect: > > - Adjust the Cyan channel hue by +100º ( -> Magenta/blue) > - Adjust the Blue channel hue by -100º ( -> Cyan/green) > - Set Overlap to 100% > > So if a hue falls between Cyan and Blue ranges, it should get mapped to a > Magenta -> Blue -> Cyan -> Green range, right? > But instead, GIMP maps them to a Magenta -> Red -> Yellow -> Green range; > here it IS going the wrong way around the circle. > > This is because of the way GIMP calculates the hue adjustment: > > mapped_primary_hue = (input_hue + primary_hue_adjustment) > mapped_secondary_hue = (input_hue + secondary_hue_adjustment) > ... > final_hue = (mapped_primary_hue * primary_intensity) + (mapped_secondary_hue > * secondary_intensity) > > A.k.a. it maps both ranges independently then interpolates the result > between them. Meanwhile, GIMP ensures that mapped_primary_hue and > mapped_secondary_hue are kept inside the (0.0 - 1.0) range, and if there is > more than a 180º difference between them, GIMP wraps mapped_secondary_hue > again to yield a "shortest circle" route. This is correct 99% of the time, > but in the above case, it fails because there's a 200º difference between > mapped_primary_hue and mapped_secondary_hue (regardless of the actual input > value or master hue adjustement); GIMP assumes it is going the wrong way > around the HSV circle when it actually isn't (the actual difference between > blue and cyan after these adjustments is 140º, not 200º). > > Another testcase to confirm why it's a bug: > - Cyan hue +90 > - Blue hue -90 > Result: Correct (overlap fades from magenta/blue -> cyan/green). > > - Cyan hue +91 > - Blue hue -91 > Result: Incorrect (overlap fades from blue/magenta -> red -> yellow -> > green/cyan) > > Who knew a humble 2º made such difference? The patch that fixed #527085 > cannot tell whether a difference of > 180º is due to crossing the > red/magenta wraparound or if that was deliberate on the part of the user. > (And it's not the tool's job to question whether the user's adjustments are > sane.) > > I can submit a patch for this that may fix the issue permanently - but let > me know if my algebra is correct first: > > Given that: > mapped_primary_hue = input_hue + (master_hue_adjustment + > primary_hue_adjustment) > mapped_secondary_hue = input_hue + (master_hue_adjustment + > secondary_hue_adjustment) > (primary_intensity + secondary_intensity) = 1 > > And: > final_hue = mapped_primary_hue * primary_intensity + mapped_secondary_hue * > secondary_intensity > > THEN: > final_hue = (input_hue + master_hue_adjusment + primary_hue_adjusment) * > primary_intensity + (input_hue + master_hue_adjusment + > secondary_hue_adjustment) * secondary_intensity > = (input_hue + master_hue_adjustment) * (primary_intensity + > secondary_intensity) + primary_hue_adjustment * primary_intensity + > secondary_hue_adjustment * secondary_intensity > = input_hue + master_hue_adjusment + (primary_hue_adjustment * > primary_intensity + secondary_hue_adjustment + secondary_intensity) > > In other words, when dealing with pixels in an overlap region the tool > should interpolate the hue adjustment from the respective primary and > secondary ranges, THEN map that adjustment to the pixel. And since the > output value is subsequently converted from HSL back to RGB space with > essentially no further processing, there's no need to worry about crossing > the red/magenta wraparound at all. > > -- Stratadrake > strata_ran...@hotmail.com > > Numbers may not lie, but neither do they tell the whole truth. > > > ___ > gimp-developer-li
Re: [Gimp-developer] Selection and paintbrush tool: is this a bug?
Ignore the double post (both have the same content)--I got an error message when I sent the first message and wasn't sure if it was sent, so I sent it again. On Mon, Jun 4, 2012 at 1:45 PM, Bruce wrote: > I think I may have found an issue with the selection tool. I wanted to run > it by you guys before bug reporting it. > > --- > > I was editing a portrait of someone. > > The layer I was editing had a layer mask, and below it was another layer > (both were visible). I used the free select tool to make a selection, then > used the quick mask feature to edit the selection. > > *Issue #1* > Then I clicked "show mask" and inverted the selection so it's selected the > person (not the background). I could use the paintbrush tool just fine and > it wouldn't go outside the selection. > > But if I inverted the selection (so the background is selected) and then > used the paintbrush on the mask layer, it affected both the selection and > outside the selection. (See screenshot 3 - > http://img40.imageshack.us/img40/2387/screenshot3em.png ) What was > strange was also that my brush opacity was 100%, I think, and while any > strokes in the background were 100%, when I moved into the part of the > image that showed the person (that wasn't selected at the time)... well, > look at screenshot 3. :) > > *Issue #2* > I also noticed strange things were happening at the edge of my selection > when I had the person selected, such that if I was masking through to the > layer underneath with the paintbrush tool, it appeared to go outside my > selection, but only a little bit. I used a quick mask to make the selection > using a soft brush, but if I turn the quick mask on, it doensn't show. See > screenshot these screenshots: > 1 - http://img198.imageshack.us/img198/5592/screenshot1ai.png > 2 - http://img684.imageshack.us/img684/6899/screenshot2bdy.png > > *Issue #3* > Then, strangely, when I tested out painting on the actual layer (not the > mask), if the background was selected I could paint on that just fine and > it didn't go beyond the selection, but if I inverted the selection so the > person was selected, if I painted on the person, it wouldn't show up on the > layer, but in the layers dialogue it did show the paint (I was using a > large brush, so I could notice it easily). No screenshot of this; just > imaging that if you have a person selected and the background not selected > and you paint on the person within the layer, the brush paint doesn't show > on the layer, but does show in the layers dialogue. > > I also tried this with the blurr tool, and it did the same thing. I.e. I > could select the background and paint on that and it'd paint in the > background but not on the person, but if I selected the person, it wouldn't > show anywhere on the layer, but would indeed show on the little layer > preview in the layer dialogue. > > * * * > > Perhaps I'm not doing something right (I'm new to Gimp; I don't understand > selections as much as I understand other things), but this feels like it's > functioning strangely and inconsistantly. > > ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] McGimp 2.8 - Mac Native Version
On Mon, Jun 4, 2012 at 12:12 AM, Partha Bagchi wrote: > Mitch, > > Thanks! for fixing the bug with rounded rectangle select and friends!! > I have been testing Gimp 2.8 with this fix and so far no issues. Nice, that sounds like we need an 2.8.1 release. :) Regards, Tobias ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
