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
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
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,
th
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
founder
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
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
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, accesib
Hi,
On Tue, 2008-03-25 at 07:40 -0600, Joshua Stratton wrote:
> Well, I do not know the current status of GEGL in GIMP's code,
> although I do believe it is the right way to go (from the GEGL
> presentations I have seen). I was assuming much of GEGL's
> implementation would be transparent to t
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
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 rat
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 pret
> 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 :)
12 matches
Mail list logo
