Hi all,
I've had a stab at a quick hack of gegl-0.1.6 to use libvips (another
demand-driven image processing library) as the backend for batch
processing. I think it is maybe an interesting way to look at gegl
performance, for this use case at least.
https://github.com/jcupitt/gegl-vips
Hello Øyvind, thanks for the reply.
On 17 April 2011 14:24, Øyvind Kolås pip...@gimp.org wrote:
On my c2d 1.86ghz laptop I get 105s real 41s user with default settings.
Setting GEGL_SWAP=RAM in the environment to turn off the disk swapping
of tiles makes it run in 43s real 41s user.
I found
Hi Chris,
On 29 March 2011 16:28, Chris Moller mol...@mollerware.com wrote:
(The utterly prosaic background of this question is that my wife runs an
eBay business for which I am the reluctant photographer. Frequently, I
take multiple pictures of the same object, under the same lighting,
On 2 March 2011 12:52, Graeme Gill grae...@argyllcms.com wrote:
jcup...@gmail.com wrote:
As a result of this strange design, it's impossible on Windows to
write a .exe that can be used smoothly both from the command-line and
from the desktop.
I've written a couple of applications that run
On 1 March 2011 05:00, Roger Penn roger.p...@gmail.com wrote:
work out all the how's and so-forth, but for now if anyone knows the inner
workings of gimp-quit or why calling gimp.exe from the command line forks
two gimp processes I'd sure be grateful for some insight. Thanks.
I might be able
, argh.
Just in case it is the wrapper that's broken, here's the wrapper
program I use, written for me by a Windows expert friend:
https://github.com/jcupitt/nip2/blob/master/src/nip2-cli.c
Perhaps it might be useful.
John
___
Gimp-developer mailing
On 24 January 2011 03:30, Christopher Curtis ccurt...@gmail.com wrote:
If I add another '0' to the perl line I get a seg fault as well. Must
be a not-quite 64-bit limit.
Off-topic, but could someone explain why this isn't a stdio bug? Or is
it a known bug and this is the accepted workaround?
On 13 December 2010 19:56, Sven Neumann s...@gimp.org wrote:
This is GIMP based on GTK+ for X11. It needs an additional X11 server
running on OS X and thus integration into the system is very poor. What
I was talking about is the Quartz backend for GTK+ which allows GIMP to
run as a native
On 7 December 2010 22:07, Sven Neumann s...@gimp.org wrote:
in GIMP on OS X. Even though there's a pretty well working Quartz port
of GTK+, there haven't been any successful attempts to make a binary
GIMP installer from this (as far as I know). I very much doubt that
gtk-osx is used to make
On Thu, 2010-10-21 at 23:23 +0200, Martin Nordholts wrote:
If someone starts experimenting with this, I suggest making littlecms
one of potentially backends, so that we can compile against the native
color management library of a platform when available.
The native CMS is often horribly
On 13 August 2010 02:57, James Cox jay...@gimp.org wrote:
You don't need to worry that the sRGB gamut is rather small since,
because GEGL is using float, it can represent values outside the gamut
as less than 0 or greater than 1.
That sounds good in theory, but there will be some very sharp
On 12 August 2010 00:17, Edward Coffey edward.cof...@gmail.com wrote:
My understanding of GEGL (and, I assume, a fully GEGL-based GIMP) is
that colors will be represented internally as linear-light RGB(A)
structures. Given that (and please correct me if I'm already veering
off track), how are
On 10 March 2010 08:04, Sven Neumann s...@gimp.org wrote:
BUT... that little double-arrow thingy at the bottom of the curves
graph reverses black/white positions.
Sorry, but the fact that another program has a toggle button for this is
not an argument for adding such a toggle button to GIMP.
2009/10/22 Martin Nordholts ense...@gmail.com:
I have the impression that the least painful way to make GEGL fast
SOON may be to build its desired API on top of VIPS.
We can't use VIPS in GIMP because we need a dynamic graph.
In practice that also rules out implementing GEGL with VIPS.
You
Hi Martin,
2009/10/22 Martin Nordholts ense...@gmail.com:
It doesn't seem feasible from a performance perspective to construct
complex compositing graphs from scratch all the time. For example, can
caches be reused between VIPS pipeline setups?
That's true, there is a cost there. I would
2009/7/8 yahvuu yah...@gmail.com:
Nicolas Robidoux schrieb:
At start-up, the user could be presented with a list of unfinalized
workspaces, and asked whether to finalize each, or open each.
just for clarification: by workspaces you're referring to nip2 workspaces,
which roughly translate to
2009/1/24 David Gowers 00a...@gmail.com:
a) You should investigate implementing this interpolation method for
GEGL rather than GIMP, as in the fairly near future these kinds of
transformations in GIMP will be implemented through use of GEGL.
My understanding is that this will not be possible
2009/1/20 sanju More sanjee...@inetfi.com:
Is it possible to cross compile gimp2.6.4? i am trying to cross compile
gimp2.6.4 with arm-linux-gcc. Pleae let me know the procedure to do this.
Is there any toolchains required?
I cross-compile from x86 linux to windows and I imagine it's pretty
2009/1/20 sanju More sanjee...@inetfi.com:
But i need gimp2.6.4 to be cross compiled with arm-linux-gcc. For this i need
to cross compile all these packages(babl,gegl,glib...) and then gimp2.6.4 or
just i need compile gimp2.6.4
I'm afraid you'll have to build almost averything, from glibc
2008/11/20 Guillermo Espertino [EMAIL PROTECTED]:
A better solution (and I think that the porting to GEGL is aiming in
this direction, among other things) would be to put the filter and the
transformations in a sort of queue, so the interaction is never blocked
and the processes are stacked so
20 matches
Mail list logo
