Re: [Gimp-developer] trying to compile gimp master on Ubuntu 20.04

[Ell via gimp-developer-list]

On 8/5/20 10:26 AM, Marco Ciampa via gimp-developer-list wrote:
> On Tue, Aug 04, 2020 at 09:33:56PM +0300, Ell via gimp-developer-list wrote:
>>
>>
>> On 8/4/20 9:16 PM, Marco Ciampa via gimp-developer-list wrote:
>>> Trying to compile gimp master on Ubuntu 20.04 I see this error:
>>>
>>> ake[4]: Entering directory '/home/marco/git/gnome/gimp-master/app/core'
>>> make[4]: *** No rule to make target 'gimppickable-contiguous-region.c', 
>>> needed by 'gimppickable-contiguous-region.o'.  Stop.
>>> make[4]: Leaving directory '/home/marco/git/gnome/gimp-master/app/core'
>>> make[3]: *** [Makefile:1452: all] Error 2
>>> make[3]: Leaving directory '/home/marco/git/gnome/gimp-master/app/core'
>>> make[2]: *** [Makefile:1305: all-recursive] Error 1
>>> make[2]: Leaving directory '/home/marco/git/gnome/gimp-master/app'
>>> make[1]: *** [Makefile:869: all-recursive] Error 1
>>> make[1]: Leaving directory '/home/marco/git/gnome/gimp-master'
>>> make: *** [Makefile:770: all] Error 2
>>>
>>> Any hint?
>>
>> This happens in existing builds when we convert C files to C++.  A clean
>> rebuild should fix it.
> 
> What do you mean? And make clean did not resolve. 

Yeah, it should be a *completely* clean rebuild, as in, start from an
empty build directory (or, if you build in the source directory, use
"git clean -dxf").

A more surgical approach, if you don't want to do a full rebuild, is to
change "gimppickable-contiguous-region.c" to
"gimppickable-contiguous-region.cc" at the top of
"app/core/.deps/gimppickable-contiguous-region.Po" in your build directory.

--
Ell
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] trying to compile gimp master on Ubuntu 20.04

[Ell via gimp-developer-list]

On 8/4/20 9:16 PM, Marco Ciampa via gimp-developer-list wrote:
> Trying to compile gimp master on Ubuntu 20.04 I see this error:
> 
> ake[4]: Entering directory '/home/marco/git/gnome/gimp-master/app/core'
> make[4]: *** No rule to make target 'gimppickable-contiguous-region.c', 
> needed by 'gimppickable-contiguous-region.o'.  Stop.
> make[4]: Leaving directory '/home/marco/git/gnome/gimp-master/app/core'
> make[3]: *** [Makefile:1452: all] Error 2
> make[3]: Leaving directory '/home/marco/git/gnome/gimp-master/app/core'
> make[2]: *** [Makefile:1305: all-recursive] Error 1
> make[2]: Leaving directory '/home/marco/git/gnome/gimp-master/app'
> make[1]: *** [Makefile:869: all-recursive] Error 1
> make[1]: Leaving directory '/home/marco/git/gnome/gimp-master'
> make: *** [Makefile:770: all] Error 2
> 
> Any hint?

This happens in existing builds when we convert C files to C++.  A clean
rebuild should fix it.

--
Ell
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] [ANNOUNCE] GIMP 2.10.20, babl 0.1.78, GEGL 0.4.24

[Ell via gimp-developer-list]

On 6/12/20 3:02 AM, Ell via gimp-developer-list wrote:
> 
> 
> On 6/12/20 2:30 AM, Cristian Secar?? wrote:
>> ??n data de Thu, 11 Jun 2020 16:51:26 +0300, Alexandre Prokoudine via 
>> gimp-developer-list a scris:
>>
>>> We've just released GIMP 2.10.20 with usability improvements, new
>>> features, and bug fixes. Just like always, the release is accompanied
>>> by new releases of babl and GEGL libraries.
>>
>> Installer for Windows does not offer Romanian language for install process, 
>> in spite of the fact that the installer language file is 100% translated
>> https://l10n.gnome.org/vertimus/gimp/gimp-2-10/po-windows-installer/ro/
>>
>> Why ?
> 
> Sorry about that.  There are a few characters in the Romanian
> translation (namely ??, ??, and ??) that can't be converted to the encoding
> the installer uses (Windows-1250).  If there are some other characters
> you can use instead that are supported by Windows-1250, we could add the
> translation.

Heh, looks like the list isn't crazy about them either :)  It's:

U+021A (Latin Capital Letter T with Comma Below)
U+021B (Latin Small Letter T with Comma Below)
U+0219 (Latin Small Letter S with Comma Below)

--
Ell
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] [ANNOUNCE] GIMP 2.10.20, babl 0.1.78, GEGL 0.4.24

[Ell via gimp-developer-list]

On 6/12/20 2:30 AM, Cristian Secar?? wrote:
> ??n data de Thu, 11 Jun 2020 16:51:26 +0300, Alexandre Prokoudine via 
> gimp-developer-list a scris:
> 
>> We've just released GIMP 2.10.20 with usability improvements, new
>> features, and bug fixes. Just like always, the release is accompanied
>> by new releases of babl and GEGL libraries.
> 
> Installer for Windows does not offer Romanian language for install process, 
> in spite of the fact that the installer language file is 100% translated
> https://l10n.gnome.org/vertimus/gimp/gimp-2-10/po-windows-installer/ro/
> 
> Why ?

Sorry about that.  There are a few characters in the Romanian
translation (namely ??, ??, and ??) that can't be converted to the encoding
the installer uses (Windows-1250).  If there are some other characters
you can use instead that are supported by Windows-1250, we could add the
translation.

--
Ell
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] GIMP 2.10.18? Yes, 2.10.18!

[Ell via gimp-developer-list]

On 2/21/20 8:57 PM, Ell via gimp-developer-list wrote:
> Hey, we're doing a ninja 2.10.18 release.  There was an ugly data
> corruption bug in 2.10.16
> (https://gitlab.gnome.org/GNOME/gimp/issues/4643) -- good thing we
> didn't announce it yet, huh? :)  We want to do it later today or
> tomorrow (more likely).  Just a heads up, if you have some last-minute
> fixes to push.

Well, this wasn't actually supposed to go to the list, but whatever.  If
anyone is already using 2.10.16, you might want to revert to 2.10.14 for
now.  There should be a new release soon.

--
Ell
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

[Gimp-developer] GIMP 2.10.18? Yes, 2.10.18!

[Ell via gimp-developer-list]

Hey, we're doing a ninja 2.10.18 release.  There was an ugly data
corruption bug in 2.10.16
(https://gitlab.gnome.org/GNOME/gimp/issues/4643) -- good thing we
didn't announce it yet, huh? :)  We want to do it later today or
tomorrow (more likely).  Just a heads up, if you have some last-minute
fixes to push.

--
Ell
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] GEGL operation as a GIMP plugin with UI builder

[Ell via gimp-developer-list]

On 1/31/20 1:07 PM, JonnyRobbie via gimp-developer-list wrote:
> 
> Hello,
> 
> I'm still in the quest of creating a pixel based gimp plugin.
> 
> Also this question is both for gimp and gegl, but pippin from gegl, directed
> me more towards gimp list (here).
> 
> I've managd to create a gegl operation - which seems to work fine (apart 
> some detail). The catch is that my implementation currently has the form of 
> directly altering gegl source code, recompiling whole gegl, installing that 
> and loading that into a gimp as a 'Tools-GEGL Operation', which is a lot 
> unwieldy.
> 
> Is there a way to implement a gegl operation in the form of a modular gimp 
> plugin, so it would work with ui builder widgets, like proprerty_double(), 
> auxulary inputs, etc? (see https://gitlab.gnome.org/GNOME/gegl/blob/master/
> operations/common/exposure.c#L26 for example). All the plugins in /plugins/ 
> seems to build its ui from scratch instead uf using gegl-like widgets.

Plug-ins and GEGL operations are two separate things.  Essentially,
plug-ins get a much higher-level access to GIMP -- they understand stuff
like images and layers -- while GEGL operations are filters that
transform an input buffer (or buffers) into an output.  If what you're
making fits into the model of a filter, you're much better off
implementing it as a GEGL operation, for the reasons pippin mentioned in
his mail.  Namely, better integration (e.g., a live on-canvas preview,
and, in the future, non-destructive editing), and much less boilerplate.
Most of the old plug-ins that implemented filters have been converted to
GEGL ops.

The main gotcha right now is the inability of GEGL ops to register a
menu item.  The ones that do show in the menu are hard-coded, while
other operations can only be accessed through the GEGL operation tool.
That's indeed pretty clunky, and it's something we want to fix, along
with better support for applying GEGL operations in scripts and plug-ins.

Plug-ins in general don't get an auto-generated UI right now (other than
scripts and python plug-ins), though the entire plug-in framework is
undergoing major changes for GIMP 3, with support for auto-generated UI
being one of them.

As for building GEGL ops, you can do it out-of-tree, without having to
build it as part of GEGL.  Essentially, if you start with one of the ops
from the GEGL tree, remove the `#include "config.h"` line, and compile
it as a shared library against GEGL (e.g., using `pkg-config --cflags
--libs gegl-0.4`; also, make sure the directory containing your source
file is in the include path), you should be able to get a standalone
library containing your op.

> Hte second issue I have is that most of the enums from here https://gitlab.
> gnome.org/GNOME/gegl/blob/master/gegl/gegl-op.h#L271 work, apart from 
> property_curve() from #L282. Is there a way to enable property_curve in gimp
> ()

Nope, there's no UI for property_curve() in GIMP right now.

--
Ell
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] GIMP not compiling... and it is putting the blame on me??

[Ell via gimp-developer-list]

On 9/14/19 6:59 PM, Marco Ciampa via gimp-developer-list wrote:
> Hi devs,
> I received this email telling me that last commit I did made the GIMP
> compilation stop.
> 
> I updated the po/it.po file and then the po-plugins/it.po file, and
> NOTHING ELSE.
> 
> 
> Looking into the GIMP compilation error messages, I see this:
> 
> [...]
> 
> Obviously this has nothing to do with the translation .po files...
> 
> What is going on here?

The 2.10 CI build is currently broken, it's not your doing :)  GitLab
sends this message whenever CI fails to build a commit you've pushed,
even if previous commits had already been failing the same way.

--
Ell
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Is there any kind of documentation on the new layer blend modes?

[Ell via gimp-developer-list]

On 8/16/19 10:31 AM, Ofnuts wrote:
> Specifically, I'm wondering about the "Split", "Merge", and the group
> "Passthrough" modes.
> 
> The only relevant Google answer is a paying video tutorial.
> 
> Of course I have checked the online doc...

There's indeed no organized documentation for all the new layer modes
yet, unfortunately.

For Pass Through mode, see:

  https://docs.gimp.org/2.10/en/glossary.html#glossary-pass-through

Merge and Split are complementary modes, as their names suggest.  They
are similar to Normal and Erase modes, respectively, but they handle
alpha values differently.  The short version is that (when using their
default composite modes) Merge adds the alpha values of the input
layers, while Split subtracts them.  In other words, if the alpha values
of the bottom and top layers are A and B, respectively, the resulting
alpha values for Merge and Split are `min (A + B, 100%)`
and `max (A - B, 0%)`, respectively.

--- Wall-of-text warning.  Skip to the end for practical examples. ---

The slightly more advanced version has to do with how alpha values are
interpreted.  Alpha values can be seen as a property of the sub-pixel
geometry of a pixel; they specify how much of a pixel's area is covered
by the layer's content.  For example, when you rasterize an ideal shape,
such as a circle, pixels along the circumference will only be partially
covered by it; their alpha values specify how much of their area is
covered by the circle.  It's even more instructive to think of alpha
values in terms of probability: when picking a random point within a
pixel, the alpha value specifies the *probability* of the point
belonging to the layer.

The information conveyed by the alpha value is, of course, only partial:
while it tells you *how much* of a pixel's area is covered by its
content, it doesn't tell you exactly *which* portion of the pixel is
covered.  The latter becomes relevant when you combine multiple layers,
though: two layers having a pixel with 50% alpha each, when overlaid on
top of each other, can result in a pixel having anywhere between 50%
alpha (if the areas covered by both layers coincides exactly) to 100%
alpha (if the areas covered by both layers don't coincide at all).
There is no correct answer here: we have to make a certain assumption
about the relationship between the two layers.

The "ordinary" assumption, used by most layer modes, is that the two
layers are independent (in the probabilistic sense): whether a given
point within a pixel belongs to one layer doesn't affect the probability
of it belonging to the other layer as well; this leads to the familiar
`A + B - AB` formula for combining alpha values.  I call this the
"diffuse" assumption.  While it's a reasonable assumption in the general
case, in can lead to artifacts when applied inappropriately.  Most
notably, it can lead to semitransparent "seams" between opaque objects
that should, in theory, intermesh perfectly.  That's a common problem
with Inkscape, for example; it happens because Inkscape renders each
object separately, throwing away the actual sub-pixel geometry in favor
of alpha values, and then combining the alpha values with the (wrong)
assumption that the objects are independent of each other.

There are at least two other simple assumptions we can make about the
layers: the "complement" assumption, where the two layers are thought to
be mutually exclusive (i.e., to *complement* each other), and the
"coincide" assumption, where the two layers are thought to occupy the
same area (i.e., to *coincide* with each other).  Note, however, that
this formalism places some restrictions on the layers' alpha values
(namely, that `A + B <= 100%` for "complement", and that `A = B` for
"coincide").  A more precise formalism is that with "complement" the
intersection of the two layers is as small as possible, and with
"coincide" the intersection is as big as possible.

One day, GIMP might allow this assumption to be controlled separately
from the layer mode, through an additional layer attribute.  For now,
Merge and Split are singled out as two useful cases of non-diffuse
modes: Merge is simply Normal mode with the "complement" assumption, and
Split is Erase mode with the "coincide" assumption.

---

Merge mode should be used when combining layers that are, logically,
separate parts of a whole.  The archetypical example is that of cutting
an antialiased selection, and pasting as a new layer.  When using Normal
mode for the pasted layer, there's usually a semitransparent "seam"
around the selection's boundary (as mentioned above).  Using Merge mode
instead fixes the issue, as the two layers are two parts of one whole,
reproducing the original image.

Split mode is complementary to Merge: it allows you to erase one of the
parts out of the whole, producing its complement; the two parts can then
be combined using Merge mode to reproduce the original.  For example,
you can split an image into two layers by first isolating one of 

Re: [Gimp-developer] Building GIMP master fails because of missing gobject-introspection

[Ell via gimp-developer-list]

On 7/29/19 11:14 AM, Steve Pricks wrote:
> Hello,
> 
> I was trying to build GIMP master (commit 
> f74320d4dc5e92351001cd44c4380c95725eccd5).
> Configure failed with this message:
> 
> checking for gobject-introspection... configure: error: 
> gobject-introspection-1.0 is not installed
> 
> Configure failed or did not finish!
> 
> It also happened when I pass the parameter --enable-introspection=no
> Interestingly having the Debian package gobject-introspection (version 1.58) 
> installed didn't have an effect.
> After installing the package libgirepository1.0-dev it works, but it seems 
> that the handling of the parameter --enable-introspection=no is buggy (or if 
> introspection is required, then it should not be possible to disable it).

Introspection is indeed required to build master right now, and can't be
disabled.  Autoconf simply ignores unsupported --enable-foo flags by
default, so you didn't get an error for the flag (but you should have
gotten a warning at the beginning of the output).

--
Ell
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] the blur/smudge was better in 2.8

[Ell via gimp-developer-list]

On 6/22/19 7:55 PM, Ell via gimp-developer-list wrote:
> On June 20, 2019 8:12:32 AM GMT+02:00, Natalie Baldwin via 
> gimp-developer-list  wrote:
>> The gradient
>> tool with perceptual RGB works almost as expected, somehow the blue
>> value
>> goes up even though i'm trying to gradient between pure red and pure
>> green.
> 
> Oof, good catch! That's a bug. You can take care of that by disabling 
> dithering in the gradient-tool options, but it shouldn't happen with 
> dithering enabled either.


This is now fixed in master and gimp-2-10 by
e22fcc8942963d7a1cfca57965d0385f073d5b3a and
91c20c783abd73849457ea586f760a7ec44d1f3c, resp.

--
Ell
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Issue building Gimp from GIT

[Ell via gimp-developer-list]

On July 4, 2019 4:59:10 AM GMT+02:00, "Steven P. Ulrick via 
gimp-developer-list"  wrote:
>Hello, Everyone
>
>I am running Fedora 30 and attempting to build, install & eventually
>run 
>GIMP from GIT. It builds & installs without error. But when I attempt
>to 
>run it I get the following:
>
>[steve@afolkey2 bin]$ ./gimp-2.99
>./gimp-2.99: error while loading shared libraries: libjson-c.so.2: 
>cannot open shared object file: No such file or directory
>
>Obviously the error itself makes perfect sense. Fedora 30 has 
>libjson-c.so.4, not libjson-c.so.2
>
>So the question is, why does GIMP compile and install with 
>libjson-c.so.2 not installed, but it won't run. I would assume that if
>a 
>file that GIMP requires if it is not going to crash is not present,
>that 
>GIMP would not compile. Also, what can I do to get this to work.

One of GIMP's dependencies was built against an older version of json-c.  
Probably libmypaint, but you can find out using lddtree.  If you've built that 
dependency yourself as well (which is likely, otherwise we'd be hearing a lot 
more about it :) you need to rebuild it.

--
Ell
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] please help me compile gimp

[Ell via gimp-developer-list]

On June 28, 2019 9:14:14 AM GMT+02:00, Marco Ciampa via gimp-developer-list 
 wrote:
>Hello devs,
>I'm very sorry to bother you,
>but I do not know what to do and who to ask,
>and it is definitely my fault...
>I messed up my distro deleting some packages I should not remove.
>(Ubuntu 18.04 64)
>Now it seems to work perfectly again after reinstall of those packages
>(all other apps and compilations work) but apparently something is
>wrong, 
>and gimp (2.10 from git) compilation don't work again...
>
>This is the output after a make clean ; make -j4
>
>ar: `u' modifier ignored since `D' is the default (see `U')
>/usr/bin/ld: core/libappcore.a(gimp-parallel.o): relocation R_X86_64_32
>against `.rodata.str1.1' can not be used when making a PIE object;
>recompile with -fPIC
>/usr/bin/ld: core/libappcore.a(gimpbrush-transform.o): relocation
>R_X86_64_32 against `.text' can not be used when making a PIE object;
>recompile with -fPIC
>/usr/bin/ld: core/libappcore.a(gimppickable-contiguous-region.o):
>relocation R_X86_64_32 against `.rodata.str1.1' can not be used when
>making a PIE object; recompile with -fPIC
>/usr/bin/ld: paint/libapppaint.a(gimpbrushcore-loops.o): relocation
>R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE
>object; recompile with -fPIC
>/usr/bin/ld: paint/libapppaint.a(gimppaintcore-loops.o): relocation
>R_X86_64_32 against `.text' can not be used when making a PIE object;
>recompile with -fPIC
>/usr/bin/ld:
>operations/libappoperations.a(gimpoperationmaskcomponents.o):
>relocation R_X86_64_32 against `.bss' can not be used when making a PIE
>object; recompile with -fPIC
>/usr/bin/ld: gegl/libappgegl.a(gimp-gegl-loops.o): relocation
>R_X86_64_32 against `.text' can not be used when making a PIE object;
>recompile with -fPIC
>/usr/bin/ld: gegl/libappgegl.a(gimp-gegl-mask-combine.o): relocation
>R_X86_64_32S against `.rodata' can not be used when making a PIE
>object; recompile with -fPIC
>/usr/bin/ld: final link failed: Nonrepresentable section on output
>collect2: error: ld returned 1 exit status
>Makefile:1020: recipe for target 'gimp-console-2.10' failed
>make[3]: *** [gimp-console-2.10] Error 1
>make[3]: *** Attesa per i processi non terminati
>/usr/bin/ld: core/libappcore.a(gimp-parallel.o): relocation R_X86_64_32
>against `.rodata.str1.1' can not be used when making a PIE object;
>recompile with -fPIC
>/usr/bin/ld: core/libappcore.a(gimpbrush-transform.o): relocation
>R_X86_64_32 against `.text' can not be used when making a PIE object;
>recompile with -fPIC
>/usr/bin/ld: core/libappcore.a(gimppickable-contiguous-region.o):
>relocation R_X86_64_32 against `.rodata.str1.1' can not be used when
>making a PIE object; recompile with -fPIC
>/usr/bin/ld: paint/libapppaint.a(gimpbrushcore-loops.o): relocation
>R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE
>object; recompile with -fPIC
>/usr/bin/ld: paint/libapppaint.a(gimppaintcore-loops.o): relocation
>R_X86_64_32 against `.text' can not be used when making a PIE object;
>recompile with -fPIC
>/usr/bin/ld:
>operations/libappoperations.a(gimpoperationmaskcomponents.o):
>relocation R_X86_64_32 against `.bss' can not be used when making a PIE
>object; recompile with -fPIC
>/usr/bin/ld: gegl/libappgegl.a(gimp-gegl-loops.o): relocation
>R_X86_64_32 against `.text' can not be used when making a PIE object;
>recompile with -fPIC
>/usr/bin/ld: gegl/libappgegl.a(gimp-gegl-mask-combine.o): relocation
>R_X86_64_32S against `.rodata' can not be used when making a PIE
>object; recompile with -fPIC
>/usr/bin/ld: final link failed: Nonrepresentable section on output
>collect2: error: ld returned 1 exit status
>Makefile:1016: recipe for target 'gimp-2.10' failed
>make[3]: *** [gimp-2.10] Error 1
>make[3]: uscita dalla directory "/home/marco/git/gitlab/gnome/gimp/app"
>Makefile:1240: recipe for target 'all-recursive' failed
>make[2]: *** [all-recursive] Error 1
>make[2]: uscita dalla directory "/home/marco/git/gitlab/gnome/gimp/app"
>Makefile:852: recipe for target 'all-recursive' failed
>make[1]: *** [all-recursive] Error 1
>make[1]: uscita dalla directory "/home/marco/git/gitlab/gnome/gimp"
>Makefile:753: recipe for target 'all' failed
>make: *** [all] Error 2
>
>any hint?

These are all C++ files, so there seems to be a mismatch between your gcc and 
g++ options with regard to PIC (esp., your gcc might be newer than your g++).  
Try reinstalling g++, and make a (fully) clean build of GIMP.

--
Ell
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] the blur/smudge was better in 2.8

[Ell via gimp-developer-list]

On June 20, 2019 8:12:32 AM GMT+02:00, Natalie Baldwin via gimp-developer-list 
 wrote:
>I've redownloaded version 2.8 because i've found no way to emulate the
>mathematical precision that the blur/smudge tools give me.
>
> [...]
>
>Making a transition with blur/smudge from 255-0-0 to 0-255-0 (red to
>green)
>i do not expect to get any colours where red+green > 255. I expect to
>find
>254-1-0 followed by 253-2-0 followed by 252-3-0 etc. This feature is
>extremely important to me because of a shader i wrote that reads colour
>values mathematically. So, if i get a vote, please reintroduce the old
>way
>to blur.

In 2.10, many operations, especially ones involving color blending, 
transitioned from working in perceptual RGB, to linear RGB. This is the 
physically-correct way to blend colors, as, in perceptual RGB, the component 
intensities are compressed using a nonlinear gamma function. In other words, 
this change is intentional, and is generally the Right Thing to do.

That being said, there are still valid reasons to want to keep working in 
perceptual RGB, as in your case. Unfortunately, while some parts of GIMP 
provide this choice, others (like the smudge and blur tools) don't: it's a 
balancing act between allowing enough control, while not cluttering the UI with 
too many options, which we haven't fully nailed down yet. That's not to say we 
don't want to get there eventually, just that we don't have a general solution 
that feels quite *right* yet.

While there are workarounds for working perceptually in 2.10, even when GIMP 
doesn't provide this option otherwise, they're so terrible that I'd rather not 
mention them :)

Lastly, just to reiterate, the smudge and blur tools *do* still have the 
properties you're looking for, they just apply to the *linear* component 
values, rather than to the perceptual ones (which can be checked by converting 
the image precision to 32-bit linear float, and using the color picker tool in 
"pixel" mode). So, another option is to switch your shaders from working in 
perceptual RGB to linear RGB, if that's applicable.

>The gradient
>tool with perceptual RGB works almost as expected, somehow the blue
>value
>goes up even though i'm trying to gradient between pure red and pure
>green.

Oof, good catch! That's a bug. You can take care of that by disabling dithering 
in the gradient-tool options, but it shouldn't happen with dithering enabled 
either.

--
Ell
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] What would it take to add an option for the Pencil tool to support brush transparency?

[Ell via gimp-developer-list]

On 5/21/19 9:57 PM, James Houx via gimp-developer-list wrote:
> I /really, really /badly want this feature!?? Badly enough that I will 
> have to figure out how to hack the source myself unless can tell me a 
> way to accomplish it.
> 
> Basically, the problem is this:
> 
> The brush tool uses sub-pixel sampling to get an anti-aliased effect 
> when you paint.?? I don't want this, because I'm working at pixel-level 
> scale and I need exact pixel painting with anti-aliasing.
> 
> The pencil tool would be the natural solution, but the pencil tool does 
> not support transparency for RGB brushes!?? I'm surprised because it 
> seems like such a very simple feature. :(

Right, the pencil tool lumps together both binary transparency and
pixel-grid alignment, which are really two independent things.  It has
come up before, and I agree that being able to control these separately
would be useful.  It's one of those simple features where generality and
consistency get in the way:  Should we add this to the pencil tool, or
the paintbrush tool?  What about the other paint tools, which already
suffer from an annoying lack of consistency?  Should we just merge the
pencil and paintbrush tools?  Or, if this separation is convenient, why
not generalize this and allow creating new tools from arbitrary tool
presets, etc.?  It's a slippery slope :)  Ultimately, though, I agree
that it's a useful feature.

> Without this, there's no way to do per-pixel precise painting that 
> supports transparency.
It is possible, although it's a bit clunky:  You need to set up a
1px-by-1px image grid ("Image -> Configure Grid..."), and enable
"View -> Snap to Grid" (and possibly also "View -> Show Grid").  This
would snap the pointer to the pixel grid in all tools, including the
paintbrush.  Now, here's the clunky part: the grid offset should depend
on the brush size -- if the brush size is even, you need a grid offset
of 0px (grid along pixel edges), while if the brush size is odd, you
need an offset of 0.5px (grid along pixel centers).  If the brush isn't
square, you might need different offsets in different dimensions.

--
Ell
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] [Gimp-docs] spyrogimp untranslated

[Ell via gimp-developer-list]

On 4/3/19 2:04 AM, Marco Ciampa via gimp-developer-list wrote:
> On Tue, Apr 02, 2019 at 05:51:14PM +0200, Marco Ciampa via gimp-docs-list 
> wrote:
>> Hi devs,
>> for translating purpouses I use to compile GIMP from git.
>> I do not see any translation strings for the spyrogimp plug-in and yet I see 
>> it completely untranslated.
>> What am I doing wrong here?
>>
> 
> Sorry I was unclear, I meant the GIMP application, not the manual.
> 
> I was trying to update the translation of the manual when I realized that
> the specific dialog window was completely untranslated, yet no strings
> were untranslated or fuzzy in the app...
> 
> Presumably my fault but I have no clue on how to fix it...

Make sure to run intltool-update in the po-python/ directory -- that's
where the spyrogimp translation lives.  It should all work normally.

--
Ell
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] GIMP-2.99 "No rule to make target 'gimpoperationmaskcomponents.c'"

[Ell via gimp-developer-list]

On 2/17/19 2:24 PM, Elle Stone wrote:
> When compiling GIMP-2.99 updated this morning, I got this error:
> 
> make[4]: *** No rule to make target 'gimpoperationmaskcomponents.c', 
> needed by 'gimpoperationmaskcomponents.o'.  Stop.
> make[4]: *** Waiting for unfinished jobs
> make[3]: *** [Makefile:984: all-recursive] Error 1
> make[2]: *** [Makefile:1266: all-recursive] Error 1
> make[1]: *** [Makefile:854: all-recursive] Error 1
> make: *** [Makefile:755: all] Error 2
> 
> In fact there doesn't seem to be "gimpoperationmaskcomponents.c", though 
> there is "gimpoperationmaskcomponents.cc".
> 
> Renaming the file and typing "make" to continue compiling results in a 
> bunch of other errors, and "make" doesn't finish.

This happens each time we convert a C file to C++.  Since both the old
.c and new .cc files compile into the same .o file, autofoo is too dumb
to smoothly handle that for an existing build.  You need to either do
fresh build, or, in your build directory, edit
app/operations/.deps/gimpoperationmaskcomponents.Po, and change
"gimpoperationmaskcomponents.c" to "gimpoperationmaskcomponents.cc", on
the first or second line.

--
Ell
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Compilation errors in file-dds plugin under CentOS7 and GCC 6.4.0

[Ell via gimp-developer-list]

On 2/16/19 4:06 PM, Carmelo DrRaw via gimp-developer-list wrote:
> When compiling the current GIMP code under CentOS7 with GCC 6.4.0, I get some 
> compilation errors that are due the plug-ins/file-dds/endian.h header file.
> This file interferes with the system-wide endian.h header. The error can be 
> fixed by renaming the file in the DDS plug-in to something like "dds-endian.h"

Thanks!  Fixed in master (b5a34c3190d62294dc0316c93251baa807b26c9e) and
gimp-2-10 (bfa6285d238bac6ea30dd25269cb5283d13f6936).

--
Ell
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Spyrogimp plugin rewrite

[Ell via gimp-developer-list]

On 1/27/19 7:51 PM, Elad Shahar via gimp-developer-list wrote:
> Hi Jehan,
> 
> Thanks for committing the code!  All your changes made sense to me. I'm
> pretty excited.
> 
> I will stay around. I might add some features and documentation to this
> plugin.
> My gitlab account name is "eladsha".
> 
> Thanks!!

Hi Elad, thanks for the awesome plug-in!

Just one comment: none of the UI strings are marked for translation.
Could you please mark the necessary ones, and add the file to
po-python/POTFILES.in?  Just look at how the other Python plug-ins do it.

Thanks.

--
Ell
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] FTBFS with gegl commit 413b8bd1a5654ad0fef7f6400e342c810e5bbfdd

[Ell via gimp-developer-list]

On 1/12/19 3:54 AM, Thorsten Stettin via gimp-developer-list wrote:
> Hi all,
> 
> what went wrong?
> 
> https://launchpadlibrarian.net/405910118/buildlog_ubuntu-bionic-amd64.gegl_1%3A0.4.13+om~7-1ubu18.04.1~ppa_BUILDING.txt.gz
> 
> Don't panic. I cant wait.
> 
> This was a build for Ubuntu 18.04
> 
> https://launchpad.net/~otto-kesselgulasch/+archive/ubuntu/gimp-standalone/+build/16266380

My bad :P  Fixed by commit 61ea5fe3a721cda87e03897a638f79c78b7ef41a.
Thanks.

--
Ell
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Behavior change in paint modes between 2.8 and 2.10

[Ell via gimp-developer-list]

On 12/9/18 9:56 AM, Ell via gimp-developer-list wrote:
< [...] you can use the alpha lock, but this works only
> superficially: it produces correct results when either the existing
> pixel or the new pixel are fully opaque, but if both are
> semi-transparent, the result is wrong.

Actually, it's worse than that:  In general, with non-Normal modes, the
result when using alpha-lock is wrong whenever the existing pixel is
semi-transparent, even if the new pixel is fully opaque.

--
Ell
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Behavior change in paint modes between 2.8 and 2.10

[Ell via gimp-developer-list]

On 12/7/18 6:16 AM, Ofnuts wrote:
> In 2.8, on a transparent layer, paint something blue, set the FG color 
> to red, set the paint tool to "Hue" mode, paint over: the blue parts 
> turns to red, the transparent parts remains unchanged.
> 
> In 2.10, if you do the same thing with the non-legacy modes, the 
> transparent parts are painted. The legacy modes behave as in 2.8, and it 
> seems that setting the alpha-lock also provides the 2.8 behavior.
> 
> It used to be that painting a layer with the paint tool in mode XXX 
> would give the same result as adding a transparent layer in mode XXX and 
> painting on it in "Normal" mode.
> 
> Is it a bug/regression or is it a deliberate change, and if the latter, 
> what is the rationale?

Tl;dr: it's deliberate, but it needs to be improved.

In 2.10, layers have a new property called the "composite mode", which
is available when using the new layer modes.  It controls which parts of
the combined layers remains visible: the opaque parts of either layer
(Union), the opaque parts of the bottom layer (Clip to Backdrop), the
opaque parts of the top layer (Clip to Layer), or the opaque parts of
both (Intersection).  There are a few examples in the "Composite Mode"
section of:

  https://docs.gimp.org/2.10/en/gimp-layer-new.html

The default composite mode of a layer currently depends on its layer
mode, in a way that mimics the legacy modes: Union for Normal and
Normal-like modes, and Clip to Backdrop for the rest.  By changing the
composite mode of a non-Normal layer to Union, you can get the same
result as for painting.

Unfortunately, the other way around is currently not true: there is no
UI for controlling the composite mode of paint tools.  The composite
mode used for painting is currently determined according to the paint
mode: Union for everything, except for the "subtractive" modes: Erase,
Split, and Color Erase, which use Clip to Backdrop.

"Why?" is a good question.  There is no great answer, but this sort of
behavior for the paint tools is what a lot of people seem to expect, and
what most other software provide.  Ultimately, I hope to revamp the
layer-mode UI, and expose all the relevant options for both layers and
paint tools, so that you could paint using either composite mode.

In the meantime, there is no great way to restrict painting to opaque
regions.  Like you said, you can use the alpha lock, but this works only
superficially: it produces correct results when either the existing
pixel or the new pixel are fully opaque, but if both are
semi-transparent, the result is wrong.  Likewise, the result of
combining semi-transparent pixels using the non-Normal legacy modes,
while painting *or* using layers, is also wrong (that's part of the
motivation for the new modes; we're keeping the broken behavior of the
legacy modes for backward compatibility -- they really shouldn't be used
in new images.)  The only fully-correct way to do this right now is
using layers, using the new modes with Clip to Backdrop.

--
Ell
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] wavelet-decompose id

[Ell via gimp-developer-list]

On 11/30/18 1:59 AM, Julien Hardelin wrote:
> Hi,
> 
> I can't find id for wavelet-decompose filter in gimp-help-ids.h

wavelet-decompose is a plug-in, not a GEGL filter.  Its help-id is
derived from its procedure name, "plug-in-wavelet-decompose", and is not
found in gimp-help-ids.h.

You can find the procedure name for a plug-in by searching for the
plug-in in "Help -> Plug-in Browser".  The procedure name is shown at
the top of the info pane.

--
Ell
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Missing include file in current GIMP_2_10 branch

[Ell via gimp-developer-list]

On 11/19/18 9:12 AM, Elle Stone wrote:
> On 11/19/2018 06:57 AM, Shlomi Fish wrote:
>> Hi Carmelo,
>>
>> On Mon, 19 Nov 2018 10:46:43 +0100
>> Carmelo DrRaw via gimp-developer-list  wrote:
>>
>>> Trying to compile some plug-ins against the current GIMP_2_10 branch, I get
>>> errors due to a missing include file:
>>>
>>> In file included from
>>> /usr/local/gimp/include/gimp-2.0/libgimp/gimpui.h:24:0, from
>>> print_gimp.h:42, from print-image-gimp.c:27:
>>> /usr/local/gimp/include/gimp-2.0/libgimpwidgets/gimpwidgets.h:78:43: 
>>> fatal
>>> error: libgimpwidgets/gimpspinbutton.h: No such file or directory #include
>>>  
>>> compilation terminated.
>>>
>>
>> you have a stale installation of the headers under /usr/local. Please remove 
>> it.
> 
> Hmm, I don't install GIMP in /usr/local but rather in a prefix in my 
> home folder.
> 
> I removed all the files installed by GIMP before updating and doing "git 
> clean -xdf" and recompiling from scratch. Which file/folder in a given 
> install prefix actually contains the "stale installation of the headers"?
> 
> Looking at the contents of "$PREFIX/include/gimp-2.0/libgimpwidgets/ 
> here are the files - I don't see gimpspinbutton.h:

Thanks everyone.  The file was indeed not being installed.  Fixed now,
by commit 46d476869985013ea3e620240eaaf445bb3bc5e3.

--
Ell
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] GIMP 2.10.x AppImage packages

[Ell via gimp-developer-list]

On Mon, 10 Sep 2018 11:59:26 +0200
Carmelo DrRaw via gimp-developer-list 
wrote:

> Dear all,
> 
> recently I have done additional work on the GIMP AppImage packages,
> trying to improve the compatibility with various linux distributions
> and improving the building/packaging scripts.
> 
> In a nutshell:
> * I have moved the build environment to CentOS 7, which is based on
> glibc 2.17
> * the whole appimage creation process now runs through a single bash
> script that can be executed inside a docker container. This means
> that the automated integration, now based on Travis CI, can be easily
> moved to any other system that supports Docker
> * the appimage packages are now built in two flavours: one “bare”
> package that only provides GIMP, and a “full-featured” package that
> also contains few popular and useful plug-ins (including G’MIC-Qt)
> 
> The 2.10.7 packages are available for download from here:
> https://github.com/aferrero2707/gimp-appimage/releases/tag/continuous
> 
> 
> Running the AppImages is very simple:
> * download the package
> * make it executable via 
>   chmod u+x
> * run the package as any other Linux executable

Thanks for doing all this.  Having the latest-and-greatest code
easily available as an AppImage is really awesome :)

> A note to the developers: the current 2.10.x branch requires a quite
> recent version of Glib, but only due to the use of a single function
> in app/gui/splash.c, and only for diagnostics purposes. To circumvent
> the problem and be able to use the older Glib version available on
> CentOS 7, I am applying the following patch:
> https://github.com/aferrero2707/gimp-appimage/blob/master/gimp-glib-splash.patch
> 
> Is that OK?

This has already been fixed in the gimp-2-10 branch (master requires a
newer GLib version).  See commit
499a8962b326823bdf12936960798f802c79f283.

--
Ell
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] GIMP 2.10 Unable to read tile data from swap

[Ell via gimp-developer-list]

On Wed, 2 May 2018 16:08:31 -0400
Partha Bagchi  wrote:

> On Wed, May 2, 2018 at 3:58 PM, Ell  wrote:
> 
> > On Wed, 2 May 2018 15:56:12 -0400
> > Partha Bagchi  wrote:
> >  
> > > On Wed, May 2, 2018 at 3:49 PM, Ell  wrote:  
> > > > Note that the actual bug was the swap being used in the first
> > > > place. I'm still not sure why you're getting read errors,
> > > > though.  Since the swap shouldn't be used anymore (in this
> > > > particular case) after the above commit, the errors will
> > > > probably go away, but the issue causing them might still be
> > > > there.  I'd try to set a very low cache size, in order to force
> > > > the swap to become very active, and see if you're getting any
> > > > more errors. 
> > > I should do this after update gegl and gimp, correct?  
> >
> > Yep.
> >
> > --
> > Ell
> >  
> Sounds good.
> 
> I think your hypothesis that it's related to the zoom level may be
> correct. I restarted GIMP with no GEGL environment variables. I
> opened image > duplicated layer. I set the zoom level to 50.1% and I
> saw the same artifacts. Then I increased the zoom to 50.5% and it
> went away.
> 
> You realize that for large images, it would be unwieldy to be
> painting at that zoom level?
> 
> Thanks again to you and pippin for resolving this.
> 
> Partha
> 
> PS: Did you see the screenshots I posted?

I have now.  The artifacts are only present in the flat, downscaled
version of the image, and not in the layers themselves, so changing a
layer's mode, or doing anything else that would cause the entire image
to get re-rendered, would make them go away.

--
Ell
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] GIMP 2.10 Unable to read tile data from swap

[Ell via gimp-developer-list]

On Wed, 2 May 2018 15:56:12 -0400
Partha Bagchi  wrote:

> On Wed, May 2, 2018 at 3:49 PM, Ell  wrote:
> > Note that the actual bug was the swap being used in the first place.
> > I'm still not sure why you're getting read errors, though.  Since
> > the swap shouldn't be used anymore (in this particular case) after
> > the above commit, the errors will probably go away, but the issue
> > causing them might still be there.  I'd try to set a very low cache
> > size, in order to force the swap to become very active, and see if
> > you're getting any more errors.
> >  
> I should do this after update gegl and gimp, correct?

Yep.

--
Ell
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] GIMP 2.10 Unable to read tile data from swap

[Ell via gimp-developer-list]

On Wed, 2 May 2018 15:04:01 -0400
Partha Bagchi  wrote:

> On Wed, May 2, 2018 at 2:18 PM, Øyvind Kolås  wrote:
> 
> >
> > GEGL has stopped enabling opencl by defult now, since GEGL-0.3.24 of
> > 2017-11-24 it no longer being enabled by default since it relies on
> > good results from the varying quality different opencl
> > implementations,.. may also have generic race conditions resulting
> > from new code not manifest during regular testing either, so trying
> > without OpenCL enabled.
> >
> > /pippin
> >  
> I removed the above environment variable but no change with my 36MP
> image. The moment I put the brush on the screen, I get the error
> messages above.
> 
> Then I experimented with some more pictures and it seems to be
> related to the size of the image.
> 
> I open a 1 megabyte (MB), and 4MB image and no error. Then I open a
> 74MB image without error. But when I opened an 300 MB Tiff, I started
> getting the error.
> 
> I repeated the experiment with GEGL_CACHE_SIZE = 2048 with the same
> result.
> 
> For all all images, I first fit to window > duplicate layer > paint on
> duplicate layer.

My guess is that this is related to the zoom level (being <= 50%),
rather than to the size of the image per se.  There were some changes
to the mipmapped tiles code recently, and there was indeed a subtle bug
there.  GEGL commit 3557811a5527bccbfef2006046a05047b6edd480 should fix
it.

Note that the actual bug was the swap being used in the first place.
I'm still not sure why you're getting read errors, though.  Since the
swap shouldn't be used anymore (in this particular case) after the
above commit, the errors will probably go away, but the issue causing
them might still be there.  I'd try to set a very low cache size, in
order to force the swap to become very active, and see if you're
getting any more errors.

--
Ell
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] GIMP 2.10 Unable to read tile data from swap

[Ell via gimp-developer-list]

On Wed, 2 May 2018 09:16:46 -0400
Partha Bagchi  wrote:

> > It started again after the final release. It was not there in RC1.

So it only started at some point after RC1, but before 2.10? (days?
weeks?)  I'm trying of think of things that changed during that time
that might have caused this.  Did you change something on your end?

> > This may be a affect of the transition from gegl 0.3 to 0.4?

Not likely, especially if it already happened before 2.10.  The 0.4
switch happened right before the release.

> > In the past, it was related to complicated images with high
> > resolution and usually setting GEGL_CACHE_SIZE to 2048 or
> > thereabouts fixed it. Now, it does not.

This sounds like you might have ran out of cache and swap space, in
which case you'd start getting write errors.  These are read errors,
which are much more surprising.

> I did the following. I set the following environment variables:
> GEGL_SWAP=C:\Users\partha\AppData\Local\Temp\gegl
> GIMP_NO_PAINT_THREAD="Y"
> 
> It didn't make any difference.

Ok, so it's not the separate paint thread.  That's a good thing :)
What's the rest of your GEGL setup like?  Are you using any other
environment variables?  What's the thread count?

> Matter of fact, GEGL_SWAP was unused.
> So, I removed it and reran GIMP. No change.

Do you mean that GEGL wasn't using the swap?  Can you use the dashboard
to see if anything "interesting" is going on while this happens?  Is
the cache full?  Is the swap nearly full?  Do the reported cache/swap
size limits make sense?

--
Ell
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] GIMP 2.10 Unable to read tile data from swap

[Ell via gimp-developer-list]

On Tue, 1 May 2018 16:17:12 -0400
Partha Bagchi  wrote:

> GIMP 2.10, Windows 64-bit
> 
> I seem to be getting the following errors when using some brushes:
> 
> "Unable to read tile data from swap: No such file or directory (0/xxx
> bytes read) --"
> 
> twice, followed by
> 
> "Unable to read tile data from swap: No error (0/xxx bytes read) --"
> 
> etc. followed by
> "Too many error messages!"
> "Messages are redirected to stderr."
> 
> Any ideas on what is going wrong here for me?
> 
> Thanks,
> Partha
> 
> PS: I was not getting these swap errors for sometime now and suddenly
> in the final release, they are back again.

How long ago did it start?  Does disabling the separate paint thread
fixes this?  It can be disabled by setting the GIMP_NO_PAINT_THREAD
environment variable.

--
Ell
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] GNU++11 not allowed with Objective-C code

[Ell via gimp-developer-list]

On Sat, 7 Apr 2018 18:00:57 -0400
Ell via gimp-developer-list <gimp-developer-list@gnome.org> wrote:

> On Sat, 7 Apr 2018 17:35:20 -0400
> Partha Bagchi <parth...@gmail.com> wrote:
> 
> > Confirmed. It's something you did!! :) :)
> > 
> > Anyway, reverted back to previous head and c++14 error is back but
> > all the above is gone.  
> 
> Ha, of course it is :)  The commit caused -xobjective-c to be passed
> during linking too, and this apparently causes the object file to be
> treated as a source file.  We'll need to untangle this mess, but not
> today :)

This should be fixed now, by commit 6ebc3f1b09.  Hopefully, for real
this time :)

--
Ell
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] GNU++11 not allowed with Objective-C code

[Ell via gimp-developer-list]

On Sat, 7 Apr 2018 17:35:20 -0400
Partha Bagchi  wrote:

> Confirmed. It's something you did!! :) :)
> 
> Anyway, reverted back to previous head and c++14 error is back but
> all the above is gone.

Ha, of course it is :)  The commit caused -xobjective-c to be passed
during linking too, and this apparently causes the object file to be
treated as a source file.  We'll need to untangle this mess, but not
today :)

--
Ell
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] GNU++11 not allowed with Objective-C code

[Ell via gimp-developer-list]

On Sat, 7 Apr 2018 15:43:30 -0400
Partha Bagchi  wrote:

> My apologies. I should have framed that as 2 different issues. One
> about  
> the compilation and the other that we should probably be using C++14
> (or 11) instead of gnu++11.

The exact flag we use is not hard coded, it's determined by
AX_CXX_COMPILE_STDCXX() during configure.  We *could* ask it for a
strictly standard-compliant mode, but we're not that concerned about
it.  We might want to use some GCC extension, based on some other
configure test, or whatnot.

> 
> In any case, the verbose mode may not be particularly helpful:
>
> [...]
> 
> In there you can see "-xobjective-c" is being used to compile
> gimp-parallel.cc. Also, you're seeing -std=c++14 because I have
> CXXFLAGS defined that way.

Thanks.  So, we've been passing "-xobjective-c" unconditionally to all
compiled files on Mac.  Commit 06950be7f0 should fix that, only passing
it when compiling C files.

--
Ell
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] GNU++11 not allowed with Objective-C code

[Ell via gimp-developer-list]

On Sat, 7 Apr 2018 12:41:10 -0400
Partha Bagchi  wrote:

> Ell my friend, it's me again. :)
> 
> We can't use gnu++11 with objective-c code.
> 
>   CXX  gimp-parallel.o
> 
> error: invalid argument '-std=gnu++11' not allowed with 'Objective-C'
> 
> make[3]: *** [gimp-parallel.o] Error 1
> 
> So, how do we fix this? Also, shouldn't we be using c++11 or c++14 to
> be generic?

The specific compiler flag is chosen by some configure magic, so it
should generally be ok.  A little googling shows that people are
getting the same error with -std=c++11 too.

I'm not sure why clang tries to compile this as objective-c, though.
Can you post the output of $ make V=1 ?

--
Ell
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Windows gimp-spawn.c compile Error

[Ell via gimp-developer-list]

On Fri, 9 Mar 2018 16:30:10 -0500
Partha Bagchi  wrote:

> Hi Ell,
> 
> This one has me stumped. I get the following compile error:
> 
> gimp-spawn.c: In function 'gimp_spawn_set_cloexec':
> > gimp-spawn.c:244:26: error: 'HANDLE' undeclared (first use in this
> > function)
> >SetHandleInformation ((HANDLE) _get_osfhandle (fd),
> > HANDLE_FLAG_INHERIT, 0);
> >   ^~
> > gimp-spawn.c:244:26: note: each undeclared identifier is reported
> > only once for each function it appears in
> > gimp-spawn.c:244:34: error: expected ')' before '_get_osfhandle'
> >SetHandleInformation ((HANDLE) _get_osfhandle (fd),
> > HANDLE_FLAG_INHERIT, 0);  
> 
> 
> I think this means that the includes windows.h and io.h are not seen.
> If I change Line 34
> 
> > #ifdef G_OS_WIN32  
> 
> to
> 
> > #ifdef __WIN32__  
> 
> 
> then it works for me. What do you think is going wrong?

The include order was wrong, so the Windows headers were indeed not
included.  Fixed by b590b5954202fa379284a13914d1c08b0b8b221e.  Thanks :)

--
Ell
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] GIMP-get Compile Failure (Windows)

[Ell via gimp-developer-list]

On Sat, 20 Jan 2018 16:06:46 -0500
Partha Bagchi  wrote:

> Ell,
> 
> Issues with process_system_time (addition from yesterday?):
> 
>   CC   gimpdashboard.o
> > gimpdashboard.c: In function 'gimp_dashboard_sample_cpu_usage':
> > gimpdashboard.c:1559:27: error: 'process_system_time' undeclared
> > (first use in this function); did you mean 'process_user_time'?
> >   _system_time,
> >^~~
> >process_user_time
> > gimpdashboard.c:1559:27: note: each undeclared identifier is
> > reported only once for each function it appears in
> > Makefile:1381: recipe for target `gimpdashboard.o' failed
> > make[4]: *** [gimpdashboard.o] Error 1  
> 
> 
> I think you meant to say "process_kernel_time".

Indeed.  This is what happens when you push untested code :)

Fixed in 4d3720baad3792a418f2d002b66440c1bda29cbb, thanks!

--
Ell
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Gimp GIT and GEGL GIT = segment fault

[Ell via gimp-developer-list]

On Thu, 28 Dec 2017 17:31:48 +0100
Helmut Jarausch  wrote:

> Hi,
> Segmentation fault in gegl_buffer_iterate_read_simple
> 
> [...]

This should be fixed now in GEGL master, by commit
03bdb529bccfcc5bc51dd02bc266d901a4af6300 (see also bug 792018).

--
Ell
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Show clipped and out of gamut colors using blinking colors

[Ell via gimp-developer-list]

On Fri, 10 Nov 2017 09:44:37 -0500
Elle Stone  wrote:

> Is this the case? The clip warning always and only shows colors that
> are out of gamut wrt to GIMP's built-in sRGB color space?

At the moment, yes.

--
Ell
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Show clipped and out of gamut colors using blinking colors

[Ell via gimp-developer-list]

On Fri, 3 Nov 2017 09:38:33 -0400
Elle Stone <ellest...@ninedegreesbelow.com> wrote:

> On 11/02/2017 04:21 PM, Ell via gimp-developer-list wrote:
> > On Fri, 20 Oct 2017 09:03:01 -0400
> > Elle Stone <ellest...@ninedegreesbelow.com> wrote:
> >   
> >> Hi All,
> >>
> >> It would be really nice to be able to click a button or have a view
> >> module option that would indicate clipped colors by coloring them
> >> in some way (perhaps black for shadows, white for highlights),
> >> with an option to make these pixels blink.  
> > 
> > master has a clip-warning display filter now (commit 5b118a260b),
> > which does that.  No blinking, though :)  
> 
> Hi Ell, and thank you! That clip warning display filter is really
> nice!

Yay, glad you like it :)

> Regarding the blinking, personally I don't much like blinking pixels
> - probably the only advantage of blinking is to draw attention to
> very small areas that have out of display range colors. Seeing these
> areas probably requires zooming in to 100% for just about all image
> editing softwares, so the blinking per se doesn't seem all that
> useful.

I can see how blinking, or more generally, animating the warning
(say, marching-ants style), can be useful.  The main reason why it's
not there is that the pain/gain ratio of implementing this is too
high to justify, for now anyway.

> Yesterday when I compiled GIMP the new filter was there, but nothing
> was happening on the image - not sure why. But today I updated GIMP
> again, and recompiled, and made an image that was a gradient from
> -1.0f to +2.0f. The gradient ran from the upper left to the lower
> right corner. The Clip Warning shows diagonal parallel red and black
> bars for the highlights, and diagonal parallel blue and black bars
> for the shadows.

Yeah, the filter used to run after the conversion to the monitor
profile, at which point the colors were probably already clipped.  The
last commit from today (9cd8e7f9c6) moves the filter before the monitor
transform.

> Are there supposed to be diagonal bars instead of solid blotches of
> the user-chosen warning colors? If so, how would this work with
> images with just speckles and very small areas of out of display
> range colors? I'll try to do some more experimenting later on today.

Yes, the diagonal stripes are basically a static substitute for
blinking: it's possible that your image has areas with similar color to
the warning color, but it's much less likely that these areas also have
a stripe pattern, making the warning more distinguishable.

I'm not sure why this would be specifically problematic with small
our-of-range areas (though obviously less useful in these cases.)  Note
that the size of the stripe pattern is independent of the area size, or
the zoom level, so, in particular, when you zoom in you can see the
pattern over individual pixels.

--
Ell
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Show clipped and out of gamut colors using blinking colors

[Ell via gimp-developer-list]

On Fri, 20 Oct 2017 09:03:01 -0400
Elle Stone  wrote:

> Hi All,
> 
> It would be really nice to be able to click a button or have a view 
> module option that would indicate clipped colors by coloring them in 
> some way (perhaps black for shadows, white for highlights), with an 
> option to make these pixels blink.

master has a clip-warning display filter now (commit 5b118a260b), which
does that.  No blinking, though :)

https://i.imgur.com/5PJpWi8.png

--
Ell
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] missing babl fast path and lt-gimp-2.9 segfault

[Ell via gimp-developer-list]

On 08/11/2017 04:02 AM, Tobias Ellinghaus wrote:
> To make the backtrace even more useful you can use these commands in gdb once 
> GIMP crashed (just copy them over):
> 
> set pagination off
> set logging file gdb.txt
> set logging on
> where
> echo \n=\n\n
> info threads
> echo \n=\n
> thread apply all bt full
> 
> the result will be in the file "gdb.txt".

Useful indeed :)

--
Ell
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] missing babl fast path and lt-gimp-2.9 segfault

[Ell via gimp-developer-list]

On 08/10/2017 10:54 PM, richard brown wrote:
> Here we are:
> 
> Thread 1 "gimp-2.9" received signal SIGSEGV, Segmentation fault.
> g_type_check_instance (type_instance=type_instance@entry=0x4ce7a90) at 
> gtype.c:4131
> 4131  TypeNode *node = lookup_type_node_I 
> (type_instance->g_class->g_type);
> (gdb) bt
> #0  g_type_check_instance (type_instance=type_instance@entry=0x4ce7a90) 
> at gtype.c:4131
> #1  0x73d67d5e in g_signal_emit_valist (instance=0x4ce7a90, 
> signal_id=227, detail=0, var_args=var_args@entry=0x7fffdbf0) at 
> gsignal.c:3176
> #2  0x73d6900f in g_signal_emit (instance=, 
> signal_id=, detail=detail@entry=0) at gsignal.c:3447
> #3  0x750a51d3 in delayed_emission (data=0x7fffb8005040) at 
> gegl-node.c:2192
> #4  0x73a71a9a in g_main_dispatch (context=0xd42e90) at gmain.c:3148
> #5  g_main_context_dispatch (context=context@entry=0xd42e90) at gmain.c:3813
> #6  0x73a71e48 in g_main_context_iterate (context=0xd42e90, 
> block=block@entry=1, dispatch=dispatch@entry=1, self=) at 
> gmain.c:3886
> #7  0x73a72172 in g_main_loop_run (loop=0x33289c0) at gmain.c:4082
> #8  0x00494612 in app_run (full_prog_name=, 
> filenames=, 
> alternate_system_gimprc=alternate_system_gimprc@entry=0x0, 
> alternate_gimprc=alternate_gimprc@entry=0x0, session_name=,
>  batch_interpreter=0x0, batch_commands=0x0, as_new=0, 
> no_interface=0, no_data=0, no_fonts=0, no_splash=0, be_verbose=0, 
> use_shm=1, use_cpu_accel=1, console_messages=0, use_debug_handler=0, 
> show_playground=1,
>  stack_trace_mode=GIMP_STACK_TRACE_QUERY, 
> pdb_compat_mode=GIMP_PDB_COMPAT_WARN) at app.c:331
> #9  0x00493f45 in main (argc=, argv=0xc866c0) at 
> main.c:551
> 
> 
> 
> 
> I have four threads set in preferences. The image is 16bit gamma 
> integer, and I try and stretch HSV contrast.

Thanks.  This should be fixed in GEGL master:

commit e3787440917255b6936a8d55428aa9402fdfba08
Author: Ell 
Date:   Fri Aug 11 08:44:27 2017 -0400

gegl-node: only emit the progress signal from the main thread

Only emit the progress signal when gegl_node_progress() is called
from the main thread -- don't queue a signal emission from other
threads.  Otherwise, the queued signal may be emitted after the
operation is complete, and, in particular, after the node is
destroyed (we could keep a the node alive while the signal is
queued, but that's not really useful.)

Regardless, for auto-threaded ops, each thread would track its
progress independently, so emitting interleaving progress signals
from different threads is not too meaningful anyway, while only
reporting the main thread's progress should give a good-enough
indication of the overall progress.

 gegl/graph/gegl-node.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

Note that the HSV stretch contrast operation doesn't work correctly with
multiple threads atm, so you're still better off using a single thread,
but at least it doesn't crash anymore :)

If you run into more issues, feel free to report them through our bugzilla:

  https://bugzilla.gnome.org/enter_bug.cgi?product=GIMP

--
Ell
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] missing babl fast path and lt-gimp-2.9 segfault

[Ell via gimp-developer-list]

On 08/09/2017 07:31 AM, richard brown wrote:
> But, I checked 'Preferences' and I was running 4 threads, and there's a 
> warning there about instability.  So, I tried putting that to 1, and, so 
> far, no crash.

Hi!  We're trying to track down (and fix) as many threading related bugs
as we can.  They're especially sneaky, so reporting these bugs helps us
greatly.  Could you please file a bug report, explaining what you did to
trigger the crash?  A backtrace at the point of the crash would also be
very helpful: when you run gimp under gdb, type "bt" once gimp crashes,
and include the output in the bug report.

Thanks :)

--
Ell
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Masks not very effective in 2.9 scheme script

[Ell via gimp-developer-list]

On Tue, 11 Jul 2017 00:38:17 +0100
Ken Moffat  wrote:

> Hi,
> 
> TL;DR - using masks in a 2.8 scheme script works as intended to
> extract parts of an image, but after converting it for 2.9 it does
> much less.

The most likely reason for the different results, is that in 2.9 masks
use the pixels' linearized intensity as the alpha value, while in 2.8
they use the gamma-corrected intensity.  The linearized intensity
values are generally lower than the gamma-corrected ones, so the
resulting mask values, after pasting a desaturated image into the mask,
are lower in 2.9 than they would be in 2.8, resulting in a subtler
effect.  Note that these sorts of interactions is something we're still
working on.

For now, you have several options:  You can cast the mask values from
gamma-corrected ones to linear ones.  While there's no "obvious" way to
do that, there are several hackish ways.  For example, you could use
"colors -> components -> extract component", select any of the RGB
components, and enable "linear output".  You can do that either before
or after pasting the desaturated image into the mask; either way, you
should make sure to use high precision ("image -> precision"),
preferably floating point, or else there'll be notable data loss in
the intermediary results, in either the dark or the bright areas.
Unfortunately, this operation is not currently available to scripts.
You can get a good approximation for it using the levels tool instead
("colors -> levels"), with a gamma of 2.2.

Alternatively, you can avoid masks and use other forms of layer
compositing, although this might be more cumbersome.  Instead of
attaching a mask to a layer, keep both the masked layer and the mask as
ordinary layers, and put them in their own layer group, with the "mask"
layer below the "masked" layer.  Use "colors -> color to alpha", with
black color, on the mask, to turn black into transparency.  Then, set
the upper layer's mode to "multiply", or, alternatively, to
"normal" (from the default group), while also setting its composite
mode to "source atop" (in the layer attributes dialog).  If you want to
keep the mask layer opaque, then instead of using "color to alpha", add
a black layer above it, set its layer mode to "color erase" (from the
default group), and set its blend space to "RGB (perceptual)" (in the
layer attributes dialog).

All of the above (except as noted) is doable through a script, although
I'll leave it to you to work out the details :)  The procedure browser
is your friend.

--
Ell
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Warp transform: spacing option

[Ell via gimp-developer-list]

On Fri, 16 Jun 2017 07:37:22 +0200
Julien Hardelin  wrote:

> Hello developers,
> 
> Sorry to disturb you again : I have difficulty in documenting the 
> Spacing option of Warp Transform.
> 
> Checking or unchecking this option makes no difference in the result
> of Move pixels.
> 
> I thought it could be related to the Stroke periodically option (that 
> has a Rate option), but I can see no difference after checking or 
> unchecking it also.
> 
> And no reference on the Web.
> 
> Please help me for these two options.

I'd suggest waiting with the documentation of these options, as they're
likely to change.  The interplay between them is indeed a bit vague at
the moment.  Ultimately, they'll most likely behave similarly to the
"spacing", "motion only", and "rate" options of the airbrush tool.

--
Ell
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Warp transform Abyss policy

[Ell via gimp-developer-list]

On Wed, 14 Jun 2017 21:40:39 +0200
Marco Ciampa via gimp-developer-list 
wrote:

> On Wed, Jun 14, 2017 at 07:01:10AM -0400, Ell wrote:
> > On Wed, 14 Jun 2017 07:44:28 +0200
> > Marco Ciampa via gimp-developer-list 
> > wrote:
> >   
> > > Veeery interesting indeed Ell! And also very clear!
> > > Do you know exactly which tools share this same option?  
> > 
> > Warp is the only tool that has an abyss policy option, IIRC.  As for
> > filters, convolution matrix, displace, edge, fractal trace, and
> > Gaussian blur all have this option, although some of them call it
> > "border" or "border behavior" instead.  Bump map, ripple, and waves
> > also have a toggle that switches between two of the abyss policy
> > modes, although they call it "clamp", or "tiled/tileable".  
> 
> Ok probably a more coherent choice for a label for all these tools
> would be a good idea...

There are other similar inconsistencies across the different filters.
It would be nice if we made sure they're better aligned before 2.10.

> > > PS: also I see that in the warp tool the Abyss options remains
> > > translated in my system language (Italian) even if I set the gimp
> > > language to English... here and there there are some other
> > > translated particulars like 4 controls in the
> > > render->patterns->checkboard filter, tooltips, keyboard
> > > accelerators...small bug?  
> > 
> > The text for the abyss policy items comes from GEGL.  It seems that
> > switching the language in the preferences only affects GIMP text,
> > and not GEGL.  We should probably fix that, since it affects all
> > the GEGL filters.  
> 
> Very good catch!
> 
> Now you said it I see that all the untranslated operations are
> GEGL... :-)

Aaaand... fixed in master.  Commit
d37fb8aa5c915b57d07da2f2e48fac36e75e7a64.

--
Ell
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Warp transform Abyss policy

[Ell via gimp-developer-list]

On Wed, 14 Jun 2017 07:44:28 +0200
Marco Ciampa via gimp-developer-list 
wrote:

> Veeery interesting indeed Ell! And also very clear!
> Do you know exactly which tools share this same option?

Warp is the only tool that has an abyss policy option, IIRC.  As for
filters, convolution matrix, displace, edge, fractal trace, and Gaussian
blur all have this option, although some of them call it "border" or
"border behavior" instead.  Bump map, ripple, and waves also have a
toggle that switches between two of the abyss policy modes, although
they call it "clamp", or "tiled/tileable".

> Your example seems to come from the whirl-pinch distortion filter but
> I do not see any abyss option in the filter option dialog... even in
> any other filter option dialog... am I looking in the wrong place?

The example uses the warp tool, of course :)  It is in swirl mode,
though, as you guessed.  The whirl/pinch filter indeed lacks this
option.

> PS: also I see that in the warp tool the Abyss options remains
> translated in my system language (Italian) even if I set the gimp
> language to English... here and there there are some other translated
> particulars like 4 controls in the render->patterns->checkboard
> filter, tooltips, keyboard accelerators...small bug?

The text for the abyss policy items comes from GEGL.  It seems that
switching the language in the preferences only affects GIMP text, and
not GEGL.  We should probably fix that, since it affects all the GEGL
filters.

--
Ell
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Warp transform Abyss policy

[Ell via gimp-developer-list]

On Tue, 13 Jun 2017 18:39:39 +0200
Julien Hardelin  wrote:

> Hello developers,
> 
> I am writing gimp-help-2 doc for warp transform tool and I have 
> difficulty with "Abyss policy". I read the wiki/glossary for these
> items but did not understand what they do.
> 
> How to explain these features to users?

Granted, the abyss policy option is a bit on the technical side.

The warp tool moves pixels from one point to another.  Some pixels may
come from outside the layer boundary.  These pixels don't actually
exist anywhere, and therefore don't have any associated color; yet, we
must assign *some* color to them.  The abyss policy specifies how to
determine their color:

  - None:  Assume that all pixels outside the layer boundary are
transparent.

  - Clamp:  Assume that each edge of the layer stretches out
indefinitely, so, for example, a pixel to the left of the layer
boundary has the same color as the leftmost pixel of the layer with
the same y coordinate.  An alternative way to think of it is that
each pixel outside the layer boundary has the same color as the
closest pixel inside the layer boundary.

  - Loop:  Assume that the layer repeats itself in all directions, so
that, for example, falling off the right edge of the layer takes
you back to the left edge.

And here's a quick comparison of the three modes:
http://i.imgur.com/R5RKkLF.gif

You'll find an abyss policy option in some of the filters as well, with
a similar function.  In filters, there are additional "black" and
"white" modes, which are similar to "none", but use black and white for
out-of-bounds pixels, instead of transparency.

--
Ell
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] GIMP git build error on Mac

[Ell via gimp-developer-list]

On Fri, 2 Jun 2017 06:55:41 -0400
Partha Bagchi  wrote:

> Sounds good. Let me know when you upload a fix. Thanks in advance for
> such a quick fix! :)

Should be fixed now, by commit 3ca48a0b30a85cfc8a63912906dd483208c342fb.

--
Ell
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] GIMP git build error on Mac

[Ell via gimp-developer-list]

On Thu, 1 Jun 2017 22:28:07 -0400
Partha Bagchi  wrote:

> > Can you please report the output of "make V=1"?
> >
> > --
> > Ell
> >  
>  Sure thing Ell. Here it is:

Thanks :)

> make[2]: Nothing to be done for `all'.
> 
> Making all in libgimpbase
> 
> if ! cmp -s xgen-bec gimpbaseenums.c; then \
> 
> cp xgen-bec gimpbaseenums.c; \
> 
> else \
> 
> # if the file hasn't changed, only update its timestamp, so that \
> 
> # the receipe doesn't get executed again next time, but allow this \
> 
> # to fail (e.g., when using a read-only source directory). \
> 
> touch gimpbaseenums.c 2> /dev/null \
> 
> || true; \
> 
> fi
> 
> /bin/sh: -c: line 1: syntax error: unexpected end of file
> 
> make[2]: *** [gimpbaseenums.c] Error 2
> 
> make[1]: *** [all-recursive] Error 1
> 
> make: *** [all] Error 2

Hrmph, must be the comment in the middle of the recipe.  I was actually
surprised it worked in the first place -- must be a bash thing.

Oh well, no comments it is then :P

--
Ell
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] GIMP git build error on Mac

[Ell via gimp-developer-list]

On Thu, 1 Jun 2017 19:15:03 -0400
Partha Bagchi  wrote:

> Hi All,
> 
> A new wrinkle since May 22 (my last build). Did a pull today and now
> I am now getting the following error on my Mac:
> 
> GEN  xgen-bec
> > /bin/sh: -c: line 1: syntax error: unexpected end of file
> > make[2]: *** [gimpbaseenums.c] Error 2
> > make[1]: *** [all-recursive] Error 1
> > make: *** [all] Error 2  

Can you please report the output of "make V=1"?

--
Ell
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Search box for layers

[Ell via gimp-developer-list]

On Tue, 18 Apr 2017 15:59:45 +0900
John Tapsell  wrote:

> Hi,
> 
>   I have around a hundred layers, and it's really cumbersome to
> navigate. I was wondering:
> 
> What do you think of a having a filter/search box for the layers?  To
> let you jump to a layer quickly

In 2.9 we have a new action search dialog.  It might be interesting to
include more than just actions in the search results, such as images,
layers, paths, brushes, etc.

--
Ell
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Error Message on Gegl - Last Git Master

[Ell via gimp-developer-list]

On Sun, 26 Mar 2017 14:00:28 -0300
Americo Gobbo <jag.rabi...@gmail.com> wrote:

> I have installed my dependencies directly on my gimp folder because I 
> had different dependencies outdated on my distro.
> So, to install Pango 1.38 or higher is necessary to install also the 
> dependencies of this version?
> I have tried install in my 'make' environment the pango-1.38.1, but 
> without success and on my ./configure (final part) has these messages:
> 
> checking whether the c++ linker (/usr/bin/ld -m elf_x86_64) supports 
> shared libraries... yes
> checking dynamic linker characteristics... (cached) GNU/Linux ld.so
> checking how to hardcode library paths into programs... immediate
> configure: creating ./config.lt
> config.lt: creating libtool
> checking for some Win32 platform... no
> checking for pkg-config... /usr/bin/pkg-config
> checking pkg-config is at least version 0.9.0... yes
> checking for HARFBUZZ... no
> checking for CoreText availability... no
> checking for CAIRO... yes
> checking which cairo font backends could be used... none
> configure: Disabling cairo support
> configure: error: *** Could not enable any backends.
> *** Must have at least one backend to build Pango.
> ---
> Can you help to resolve the steps to follow?

Looks like Pango can't find the cairo freetype backend, which is
strange because it's installed by the "libcairo2-dev" package on
Ubuntu.  If you're building cairo yourself, you might be missing some
dependencies required to build freetype support.

> On 26-03-2017 13:16, Ell via gimp-developer-list wrote:
> > Actually, there was an interval where gegl:text would get built
> > without checking this dependency, so it's possible that this is a
> > leftover from an earlier build (although that would be weird if
> > this problem only started recently.)  You can manually remove
> > "text.so" (and make sure that it's not getting reinstalled by a
> > GEGL "make install") if that's the case.  It shouldn't be a problem
> > for GIMP for now, but in the long run it's better to get it built.  
> Ok, now is Ok!
> After LGM I am thinking install a new release of my distro... the 
> current, sure is becoming a bit outdated ;-)
> To install the new release of Pango is not recommended on my 
> ubuntu-gnome 14.04?

You can probably install a new Pango relase on 14.04 if you're
persistent enough, but a shiny new distro is always better :)

--
Ell
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Error Message on Gegl - Last Git Master

[Ell via gimp-developer-list]

On Sun, 26 Mar 2017 11:53:57 -0400
Ell via gimp-developer-list <gimp-developer-list@gnome.org> wrote:

> On Sun, 26 Mar 2017 11:11:36 -0300
> Americo Gobbo <jag.rabi...@gmail.com> wrote:
> 
> > Hi I have updated my git master... but I have this message while I
> > am creating an screenshot or exporting as jpg, png, etc: Module
> > '/opt/gimp-default-master/lib/gegl-0.3/text.so' load
> > error: /opt/gimp-default-master/lib/gegl-0.3/text.so: undefined
> > symbol:pango_attr_foreground_alpha_new. --- Is possible that the
> > dependencies are modified recently? Thanks, americo
> > 
> > ---
> > My distro is Ubuntu 14.04.3 GNOME 3.10  
> 
> GEGL requires Pango >= 1.38 to build gegl:text since February.  Looks
> like Ubuntu 14.04 ships with 1.36.  Either way, this should be picked
> up when you configure GEGL.  Is it possible you're building against a
> newer version of Pango than the one being picked up at runtime?

Actually, there was an interval where gegl:text would get built without
checking this dependency, so it's possible that this is a leftover from
an earlier build (although that would be weird if this problem only
started recently.)  You can manually remove "text.so" (and make sure
that it's not getting reinstalled by a GEGL "make install") if that's
the case.  It shouldn't be a problem for GIMP for now, but in the long
run it's better to get it built.

--
Ell
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Proposal for erasing background from an image

[Ell via gimp-developer-list]

On 03/02/2017 02:24 AM, John Tapsell wrote:

Hi all,


  I'm guessing this is frowned on but I've written this up on my blog here:


Absolutely not frowned upon :)


...


Hate to be a buzzkill, but it's already doable: clone tool + color erase 
mode + registered alignment.


Note that this technique might not work as well as you imagine.  For 
each pair of background/output colors, what you essentially do is pass a 
ray from the background color, towards the output color, and look for 
the ray's intersection with the hull of the RGB cube.  This point is 
your foreground color, and the alpha is the relative position of the 
output color along the background-foreground segment.  This means, that 
all resulting foreground colors are on the hull of the color cube (i.e., 
fully saturated, including black, or full-value), and, conversely, all 
output colors that aren't on the hull result in semi-transparent 
foreground pixels.


Something that might be fun to try is this: suppose you have two pairs 
of background/background+foreground images, where the backgrounds are 
different, while the foreground object aligns (as much as possible) 
across the two images  Then, at each pixel, you have two 
background->output rays, and, ideally, the true foreground color is 
their point of intersection.  Most chances are that the rays won't 
intersect exactly, because of imperfect alignment/differences in color, 
but you can still look for the pair of points, one along each ray, that 
minimize the distance between each other; each one would be the 
foreground color for the corresponding image pair.


That being said, I imagine you'd need such a controlled environment to 
get good results with this, while there are usually simpler 
alternatives, that this strikes me as something that will only be useful 
is very specialized cases.


--
Ell
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Layer modes: Add vivid light blend mode?

[Ell via gimp-developer-list]

On 01/23/2017 06:58 AM, Laxminarayan Kamath wrote:

Hi all!

While you guys are at it, I encourage you to try out this formula:

E = (2 * I ) - M


Note that the recent work in master removed the channel-value clamping
that used to happen during blending (yay! :), and since each layer
appears only once in this formula, you can implement this mode using the
existing ones, with the help of some ancillary layers, but without
having to duplicate the "content" layers (I and M).

--
Ell
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list