s, instead of
just looking at the four orthogonal neighbors of each pixel, they look
at all eight neighbors. This comes in handy when working with thin lines
and curves, as shown in http://i.imgur.com/fLDUlEf.png.
Any takers?
--
Ell
___
gimp-developer-li
On 11/01/2016 05:28, Jehan Pagès wrote:
> Hello,
>
> On Sun, Jan 10, 2016 at 4:32 PM, Ell wrote:
>> Hi, Gimpers!
>>
>> I have a small patchset that I wonder if might be of interest. It adds a
>> "diagonal neighbors" option to the fuzzy-select and
On 17/01/2016 14:46, Alexandre Prokoudine wrote:
> BTW, do you want to be acknowledged as Ell in the list of
> contributors, or would you like full first/second names to be used?
Just Ell is fine, thanks :)
--
Ell
___
gimp-developer-list mailin
angry reply to this thread, or on the bug report. We can always
change the default back to "hard" if it turns out to be an issue.
Cheers.
[1] https://bugzilla.gnome.org/show_bug.cgi?id=764614
--
Ell
___
gimp-developer-list mailing list
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 addres
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
On Sun, 26 Mar 2017 11:53:57 -0400
Ell via gimp-developer-list wrote:
> On Sun, 26 Mar 2017 11:11:36 -0300
> Americo Gobbo 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
&
uilding 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 possibl
n 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
d 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
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 li
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-dev
f 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
___
gim
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
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 interes
ith 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.
--
ts 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
;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 arch
1
> #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 e3787440917255b6936a8d55428aa9
==\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
Lis
gt; 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-develo
On Fri, 3 Nov 2017 09:38:33 -0400
Elle Stone 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 wrote:
> >
> >> Hi All,
> >>
> >> It would be really nice to be able to click
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 m
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 7920
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: er
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' u
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-
nditionally 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/
ing 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://
On Sat, 7 Apr 2018 18:00:57 -0400
Ell via gimp-developer-list wrote:
> 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
> >
,
> 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 varia
g "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
, 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:
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 sho
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 ac
b.com/aferrero2707/gimp-appimage/blob/master/gimp-glib-splash.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
499a8962b326823b
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
imp-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:
;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
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 wron
> 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 mailin
tlab 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
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-
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, a
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
e 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.
een.
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.
__
>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
t 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 ne
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
d. 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:gim
ning the two layers using Merge mode:
https://streamable.com/r7yie
Note that the original image in the example deliberately has
semitransparency to begin with, otherwise the same result could have
been achieved with Erase mode instead of Split (but not with Normal
instead of Merge).
--
Ell
___
ver 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/mail
ath), 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.
ast-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
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 t
indows-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
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
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
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
60 matches
Mail list logo
