Re: [Gegl-developer] fixes to gegl-0.4.38 to get it compileable

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,

Re: [Gegl-developer] New operation pull request

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

Re: [Gegl-developer] New operation pull request

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

Re: [Gegl-developer] gegl:convert-space

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

Re: [Gegl-developer] gegl:convert-space

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

Re: [Gegl-developer] gegl:convert-space

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

Re: [Gegl-developer] gegl:convert-space

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.

Re: [Gegl-developer] Is gegl_buffer_* aware of source color profile?

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

Re: [Gegl-developer] Is gegl_buffer_* aware of source color profile?

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

Re: [Gegl-developer] OpenCL platform

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

[Gegl-developer] note to packagers: partially desynchronising babl, GEGL and GIMP releases cycles

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

Re: [Gegl-developer] babl and gegl: SHA{1, 256}SUMS files not updated

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

Re: [Gegl-developer] VIPS and GEGL performance and memory usage comparison

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

Re: [Gegl-developer] VIPS and GEGL performance and memory usage comparison

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

Re: [Gegl-developer] [Gimp-developer] Question regarding Gegl commit 73ca89e42f5b0f0290d08be05650f0b86ffe5ec9

On Mon, Jun 8, 2015 at 9:15 PM, Thorsten Stettin thorsten.stet...@gmail.com 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

Re: [Gegl-developer] Returning to python-gegl

On Fri, Feb 13, 2015 at 12:52 PM, Joao S. O. Bueno gwid...@mpc.com.br 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,

Re: [Gegl-developer] Clamping results to valid range

On Sun, Dec 21, 2014 at 4:39 PM, Nanley Chery nanleych...@gmail.com 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

[Gegl-developer] babl roadmap ever so slightly updated

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

Re: [Gegl-developer] [Gimp-developer] babl roadmap

On Fri, Oct 17, 2014 at 12:01 PM, Elle Stone ellest...@ninedegreesbelow.com wrote: On 10/16/2014 03:37 PM, Øyvind Kolås wrote: On Thu, Oct 16, 2014 at 6:52 PM, Elle Stone ellest...@ninedegreesbelow.com wrote: Is there in fact general agreement among the devs that the criteria for deciding

Re: [Gegl-developer] [Gimp-developer] babl roadmap

On Tue, Oct 14, 2014 at 12:34 AM, Elle Stone ellest...@ninedegreesbelow.com 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

Re: [Gegl-developer] babl roadmap: How do you know which images are sRGB images?

On Tue, Oct 14, 2014 at 11:20 AM, Elle Stone ellest...@ninedegreesbelow.com 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

Re: [Gegl-developer] [Gimp-developer] babl roadmap

On Tue, Oct 14, 2014 at 1:34 PM, Elle Stone ellest...@ninedegreesbelow.com 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

Re: [Gegl-developer] babl roadmap

On Mon, Oct 13, 2014 at 8:19 PM, Elle Stone ellest...@ninedegreesbelow.com 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

Re: [Gegl-developer] [Gimp-developer] Don't make an architectural mistake based on a groundless premise

On Sun, Oct 12, 2014 at 8:41 AM, Elle Stone ellest...@ninedegreesbelow.com 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

Re: [Gegl-developer] [Gimp-developer] Don't make an architectural mistake based on a groundless premise

On Sat, Oct 11, 2014 at 1:41 PM, Elle Stone ellest...@ninedegreesbelow.com 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.

Re: [Gegl-developer] [Gimp-developer] Don't make an architectural mistake based on a groundless premise

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

Re: [Gegl-developer] [Gimp-developer] Don't make an architectural mistake based on a groundless premise

On Fri, Oct 10, 2014 at 6:36 PM, Elle Stone ellest...@ninedegreesbelow.com 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

Re: [Gegl-developer] [Gimp-developer] Don't make an architectural mistake based on a groundless premise

On Fri, Oct 10, 2014 at 9:38 PM, Elle Stone ellest...@ninedegreesbelow.com 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

Re: [Gegl-developer] [Gimp-developer] Don't make an architectural mistake based on a groundless premise

On Sat, Oct 11, 2014 at 1:18 AM, Elle Stone ellest...@ninedegreesbelow.com 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

Re: [Gegl-developer] [Gimp-developer] Don't make an architectural mistake based on a groundless premise

On Wed, Oct 8, 2014 at 3:25 PM, Elle Stone ellest...@ninedegreesbelow.com 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). None

Re: [Gegl-developer] [Gimp-developer] Don't make an architectural mistake based on a groundless premise

On Tue, Oct 7, 2014 at 8:10 PM, Elle Stone ellest...@ninedegreesbelow.com 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

Re: [Gegl-developer] [Gimp-developer] Don't make an architectural mistake based on a groundless premise

On Tue, Oct 7, 2014 at 9:23 PM, Elle Stone ellest...@ninedegreesbelow.com 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

Re: [Gegl-developer] [Gimp-developer] Don't make an architectural mistake based on a groundless premise

On Tue, Oct 7, 2014 at 10:20 PM, Elle Stone ellest...@ninedegreesbelow.com 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

Re: [Gegl-developer] [Gimp-developer] Don't make an architectural mistake based on a groundless premise

On Mon, Oct 6, 2014 at 6:57 PM, Elle Stone ellest...@ninedegreesbelow.com 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

Re: [Gegl-developer] [Gimp-developer] Don't make an architectural mistake based on a groundless premise

On Sun, Oct 5, 2014 at 5:16 PM, Elle Stone ellest...@ninedegreesbelow.com wrote: On 10/04/2014 11:59 AM, Øyvind Kolås wrote: On Sat, Oct 4, 2014 at 2:46 PM, Elle Stone ellest...@ninedegreesbelow.com wrote: Based on the groundless premise that editing operations should produce the same

Re: [Gegl-developer] TODO for GEGL 0.3

On Thu, Sep 4, 2014 at 9:48 PM, Teo Mazars maza...@ensimag.grenoble-inp.fr 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-developer] GEGL_THREADS

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

Re: [Gegl-developer] Transparency causes gegl to hang / freeze

On Tue, May 6, 2014 at 2:40 PM, Matteo F. Vescovi mfvesc...@gmail.com 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

Re: [Gegl-developer] Removed wildcard rules from operations Makefiles

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-developer-list

Re: [Gegl-developer] GPL code in GEGL (gegl-cache.c)

On Sun, Jun 9, 2013 at 2:52 PM, Daniel Sabo daniels...@gmail.com 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

Re: [Gegl-developer] OpenCL support in GEGL is almost there

On Tue, Apr 10, 2012 at 11:12 PM, johannes hanika hana...@gmail.com 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

Re: [Gegl-developer] I want to add some other code

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