[Gimp-developer] Water Brush (color dynamics) simular to the ones in Sai Paint Tool, or shi-dow's oekaki java applet
This is a feature that i really miss,as a CG artist,because it considerably helps one get inbetween colors without playing too much with the pallette. Here is what i mean: Sain Paint Tool ( http://sai.detstwo.com/sai/ ) has brushes which enable the user to mix colors directly on the canvas. I tried to figure out how it does that and came to the conclusion that the brush checks the color you start your stroke on and compares it with the color that is set and comes up with a color value that stands between the two. ( brush stroke color = color that it draws over (same layer) +color that is picked) Having it check only the color where the stroke starts on gives is a slight smudge effect too,but in a way that the user can actually easily get the transition between two color values (makes shading and lights a bliss) Another interesting thing is that the brush also tries to emulate thickness of color, not only depending on how hard you press the stylus. That way you get different values of a single color. Ultimately Sai has different brushes that work on the same principle,but their values are differently set in order to emulate real materials ( brush(thick), water brush (less thick), marker,pen..and so on ) It also has a color mixer pallette where you can mix colors,but the users does that on the canvas with the same ease. Having this brush dynamics will enable gimp to have such a color mixer pallette. This brush is something that i couldnt find in photoshop,i saw that there you have color dynamics,but couldnt get them to work that way. Only Sai Paint Tool and that java applet have a waterbrush, the first one's popularity among graphic artists is rapidly growing just because of that feature.Having it in gimp's brush will make it supperior and unique to other graphic software. This simple feature makes it a lot easier to get right color values and the transition between them directly on the canvas. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] gimp modification
hi, my name ek kian. i'm sorry for my limited english, but i have questions about gimp modification. i make gimp modification called gimphoto. I'm sorry but this is my first time making software modification and also my first time doing open source software, i hope i didn't do it wrong. my first modification is based on GIMP 2.3.19 but it done at binary level (i used hex editor to modify the file, this because i still unable to compile GIMP under Windows) and also for second released that based on GIMP 2.4.0, so there is no source code for first and second released of gimphoto. but for the latest release, gimphoto is based on GIMP 2.4.3 and modified at source code level, so i released the modified GIMP source code (can be downloaded at gimphoto.googlecode.com) the GIMP modification that i made is: - GIMP menu structure. - disable many GIMP menu icon for speedup menu rendering (i don't know under Linux, but under Windows this make speedup 25% for menu rendering). - change GIMP built-in plugins menu location to adapt new menu structure. - change default GTK Theme that used by GIMP. - change splash screen. - many external plugin still modified using hex editor rather than re-compiled from source code. Mr.Tor told me that there is possibility to do official modification on GIMP with following some rules, where i can find the rules that i must followed to make my modification officially? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] SoC 2008 - midterm evaluations start soon
Hi, what I've read on IRC and the commit logs so far makes me confident that this year's SoC will be very successful for all of our participants and GIMP. I'd like to remind you that the midterm evaluations start on 2007-07-07 and end on 2007-07-14. Expect to fill out a questionaire, details will be provided by Google at a later time. See http://code.google.com/opensource/gsoc/2008/faqs.html#0.1_evaluations After the evaluations, the second coding phase starts. The midterm is a good time to make adjustments to the projects, e.g. if it has become evident that the initial goal is too much (or too little) to accomplish. HTH, Michael -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Image color representation?
David Gowers wrote:
I'm having a bit of trouble myself deciding which type I should have in
the
program I'm going to make, to use for each channel. If I use 8 bits per
channel, the different functions will probably run a bit faster than if
I
use floating point values.
Premature optimization is the root of all evil.
I know it's tempting, but it's really good practice to only optimize
when a) there is something fundamentally wrong with the approach taken
by the algorithm, or b) you have proof that that specific code is
unacceptably slow (bottlenecking the process)
But gimp uses 8 bits per channel and gimp isn't evil? Oh, I see, THAT
optimization is mature! :)
No to be honest, I don't really see your point. Do you mean I should use
floating point values even though gimp uses 8-bit values?
Joao S. O. Bueno Calligaris wrote:
The gimop currently works with 8 bit per channel only.
Sorry, but I haven't heard of gimop before. :) Just kidding!
How does it come there is a structure GimpRGB in gimp that looks like:
typedef struct {
gdouble r, g, b, a;
} GimpRGB;
if gimp only uses 8 bits/channel? Is this intended for representing some
color other than those in image pixels?
By the way, if gimp only 8 bits/channel, wouldn't there be bigger and bigger
quality losses of the picture if one does a lot of manipulation and the
functions used constantly are scaling down the values to 8-bits per channel?
Or is it hard to notice the rounding effects? I'm just curious, since you
say you shouldn't save and re-load a jpg image too much, isn't this about
the same thing? Maybe the idea is to implement floating point values and
other more high resolution data types, to the channels when GIMP gets more
dependent of GEGL?
--
View this message in context:
http://www.nabble.com/Image-color-representation--tp17855048p17871475.html
Sent from the Gimp Developer mailing list archive at Nabble.com.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Image color representation?
David Gowers wrote: I suggest investigating GEGL (gegl.org), which can provide pixel data in a wide range of formats, and load images, if you require 8bpp support. GIMP 2.5+ already depends on GEGL. I should take a look a that library, it seems quite handy. Thanks for the tip! -- View this message in context: http://www.nabble.com/Image-color-representation--tp17855048p17871593.html Sent from the Gimp Developer mailing list archive at Nabble.com. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Enhancement idea: Snapshot tool for quick comparisons
I tried posting this to the list first, but apparently the list was down, so I went ahead and submitted a bug (#540091). The text below is from that bug report, and I would love to have this idea discussed on the list for possible development. When editing photos I find that it is tedious waiting for the rendering to be completed as I turn layers on and off for comparing the effects of the changes I'm making. I would like to see a new tool/UI that would allow a snapshot to be taken of any currently displayed view and saved for comparison with other snapshots later. It would be good to allow these snapshots to be named. I visualize a list of snapshots, and clicking on each one displays it in a snapshot review window. This window would have zooming and panning capabilities. By eliminating the processing that I assume is required each time a layer is turned on/off, I would think that the snapshots could be displayed very quickly and make subtle differences between snapshots more apparent. Perhaps something like this might be done using the Copy Visible function and creating a display window with a list of snapshots displayed on the side? Comment #1 from Martin Nordholts (GIMP developer, points: 14) 2008-06-25 04:29 UTC [reply] Hi Why not just use Image - Duplicate as the snapshot mechanism? If that doesn't work, please bring this up on the gimp-developer mailing list. Before opening an enhancement request the feature and solution should have been discussed there. Thanks Comment #2 from vabijou yahoo com (reporter, points: 6) 2008-06-25 13:12 UTC [reply] The gimp-developer mailing list has had no activity since June 16, so it does not appear to be working. I've tried posting there, and my e-mails have been returned. I've e-mailed the gimp-developer administrator and had that e-mail returned. I posted it on nabble on June 20 and there it sits. I think I've done my best to work within the system, and the system failed me. Hence, I'm posting it here. Image - Duplicate is an unacceptable alternative. The idea is to create a single window that allows the user to cycle through multiple (named) snapshots in any order he chooses to see large or small changes more readily. Image - Duplicate has so many negatives to this process that I don't know where to start. Two major problems with Image - Duplicate immediately come to mind: 1) It would be a huge waste of memory, since it completely copies the image info (except for the History). 2) It scatters windows all over the place, making comparisons difficult. What I'm after is a fast-rendering, easy to use method of flipping through snapshots of my workflow. Shift-clicking on the eye-ball by each layer comes close, but it is slowed by the processing required during rendering. My proposal is a way to get around that and speed things up for the user. -- View this message in context: http://www.nabble.com/Enhancement-idea%3A--Snapshot-tool-for-quick-comparisons-tp18142100p18142100.html Sent from the Gimp Developer mailing list archive at Nabble.com. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp modification
Ek kian wrote: hi, my name ek kian. i'm sorry for my limited english, but i have questions about gimp modification. i make gimp modification called gimphoto. Hi Ek! In order for a change to become part of GIMP there are basically two criteria that needs be fulfilled: 1. The change must be a sensible change in the eyes of the GIMP developers, that preferably realizes some or many parts of the GIMP product vision [1] 2. The change must be done in a clean way that follows good general and GIMP programming practices. GIMP programming practices and coding style is probably best learned by studying the actual source code. From the list of changes you mention below, the improvements to the plugins sounds most interesting to bring into GIMP, but in order to do that we need a source code patch (a binary patch doesn't make sense since as you probably know a GIMP release is a source code release, not binary releases). [1] http://gui.gimp.org/index.php/GIMP_UI_Redesign#product_vision Best regards, Martin Nordholts ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Image color representation?
On Fri, Jun 27, 2008 at 4:41 AM, TriKri [EMAIL PROTECTED] wrote:
David Gowers wrote:
I'm having a bit of trouble myself deciding which type I should have in
the
program I'm going to make, to use for each channel. If I use 8 bits per
channel, the different functions will probably run a bit faster than if
I
use floating point values.
Premature optimization is the root of all evil.
I know it's tempting, but it's really good practice to only optimize
when a) there is something fundamentally wrong with the approach taken
by the algorithm, or b) you have proof that that specific code is
unacceptably slow (bottlenecking the process)
But gimp uses 8 bits per channel and gimp isn't evil? Oh, I see, THAT
optimization is mature! :)
That's exactly correct. It's mature and out of date: It was an
optimization that was definitely required at the time (running on
486s, small hard disks, etc..), and is no longer required in today's
world of fast CPUs with fast FSBs, large memory, and huge hard drives.
AFAIK no new GIMP code is being written that manipulates 8bpp sRGB
integers, only 32/64bit scRGB floats/doubles (such as the new color
processing ops (levels curves posterize etc.))
No to be honest, I don't really see your point. Do you mean I should use
floating point values even though gimp uses 8-bit values?
I mean you should use whichever fits the way you are manipulating them
best, without attempting to be clever or fast until you have
determined for sure that the algorithym is not already clever or fast
enough.
Usually, I expect the appropriate choice to be floating point, as it
tends to be the 'least surprising' in it's behaviour. It's only a few
filters (things like 'Gradient Map', which basically map the image
data through a set of lookup tables), that would glean no benefit from
using floats when the input image format is 8bit/channel integer.
Joao S. O. Bueno Calligaris wrote:
The gimop currently works with 8 bit per channel only.
Sorry, but I haven't heard of gimop before. :) Just kidding!
How does it come there is a structure GimpRGB in gimp that looks like:
typedef struct {
gdouble r, g, b, a;
} GimpRGB;
if gimp only uses 8 bits/channel? Is this intended for representing some
color other than those in image pixels?
Yes, it is used for passing around individual colors -- for example,
the FG and BG color are stored in GimpRGB structures.
By the way, if gimp only 8 bits/channel, wouldn't there be bigger and bigger
quality losses of the picture if one does a lot of manipulation and the
functions used constantly are scaling down the values to 8-bits per channel?
Yes
Or is it hard to notice the rounding effects? I'm just curious, since you
say you shouldn't save and re-load a jpg image too much, isn't this about
the same thing? Maybe the idea is to implement floating point values and
other more high resolution data types, to the channels when GIMP gets more
dependent of GEGL?
Yes, it is. Integration of GEGL has begun, with 2.5 providing
GEGL-based code for all the color adjustment tools (curve, levels,..)
8 bit / channel limitation will persist until all core parts of the
GIMP code are aware, through GEGL, of differing
pixelformats/colorspaces. This is a fairly massive set of changes
needed before GIMP handles non-'8bpp RGB' image data gracefully, after
which I expect we'll want to migrate as many plugins to support
different color depths/spaces as possible.
Various PDB functions will have to be deprecated (due to a) wrong
assumptions that values range 0..255, and b) INT8 and INT8ARRAY
parameters that are no longer appropriate) and functions to replace
them created. Hopefully a major update of the PDB interface to provide
things like default parameters, varargs, and keyword args will be done
aside that ('rockwalrus' was working on this 'libpdb', I haven't heard
news of it in some time)
That's why the overall timeframe for integrating GEGL is so long. HTH.
David.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enhancement idea: Snapshot tool for quick comparisons
On Thursday 26 June 2008, vabijou2 wrote: I tried posting this to the list first, but apparently the list was down, so I went ahead and submitted a bug (#540091). The text below is from that bug report, and I would love to have this idea discussed on the list for possible development. When editing photos I find that it is tedious waiting for the rendering to be completed as I turn layers on and off for comparing the effects of the changes I'm making. I would like to see a new tool/UI that would allow a snapshot to be taken of any currently displayed view and saved for comparison with other snapshots later. It would be good to allow these snapshots to be named. I visualize a list of snapshots, and clicking on each one displays it in a snapshot review window. This window would have zooming and panning capabilities. By eliminating the processing that I assume is required each time a layer is turned on/off, I would think that the snapshots could be displayed very quickly and make subtle differences between snapshots more apparent. Perhaps something like this might be done using the Copy Visible function and creating a display window with a list of snapshots displayed on the side? Hi there - I am improving the layer group plug-in that hacks some layer group functionality in GIMP. You can have a version of it at [1] right now - but I am working on a version featuring a dialog where one can trun the groups visible or invisible with a single click. That will still work on teh same image, but you can do image-duplicate if you need to see diferent versions at once. [1] - http://www.gimpstuff.org/content/show.php/Layer+groups?content=83137 js -- --- - Comment #1 from Martin Nordholts (GIMP developer, points: 14) 2008-06-25 04:29 UTC [reply] Hi Why not just use Image - Duplicate as the snapshot mechanism? If that doesn't work, please bring this up on the gimp-developer mailing list. Before opening an enhancement request the feature and solution should have been discussed there. Thanks --- - Comment #2 from vabijou yahoo com (reporter, points: 6) 2008-06-25 13:12 UTC [reply] The gimp-developer mailing list has had no activity since June 16, so it does not appear to be working. I've tried posting there, and my e-mails have been returned. I've e-mailed the gimp-developer administrator and had that e-mail returned. I posted it on nabble on June 20 and there it sits. I think I've done my best to work within the system, and the system failed me. Hence, I'm posting it here. Image - Duplicate is an unacceptable alternative. The idea is to create a single window that allows the user to cycle through multiple (named) snapshots in any order he chooses to see large or small changes more readily. Image - Duplicate has so many negatives to this process that I don't know where to start. Two major problems with Image - Duplicate immediately come to mind: 1) It would be a huge waste of memory, since it completely copies the image info (except for the History). 2) It scatters windows all over the place, making comparisons difficult. What I'm after is a fast-rendering, easy to use method of flipping through snapshots of my workflow. Shift-clicking on the eye-ball by each layer comes close, but it is slowed by the processing required during rendering. My proposal is a way to get around that and speed things up for the user. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] SoC 2008 - midterm evaluations start soon
Hi Michael, On Thu, Jun 26, 2008 at 9:56 PM, Michael Schumacher [EMAIL PROTECTED] wrote: Hi, what I've read on IRC and the commit logs so far makes me confident that this year's SoC will be very successful for all of our participants and GIMP. I'd like to remind you that the midterm evaluations start on 2007-07-07 and end on 2007-07-14. Expect to fill out a questionaire, details will I'd like to remind you that we do not have time machines at our disposal. Thanks. ;) David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
