Guillermo, I would encourage you towards formalizing this application -
try to summarize objectively what exists today and what do you plan to
implement. Also, try some guestimates on a time frame for completing
each task.
Joao: Unfortunately I'm not a coder. I'm not even a student :)
Just
Hi,
On Tue, 2008-03-25 at 10:06 -0700, Bill Skaggs wrote:
If you can build the svn-trunk version of gimp (which by the way
is a very useful thing to do if you are interested in soc), you
can find there a new gegl tool that allows a long list
of operations to be performed, but has a pretty
Hi,
On Tue, 2008-03-25 at 20:20 -0400, Robert Krawitz wrote:
A lot of what was described about separate+ is already present in the
Gutenprint plugin for GIMP (and I think also in Cinepaint), and also
in PhotoPrint, which is a standalone application layered on the
Gutenprint core. I'd rather
Hi,
On Wed, 2008-03-26 at 04:07 -0300, Guillermo Espertino wrote:
About the plugin itself, it already provides profiles management.
Profile management should be left to the GIMP application and to widgets
provided by it. It doesn't make sense if every plug-in does its own
thing here.
It's
Well, I guess I'm a little confused about the actual purpose of GEGL. It
sounded like it would provide a more formal and robust interface for GIMP's
image processing. GEGL might be a good choice if the current tools are hard
to interface with, but I really wanted all filters, for example,
Hi,
2008/3/26, Sven Neumann [EMAIL PROTECTED]:
Whatever you do to the image is represented as a graph. If you are doing
a series of operations on an image, then your graph boils down to a load
operation, a chain of manipulations and a save operation.
Do you mean every stroke path like
Hi,
On Thu, 2008-03-27 at 00:55 +0900, Souichi TAKASHIGE wrote:
Do you mean every stroke path like interactive paint tool MUST become
an graph nodes ?
Probably not an individual graph node, but it will be kept in a paint
operation node which itself stores each stroke so that it can be edited
hey GIMPsters,
let me give you an update here.
in the last 10 days the concept and spec has matured quite a bit.
the feedback and plain old bug reports, both here and on the IRC
went into what is being built right now.
check it out when you have the chance.
thanks,
--ps
Hi,
I run Gimp 2.2 on a Red Hat machine. The Perl scripts delete the images
that are created by using gimp_image_delete. Even so, the swap file is
created and it inflates significantly. For instance, after creating 250
images its size is of 2.7 MB. If the image is not deleted in the script,
Andrei Simion [EMAIL PROTECTED] wrote:
I run Gimp 2.2 on a Red Hat machine. The Perl scripts delete the images
that are created by using gimp_image_delete. Even so, the swap file is
created and it inflates significantly. For instance, after creating 250
images its size is of 2.7 MB. If
Andrei Simion wrote:
I run Gimp 2.2 on a Red Hat machine. The Perl scripts delete the images
that are created by using gimp_image_delete. Even so, the swap file is
created and it inflates significantly. For instance, after creating 250
images its size is of 2.7 MB.
I have done some work on
11 matches
Mail list logo
