Sorry, not true :) It's rather pretty hard to do than completely
trivial. Yes, all format magic is hidden behind well-defined
APIs and can be safely extended, but adding arbitrary formats
there is not so trivial.
I did restrict myself to those 3 bullet points because they where the
ones I
Does this mean that in float bitdepths a pixel in a layer could have
negative RGBA values?
That could break compositing badly if those values are not clipped (and
clipping those out-of-bound values would destroy the original gamut,
defeating the purpose of the unbounded colorspace transform).
Simon is right, auto-updates are nice. I think GIMP should implement an
auto-update function for Windows. Perhaps the code for this can be copied
from Firefox.
When we talk about taking up developer time asking to implement a
(windows specific) auto-update system, which will also require a
I don't think it's fair to call that a consensus. We are currently at
a point where no one sees a sufficient reason to do it to overcome the
moral niggles about supporting another proprietary platform.
If someone was to figure out what exactly is required to distributed
via Steam and volunteer to
Which part of we have a contributor willing to maintain a build for
Steam, in my previous email do I need to clarify?
Levels of enthusiasm. If Michael wants to do it then there is not a
consensus stopping him from doing so; my interpretation of your email
was that he was only going to do it if
Sorry, the last time I heard about this before you posted this email
was you saying on IRC that drawoc had volunteered to do a build. I am
really not clear at this point why you posted a message saying we had
rejected the idea.
___
gimp-developer-list
the core team's opinion currently is that supporting a proprietary software
delivery platform doesn't feel right.
I took from this that either drawoc didn't really want to do it or
someone else had explicitly asked him not to.
There are several people who have legitimate gripes we this idea
The evil Use GimpApplicator checkbox on the paint tools will cause
them to render with a gegl graph that replicates the painting
functions (evil because it's slow). I do think we should have
pluggable tools in gimp, and using a graph editor to build tools would
also be cool. But I don't think they
All painting is GEGL based in 2.10; I don't think there is any plan to
allow arbitrary ops for painting. You can't retrieve coordinates is
because plugins run in their own process and can't access Gimp's event
loop or windows. It would be hypothetically possible for Gimp to pump
events across to
32bit floats have a precision of 24bits*. The exact size of the ulps**
(unit in the last place) in the range [0.0, 1.0] is more complex
because the exponent will give you more precision as you approach 0.
This gets even more complicated because actually doing any math most
likely gives you some
This appears to be something new, I would file a bug.
Standard questions:
What was the last version that worked?
What were you doing when it crashed?
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership:
$ python
Python 2.7.3 (default, Jul 24 2012, 11:41:40)
[GCC 4.6.3 20120306 (Red Hat 4.6.3-2)] on linux2
from gi.repository import Gegl
Gegl.init([])[]
params = Gegl.operation_list_properties(gegl:png-load)
(python:21947): GEGL-gegl-operations.c-WARNING **: Adding
GeglChantinvert-linear_c
Assuming were talking about gegl-master here, what are you unable to
do via introspection? The introspection bindings have full coverage of
the GEGL API. Mainipulating pixels directly (rather than though
operations) involves more copying in Python than is C because Python
has no concept of mutable
I've checked in a version of the generator script that should work
with both python 2 3.
On Mon, Oct 28, 2013 at 2:21 PM, Jon Nordby jono...@gmail.com wrote:
On 28 October 2013 21:18, Victor Oliveira victormath...@gmail.com wrote:
It looks like the problem is that this script depends of Python
You should bug mitch or me IRC for faster responses :).
Issues with this code:
Don't modify the buffer you got from gimp_pickable_get_buffer
(GIMP_PICKABLE (projection)), it's a live part of the projection.
Adding the buffer to the iterator twice probably doesn't do what you want
it to do.
The conversion happens in app/display/gimpdisplayshell-render.c :
gimp_display_shell_render() .
Look for the gegl_buffer_get call that converts to babl_format
(cairo-ARGB32).
It's more complicated that just that because the display filters all expect
sRGB u8 data still, but I suspect the best
This is something similar I've been working on, but I'm not sure how to
implement the live preview in Gimp.
I've found that when working with a stylus the circular motion is easier to
control than moving linearly left and right. It also keeps you near the
spot your working on even when making
For painting this issue got mostly evaded by the new graph code, but my
plan prior to that was to add a _blit() and _copy() function to projection
and use that in the spots that just want to pull pixel data out of it. That
will give it enough information about the request size to be smart, while
You might want to try running gimp with GEGL's swap turned off, this will
avoid filling up your drive with cache files:
GEGL_SWAP=RAM gimp-2.9
If you don't have OpenCL set up forcing it off will give a bit of a
performance boost (due to a bug in the detection code):
GEGL_USE_OPENCL=no
Does this mean Gimp and gegl would be competing for my meagre 4gb of
ram? I didn't know gegl wrote cache files. Where does gegl write its
cache files?
~/.cache/gegl-0.2/
Yes it will limit you to available ram for the image buffers; but if you're
in a circumstance where you would actually
20 matches
Mail list logo
