Re: [Gimp-developer] GIMP GNU GPLv3/LGPLv3 in general (was: Re: distributing gimp with another program)
On Mon, Nov 22, 2010 at 8:04 AM, Michael Schumacher schum...@gmx.de wrote: Von: Christopher Curtis ccurt...@gmail.com *** (Sven, Mitch) *** This LICENSE text should probably be updated as 'Section 2' of GPLv3 doesn't talk about aggregations - it's been moved into section 5. It might also be useful to address this issue directly as the GPLv2 is generally well understood to allow command line usage as an 'aggregation', but GPLv3 seems to muddy this distinction. At the moment I'm not even sure if GIMP should be licensed under GPLv3 without a much better understanding of the license. For example, the fact that it is now impossible to use GPLv2-only libraries in plug-in wasn't considered at all. It's not such much the fact that we can't use them anymore, rather the problem of no one even thinking about it when we changed the license version to v3. I have contacted the Freedom Task Force of the FSF in order to get help, and they requested more details. Unfortunately my spare time (or the lack thereof) didn't allow me to write a reply yet. I'd be glad to learn about any additional side-effects of a GPLv3-licensed GIMP (note that libgimp* is licensed under LGPLv3) that may surprise us - but please base them on actual FSF information and not mere speculation. Since a long time ago, we had an exception of the license for plug-ins in a sense that GIMP plug-ins can be non GPL. If you as much as take a look at the LICENSE file provided in the tree, it is at the second and third paragraphs. Therefore, there should be no problem in suiong GPLv2 or any other license for libraries linking to plug-ins. js -- Regards, Michael -- Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] astronomical use of GIMP
On Fri, Nov 19, 2010 at 03:13:24PM +, Øyvind Kolås wrote: Almost all the foundation work for supporting this is already done in GEGL/GIMP, the only missing bits is making a real decision on how things are done in the UI as well as probably starting to let GIMP use OpenRaster instead of XCF for composition storage. The projection of GIMP can be made to render using a GEGL graph, in this graph any arbitrary operation can be inserted anywhere in the hierarchy providing a combination of the features photoshop call adjustment layers/layer effects. Artificially limiting the selection of ops doesn't seem good. A couple of years ago I tried exchanging the opacity op in the GIMP code for the layer stack with a dropshadow op, this worked fine and allowed to have live drop-shadows with an adjustable parameter... thus one can almost say that GIMP can already do these things and more, it just doesnt expose them to the user in any useful form. These are all wonderful news to me... Thanks to all developers! -- Marco Ciampa ++ | Linux User #78271 | | FSFE fellow #364 | ++ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] unsharp mask
Now, looking through the code I don't see gimp doing anything really different from me outside of the convolution matrix code. Frankly, I don't understand the convolution matrix code. Why does it take 50 samples and then average them? Is this significant? even if i am not a developer i may assure you that consider the neighboring pixels (that is what convolution matrix are for ) is VERY significant, and sure that may explain well why result look simultaneously more contrasted and smoother. i think you should really give a look to what convolution matrix may do Er, I think you misunderstood me a bit. I believe I understand what the convolution matrix is, and I also understand why it's important. Yes, the entire purpose of the convolution matrix is to look at neighbouring pixels to create the pixel you're looking for, but that is not what I was talking about when I said '50 samples'. In the code which *creates* the convolution matrix it does not look at the pixels at all. It creates the convolution matrix using an equation. I would think that it would simply plug in the variables for each convolution matrix value it's looking for, but what it is actually doing is taking 50 numbers and plugs those into the equation, then averages them. Just to repeat, this is in the part that creates the convolution matrix, not the part that uses the convolution matrix to generate pixel values. I was wondering about the purpose of all those samples along the equation that generates the matrix. -- bioster (via gimpusers.com) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] unsharp mask
On 11/22/2010 05:59 AM, Ofnuts wrote: On 11/22/2010 02:24 PM, bioster wrote: ... elisions by patrick ... Er, I think you misunderstood me a bit. I believe I understand what the convolution matrix is, and I also understand why it's important. Yes, the entire purpose of the convolution matrix is to look at neighbouring pixels to create the pixel you're looking for, but that is not what I was talking about when I said '50 samples'. In the code which *creates* the convolution matrix it does not look at the pixels at all. It creates the convolution matrix using an equation. I would think that it would simply plug in the variables for each convolution matrix value it's looking for, but what it is actually doing is taking 50 numbers and plugs those into the equation, then averages them. Just to repeat, this is in the part that creates the convolution matrix, not the part that uses the convolution matrix to generate pixel values. I was wondering about the purpose of all those samples along the equation that generates the matrix. From the comments in the code, it looks like it's computing the convolution matrix values by integrating the gaussian bell curve (using 100 points total). Now I'm interested. Where can I look in the code for this? They really do this every time with the same results instead of just having an array of the numbers so generated? Patrick ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] unsharp mask
On 11/22/2010 09:59 PM, Patrick Horgan wrote: From the comments in the code, it looks like it's computing the convolution matrix values by integrating the gaussian bell curve (using 100 points total). Now I'm interested. Where can I look in the code for this? They really do this every time with the same results instead of just having an array of the numbers so generated? plugins/unsharp-mask.c, line 768 and up. It's not always the same results, because the blur radius is used as at the standard deviation of the integrated gaussian. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] unsharp mask
On 11/22/2010 12:59 PM, Patrick Horgan wrote: Now I'm interested. Where can I look in the code for this? They really do this every time with the same results instead of just having an array of the numbers so generated? Never mind. I saw it. It's depending on the radius which is a double. Even though double's aren't reals so it wouldn't be an infinite number of matrices required if you did it for each possible value less than 10 to would be an impossibly large number. Reading this code was a pleasure. Clearly written by someone who wants the code to be maintainable/comprehensible by others. Patrick ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] unsharp mask
On 11/22/2010 10:18 PM, Patrick Horgan wrote: On 11/22/2010 12:59 PM, Patrick Horgan wrote: Now I'm interested. Where can I look in the code for this? They really do this every time with the same results instead of just having an array of the numbers so generated? Never mind. I saw it. It's depending on the radius which is a double. Even though double's aren't reals so it wouldn't be an infinite number of matrices required if you did it for each possible value less than 10 to would be an impossibly large number. Reading this code was a pleasure. Clearly written by someone who wants the code to be maintainable/comprehensible by others. Well, I wondered too: the radius slider goes from 0 to 120 in .1 steps so that would be only 1200 values to pre-calculate. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] a reset...
GIMPsters, just FYI, but to escape out of a backlog of 641 GIMP devlist emails waiting for me with ever more not-so-trivial-as-one-thinks UI issues waiting for me, I had to set them all to read, and jump in again. on a more positive note, in order to get some UI work moving for GIMP again, I am in the process of creating (and paying for) two internships at my company. These two apprentices will work by default on GIMP under my direction. --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] unsharp mask
On 11/22/2010 01:26 PM, Ofnuts wrote:
Well, I wondered too: the radius slider goes from 0 to 120 in .1 steps
so that would be only 1200 values to pre-calculate.
They only do it for numbers less than 10 and the length
varies with the radius (from a low of 5 to a high of
45) as well. The total number of entries would be 2520
* 8 bytes for a gdouble so it would only need 20,160
bytes of storage, ideally but since C doesn't have
variable length arrays you'd have to declare the array
as something like:
static gdouble global_cmatrix[100][45];
which would make the length 4500*8=36000 bytes but of
course you'd have to store the length of each as well.
If you wanted to you could store them as unsigned
chars, so it would be another 100 bytes, or a total of
36100 bytes. In a trial it really added 36831 bytes.
How would that affect the usability of the plugin?
I've attached an include file that has the matrices you
would need. Then you could use:
static gint
gen_convolve_matrix (gdouble radius,
gdouble **cmatrix_p)
{
*cmatrix_p=global_cmatrix[(int)((radius*10)-.5)];
return cmatrix_lens[(int)((radius*10)-.5)];
}
I don't know if it would be a good idea or not.
Is it true though that the user interface only _allows_
values in tenths or is it that it only displays values
in tenths but returns values in between?
Patrick
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
static gdouble global_cmatrix[100][45]={
{
0.066057,0.249386,0.369113,0.249386,0.066057},
{
0.086233,0.243728,0.340077,0.243728,0.086233},
{
0.004653,0.101075,0.236695,0.315153,0.236695,
0.101075,0.004653},
{
0.014879,0.109394,0.228952,0.293550,0.228952,
0.109394,0.014879},
{
0.026040,0.115701,0.220929,0.274660,0.220929,
0.115701,0.026040},
{
0.037819,0.120277,0.212898,0.258013,0.212898,
0.120277,0.037819},
{
0.049946,0.123406,0.205029,0.243238,0.205029,
0.123406,0.049946},
{
0.002671,0.058980,0.125509,0.197673,0.230332,
0.197673,0.125509,0.058980,0.002671},
{
0.010389,0.064038,0.126343,0.190138,0.218185,
0.190138,0.126343,0.064038,0.010389},
{
0.018030,0.068458,0.126576,0.183198,0.207479,
0.183198,0.126576,0.068458,0.018030},
{
0.025583,0.072276,0.126348,0.176804,0.197977,
0.176804,0.126348,0.072276,0.025583},
{
0.034475,0.075309,0.125382,0.170380,0.188909,
0.170380,0.125382,0.075309,0.034475},
{
0.002555,0.040510,0.077849,0.124195,0.164488,
0.180807,0.164488,0.124195,0.077849,0.040510,
0.002555},
{
0.007970,0.043809,0.079879,0.122735,0.158923,
0.173366,0.158923,0.122735,0.079879,0.043809,
0.007970},
{
0.013744,0.046801,0.081459,0.121073,0.153668,
0.166510,0.153668,0.121073,0.081459,0.046801,
0.013744},
{
0.019815,0.049485,0.082646,0.119263,0.148705,
0.160171,0.148705,0.119263,0.082646,0.049485,
0.019815},
{
0.026127,0.051869,0.083492,0.117348,0.144016,
0.154295,0.144016,0.117348,0.083492,0.051869,
0.026127},
{
0.002084,0.030543,0.053965,0.084043,0.115365,
0.139584,0.148832,0.139584,0.115365,0.084043,
0.053965,0.030543,0.002084},
{
0.006461,0.032806,0.055791,0.084341,0.113339,
0.135390,0.143741,0.135390,0.113339,0.084341,
0.055791,0.032806,0.006461},
{
0.011089,0.034915,0.057365,0.084424,0.111294,
0.131421,0.138985,0.131421,0.111294,0.084424,
0.057365,0.034915,0.011089},
{
0.015933,0.036866,0.058707,0.084323,0.109245,
0.127659,0.134532,0.127659,0.109245,0.084323,
0.058707,0.036866,0.015933},
{
0.020963,0.038658,0.059837,0.084068,0.107206,
0.124091,0.130355,0.124091,0.107206,0.084068,
0.059837,0.038658,0.020963},
{
0.001760,0.024387,0.040292,0.060774,0.083681,
0.105188,0.120705,0.126428,0.120705,0.105188,
0.083681,0.060774,0.040292,0.024387,0.001760},
{
0.005431,0.026025,0.041774,0.061536,0.083185,
0.103197,0.117487,0.122730,0.117487,0.103197,
0.083185,0.061536,0.041774,0.026025,0.005431},
{
0.009287,0.027577,0.043109,0.062141,0.082599,
0.101241,0.114426,0.119241,0.114426,0.101241,
0.082599,0.062141,0.043109,0.027577,0.009287},
{
0.013308,0.029039,0.044304,0.062605,0.081936,
0.099323,0.111513,0.115945,0.111513,0.099323,
0.081936,0.062605,0.044304,0.029039,0.013308},
{
0.017473,0.030409,0.045367,0.062943,0.081212,
0.097446,0.108737,0.112825,0.108737,0.097446,
0.081212,0.062943,0.045367,0.030409,0.017473},
{
0.001523,0.020240,0.031687,0.046306,0.063169,
0.080438,0.095613,0.106089,0.109868,0.106089,
0.095613,0.080438,0.063169,0.046306,0.031687,
0.020240,0.001523},
{
0.004684,0.021476,0.032872,0.047130,0.063295,
0.079624,0.093826,0.103562,0.107062,0.103562,
0.093826,0.079624,0.063295,0.047130,0.032872,
0.021476,0.004684},
{
0.007986,0.022661,0.033967,0.047846,0.06,
0.078778,0.092084,0.101148,0.104396,0.101148,
0.092084,0.078778,0.06,0.047846,0.033967,
0.022661,0.007986},
{
