On Sun, Nov 20, 2011 at 2:55 AM, Alexandre Prokoudine
wrote:
> babl 0.1.6 9as well as Git master) fails to build on Ubuntu 11.10:
> http://pastebin.com/9x5e8PsG
>
> I'd file it to bugzilla, but apparently there is no babl component.
It will probably build if you pass --disable-introspection but r
On Fri, Dec 23, 2011 at 10:51 AM, Alexander Hämmerle
wrote:
> Hi,
>
> there seem to be some quirks in babl.
>
> 1) ./babl/base/model-cmyk.c
I've removed this file, it was unused also when building the git version.
> 2) ./babl/extensions/naive-CMYK.c
> 3) More stunning for me: model-cmyk.c exist
On Wed, Dec 28, 2011 at 5:20 PM, Alexandre Prokoudine
wrote:
> On Wed, Dec 28, 2011 at 9:19 PM, Alexander Hämmerle wrote:
>
>> I'm very interested in a more ambitious implementation of the
>> CMYK-colorspace.
>> Also because I would like to do more experimentation with printed outputs of
>> proce
On Thu, Mar 29, 2012 at 4:12 PM, wrote:
> This message has two subjects.
> 1. Is there a gaussian reduce operation in GEGL? Refer to the paper by Burt
> and Adelson, 1983, where it is called REDUCE and apparently claims that it is
> faster than operation gaussian blur followed by down-sample (
On Thu, Mar 29, 2012 at 8:10 PM, wrote:
> OK. It is not clear to me that the new API using GeglBuffers will let Python
> plugins use GEGL,
> only C-language plugins, unless there are more changes to, for example, the
> GIMP PDB or to Pygimp.
> But I understand it is not high priority, since fe
to drop cached tiles.
• Added API for handling abyss policy (not implemented yet)
• Avoid iterating global tile cache when flushing/destroying buffers
that have no tiles in the cache.
This release of GEGL was brought to you through contributions from:
Øyvind Kolås, Martin Nordholts
On Thu, Apr 5, 2012 at 10:40 AM, Zhang Peixuan
wrote:
> Hello All,
> I tested GEGL-0.2.0 on GIMP 2.8-RC1, I change some code for
> GIMP-2.8.RC1:
>
> app/gegl/gimpoperationtilesource.c
>
> gimp_operation_tile_source_prepare (GeglOperation *operation)
> {
> GimpOperationTileSource *self = G
On Tue, Apr 10, 2012 at 11:12 PM, johannes hanika wrote:
> actually darktable's pixel pipeline was based on gegl as the project
> started (you'll still notice some #ifdef HAVE_GEGL if you look around
> the code closely). that was 2-3 years ago and at that time it turned
> out a simple DIY pipeline
ld want you to directly poke
master.. we can arrange direct access to the GEGL master git repo.
/Øyvind Kolås
--
___
gegl-developer-list mailing list
gegl-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gegl-developer-list
On Thu, Jul 5, 2012 at 6:07 PM, gfxuser wrote:
> I was also wondering why not XML. IIRC image processing in GEGL is
> internally represented by a tree (correct me if I'm wrong). Are YAML and
> JSON able to handle this, better than a native tree format like XML?
The reason that a new/extended form
.92 = 0.003040247678
> ((0.03928 + 0.055)/1.055)^2.4 = 0.003039492412
> continuity error of 1 part in 4e3
>
> So the util.h values are a lot less smooth than the sRGB standard values.
Thank you both, I've pushed changes that should make babl adhere to
the current standard
On Thu, Dec 27, 2012 at 5:25 AM, Victor Oliveira
wrote:
> For now, I've been using the gegl op tool in gimp to test gegl
> operations with OpenCL.
> But it shouldn't be hard to create a simple filter using the gegl API
> and test performance.
>
> If you want to enable OpenCL, just set the GEGL_USE
On Sun, Feb 24, 2013 at 8:02 AM, Alexandre Quessy wrote:
> Hello everyone,
> I am trying to build a simple program using GEGL, but I fail.
> It's the simple program in the http://www.gegl.org/ page.
> Here is the command line I used:
>
> $ gcc fractal.c `pkg-config --libs --cflags gegl` -o fractal
On Mon, Feb 25, 2013 at 8:37 AM, Alexandre Quessy wrote:
> Hello again,
>
> 2013/2/24 Alexandre Quessy :
>> Now, I am facing another issue: there is no "display" operation.
>>
>
> Maybe I should build a more recent version ot it to get more operations?
Of course you should if you intend to try to
On Tue, May 28, 2013 at 5:27 PM, Dov Grobgeld
wrote:
> > I finished a saver operation for floating point npy images. It may e.g.
>> be
>> > used to debug floating point operations (e.g. gaussian-blur) with
>> numerical
>> > python. The resulting image may be read into numpy as follows:
>> >
>> >
On Sun, Jun 9, 2013 at 2:52 PM, Daniel Sabo wrote:
> Mike Henning noticed that this file is actually licensed GPL. It looks
> like the only contributors are mitch and pippin, but I don't know what they
> might have used code from. Is the copyright on this clean? Can we change
> the license to LGP
ve them adjecant to the .c files when they correspond to
single ops; and have rules about how to deal with
opname.c
opname.cl
opname.cl.h
all co-existing in the same directory.
/Øyvind Kolås
___
gegl-developer-list mailing list
List address:gegl-dev
On Wed, Mar 12, 2014 at 10:27 PM, Elle Stone
wrote:
>> In the New GEGL World, converting between different channel layouts is
>> going to be a reality, and we should at least put _some_ thought into
>> what that means for color management. Of course, this is way out of my
>> depth, and I have no
On Fri, Mar 14, 2014 at 2:21 PM, Elle Stone
wrote:
> I looked at the code. Some questions come to mind:
>
> 1. LCMS2 has CMYK soft proofing and also ink-limiting already covered.
> Here's the ink-limiting algorithm, quoted from the LCMS API (looks similar
> to the GEGL code):
>
> Ink-limiting algo
On Sun, Mar 16, 2014 at 10:22 PM, Elle Stone
wrote:
> On 03/14/2014 10:34 AM, Øyvind Kolås wrote:
>>
>> On Fri, Mar 14, 2014 at 2:21 PM, Elle Stone
>> wrote:
>>>
>>> But a
>>> patch to LCMS for more than four inks is surely possible.
Doing soft sp
The autogenerated UIs for GEGL operations work well; but for many
operations additional information about how to
render/group/pre-initialize defaults not based on storage type but
depending on
the property role as control data for the operation.
The first time such data was needed; an additional p
On Tue, May 6, 2014 at 2:40 PM, Matteo F. Vescovi wrote:
> Hi all!
>
> As reported at [1], it seems like gegl has a weird behaviour when
> running using an image with transparency as input.
>
> Any idea how to fix it? Has it been solved already in git repository?
Using the same test image and com
GEGL master can now be thread-accelerated. Different approaches have
been tried; the approach that first yielded promising results was
parallelizing each individual operations process call. Most GEGL
operations now have threading support; some are opted out of the
automatic threading provided by th
On Thu, Sep 4, 2014 at 9:48 PM, Teo Mazars
wrote:
...
> add a "gamma-correction" toggle if needed (like the "srgb" boolean in over.
In this particular instance I would offer the opposite advice :).
Remove the "gamma-correction" toggle / "srgb" boolean, and create a
separate "gegl:over-perceptual"
On Fri, Sep 5, 2014 at 2:24 PM, Téo Mazars wrote:
> I am not convinced. The way it's done is fine in my opinion, mainly because
> it doesn't duplicate the implementation. What you suggest would be to create
> specialized meta operations foo-linear and foo-perceptual on top of foo with
> fixed "srg
On Sat, Oct 4, 2014 at 2:46 PM, Elle Stone
wrote:
> Based on the groundless premise that editing operations should produce the
> same results when performed on the same colorimetric colors, ..
No; but same parameters for same input colors producing same results
is considered desirable behavior. P
On Sun, Oct 5, 2014 at 5:16 PM, Elle Stone
wrote:
> On 10/04/2014 11:59 AM, Øyvind Kolås wrote:
>>
>> On Sat, Oct 4, 2014 at 2:46 PM, Elle Stone
>> wrote:
>>>
>>> Based on the groundless premise that editing operations should
>
> produce the
&g
On Mon, Oct 6, 2014 at 6:57 PM, Elle Stone
wrote:
> On 10/05/2014 12:49 PM, Øyvind Kolås wrote:
> You've conceded that your architecture is broken to the point where you must
> hack in fixes for multiply. That's the first of many such hacks to come:
This is not the first such
On Tue, Oct 7, 2014 at 8:10 PM, Elle Stone
wrote:
> I'm posting to the original thread. Pippin had started a new thread:
> https://mail.gnome.org/archives/gimp-developer-list/2014-
gmail started a new thread when I tired to change the alarmist subject.
> Brasseur shows why scaling needs to be do
On Tue, Oct 7, 2014 at 9:23 PM, Elle Stone
wrote:
> You could accomplish guiding users as to the right choices regarding linear
> vs perceptual by creating presets and allowing users the freedom to control
> their own editing decisions. You don't have to build fences around what
> people can do wi
On Tue, Oct 7, 2014 at 10:20 PM, Elle Stone
wrote:
> Who decides what's common and what's rare for an artist to want to do? The
> GIMP devs? Isn't that just a trifle presumptuous?
>
> These kinds of decisions belong with the users, not the devs.
I'm sorry but you've crossed the line from being a
On Wed, Oct 8, 2014 at 3:25 PM, Elle Stone
wrote:
> On 10/07/2014 08:23 PM, Øyvind Kolås wrote:
>> The choice of something "close" to sRGB is to have efficient
>> integration with libpng/libjpeg/gtk/v4l/ffmpeg (in addition to raster
>> layers stored in sRGB
On Fri, Oct 10, 2014 at 6:36 PM, Elle Stone
wrote:
> On 10/09/2014 07:52 PM, Michael Henning wrote:
>> On Thu, Oct 9, 2014 at 7:22 PM, Elle Stone
> So where in the conversion to XYZ and then to LAB (or any other reference
> color space) will "sRGB as PCS" fit in?
> Of course you could convert fr
On Fri, Oct 10, 2014 at 9:38 PM, Elle Stone
wrote:
> You cannot get from "sRGB as PCS" to LAB without first converting from "sRGB
> as PCS" to XYZ. LAB is a mathematical transform of XYZ, not sRGB.
>
> This is the normal path from User_RGB to LAB: User_RGB -> XYZ -> LAB. Two
> conversions.
>
> You
On Sat, Oct 11, 2014 at 1:18 AM, Elle Stone
wrote:
> I really don't want to forget about LAB. The plan is that "sRGB as PCS" will
> be used for "something". I'm trying to figure out what exactly "something"
> covers. So I have two specific questions. The first question is about
> converting to LAB
On Sat, Oct 11, 2014 at 1:41 PM, Elle Stone
wrote:
> As I have indicated before, the invitation is very kind. But not everyone is
> able to drop other obligations and go to LGM.
>> until then I prefer IRC.
>
> Twice I tried to discuss problems with unbounded sRGB on IRC. It was neither
> pleasant
> Please provide a specific example of an actual CMM in an ICC profile
> workflow that doesn't use XYZ for converting between RGB working spaces.
Please read simons post about matrix multiplication, in his camera
example the data never exists as XYZ.
> You falsely assume that 8-bit images are alw
On Sun, Oct 12, 2014 at 8:41 AM, Elle Stone
wrote:
> On 10/11/2014 08:52 PM, Jon Nordby wrote:
> Please correct me if I misunderstood what you are saying. I think you are
> saying:
>
> GIMP uses GTK+.
>
> GTK+ uses Cairo APIs for rendering to the screen.
>
> Cairo APIs assume 8-bit sRGB.
>
> There
On Mon, Oct 13, 2014 at 8:19 PM, Elle Stone
wrote:
> The "sRGB as PCS" architecture outline in babl/docs/roadmap.txt will likely
> collapse under its own weight. The roadmap should be amended to reflect a
> more accurate assessment of the amount of work the planned architecture will
> entail.
>
>
On Tue, Oct 14, 2014 at 12:34 AM, Elle Stone
wrote:
> You designed an architecture around converting images to unbounded sRGB for
> editing.
>
> After 6 months of trying to show you that your architecture has serious
> built-in problems, you finally believe me, or at least you believe Mansencal
>
On Tue, Oct 14, 2014 at 11:20 AM, Elle Stone
wrote:
> On 10/13/2014 06:36 PM, Elle Stone wrote:
>>
>> How do you plan to tell when an image is an sRGB image and when it's not
>> an sRGB image?
>
>
> The roadmap specifies 24 different formats for sRGB images and 24 additional
> formats for non-sRGB
On Tue, Oct 14, 2014 at 1:34 PM, Elle Stone
wrote:
> The above sentence confuses concepts: The babl architecture might require
> that images to be converted to and from unbounded linear gamma sRGB. That
> doesn't mean babl is a CMS. And it doesn't mean unbounded linear gamma sRGB
> has been turned
On Wed, Oct 15, 2014 at 2:11 PM, Elle Stone
> When the user opens a color-managed fooRGB image, for which *specific*
> editing operations will the image be converted to unbounded sRGB?
>
> This isn't just an implementation detail. The answer to this question will
> determine the path for writing co
On Thu, Oct 16, 2014 at 6:52 PM, Elle Stone
wrote:
> On 10/15/2014 01:46 PM, Simon Budig wrote:
> If I understand them correctly, Michael Henning and Jon Norby are saying
> that the criteria is something along the lines of: "For RGB editing
> operations, use UserRGB primaries *unless* there's a re
On Fri, Oct 17, 2014 at 12:49 AM, Jon Nordby wrote:
> you are answering in detail 'how we will get "there"' but Elle (as I see it)
> is asking more 'do you agree that we want to go "there"'. This leaves me
> unsure if you are implicitly agreeing, if you disagree and have a different
> "there" in m
On Fri, Oct 17, 2014 at 12:01 PM, Elle Stone
wrote:
> On 10/16/2014 03:37 PM, Øyvind Kolås wrote:
>>
>> On Thu, Oct 16, 2014 at 6:52 PM, Elle Stone
>> wrote:
>>>
>>> Is there in fact general agreement among the devs that the criteria for
>>> decidi
A note that the babl roadmap towards enabling use of multiple
working/sensor/target RGB spaces in a single GEGL graph has been
slightly updated. Now also mentions why accumulating floating point
errors if more conversions than desired happens isn't a real concern
with current photo technology senso
On Wed, Nov 19, 2014 at 7:33 PM, Victor Oliveira
wrote:
> I was actually giving a look at that this morning and figuring out
> with Daniel Sabo if that's really the case.
>
> Pippin, did you delete that code on purpose?
Nope, removal of the code making OpenCL work definetely would have
been unint
On Fri, Nov 21, 2014 at 3:59 AM, Nanley Chery wrote:
> Thanks for the quick fix, it's working on my system.
>
> I noticed that you've enabled GPU's by default due to some testing. Where
> can I find these results? According to my tests among two operations
> Edge-laplace and Video-degradation (cu
On Mon, Dec 15, 2014 at 11:00 PM, Nanley Chery wrote:
> Is there a way for an operation (e.g. blur) to call another operation (e.g.
> rotate) in it's process function?
Composite operations do exist, in GEGL they are called
meta-operations, some examples are gegl:unsharp-mask, gegl:dropshadow
and
On Sun, Dec 21, 2014 at 4:39 PM, Nanley Chery wrote:
> Why don't operations like gegl:add and gegl:multiply clamp the resulting
> values between 0.0 and 1.0? Won't this potentially result in garbage rgb
> values?
The RGB values used by GEGL are not bounded by the gamut of a color
space. Out of ga
On Fri, Feb 13, 2015 at 12:52 PM, Joao S. O. Bueno wrote:
> Ok, if people are committed to it, that means it is not left
> to die, and it is a matter of fixing it in GEGL (and GIMP soon).
>
> I've been looking around, one problem seems to be that since BABL
> has no introspection, any functions re
On Tue, Mar 17, 2015 at 10:20 PM, Elle Stone
wrote:
> Everything works faster on a smaller image.
A good observation, and the rationale for plans that are already
partially implemented.
> Unlike simpler edits like Curves, currently the transform tools don't save a
> record as a recallable transf
On Tue, May 26, 2015 at 10:50 AM, Alexandre Prokoudine
wrote:
> On Tue, May 26, 2015 at 10:28 AM, wrote:
>> Hi,
>> I have written some operations for my own use into gimp.
>> Let me know if you are interested by some of them, I will write tests and
>> push to master.
For ops that you are uncer
Claussner, Téo Mazars,
Thomas Manni, Tim Lunn, Tim Mooney, Ting-Wei Lan, Tom Stellard, Ulf-D.
Ehlert, Vadim Rutkovsky, Victor Oliveira, Ville Sokk, Vincent Untz, Yongjia
Zhang, Yongjia Zhang, Øyvind Kolås and 周 周.
Where to get GEGL:
The latest versions of GEGL and it's hard dependencies bab
On Mon, Jun 8, 2015 at 9:15 PM, Thorsten Stettin
wrote:
> do you really need libraw >= 0.16.0?
>
> I have some trouble with the recent version in Ubuntu Trusty - 0.15.4.
> You know - dependency nightmare.:'(
If it compiles and thus probably works with an older version - I see
no reason to make th
,
Michael Natterer, Necdet Yücel, Pedro Albuquerque, Piotr Drąg, Roman Lebedev,
Sven Neumann, Thomas Manni, Vilson Vieira, akash akya and Øyvind Kolås.
Where to get GEGL:
The latest versions of GEGL and it's hard dependencies babl and glib can be
fetched from:
http://download.gimp.org/pub/babl/0.1
On Fri, Jan 29, 2016 at 5:41 AM, Sven Claussner wrote:
> On 28.1.2016 at 10:29 PM Daniel Rogers wrote:
>> I am confused. What technical reason exists to assume gegl cannot be as
>> fast as vips? Is it memory usage? Extra necessary calculations? Some way
>> in which parallelism is not as possible
On Mon, Feb 1, 2016 at 10:35 PM, Daniel Rogers wrote:
>>> * Anyone can do dynamic compilation nowadays with llvm. Imagine
>>>
>>> taking the gegl dynamic tree, and compiling it into a single LLVM
>>> dynamically compiled function.
>>
>> What exactly do you mean? How is this supposed to
On Sun, Feb 21, 2016 at 1:49 AM, Eric Omine wrote:
> Hello,
> I'm trying to build GEGL and I'm getting a lot of these:
>
> (lt-gegl-tester:23490): GEGL-gegl-node.c-WARNING **: Failed to set operation
> type gegl:text, using a passthrough op instead
>
> (lt-gegl-tester:23490): GEGL-gegl-node.c-WARN
On Mon, Mar 21, 2016 at 3:49 PM, richard brown
wrote:
> I've been running gimp 2.9 in my home directory for some time now. Recently
> however, gegl 0.3.2, 0.3.4 and 0.3.6 have all failed to build, I have
> current git pulls of glib, babl, gexiv2, harfbuzz. gegl 0.3.0 does build,
> however. The c
Please use bugzilla which is GEGLs normal patch/bug handling system.
I've pushed these changes to git master - albeit with slightly
deteriorated meta data since the diffs were manually incorporated.
/pippin
On Sun, May 15, 2016 at 1:04 AM, Jan Vesely wrote:
> Signed-off-by: Jan Vesely
> ---
>
On Sun, Nov 6, 2016 at 3:46 AM, nek0 wrote:
> Hi folks,
>
> I am currently attempting to write Haskell bindings to the GEGL library.
> In that proces sof making I encountered a problem with the operations of
> gegl. There is not really an up to date guide or compendium of these
> available online.
On Wed, Dec 28, 2016 at 11:34 PM, Vincent
wrote:
> gegl_buffer_set(buf, &_rect, 1, format, image_buffer,
> GEGL_AUTO_ROWSTRIDE);
> The problem is that all I get from this code is segfaults. What did I
> miss? Isn't gegl-gtk supposed to display the image data given by the
> output port of a n
On Thu, Jan 5, 2017 at 2:08 AM, Vincent
wrote:
> Thank you both for your answers. I finally made a sample application
> that reads a FITS file and tries to display the first channel's grey
> buffer in a gegl-gtk object.
>
> The code is here:
> https://free-astro.org/svn/siril/trunk/src/main_gegl_t
ious new performance short-cuts and profiling cache
improvements.
This release of GEGL was brought to you through contributions from:
Piotr Drąg, Marco Ciampa, Sergey "Shnatsel" Davidoff, Ell, Michael Hennig,
Anders Jonsson, Christian Kirbach, Øyvind Kolås, Thomas Manni, Jordi Mas,
Michael Na
GEGL was brought to you through contributions from:
Alexandre Prokoudine, Debarshi Ray, Dimitris Spingos (Δημήτρης
Σπίγγος), Jordi Mas, Martin Srebotnjak and Øyvind Kolås
Where to get GEGL:
The latest versions of GEGL and babl can be fetched from:
http://download.gimp.org/pub/gegl/0.3/gegl
On Mon, Nov 27, 2017 at 7:38 AM, Chris Clayton via gegl-developer-list
wrote:
> Hi
>
> gegl-0.3.24 and babl-0.1.38 have been released recently, but in neither case
> have the SHASUMS files been regenerated.
>
> Where possible, I like to verify sources before building and installing on my
> syste
On Fri, Dec 1, 2017 at 12:06 AM, Tom Lechner wrote:
> I'm trying to figure out how to translate various data types for use with
> gegl. For instance, I want to set a GeglColor on a property. The example
> sdl-draw.c uses GeglColor directly in gegl_node_new_child(), but if I try to
> do this with g
Packagers for linux distributions should update the recipes for babl
and GEGL, and new releases of GIMP 2.10.6 for flatpak/snap/OSX/windows
with the new babl and GEGL is desirable.
Before in the 2.10 releases we have synchronized the releases of babl,
GEGL and GIMP. This synchronization has been a
On Mon, Oct 22, 2018 at 3:13 PM Øyvind Kolås wrote:
> Packagers for linux distributions should update the recipes for babl
> and GEGL, and new releases of GIMP 2.10.6 for flatpak/snap/OSX/windows
> with the new babl and GEGL is desirable.
>
> Before in the 2.10 releases we have s
Sorry for the delayed reaction, thank you for the patch which has been
integrated in the git repo.
In addition to git/gitlab and infrequently used mailinglist, the
developers do chat in the IRC channels #gegl and #gimp on GIMPnet -
also used by GNOME on irc.gimp.org
Note that the OpenCL code in G
On Mon, Jan 21, 2019 at 3:10 PM Debarshi Ray wrote:
>
> On Mon, Jan 21, 2019 at 09:54:01AM +0100, Richard B. Kreckel wrote:
> > > Note that the OpenCL code in GEGL works but multi-core CPU code most
> > > often will be faster (in particular in GIMP with lower OpenCL coverage
> > > of operations th
A different operation would be better, though the operation in
question exists in GIMP and not in GEGL.
This is because the curves op in GIMP is not properly
migrated/implemented to be part of GEGL, it is controlled with
properties on a "configuration object" and thus as-implemented is only
suitab
On Tue, Jan 21, 2020 at 9:49 AM JonnyRobbie via gegl-developer-list
wrote:
>
> For example, let's say I'm developing a gimp plugin and I'm using
> gegl_buffer_iterator_* to get the data. And I want to manipulate the data in
> profile connection space CIE xyY. I have:
If you are creating an imag
On Sat, Jan 25, 2020 at 2:58 PM JonnyRobbie via gegl-developer-list
wrote:
> It is true that I might do away with a gegl operation to get the auto
> constructed parameter UI. But I would need more than one input image. In my
> mind/design, there's this main layer which would get this filter appl
Thanks for pointing this out. Both gegl:convert-space and
gegl:cast-space are working and it is a glitch that they are not
packaged yet. I've added them to the build. In general these
operations should be unnecessary *unless* one needs to override the
implicit color management in the graph.
/pippi
On Wed, Nov 18, 2020 at 10:08 PM JonnyRobbie via gegl-developer-list
wrote:
> I think it is rude to send emails and questions directly open source
> developers
> when there is mailinglists - please use the mailinglists.
>
> I didn't mean to offend you in any way. I'm still having some trouble wit
On Wed, Nov 18, 2020 at 10:08 PM JonnyRobbie via gegl-developer-list
wrote:
> I really hope this is just some misunderstanding. I was just having problems
> with gegl and I was hoping someone on gegl mailing list might be able to help
> me.
I'm sorry about the grumpiness due to the off-list rep
On Sun, Nov 29, 2020 at 2:43 PM JonnyRobbie via gegl-developer-list
wrote:
>
> I still feel like I haven't gotten the hang on it.
Your expectations of gegl:convert-space 's behavior is mostly right,
it was the code that wasn't ready but a rather good
draft had been written and presumed to work wh
On Fri, Jan 8, 2021 at 2:02 PM JonnyRobbie via gegl-developer-list
wrote:
>
> You can do a merge request for GEGL on GNOME's Gitlab instance:
> https://gitlab.gnome.org/GNOME/gegl/.
>
> Good. Just a question. What category (comon, comon-cxx, core, external, ...)
> should I put it in? Also, it inc
On Fri, Jan 8, 2021 at 5:44 PM JonnyRobbie via gegl-developer-list
wrote:
>
> > Maybe having
> > everything in the .c single file with enums and forward declarations
> > for the data early and the data after the operation code?
>
> Locally, I use an external python script in a meta-programming way
Your fixes would break the GEGL build when using the most recent babl
library, I have pushed changes to GEGL that should make it possible to
build GEGL with very old babl again. The best course of action for you
will be updating your babl and trying again (since you already have a
recent meson, the
83 matches
Mail list logo
