[Gimp-developer] Selection and paintbrush tool: is this a bug?
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
[Gimp-developer] Odd behavior with Hue-Saturation tool and how to fix
I have a few questions/concerns about the Hue-Saturation tool because I've encountered a few very-specific cases where it simply does not work properly. The first one I have filed as bug #644032 - "Color banding in Hue-Saturation tool with overlap" but have yet to receive any response. > https://bugzilla.gnome.org/show_bug.cgi?id=644032 Does anyone else (both on Windows and Linux builds) experience this? Take the attached test image as an example and go to the Hue-Saturation tool. Set an Overlap of 100% and adjust the Magenta channel hue by +60º. Everything from Magenta from Red should now be solid red, but when I attempt this I get a full HSV gradient instead, like it's cycling the wrong way across the HSV wheel. The oddest part is that this is NOT bug #527088 -- that one was fixed years ago. Slowly adjust the Magenta Hue value and watch how the color bands just pop in and out -- at +20º, for example, there's a very sharp-edged switch from red-magenta (correct) to cyan-green (incorrect) and I can't explain how exactly that occurs. I've evev looked through the source code in the GNOME repository (gimpoperationhuesaturation.c) and can't locate anything that apparently might be causing it. I originally encountered this one "in the wild" when I simply wanted to make a minor adjustment to an image containing pink (magenta-red) pixels that I felt were too "cold". Imagine my surprise when the Hue-Saturation tool yielded blues and cyans! Now for the second bug - reset the Hue-Saturation tool. Set an Overlap of 100%, this time adjust the Cyan channel hue by +90º and the Blue channel hue by -90º (with 100% overlap). Everything looks fine, right? BUT shift the Blue channel a little more (to -100) and note the very sudden appearance of a full HSV band between the hues. Why? Because it just passed the half-circle threshold, causing GIMP to calculate the overlap regions the opposite direction around the HSV circle. This was specifically caused by the patch to #527088, where after calculating the primary and secondary hues, GIMP picks the "shortest distance on the circle". Which was necessary to compensate for magenta/red wraparound, but it breaks down in extreme cases. It's conceptually possible that the adjustments made to adjacent channels DO represent the "long way" around the HSV circle, and if that's the case we don't want GIMP to pick the "shortest" route -- but it does. There may be another way to perform the hue calculations that preserves the fixed status of bug #527088 and possibly fixes #644032, let me know if this thinking is correct: Currently, when performing a hue-saturation adjustment with overlap GIMP calculates the final hue by interpolating the results from both of the neighbboring Channels adjusted independently. I.e: (primary_hue) * (primary_intensity) + (secondary_hue * secondary_intensity), (given: primary_intensity + secondary_intensity = 1). Also, Hue adjustment is a simple function of (mapped_hue = original_hue + hue_adjustment), with hue_adjustment including both the Master and given ranges. This means that algebraically, we could reorganize the hue calculation as follows: final_hue = (primary_hue * primary_intensity) + (secondary_hue * secondary_intensity) = (original_hue + primary_hue_adjustment) * primary_intensity + (original_hue + secondary_hue_adjustment) * secondary_intensity = original_hue * (primary_intensity + secondary_intensity) + primary_hue_adjustment * primary_intensity + secondary_hue_adjustment * secondary_intensity = original_hue + (primary_hue_adjustment * primary_intensity) + (secondary_hue_adjusment * secondary_intensity) Correct? Instead of calculating each channel individually and interpolating the result (because either channel could cross the red/magenta threshold and there is no easy way to predict whether or not one did), we essentially interpolate the adjustment that the current pixel shall receive. -- Stratadrake strata_ran...@hotmail.com Numbers may not lie, but neither do they tell the whole truth. <>___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Different Languagepacks Linux/Windows?
Hi, I just wanted to butt in here: On 29.05.2012 19:02, gfxuser wrote: > Could your Windows regionale and language settings be wrong and cause > this mixture? I read of a similar problem with Portuguese and English > (see > http://sourceforge.net/projects/gimponosx/forums/forum/761056/topic/3454274) > and the reason were wrong system settings. The thread indicates a problem with Gimp and specifically with the locale fallback logic, not a configuration error. It is not an error to just specify a language without a region. The locale fallback should *never* produce a language mix with a third language (German in the thread). It should use the default fallback language, which should be English (probably US English). Portuguese (BR) should fall back to Portuguese, which in turn falls back to default. So either the GIMP translations for Portuguese regions were never properly made -- so there in fact is *no* Portuguese version and just Portuguese regional versions, which is a *mistake* -- or the fallback mechanism is simply misbehaving on MacOS. You should check the latest version of Gimp and see if this error still occurs, then file a bug report. Regards, Robert Abel ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] c2g improvements
On Sun, Jun 3, 2012 at 6:10 PM, Jon Nordby wrote: > On 3 June 2012 23:11, Jacek Poplawski wrote: >> On Sun, Jun 3, 2012 at 10:58 PM, Øyvind Kolås wrote: >>> >>> Caching the LUTs sounds like an optimization that should go in directly, >>> though I doubt that is what is taking most of the time. >> >> >> Well my primary concern is - are gimp developers at all interested in any >> work on improving c2g. > The maintainer (of GEGL) has here expressed an interest in getting > this optimization in - that is a pretty strong yes. > > -- > Jon Nordby - www.jonnor.com There is another thread here (somewhere) where I had posted numbers for c2g operations in gegl using a D800 sample jpeg. The optimization suggested by Øyvind lead to a substantial improvement in speed at least on Windows. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
[Gimp-developer] Gimp 2.8 (and previously in 2.6) Color picker issue
Friends, Bugzilla is down at the moment, but while I wait, perhaps someone might help me by confirming whether or not the behavior I found is unique to my installation (WIN 7 SP1 64bit; GIMP 2.8). If I open GIMP, select the color picker tool, and open the "Change color dialog", when I hover the cursor over the button button with the eyedropper about 1/2 way down the far right side of the dialog box, to the right of the "HTML notation:" box, I get a hint, "Click the eyedropper, then click a color anywhere on your screen to select that color." However, in my installation, I find that this hint does not correctly describe the observed behavior. When I click the eyedropper, the cursor changes to an eyedropper anytime I am over a GIMP window, but reverts to the standard cursor as soon as the cursor is over any portion of the screen that is not a GIMP related window. 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. ns ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
[Gimp-developer] McGimp 2.8 - Mac Native Version
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. Matter of fact, the bugfix also fixed the advanced tone mapping script at the same time. The script-fu window sits on the dock throughout the session but you already know that. :) A minor price to pay. I posted a screenshot on gimpchat.com. Thanks again, Partha ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] c2g improvements
On 3 June 2012 23:11, Jacek Poplawski wrote: > On Sun, Jun 3, 2012 at 10:58 PM, Øyvind Kolås wrote: >> >> Caching the LUTs sounds like an optimization that should go in directly, >> though I doubt that is what is taking most of the time. > > > Well my primary concern is - are gimp developers at all interested in any > work on improving c2g. The maintainer (of GEGL) has here expressed an interest in getting this optimization in - that is a pretty strong yes. -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] c2g improvements
On Sun, Jun 3, 2012 at 10:58 PM, Øyvind Kolås wrote: > Caching the LUTs sounds like an optimization that should go in directly, > though I doubt that is what is taking most of the time. Well my primary concern is - are gimp developers at all interested in any work on improving c2g. I like Gimp and I use it very often but I am not sure about project management here and experiences from reading this list in previous years weren't very good. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] c2g improvements
On Sun, Jun 3, 2012 at 10:46 PM, Jacek Poplawski wrote: > there are few things... reading from 3 different arrays is 3 times slower > than reading from 1 array, at least under Linux... but the overall > algorithm does too much things that's why I proposed to create "c2g lite" > which will not be so mathematically correct but give similar effect... for > instance is relative brightness really so important in envelopes.h? also > the luts are generated everytime from start, while I found out that > generating one big array and use subset of data give similar results > Caching the LUTs sounds like an optimization that should go in directly, though I doubt that is what is taking most of the time. Beware that stress/c2g should also work on HDR images and not only on images with data in the 0.0-1.0 range.. For some of the rationale behing stress/c2g see http://pippin.gimp.org/papers/Kolaas_11_jist.pdf which is a publication based on the approach explored by these GEGL ops. /Ø -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] c2g improvements
On Sun, Jun 3, 2012 at 10:40 PM, Jon Nordby wrote: > c2g is a GEGL operation. You will find it in operations/common/c2g.c > in the GEGL tree. > I know this code pretty well because I was analizing it for days and implementing my own version for delaboratory :) > I would recommend first finding out what causes the current slowness > you experience: Is it the GEGL integration in GIMP? (compare c2g usage > in GIMP with using GEGL directly). Is it due to some overhead in GEGL > core? Or maybe there is room for optimization in the operation itself? > there are few things... reading from 3 different arrays is 3 times slower than reading from 1 array, at least under Linux... but the overall algorithm does too much things that's why I proposed to create "c2g lite" which will not be so mathematically correct but give similar effect... for instance is relative brightness really so important in envelopes.h? also the luts are generated everytime from start, while I found out that generating one big array and use subset of data give similar results ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] c2g improvements
On 1 June 2012 17:55, Jacek Poplawski wrote: > hello, > > I like the effect of c2g operation available in GIMP for a long time, lots > of people use it for kind of "HDR" effect but I think it's nice way to > increase local contrast of some specific areas of photo or add nice looking > noise > However, the main problem of current implementation of c2g is its > inefficiency, it takes a lot of time to process standard size photo. > > I am author of delaboratory and I started implementing c2g-like operation in > my project, after few days I was able to achieve something similar to > GIMP/GeGL c2g but much faster. Hi Jacek, c2g is a GEGL operation. You will find it in operations/common/c2g.c in the GEGL tree. I would recommend first finding out what causes the current slowness you experience: Is it the GEGL integration in GIMP? (compare c2g usage in GIMP with using GEGL directly). Is it due to some overhead in GEGL core? Or maybe there is room for optimization in the operation itself? > I would like to implement something like that to GIMP. I don't want to > modify existing c2g code, because I assume current implementation is well > designed (mathematicaly) and should stay. So it would be nice to create > something like "simple c2g" or "c2g lite" or just "local contrast boost" > operation. > > My question is - are you interested at all in this kind of code? Will it be > accepted in GIMP? Because my main concern is that I don't want to implement > something which will never be used. I am not aware of current state of > project (I mean project management, not code) and I don't know what's the > process of submitting code to GIMP/GeGL right now. If you are going to do a new operation, the right way to do it is in GEGL. GIMP and others can then use it. -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
[Gimp-developer] Incorrect Hue-Saturation results in obscure cases
(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-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] c2g improvements
> Out of curiousity, what is the relation of Marco's wavelet filters to > local contrast? :) Well I'm not an expert but my understanding of wavelet decompose is that it decomposes the image into different details scales. So if you duplicate the Wavelet scale xx layers after using wavelet-decompose, it will make the bright details at that scale brighter and the dark details and that scale darker, ie increasing local contrast. I don't know the relationship between the two, but I it looks very similar to increasing local contrast with unsharp mask, but with direct control over different radius. Maybe that's not what the filter is designed for, but in some cases I find it to do a pretty good job. I made a quick&dirty xcf, that probably explains better than I do : https://dl.dropbox.com/u/35934134/ex.xcf.tar.gz > Could it be that GIMP simply hasn't entered optimization phase with > regards to GEGL yet? :) Well then I'm looking forward, keep up the awesomeness :) Alex Le Sunday, June 03, 2012 10:33:50 PM Alexandre Prokoudine a écrit : > On Sun, Jun 3, 2012 at 9:47 PM, Alexandre Génin wrote: > > I use c2g on almost every photo : my workflow often only consists in > > adjusting global contrast (levels/curves), and then using c2g for > > adjusting local contrast, usually with different radiuses. It a > > fantastic tool, much better imho than all the wavelet-* filters that > > always produce a 'dreamy' effect. > Out of curiousity, what is the relation of Marco's wavelet filters to > local contrast? :) > > > The only drawback is that it takes ages to process the photo > > Could it be that GIMP simply hasn't entered optimization phase with > regards to GEGL yet? :) > > Alexandre Prokoudine > http://libregraphicsworld.org > ___ > gimp-developer-list mailing list > gimp-developer-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gimp-developer-list ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] contribution processes...
On Mon, Jun 4, 2012 at 3:33 AM, peter sikking said: maybe this exactly demonstrates the sizeable gap there is between > the people that can, and do, contribute, and users and other observers. > the points listed there are about minimum decent software engineering, > thus to software engineers it is logical that they _have to_ be met, > or else the codebase goes to hell. > to users and other observers, each one of these is a barrier of entry, > and I find it good that that becomes clear to all parties. but to > be able to contribute, one has to be able to meet the requirements, > i.e. one has to be able to do the _work_ of software engineering. > note that the shorter (less ambitious) the patch, the easier it is > to meet the requirements. I think it's fine to have requirements so long as they're clear and people know where to go when they want to contribute something. People who are willing to go to the extent of contributing something probably care about Gimp or rely on it for something they do, so I think that if you have high requirements for this new contribution process we're discussing, perhaps have some sort of page that explains the requirements, and mention that if they don't meet it, they can always post their idea to the GUI brainstorm. >From a development standpoint, this helps keep the feedback channels open (and explaining contribution requirements for those channels keeps things constructive). >From a users perspective, when it comes to something they care about (such as Gimp), I feel they mostly want to: - have some sense that they're being heard (things like a product vision, project updates, and lists of know issues or things that are being worked on can help with that) - have an opportunity to contribute in some way if they have a good idea, and - have a sense that their contributions are appreciated Even if the specific ideas people share aren't that useful, I feel such contributions serve as helpful feedback--it's just a matter of that feedback going to the right place in the right format given the amount of people you have to process such feedback, and how desirous they are of wanting to process it. If the scale of feedback you're getting is too much, you can always tweak the requirements and submission guidelines (regardless of whether they're submitting things to the contribution process, or to the UI brainstorm). * * * In terms of what a requirements page may look like, here's my version of a very basic draft: If you have an idea for how the Gimp interface can be improved or , there are two ways you can contribute. *Option 1* So long as you've read X, Y, and Z pages, you can create an entry via the contribution process web page [link]. *Option 2* If you don't want to do all of that, that's okay; you can still still mock-up your idea in the form of an image and submit it to the Gimp UI brainstorm. The instructions for how you can do it are in the right sidebar of all pages on the UI brainstorm. [link to UI brainstorm] If you'd just like to talk to someone about your idea, you can visit the IRC channel [link] or send an email to the Gimp mailing list [link]. Or anther version: *Do you have ideas for how the Gimp interface can be improved? * If so, you can create a mock-up of your idea in the form of an image and submit it to the Gimp UI brainstorm. Once you do that the team that helps design Gimp's UI and works with the developers to help implement that design will review your (and other) submissions as a way to gather ideas and get insight into how people use Gimp and what features people would like. For further instructions, visit the UI brainstorm website and read the instructions in the right sidebar. [link to UI brainstorm] *Want to get more involved?* Gimp uses a Bugzilla process to keep track of UI projects that are currently in the process of being designed and discussed by the UI team and the Gimp community. That said, in order to keep that process constructive and productive, you have to be familiar with some things before you can contribute in this way. If you'd like to proceed, take a look at X, Y, and Z page. Once you've done that, create an account over at Bugzilla [link] and then go to [link to the process for the UI development]. >From there you can take a look at the list of current projects and contribute feedback and alternative designs to them, and you can also create a new project. [Note from Bruce: I'm not sure what criteria you'll have for new projects, so I was vague in that last part.] Those are just some examples. On Mon, Jun 4, 2012 at 3:33 AM, peter sikking wrote: > let's pick up this discussion again, sorry for the delay. > > Saul Goode wrote: > > > In my opinion the language of the draft is not very inviting to > contribution. > > the draft is a _description_ of the current code process, not a > manual/invitation page for new contributors. it describes how > things are in the code world, so I can derive an
Re: [Gimp-developer] c2g improvements
On Sun, Jun 3, 2012 at 9:47 PM, Alexandre Génin wrote: > I use c2g on almost every photo : my workflow often only consists in adjusting > global contrast (levels/curves), and then using c2g for adjusting local > contrast, usually with different radiuses. It a fantastic tool, much better > imho than all the wavelet-* filters that always produce a 'dreamy' effect. Out of curiousity, what is the relation of Marco's wavelet filters to local contrast? :) > The only drawback is that it takes ages to process the photo Could it be that GIMP simply hasn't entered optimization phase with regards to GEGL yet? :) Alexandre Prokoudine http://libregraphicsworld.org ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] c2g improvements
Hi Please please take time to implement this ! I'll be glad to lend a hand for testing/tutorials/etc. (I don't have coding skills). I use c2g on almost every photo : my workflow often only consists in adjusting global contrast (levels/curves), and then using c2g for adjusting local contrast, usually with different radiuses. It a fantastic tool, much better imho than all the wavelet-* filters that always produce a 'dreamy' effect. The only drawback is that it takes ages to process the photo, so I always end up making some compromise between noise level and processing time... so a speedup would be *very* useful ! Alex Le Friday, June 01, 2012 05:55:43 PM Jacek Poplawski a écrit : > hello, > > I like the effect of c2g operation available in GIMP for a long time, lots > of people use it for kind of "HDR" effect but I think it's nice way to > increase local contrast of some specific areas of photo or add nice looking > noise > However, the main problem of current implementation of c2g is its > inefficiency, it takes a lot of time to process standard size photo. > > I am author of delaboratory and I started implementing c2g-like operation > in my project, after few days I was able to achieve something similar to > GIMP/GeGL c2g but much faster. > > I would like to implement something like that to GIMP. I don't want to > modify existing c2g code, because I assume current implementation is well > designed (mathematicaly) and should stay. So it would be nice to create > something like "simple c2g" or "c2g lite" or just "local contrast boost" > operation. > > My question is - are you interested at all in this kind of code? Will it be > accepted in GIMP? Because my main concern is that I don't want to implement > something which will never be used. I am not aware of current state of > project (I mean project management, not code) and I don't know what's the > process of submitting code to GIMP/GeGL right now. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] contribution processes...
let's pick up this discussion again, sorry for the delay. Saul Goode wrote: > In my opinion the language of the draft is not very inviting to contribution. the draft is a _description_ of the current code process, not a manual/invitation page for new contributors. it describes how things are in the code world, so I can derive an interaction design process from it, that is just as open as the code process. > At minimum, each of the "has to"s should be changed to either "should"s or > "should strive to"s. maybe this exactly demonstrates the sizeable gap there is between the people that can, and do, contribute, and users and other observers. the points listed there are about minimum decent software engineering, thus to software engineers it is logical that they _have to_ be met, or else the codebase goes to hell. to users and other observers, each one of these is a barrier of entry, and I find it good that that becomes clear to all parties. but to be able to contribute, one has to be able to meet the requirements, i.e. one has to be able to do the _work_ of software engineering. note that the shorter (less ambitious) the patch, the easier it is to meet the requirements. > Also, it is unclear whether the final "does not have to be perfect" trumps > any or all of the previous seven bullet points -- if it does not then the > requirements are indeed exceedingly stringent. I have refined that point now in the wiki. > Especially problematic is the sixth bullet. just sticking with the libs that GIMP normally uses and not start using platform-specific ones, and not use platform-specific compiler features goes a long way towards writing non-platform-specific patches. it is again about simply decent software engineering. [I snipped the rest because it was about changing the code patch workflow, which is not what I intent to achive.] --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
[Gimp-developer] ANNOUNCE: Gimp User Manual 2.8.0 released
Hi! A new version of the user manual for GIMP 2.8.0 is released! You can find the releases on our FTP server: ftp://ftp.gimp.org/pub/gimp/help/gimp-help-2.8.0.tar.bz2 (md5: d6e07a569fe4b3bb11aaf5630da2693b) Users should wait until this release has been packaged in a pre-compiled form for their platform. Find more information about our goals and how you can help at http://docs.gimp.org. At the point in time, we provide a nightly updated HTML version of the user manual and PDFs of the quick reference. These show our current work in progress. We also include translations in this release, which are not complete. We welcome everyone who can help completing translations. Any enquiries, contributions and questions can be discussed on our mailing list. You'll find a quick overview on how to help us on our project page: http://docs.gimp.org/help.html Thanks to everyone who contributed! Happy GIMPing! -- Roman Joost www: http://www.romanofski.de email: romanof...@gimp.org signature.asc Description: Digital signature ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
