Re: [Gimp-developer] GIMP 2.8.16

[Michael Henning]

Yes, gimp 2.8 is supported on Windows 10.

From,
drawoc

On Sun, Nov 22, 2015 at 5:30 PM, hiro34567  wrote:

> Please teach it
>
> GIMP 2.8.16
>
> Do you support Windows 10 ?
>
>
> hiro
>
> ___
> 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-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] Application Information Required for Windows 10 |GIMP v2.6.6|

[Michael Henning]

Hello. Gimp 2.6 is an old version that is no longer supported on any
platform.

I recommend that you upgrade to gimp 2.8, which is supported on Windows 10.

The current gimp release (at the time of writing) is 2.8.14.

Always download gimp at the official site: http://www.gimp.org/downloads/

From,
drawoc

On Thu, Nov 12, 2015 at 3:40 AM, Kuppan, Rajasekar <
rajasekar.kup...@citi.com> wrote:

> Dear Team,
>
> Good Day! We are from CITI Application Readiness Team, need your
> assistance in order to gather info about application compatibility and
> support for Windows 10. We would like to know whether the below application
> is compatible and supported for Win 10 (64 Bit). If you haven't tested ,
> could you please provide us a tentative date of when we can reach you .
>
> Application Name : GIMP v2.6.6
>
> If the above version is not compatible with Windows 10. Then do we have
> any higher version/replacement which compatible with Windows 10.
>
> Thanks in Advance
> Rajasekar K
> Citigroup Inc.
> +91-4439290662
> ___
> 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-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] Brush + Paint Dynamic - performance problems and comparison between 2.9 and 2.8.14.

[Michael Henning]

Please update to latest gimp master and test. I think I fixed this.

commit 3233a70bae756e8f62fb144cbce9d8f84ed25609
Author: Michael Henning
Date:   Sun Sep 6 00:05:32 2015 -0400

libgimpwidgets: Avoid updating the rulers too often.

Ever since 72617e42b, whenever the user generated a lot of mouse
input, we would constantly queue redraws to the rulers. These redraws
had a higher idle priority than updating the canvas, so we would
rarely get around to canvas updates, which made certain tools
(painting with dynamics, the blend tool) feel very unresponsive.

This fixes it by only redrawing the rulers if the mouse has moved
far from the last location, or if there are no idle handlers with
a priority above LOW.

From,
   drawoc

On Sun, Sep 6, 2015 at 3:00 PM, Americo Gobbo <jag.rabi...@gmail.com> wrote:

>
> On Sun, Sep 6, 2015 at 3:04 PM, Richard <strata_ran...@hotmail.com> wrote:
>
>> IIRC, this was previously discussed on the mailing list (and bugzilla)
>> and the cairo library was identified as a culprit/accessory to the lag --
>> as some users reported downgrading to a previous libcairo fixes the ruler
>> lag.
>>
>> However, it also appears to have been properly fixed as of mid-August:
>> https://bugzilla.gnome.org/show_bug.cgi?id=736411#c39
>> <https://bugzilla.gnome.org/show_bug.cgi?id=736411>
>>
>
> Thanks Richard, but it seems all OK are to windows... on my linux box the
> problem is resolved only without rulers.
>
> I work only on linux, and in this box I've two GIMP, the stable 2.8.14
> (otto ppa) and and the 2.9 devel (last git master). My box is ubuntu
> gnome 14.04.2 - 64-bit. Memory 8Gb, Intel® Core™ i5-3570K CPU @ 3.40GHz ×
> 4, Gallium 0.4 on AMD CAICOS.
>
> The 2.9 first of the patch of Michael Henning in August 11, was working
> well with the rulers.
> The 2.8.14 stable - ppa otto, is working well.
>
> git log on my 2.9 git master >
>
> commit 72617e42b426e6788c075539a20df7365d2cf102
> Author: Michael Henning <dra...@darkrefraction.com>
> Date:   Tue Aug 11 16:20:59 2015 -0400
>
> Bug 736411 - Ruler updates cause slowdown when painting
>
> We now avoid drawing rulers in the position property setter and use
> gtk's region invalidation instead. Previously, we were basically
> redrawing the ruler inside the mouse event handler, which is pure evil.
>
> thanks
>
___
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 compile error on Mac OSX

[Michael Henning]

Should be fixed, thanks. :)

commit dbe598275366a92c2b4d32e376f75cee110d4047
Author: Michael Henning
Date:   Sun Sep 6 19:43:25 2015 -0400

app: Always return a value from results_list_on_key_press_event


On Sun, Sep 6, 2015 at 6:55 PM, Partha Bagchi <parth...@gmail.com> wrote:

> Latest pull from today. Getting the following error
> ___
> Making all in widgets
>
>   CC   gimpsearchpopup.o
>
> gimpsearchpopup.c:557:3: error: non-void function
> 'results_list_on_key_press_event' should return a value
> [-Wreturn-type]
>
>   g_return_if_fail (kevent->keyval != GDK_KEY_Escape   &&
>
>   ^
>
> /Users/partha/local/include/glib-2.0/glib/gmessages.h:379:3: note:
> expanded from macro 'g_return_if_fail'
>
>  return;\
>
>  ^
>
> 1 error generated.
>
> make[4]: *** [gimpsearchpopup.o] Error 1
> ___
>
> Using glib 2.45.7
> ___
> 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-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] Brush + Paint Dynamic - performance problems and comparison between 2.9 and 2.8.14.

[Michael Henning]

Does this issue clear up if you disable the rulers (by unchecking View ->
Show Rulers)? If so, it's probably my fault.

From,
   drawoc

On Fri, Sep 4, 2015 at 8:55 PM, Americo Gobbo  wrote:

> On Fri, Sep 4, 2015 at 9:45 PM, Americo Gobbo 
> wrote:
>
> > The short video with GIMP 2.9
> > https://youtu.be/_a4kchvSAvw
> >
>
> Problems with the video... now is OK, see the new:
> https://youtu.be/3hEzQO5mp_g
>
> Sorry ;-)
> ___
> 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-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-user] Time to fork BABL and GEGL

[Michael Henning]

On Mon, Nov 17, 2014 at 11:39 PM, Gez lis...@ohweb.com.ar wrote:
 P.s.: If you think this discussion is a waste of your time and my time,
 feel free to skip an answer. I don't think it's a waste of time at all,
 it's developer/user interaction regarding important aspects of the tool.
 Do you really think that discussing this is counterproductive?

Yes, I think that discussing this is counterproductive because it is
premature. If I had spent the time I spent responding to color-related
emails on coding this system instead, it would easily be working right
now. Then, we could be discussing the details of a system that
actually existed, instead of the details of a system that does not
exist, and if current rates of coding continue, will never exist.

You say I should stop responding, but it's hard to stop responding
when novels are being written about how wrong you are, but you believe
you are right. It's hard to stop responding when an article portraying
you as incompetent appears on hacker news. It's hard to stop
responding when you genuinely want people to understand.

  -- drawoc
___
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-user] Time to fork BABL and GEGL

[Michael Henning]

On Mon, Nov 17, 2014 at 8:48 PM, Gez lis...@ohweb.com.ar wrote:
 If chromaticity independent RGB operations request for bablRGB or
 userRGB doesn't seem a mere implementation detail. I think it's a valid
 question to ask why requesting for bablRGB when the mechanism for
 userRGB will be available.


 Could you please address that question with a straight answer?

It's very likely that the processing will happen in userRGB for
performance reasons.

Nobody wants to give you a straight answer because to be honest, we
don't know for sure. We could change our mind at any point in the
future, and you wouldn't know without reading the code. It doesn't
matter what space they happen in because chromaticity independent
operations, by definition, do not care which of the spaces we pass
them. If we do find a compelling reason to have those operations
happen in bablRGB (performance or numerical stability, for example),
then we reserve the right to do those operations in bablRGB. And if we
do, then nobody will ever know the difference, other than the whopping
three people that will ever read that section of the gegl code.

Now, please explain this to me with a straight answer: Why is it so
insanely important to know what color space an operation happens in,
in a situation where it *by definition* does not matter, that you are
willing to waste hours of your time and hours of developers' time
arguing about it?

  -- drawoc
___
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] GSoC 2012 and 2013 projects update

[Michael Henning]

Quick correction: The n-point deformation hasn't been merged yet.

It's close, but the gegl api still needs some review and potentially
some cleanup before merge.

  -- drawoc

On Tue, Oct 28, 2014 at 4:26 AM, Alexandre Prokoudine
alexandre.prokoud...@gmail.com wrote:
 28 окт. 2014 г. 11:16 пользователь Joseph Bupe joseph.b...@gmail.com
 написал:

 Hi,

 Just wondering how the GIMP development team is getting along with the
 following projects:

 1. implementation of the combined selection tool (GSoC 2012)

 It wasn't a successful project.

 2. implementation of the n-point image deformation tool (GSoC 2013)

 It is merged into Git master.

 and they are not listed in the Gimp roadmap. 
 http://wiki.gimp.org/wiki/Roadmap

 Will fix it for the n-point tool, thanks for pointing out.

 Alex
 ___
 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-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] Artifacts after scaling, rotation... in 2.9 git

[Michael Henning]

I can reproduce this problem. I'm going to guess that the issue is
that the nohalo code is interacting badly with the sampler caching
code in gegl, which has been rewritten since the nohalo code was
originally written. Someone should probably look into that.

  -- drawoc

On Mon, Oct 27, 2014 at 2:27 PM, Alexander Rabtchevich
alexander.v.rabtchev...@gmx.net wrote:
 Because of the size. It seems the whole letter size should be smaller than
 40k. It will be easier to use external links.

 The original tiff
 https://yadi.sk/i/J1bi__FhcKvUJ


 The result of image resizing to 1600 pixels with nohalo.
 https://yadi.sk/i/bLjZia4ccKtHK

 Mint 17 x64, mate, AMD Phenom II X6 1075T Processor, 12 Gb RAM, built-in
 Radeon HD 4290 (no OpenCl).

 With respect,
 Alexander Rabtchevich


 Paka wrote:

 * Alexander Rabtchevich alexander.v.rabtchev...@gmx.net [10-27-14
 12:40]:

 I guess the enclosure were deleted. Here is the smaller file (jpg). I
 can upload the original tiff to the internet to reproduce my actions.

 With respect,
 Alexander Rabtchevich

 Alexandre Prokoudine wrote:

 On Sat, Oct 25, 2014 at 9:55 PM, Alexander Rabtchevich wrote:

 Here is an example after scaling (a crop from the image).

 Where? :)

 Alex
 ___
 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-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

 so if enclosures are deleted, why do you expect a smaller file to
 survive?


 ___
 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-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] Don't make an architectural mistake based on a groundless premise

[Michael Henning]

 choosing an RGB working space. Adobe has hard-coded ProPhotoRGB primaries
 into their raw processing software. It is distressing to see GIMP follow
 Adobe's lead by writing code on the assumption that the sRGB primaries are
 suitable for editing all images.

I'll repeat that the sRGB primaries won't be the only supported
working space. You talked us out of that idea a long time ago.

 But the R'G'B'A
 u8 and u16 and similar better be left alone because they have been
 written with the assumption that their data is sRGB.


 If there is code for 8-bit and 16-bit integer images that uses sRGB
 *primaries*, that code needs to be rewritten or removed. It makes no sense
 in the context of a high end, high bit depth image editor.

I think this was a little confusing. Øyvind seems to be talking about
the large quality loss that's inherent in converting between different
color spaces while using 8 or 16-bit integers. Personally, I think we
should have the capability of having integer data in different working
spaces, and there's no technical reason why that's impossible.

 Globally
 switching it upon switching images does not work for copy and paste
 between images and other forms of work where different spaces might be
 at play.


 Copy-paste/drag-drop do require converting the pixels from the source layer
 stack's ICC profile to the destination layer stack's ICC profile. That's
 what properly color-managed image editors do. Krita does this. Surely GIMP
 can also do this.

Whether babl does the color conversions or lcms does the color
conversions will not make a difference; as long as the color
conversions are implemented properly, they will produce the same
output. So yes, we will do proper conversions on copy/paste. Øyvind
was just talking about an implementation detail that needs to be
worked out.

 The babl conversion to XYZ uses the sRGB D65 color space xy values and
 the
 D65 white point to convert to XYZ. This results in wrong results even for
 sRGB images in a D50-adapted ICC profile color-managed workflow. The
 right
 thing to do is retrieve the user's chosen profile's colorant XYZ values
 and
 ferry that to babl. This takes the place of the hard coded (and wrong)
 D65
 sRGB xy values. The equations for converting from XYZ to LAB are well
 known.


 Babl has no XYZ format and thus in a sense no conversion to XYZ. The
 CIE Lab implementation which came from GIMP does however contains an
 internal conversion to XYZ; you are saying the CIE Lab code is broken.


 My apologies, I meant to type RGB to XYZ to LAB. You can't get directly
 from RGB to LAB. You have to go through XYZ. You get from RGB to XYZ by
 using the illuminant-adapted profile colorants.

Okay, that needs fixing, then.

 Also, proper color temperature change code requires converting to XYZ to
 do Bradford/CATO2/etc chromatic adaptation. So a function that converts from
 RGB to XYZ really is necessary. The current temperature change code is
 hard-coded for sRGB images and although it does produce pleasing results for
 sRGB images, those results are not colorimetrically correct.

I'm not totally clear on this point. Are you saying that it produces
incorrect results for sRGB, or that it produces incorrect results for
different color spaces? I'm not too familiar with this part of the
code.

Thanks for the input.

From,
   Michael Henning
___
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] Don't make an architectural mistake based on a groundless premise

[Michael Henning]

On Thu, Oct 9, 2014 at 7:22 PM, Elle Stone
ellest...@ninedegreesbelow.com wrote:
 My assumption was that sRGB as PCS only made sense in the context of using
 unbounded sRGB as a universal working space.

 If sRGB as PCS means that unbounded linear gamma sRGB is used to convert
 from RGB to XYZ to LAB, for example, then I'm not sure when sRGB as PCS
 would be used. For example, for converting to LAB, use the user-chosen
 primaries (colorants) to convert to XYZ and then to LAB.

See below.

 Ie, babl will support your suggestion (user-chosen primaries with
 either linear or sRGB TRC) in addition to sRGB, instead of replacing
 sRGB.


 Does in addition to sRGB mean duplicate code files side by side, one set
 of files hard-coded for just sRGB images and one using Y and XYZ values
 retrieved from the user's chosen primaries? For example, the babl code that
 converts from color to Luminance for painting on a mask would be duplicated,
 once for sRGB and once generalized?

To some degree, yes.

We don't need to recreate every single transformation. For example,
when converting from some arbitrary RGB color space to luminance, we
can chain the conversions: first, one conversion from the
user-specified RGB space to linear sRGB, and then from linear sRGB to
luminance. If that's too slow, we also have the option of defining
fast paths that convert directly between two color spaces, but the
core of babl always converts to linear sRGB as an intermediate. This
is what we mean when we say sRGB as PCS: all of the color formats
are defined in terms of linear sRGB, so if a given transformation
hasn't been coded specifically, we can use linear sRGB as an
intermediate.

Also, some portions of sRGB will probably share code with the generic
RGB code. But, the important point is that we want sRGB to still exist
within babl as a usable, built-in format.


 Adobe-centric advice implies that color gamut is the only consideration
 when
 choosing an RGB working space. Adobe has hard-coded ProPhotoRGB primaries
 into their raw processing software. It is distressing to see GIMP follow
 Adobe's lead by writing code on the assumption that the sRGB primaries
 are
 suitable for editing all images.


 I'll repeat that the sRGB primaries won't be the only supported
 working space. You talked us out of that idea a long time ago.


 Oh. I didn't realize that.

Maybe we weren't too clear.  :P

 The temperature change code produces very pleasing results for sRGB images,
 much nicer than another editor that I tried. Based on eyedroppering and
 comparing to spreadsheet calculations, the colors aren't colorimetrically
 correct and maybe they never were intended to be. On the other hand, I only
 checked Bradford adaptation and I'm not 110% certain I handled all the
 matrix math correctly.

 The current code uses hard-coded coefficients based on sRGB primaries and
 produces obviously wrong results for non-sRGB images. Bradford/CAT02 etc
 chromatic adaptation code would seem to be a logical generalized
 replacement.

 This article demonstrates using CAT02 to do color temperature corrections:
 http://nbviewer.ipython.org/gist/kelsolaar/7098c6709c59b9afb018
 The article uses the D65 sRGB color space, not the D50-adapted sRGB ICC
 profile color space, but it illustrates the math nicely.

Okay, we should probably look at that then.

From,
  Mike Henning
___
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] OSX

[Michael Henning]

Gimp relies on the pkg-isocodes data files to generate the language
list correctly.

Patha: Please build and ship pkg-isocodes with your gimp binaries.
That should fix this issue.

Sources are available here: http://pkg-isocodes.alioth.debian.org/

If you already do ship pkg-isocodes (I didn't check), then this is an
issue with finding those files.

  -- drawoc

On Thu, Sep 11, 2014 at 10:33 AM, scl scl.gp...@gmail.com wrote:


 On  11.9.2014 at 12:50 PM Michael Bauer wrote:

 The screenshot is from the version Michael S posted the link for but the
 end result is pretty much the same. To sum up:
 Mavericks:
 Partha's dmg: UI in English, only System Language and English offered in
 dropdown, even with gd selected as OSX locale
 Michael S's dmg: UI in Gaelic, only System Language and [Gàidhlig
 (en-US)] offered in dropdown, with gd selected as OSX locale


 That's strange. I tested my build (= the one Michael Schumacher referred to)
 on Mavericks and see a long list of languages in the language selector,
 not only these both. With Partha's build I see indeed only two items.
 Also, what language is your primary language in the OS X system settings
 (I mean, what's it's native name so I could reproduce some issues)?
 Are more people experiencing this effect?

 Kind regards

 Sven

 ___
 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-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] Precision Conversion Dithering and Triangular wave gradient issues

[Michael Henning]

I tried playing around with the triangular wave gradients, and I can't
make the second segfault happen. Do you think you could run gimp in
gdb and generate a backtrace? Thanks.

 -- drawoc

On Tue, Sep 2, 2014 at 11:54 AM, Elle Stone
ellest...@ninedegreesbelow.com wrote:
 Precision Conversion Dithering and Triangular wave gradient both fail:

 1. The Precision Conversion Dithering doesn't seem to work at 32- and 64-bit
 precision, at least not on my computer (lower precisions work). If I say
 yes, dither, one CPU runs at 100% forever, even with a very small image,
 accomplishing nothing at all. The only way to make it stop is to kill the
 GIMP process from the command line. The terminal output looks like this:

 (gimp-2.9:2479): GLib-GObject-WARNING **: value 32 of type 'gint' is
 invalid or out of range for property 'red-bits' of type 'gint'

 (gimp-2.9:2479): GLib-GObject-WARNING **: value 32 of type 'gint' is
 invalid or out of range for property 'green-bits' of type 'gint'

 (gimp-2.9:2479): GLib-GObject-WARNING **: value 32 of type 'gint' is
 invalid or out of range for property 'blue-bits' of type 'gint'

 (gimp-2.9:2479): GLib-GObject-WARNING **: value 32 of type 'gint' is
 invalid or out of range for property 'alpha-bits' of type 'gint'


 2. The Triangular wave gradient repeat sometimes (not always) causes a
 segmentaton fault, perhaps related to trying to adjust an already drawn
 gradient before committing the gradient and also when drawing a second, new
 gradient after the first gradient is drawn:

 /home/elle/code/gimpdefault/run/bin/gimp-2.9: fatal error: Segmentation
 fault
 /home/elle/code/gimpdefault/run/bin/gimp-2.9 (pid:10351): [E]xit, [H]alt,
 show [S]tack trace or [P]roceed: p
 (script-fu:10356): LibGimpBase-WARNING **: script-fu: gimp_wire_read():
 error

 ___
 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-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-user] Correctly citing Gimp

[Michael Henning]

That's just following the way things are named in the code (CamelCase
is used for class names, like GimpApplicator). That checkbox is only
present for debugging the development version, and will certainly
disappear before 2.10 is released.

So, pretend that checkbox doesn't exist.

 -- drawoc

On Mon, Aug 4, 2014 at 5:21 PM, Cristian Secară li...@secarica.ro wrote:
 În data de Tue, 5 Aug 2014 00:19:10 +0300, Cristian Secară a scris:

 (see attached snapshot)

 Well, here
 http://www.secarica.ro/traduceri/gimpapplicator.png

 Cristi

 --
 Cristian Secară
 http://www.secarica.ro
 ___
 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-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] Blend Tool UI

[Michael Henning]

mitch: The alt shortcut has always worked in my prototype. (You sound
like you might not have been aware of this in your email.)

I'm also not sure that the handle size should should necessarily be
consistent with other tools. Gradients have only two endpoints, while
paths or free selections can get significantly more complicated, which
I think justifies having larger handles.

Ofnuts: If a gradient is modified in any way, the preview will update properly.

Simon: Spherical and Dimpled are actually portions of sinusoids, not
quarter circles, but that might be what you meant.

So, the transformations functions look like this:
http://www.wolframalpha.com/input/?i=plot+1.0+-+sin%28x%29%2C+plot+cos%28x%29%2C++from+x+%3D+0+to+pi%2F2

I'm actually in favor of just removing the Spherical and Dimpled
versions of the shaped gradients. There's not too much to
differentiate between the three right now, and the transformation
functions seem a little silly to me.

I'd like to add in a euclidean-based shaped gradient though, and give
the user a choice between euclidean and manhattan distance metrics.
The manhattan ones aren't very useful alone.

On Wed, Jun 25, 2014 at 6:53 AM, peter sikking pe...@mmiworks.net wrote:
 Maybe drawing circles most of
 the time, and then hiding the circles and switching to crosshairs
 while dragging the points, would be good?

 the alignment of the endpoint with the underlying content needs
 to also be reviewed when not moving the point.

Fair enough.

 - make the control points big (30–50px diameter) and essentially
 transparent; clearly mark the centre where the co-ordinate is.

My first naive implementation looked like this:
http://i.imgur.com/ynQTFHi.png
Those handles tended to grab your attention away from the image too much.

I went back to my original ones briefly, and I have to admit that they
are definitely more difficult to grab than the larger ones.

So, I tinkered with them and came up with this:
http://i.imgur.com/RK0odEE.png

The user still has a 40 px grab target (the entire circle), but I now
hide the circle whenever the mouse isn't within 60px of the center of
the handle. So, they look quite minimal (just the cross) most of the
time, and the grabbable area is still large. I'm generally satisfied
with them.

 - you can drop the line because the gradient is there to
  represent itself; saves on clutter.

I did remove the line, but I think I might like to add it back in if
nobody's strongly opposed. Here's why:

 * I feel like the handles are minimal enough, even with the line present.

 * I'd like to implement mitch's idea of being able to drag the line
to move both points at once.

 * apparently some people would miss the line (see Jason's post)

 * I'm planning on allowing the user to disable the preview, (which is
something that basically all of gimp's tools have, just in case the
user is working on a huge image where the preview would be painfully
slow to update), so we can't always rely on the user seeing the on
screen preview.

At the very least, we should show the line whenever the preview is hidden.

 OK, I should have consulted the manual and now I have done it.

 I am now completely convinced that the shape burst belongs
 in the gradient tool. there is nothing contradictory about
 that. the gradient tool applies a gradient fill (as everything:
 modified by the selection) and Shape is a fill ‘mode’.

 and when talking interactive: next move would be to control
 these funky fill shapes on the canvas with a handle or two.

Okay. I think I have a decent idea of how to control the shapebursts
with handles. I'm going to focus on getting the other gradients
working first though.

 Ofnuts wrote:

 good plan. combine it with updating the colours of the
 endpoints to make it truly adjustable to get it _right_

 This would be updating the gradient while using it, but a gradient can be 
 much more complicated than one color at each end. And what do you do with 
 gradient colors that are not explicit but bound to FG/BG colors?

 well, I imagined straightaway that the endpoints would be
 highlightable and then modifiable through the regular
 color selection dialog(s).

 this point - that (adjusted) color

 a more complex gradient is defined by ‘waypoints’

 on the canvas, while working interactive, the position
 where these waypoints fall on the gradient can be shown.

 then each of them can be highlighted and color-adjusted.

 when the points are there anyway on the canvas, users can
 move them, in 2 dimensions.

 and gee, once you got that. users can build a complex
 gradient out of nothing by:

 - starting with a begin and end color;

 - set up a multi-point path (click, click, click,
  double-click or return; to begin with: a straight-segment
  path; intermediate colours get interpolated, based on
  distance along the path)

 - update the points’ position and colours;

 - commit (another double-click or return).

 if this overloads Michael: you can introduce this 

Re: [Gimp-developer] Blend Tool UI

[Michael Henning]

Joao: You might have misunderstood me. I'm referring to the blend
tool, not the gradient editor.

scl: Just the ones whose name starts with 'Shaped'.

Ofnuts: Yes, FiltersRender is probably a better place than the bucket
tool, if we do move the shapebursts.

Alexandre: I'm hoping to also hook up the live preview to update along
with any modifications of the gradient that happen in the gradient
editor. It isn't quite the same as on-canvas editing of color stops,
but if you're doing that sort of work, it should become it a lot
nicer.

peter:
On Tue, Jun 24, 2014 at 7:49 AM, peter sikking pe...@mmiworks.net wrote:
 Michael Henning wrote:
 * I'd like to make the blend tool generally more interactive. By
 this, I mean that after the user has created a gradient, they will be
 presented with handles that they can use to modify the endpoints of
 the gradient before committing their changes.

 good plan. combine it with updating the colours of the
 endpoints to make it truly adjustable to get it _right_

 hint: please do not make the endpoint handles small;
 think generous (more tens of pixels than single digits) and
 also show where the exact endpoint is in the centre of the handle
 (say, with a cross to aim).

I had been imagining selection handles that are simply filled circles.
In my early prototype, they look like this:
http://i.imgur.com/t4g1zOE.png

I think they are big enough, but they don't really show the exact
location of the endpoint. I guess I'll need to experiment with this
more.

I have a feeling that If I make them circle outlines with crosshairs
in them, they'll look cluttered. Having just crosshairs won't make it
obvious that you can drag the points. Maybe drawing circles most of
the time, and then hiding the circles and switching to crosshairs
while dragging the points, would be good? (The idea is to show the
precise handles when they're needed during dragging, and then switch
to handles that invite grabbing for the remainder of the time.)

 * I'd also like to add a live preview to the blend tool so users can
 preview the gradient and experiment with different options, before
 committing their changes.

 yes, vital for making the previous point work.

 please make commit an implicit thing (moving on to another
 tool, starting another gradient) combined with explicit
 (e.g. return) as a backup. see handling of committing
 selections in the rectangular selection tool.

Agreed. I wasn't planning to make starting another gradient commit the
first, but now that I think about it, that does make more sense.

 * I'm also planning to add undo support within the tool.

 I hope you mean: step-by-step undo while not committed,
 after a commit undo the whole committed gradient.

Yes, that's exactly the plan.

 again: vital, to make other points above _really_ work.
 both for the interactive part and as a form of non-committing

 * The general consensus within the dev team seems to be that the
 shapebursts (all of the gradient types currently marked shaped)
 should be moved out of the blend tool. They would likely be moved into
 either a menu item, or (maybe?) within the fill tool.

 as far as my thoughts go: there will be more working
 with (vector) shapes in the future, and modifying those
 shapes with a gradient fill (by the gradient tool)
 could be the way to handle that.

Hmm, you might have misunderstood what I meant by shapebursts. The
shapebursts are special gradients that mimic the shape of your
selection (currently labeled Shaped (angular), Shaped (spherical),
and Shaped (dimpled)). Anyway, at this point I'm really conflicted
as to what should be done with them. I'm not sure whether they belong
in the blend tool or not right now.

Anyway, thanks for the input.

  -- drawoc
___
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] Blend Tool UI

[Michael Henning]

I'd like to make some incremental improvements to the blend tool. On
IRC, Alexandre suggested to get the UI team involved, so I'm looking
for feedback/advice from the UI team.

Here are my general plans:

 * I'd like to make the blend tool generally more interactive. By
this, I mean that after the user has created a gradient, they will be
presented with handles that they can use to modify the endpoints of
the gradient before committing their changes.

 * I'd also like to add a live preview to the blend tool so users can
preview the gradient and experiment with different options, before
committing their changes.

 * I'm also planning to add undo support within the tool.

 * The general consensus within the dev team seems to be that the
shapebursts (all of the gradient types currently marked shaped)
should be moved out of the blend tool. They would likely be moved into
either a menu item, or (maybe?) within the fill tool.

Any thoughts?

   -- drawoc
___
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 of git version on Mint 17 fails

[Michael Henning]

It sounds like you don't have a C++ compiler installed. Try installing
the package g++:

sudo apt-get install g++

Hope this helps.

  -- drawoc


On Mon, Jun 2, 2014 at 1:35 PM, Alexander Rabtchevich
alexander.v.rabtchev...@gmx.net wrote:
 Hello

 Trying to compile gegl on the newest Mint linux x64, I got the compilation
 error:


 make[3]: Entering directory `/home/sasha/Install/gegl/operations/external'
   CC   vector_stroke_la-vector-stroke.lo
   CC   path_la-path.lo
   CC   vector_fill_la-vector-fill.lo
   CC   text_la-text.lo
   CC   png_load_la-png-load.lo
   CC   png_save_la-png-save.lo
   CC   jpg-load.lo
   CC   jpg-save.lo
   CC   svg_load_la-svg-load.lo
   CC   pixbuf_la-pixbuf.lo
   CC   save_pixbuf_la-save-pixbuf.lo
   CXX  exr_load_la-exr-load.lo
   CXX  exr_save_la-exr-save.lo
 ../../libtool: line 1128: g++: command not found
 make[3]: *** [exr_load_la-exr-load.lo] Error 1
 make[3]: *** Waiting for unfinished jobs
 ../../libtool: line 1128: g++: command not found
 make[3]: *** [exr_save_la-exr-save.lo] Error 1
 make[3]: Leaving directory `/home/sasha/Install/gegl/operations/external'
 make[2]: *** [all-recursive] Error 1
 make[2]: Leaving directory `/home/sasha/Install/gegl/operations'
 make[1]: *** [all-recursive] Error 1
 make[1]: Leaving directory `/home/sasha/Install/gegl'
 make: *** [all] Error 2

 There were no complains during ./autogen.sh . libopenexr-dev is installed.


 With respect,
 Alexander Rabtchevich
 ___
 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-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] urgent

[Michael Henning]

On Sat, May 31, 2014 at 11:06 AM, C R caj...@gmail.com wrote:
 Some off list concern was raised about the GPL being primarily applied to
 restrictions for selling and redistributing the GIMP software, however, the
 GPL v3 does speak about program output as well:

 *2. Basic Permissions.*

 All rights granted under this License are granted for the term of copyright
 on the Program, and are irrevocable provided the stated conditions are met.
 This License explicitly affirms your unlimited permission to run the
 unmodified Program. The output from running a covered work is covered by
 this License only if the output, given its content, constitutes a covered
 work. This License acknowledges your rights of fair use or other
 equivalent, as provided by copyright law.
 
 Applied to GIMP, this essentially means that as long as you own the (c) to
 the materials used in your logo/image, your work is protected under the
 GPLv3 licence, when output by GIMP.

This isn't correct. Anything you make with GIMP does not need to be
under the GPL.

The clause you point out is specifically for programs that include
GPL'ed content in their output. It does not apply for gimp. If you own
the photos you started with, then you own the output.

(IANAL, and the above is not legal advice.)

  -- drawoc
___
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] Wee reminder about Gaelic in 2.10

[Michael Henning]

Don't worry. Gaelic is already available in the UI in the development
branch of 2.8.

Here's a screenshot:
http://i.imgur.com/LT64AtO.png

  -- drawoc

On Sun, May 18, 2014 at 8:06 AM, Michael Bauer f...@akerbeltz.org wrote:
 Hiya

 I don't know how the plans for 2.8.12 are progressing but I just thought I'd
 ask someone please make sure Scottish Gaelic (gd) gets added to the UI
 language menu in the settings?

 Perhaps I'm over-cautious but on VLC they managed to 'forget' Gaelic in TWO
 releases and since few people have a Gaelic OS, relaying on the cursed
 force-locale thing wouldn't work either.

 Cheers

 Michael
 ___
 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-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] Some blend modes break in unbounded mode sRGB

[Michael Henning]

You are correct in the sense that *right now*, most of the babl color
spaces are based on the sRGB chromaticities. There is nothing
preventing us from adding different color spaces in the future,
including ProPhoto RGB.

 And if the operation is better done in in some other color space *model*,
 not RGB but rather perhaps CIELAB or HSL or whatever, then the conversion is
 now and will always be from *sRGB* to CIELAB, HSL or whatever, yes?

No, not always. Gimp already has the option of storing your image in a
linear or perceptual gray color space, as well as different indexed
formats. As above, new formats can be added easily. Can I ask: what
difference does it make? If I convert an image from ProPhoto to
CIELAB, or if I convert from sRGB to CIELAB, I will get the same
result. The gegl operation doesn't care how the data is stored; it
only cares what format it receives the data in.

On Sun, Apr 13, 2014 at 8:08 AM, Elle Stone
ellest...@ninedegreesbelow.com wrote:
 On 04/13/2014 06:41 AM, pip...@gimp.org wrote:

 On Sun, Apr 13, 2014 at 06:18:08AM -0400, Elle Stone wrote:

 In the strongly color-managed world of BABL and GEGL, the only *RGB*
 color space/working is *s*RGB, either the linear gamma/light sRGB or
 the more perceptually uniform regular sRGB with its not quite
 gamma=2.2 TRC.


 There is no linear gamma *or* perceptually uniform choice at import. There
 is a
 conversion to one of the babl-managed pixel formats; and after that GEGL
 operations are free to convert between any of the unbounded babl formats.


 I didn't mean to imply that there was a choice of which TRC to choose upon
 import. The plan seems to be that when GIMP 2.10 is released the image will
 be converted from its source color space to a color space with the sRGB
 chromaticities.

 Whether that sRGB color space is actually linear gamma sRGB or sRGB with the
 regular sRGB tone reproduction curve is a separate question. You are saying
 that which TRC is used depends on the operation in questions. For example
 currently heal and drawing a gradient are done using the sRGB TRC. And
 Scale, Gaussian blur, and Unsharp Mask are done using the linear gamma TRC.
 Yes?

 The point is that when GIMP 2.10 is released, regardless of what happens to
 the TRC upon import, the *chromaticities* used for all further processing
 will be the sRGB chromaticities, NOT the chromaticities of the source color
 space. This point has been confirmed several times.

 GIMP is making things more confusing by letting an arbitrary extra
 parameter
 change the behavior of compositing ops; this feature is something I
 consider
 a bug, it shouls also be considered bugs to do operation in linear space
 if the
 algortihm of a GEGL op behaves incorrectly/really unexpectedly unless it
 works
 in a more perceptual space.


 OK, so in the interests of consistency, the limited current choice between
 allowing an operation to happen in the linear gamma sRGB color space vs the
 more perceptually uniform regular sRGB color space should be eliminated,
 yes? You consider this UI user choice to be a bug, yes?

 I've asked this question of what is actually meant by color
 space/working space in the world of BABL and GEGL twice before now,
 and no one has answered. But it's a pretty important point, so I'm
 asking again.

 Thanking you in advance for confirmation/clarification of what
 color space/working space means when discussing *BABL/GEGL* color
 spaces/working space,


 Not sure if this is a clarification; I do not know what you mean by the
 terms
 either and can only tell you what the intended architecture of GEGL is



 sRGB converted to CIELAB.
 sRGB converted to HSL.
 sRGB converted to HSV.
 sRGB converted to CMY(K).
 sRGB converted to Gray.
 sRGB converted to YCbCr.
 sRGB converted to some other model of color space, such as XYZ or
 CIELUV, for which code might be written at some point in the future.



 In the folder babl/extensions, see ycbcr.c, naive-CMYK.c, grey.c, HSV.c,
 HSL.c, CIE.c. These conversion are between the sRGB RGB color space and
 various other color space models, namely CIELAB, HSL, HSV, CMY(k), Gray, and
 YCbCr.

 The sRGB TRC is assumed in many places in the BABL code. To see what I mean,
 do a command line search in the babl source code folder:

 find -name *.c -or -name *.h | xargs grep -H gamma_2_2 {} \;

 The sRGB chromaticities are assumed in various places in BABL, GEGL, and
 GIMP. Do a search for the word LUMINANCE, although some places have the
 values hard-coded.



 The key point is that the chromaticities of the *RGB* color space, that
 might be converted to some other *model* of color space, are *always*
 the *s*RGB chromaticities.


 There is no provision for converting from some other RGB color space to
 these other color models. The only provision is for converting from sRGB to
 these other color space models.



 On 04/12/2014 06:45 PM, Øyvind Kolås wrote:

 You seem to be under the impression that all processing whatever the
 

Re: [Gimp-developer] Three questions about opening an image and converting it to linear light RGB

[Michael Henning]

The following is the planned color workflow, as I understand it.

On Wed, Apr 2, 2014 at 9:31 AM, Elle Stone
ellest...@ninedegreesbelow.com wrote:
 Please bear with me while I ask some questions. I'm trying to clarify
 something that I might be completely confused about. The point of the first
 two questions is to be able to ask the third question. If I'm confused about
 the answers to the first two questions, what I'm asking about in the third
 question won't be possible.


 First question:

 The phrase linear light RGB is used a lot. When the topic is
 BABL/GEGL/GIMP, does linear light RGB mean Pippin's extended sRGB color
 space defined by the sRGB primaries and the linear gamma tone reproduction
 curve?

Typically, yes. linear light RGB could potentially refer to other
color spaces, but when you hear it in a babl/gegl context, this is
almost always what we mean.

 Second question:

 Is Pippin's extended sRGB/BABL's linear light RGB the same as LCMS's
 unbounded mode sRGB?

 In other words, are BABL's linear light RGB and LCMS's unbounded mode
 linear gamma sRGB two ways of describing the same thing, namely, after
 converting from some other color space to linear light RGB, otherwise out of
 gamut RGB values aren't clipped but rather carried along as RGB values that
 are less than 0.0 and/or greater than 1.0?

LCMS's unbounded mode can work with a variety of different color
profiles, so we construct an icc profile that's the same as babl's
linear light RGB when we do conversions.

That's the goal of create_lcms_linear_rgb_profile in
https://git.gnome.org/browse/gegl/tree/operations/external/lcms-from-profile.c?id=944719a8ca2ad957f02c4a4bc0eca66c4e7dde7a#n60

Ideally, out of gamut values should not be clipped, but I'm not
entirely sure if that works that way right now. We should have that
working by 2.10.

 Background for the third question:

 Right now when using GIMP from git, it's possible to open an image in, for
 example, the ProPhotoRGB color space, and edit the image while keeping it in
 the ProPhotoRGB color space. There's no automatic behind-the-scenes
 conversion to unbounded mode sRGB/extended sRGB/linear light RGB.

 I've been assuming that before 2.10 is released this behavior will change.
 My understanding is that in the future:

 1. The user will open an image with GIMP and maker sure the right ICC
 profile has been assigned.

 2. Before actual image editing can begin, the image will be converted to
 extended sRGB/linear light RGB behind the scenes without the user
 necessarily even knowing that this has happened, though a little
 warning/user education/notes in the GIMP documentation might explain the
 sudden appearance of negative RGB values and/or RGB values that are greater
 than 1.0.

We will need a way for users to change the incoming icc profile on
import, just in case it has the wrong embedded profile. There will be
some level of user awareness, but I don't know how much.

 3. All subsequent image editing will be done in the extended sRGB/linear
 light RGB color space.

Yes. To clarify this point: Users will have the ability to choose to
edit in different bitdepths and (probably) also the option between
editing with the layers stored as a linear or a perceptual (sRGB TRC)
color space (which only really affects the way layer modes work, along
with things that depend on layer modes like painting).

Also, gegl operations can request to do their work in different color
spaces, so depending on the operation being performed, the editing may
actually happen in other color spaces. This is transparent to the
user.

 4. Upon exporting the image to disk, the use will be able to convert the
 image from extended sRGB/linear light RGB to their chosen ICC profile. They
 won't be forced to export an sRGB image to disk.

 I asked almost the same question in a previous email
 (http://gimp.1065349.n5.nabble.com/Soft-proofing-and-the-GIMP-Display-Filters-and-Color-Management-settings-td42139i20.html).
 But Pippin made a distinction between pipeline and workflow, and I'm not
 sure what the distinction might be in practice. So I'm asking again as
 explicitly as possible:

 Will the image be converted to extended sRGB before image editing can begin?

Yes.

 Will the user see out of gamut (that is, out of the sRGB color space's
 gamut) RGB values expressed as RGB values that are less than 0.0 and/or
 greater than 1.0?

Yes. There is one complication: Users have the ability to choose to
edit in different bitdepths, so the integer bitdepths will be clipped.

 Here's the third question:

 If what I just wrote is an accurate description of the way GIMP will
 eventually work, can the future workflow can be tested *now* by:

 1.Promoting the non-sRGB image to 32-bit floating point

 2. Doing an ICC profile conversion *from* whatever ICC profile color space
 it might be in (perhaps ProPhotoRGB), *to* the GIMP built-in sRGB profile

 3. Editing the image as desired

 4. Doing an ICC profile conversion *from* the 

Re: [Gimp-developer] Two questions about updating GIMP from git

[Michael Henning]

Here are two scripts that I use to help keep git up to date. The first
updates my git checkouts, and the second cleans out any build files
(which is useful to run from time to time). They require $SRC_DIR to
be set to the directory that your babl/gegl/gimp checkouts are under,
and $INSTALL_PREFIX must be the location of your install prefix.

The main key to these script is that the first line is #!/bin/bash
-e. The -e argument to bash means that if any command in the script
fails, then the script will exit immediately, instead of continuing to
the next command.

upd.sh:

#!/bin/bash -e

build () {
cd $SRC_DIR/$1

git pull --rebase

if [ ! -f ./Makefile ];
then
./autogen.sh --prefix=$INSTALL_PREFIX --enable-fast-install $2
fi

make
make install
}

build babl
build gegl --enable-gtk-doc --enable-debug
build gimp

clean.sh:

#!/bin/bash

rm -r $INSTALL_PREFIX
mkdir $INSTALL_PREFIX

clean () {
cd $SRC_DIR/$1
git clean -Xdf
git pull --rebase
}

clean babl
clean gegl
clean gimp

Hopefully this helps.

  -- drawoc

On Tue, Mar 11, 2014 at 7:37 AM, Elle Stone
ellest...@ninedegreesbelow.com wrote:
 Shlomi Fish and SorinN,

 Thanks! With examples to work from, hopefully it won't be too hard to write
 a script that makes updating GIMP easier.

 Elle

 ___
 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-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] Enlarge image canvas with gimp_image_resize procedure

[Michael Henning]

Are you also growing the layer boundaries? If you grow the canvas, but
not the layer boundaries, you won't be able to draw on the new canvas
area.

  -- drawoc

On Thu, Feb 27, 2014 at 4:53 AM, Alessandro Francesconi
alessandrofrancesc...@live.it wrote:
 I need to enlarge the area of an image using one of the available GIMP's 
 procedures. So, instead of using the GIMP's graphical interface and this tool 
 http://docs.gimp.org/en/gimp-image-resize.html, I want to be able to have the 
 same effects on a C code.


 The function that should be called is this one, right? 
 http://oldhome.schmorp.de/marc/pdb/gimp_image_resize.html


 But it works when I need to shrink the canvas: on a 640x480 image, if I input 
 smaller values the canvas is actually cut. Instead, if I want to add a 20px 
 transparent border along the area (so I type 680 and 520 px, also with 
 consistent offset values), the function just returns the original image.


 How does it work? Thanks

 Ale
 ___
 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-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 Action dialog feature

[Michael Henning]

My version of what it is:

Action Search (aka TITO) is valuable to gimp users because it
provides easy access to moderately used features of the gimp without
memorization of the gimp's menu layout or keyboard shortcuts.

Even experienced power users won't know (shouldn't be forced to
memorize) where *everything* is located. Now, they only need to know
the name.

On Sun, Jan 19, 2014 at 3:53 PM, peter sikking pe...@mmiworks.net wrote:
 Sven,

 I appreciate that you want to mediate to make things go forward.

 Srihari has brought up this topic often and informed about
 the progress. Many people, including Peter, joined the
 discussion and the purpose was already discussed.
 So, many things are not really new.

 as things stand right now, the biggest thing that is wrong
 with TITo is that there seems to be no underlying purpose.
 lacking this it is a rather jumbled combination of features,
 which exactly expresses this purposelessness.

 if the purpose of TITo is so clear, then tell me what it is,
 including a few words why it is valuable for GIMP users.

 (anybody can contribute to this, it is just that
 Srihari and Jehan have to the final say on this definition,
 that is the right they earned by putting in the bulk of the
 code contribution)

 I give you an example, so you know what I am asking for:

 ‘the Undo system is valuable to GIMP users because it
 allows them to proceed without fear (of doing something wrong).’

 you see I defined Undo not by its functionality, but
 by what it means to users.


 people have already asked me: ‘just say what should be changed
 about TITo.’

 I can tell you, once I know what it should be.


 --ps

 founder + principal interaction architect
 man + machine interface works

 http://blog.mmiworks.net: on interaction architecture



 ___
 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-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 from git Gegl Gaussian Blur and Unsharp Mask useability issues

[Michael Henning]

As a quick correction, gegl's gaussian blur doesn't operate in scRGB,
but rather in babl's linear premultiplied sRGB-primary space (RaGaBaA
float).

babl doesn't really have scRGB formats, although some of the formats
resemble some of the scRGB formats.

On Thu, Dec 5, 2013 at 2:08 PM, Teo Mazars
maza...@ensimag.grenoble-inp.fr wrote:
 Hi,

 I have seen the comparison between the old (from gimp 2.8) and the new 
 gaussian blur. I did not have a look at 2.8's implementation yet, but one of 
 the main difference, is that the new implementation works in scRGB instead of 
 sRGB in GIMP 2.8.

 I don't know if you were aware about that. I personally would still let the 
 possibility to make it work in both sRGB and scRGB, depending on user's need. 
 Both behavior are useful. But it's still under discussion.

 I completely forgot that until now, but Massimo worked on Gaussian-Blur some 
 times ago, and his work is now in operations/workshop (you have to pass 
 --enable-workshop to autogen to build them). This implementation should 
 replace the current implementation at some point, but the behavior is 
 equivalent to the current implementation. I mean all the work you did still 
 applies on the new implementation. The main thing that prevents the 
 replacement is that the case with std-dev  0.5 is not implemented.

 Among all improvements: Waaay faster, even with very large std-dev, it allows 
 setting how edges are handled and finally it fixes the vertical streaks bug 
 you were seeing with large std-dev.

 I don't answer to the rest because I don't know or I did not though about it 
 yet. Though, we will need to find the equivalent conversion between the 2.8 
 gblur and GEGL, because 2.10 keeps api compatibility with 2.8 and that 
 includes that all filters should be have the same given the same set of input 
 parameter from the api point of view (that is, not necesserly in the ui).

 Regards,

 Téo
 ___
 gimp-developer-list mailing list
 List address:gimp-developer-list@gnome.org
 List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] N-Point Image Deformation queries

[Michael Henning]

Sure, starting from npd-squashed would be fine.

I suppose the gegl sampling functions might be a bit slow for the
preview. On the other hand, they have had a fair amount of
optimization work done on them, so you might find that they're
actually faster. Actually trying them out is probably a good idea. If
nothing else, we should use GeglSamplers for the final rendering of
the mesh.

On Sun, Dec 1, 2013 at 7:07 PM, Marek Dvoroznak dvoro...@gmail.com wrote:
 Hello,

 thanks for the hints and sorry for the late answer. I will try to fix
 what I'm able to and then ask you for review.

 About the interpolation code - I was afraid that GEGL sampling functions
 could be slow for a preview of the deformation. I will try to use them
 and make some performance tests.

 Do you prefer me to use your branch (npd-squashed) for that work?

 Marek

 Hello,

 We somewhat assumed that you weren't here, because we couldn't easily
 get a hold of you. Apparently, we didn't try hard enough. Thanks for
 sticking around.

 Anyway, I began reviewing your code. I made some changes to it to try
 and make it a bit cleaner, so we could merge it into the main gegl
 tree. You can see all of my changes here:
 https://git.gnome.org/browse/gegl/log/?h=npd-squashed

 The main complaints we have about your code are:

   * The GEGL operation shouldn't contain any Cairo code in it. UI
 stuff like that should only be in either your library or your GIMP
 tool. Of course, you have it set up so that this should be easy to
 change.

   * Generally, when you write an API, you want to expose as little as
 possible. Only the bare minimum number of functions should be included
 in the public/installed header files, and typically no structures at
 all should appear there. I've begun fixing this by converting some of
 your functions to static functions where possible.

   * Some of the functions like add_point_to_suitable_cluster do
 bizarre things like convert floats to strings just so they can be used
 as hash table keys. A lot of this code wasn't actually used, so I
 commented it out for now.

 I would feel a lot better if the npd library didn't include its own
 interpolation code. You mentioned outputting float coordinates to an
 image and then using map-absolute, but I'd prefer if the gegl
 operation found the color values directly with a GeglSampler object.
 This gives you access to Gegl's built-in interpolation methods.

 I'm not sure if you want me to continue working on npd (I can find
 other stuff to do, if you'd prefer to make these changes yourself.)

 Anyway, these are the main things that are stopping us from merging
 the gegl npd branch right now. I haven't actually looked at the gimp
 npd branch, but mitch sounded generally happy with the code there.

 If you want to talk to me on irc, my nick is drawoc.

 Anyway, thanks for the hard work!

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

Re: [Gimp-developer] Setting Up a Release Procedure

[Michael Henning]

This wasn't a Mavericks bug; it can happen on linux too. For some
reason, this only triggered on clang. Anyway, I just fixed it in gimp
git (see commit 95becc7615c7e9cf2f6135c8d5b0fe1cca86648f).

So, this will be fixed for the next release.

  -- drawoc

On Sat, Nov 30, 2013 at 9:26 AM, Maurizio Loreti
maurizio.lor...@gmail.com wrote:
 On Sat, 30 Nov 2013 11:37:05 +0100, Simone Karin Lehmann simone lisanet
 de wrote:

 I just discovered a new bug, which is IMO release
 critical. On OS X Mavericks, the pencil and brushes outline doesn’t show,
 so it’s almost impossible to paint,
 clone and brush.


 Don't blame OS X Mavericks.  Under Mavericks GIMP 2.8.6 pencils and brushes
 work like a charm.

 --

 (@_   |

 //\   | Maurizio Loreti - Retired physicist, happy grandfather

 V_/_  | of two grandsons, wanderer and amateur photographer...
 ___
 gimp-developer-list mailing list
 List address:gimp-developer-list@gnome.org
 List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] N-Point Image Deformation queries

[Michael Henning]

Hello,

We somewhat assumed that you weren't here, because we couldn't easily
get a hold of you. Apparently, we didn't try hard enough. Thanks for
sticking around.

Anyway, I began reviewing your code. I made some changes to it to try
and make it a bit cleaner, so we could merge it into the main gegl
tree. You can see all of my changes here:
https://git.gnome.org/browse/gegl/log/?h=npd-squashed

The main complaints we have about your code are:

  * The GEGL operation shouldn't contain any Cairo code in it. UI
stuff like that should only be in either your library or your GIMP
tool. Of course, you have it set up so that this should be easy to
change.

  * Generally, when you write an API, you want to expose as little as
possible. Only the bare minimum number of functions should be included
in the public/installed header files, and typically no structures at
all should appear there. I've begun fixing this by converting some of
your functions to static functions where possible.

  * Some of the functions like add_point_to_suitable_cluster do
bizarre things like convert floats to strings just so they can be used
as hash table keys. A lot of this code wasn't actually used, so I
commented it out for now.

I would feel a lot better if the npd library didn't include its own
interpolation code. You mentioned outputting float coordinates to an
image and then using map-absolute, but I'd prefer if the gegl
operation found the color values directly with a GeglSampler object.
This gives you access to Gegl's built-in interpolation methods.

I'm not sure if you want me to continue working on npd (I can find
other stuff to do, if you'd prefer to make these changes yourself.)

Anyway, these are the main things that are stopping us from merging
the gegl npd branch right now. I haven't actually looked at the gimp
npd branch, but mitch sounded generally happy with the code there.

If you want to talk to me on irc, my nick is drawoc.

Anyway, thanks for the hard work!
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list

[Gimp-developer] Fwd: GIMP Icons

[Michael Henning]

This was replied to just me, so I'm forwarding it to the entire list.


-- Forwarded message --
From: Andrew Pullins android2...@gmail.com
Date: Thu, Nov 14, 2013 at 2:15 AM
Subject: Re: [Gimp-developer] GIMP Icons
To: Michael Henning dra...@darkrefraction.com



  You have not answered to the question. What version is it *exactly*?
  The last is 2.8.8. Just 2.8 is not enough, there has been 4 minor
  versions in 2.8. Please check the About of the program.


here are some comments form my DeviantArt

Linux

Works fine on Debian Wheezy / Gimp 2.8.x

Dark theme crashes on Ubuntu 12.04, but Light works fine.

light theme under Ubuntu 12.04 and Gimp 2.8.6 and it seems to work OK.
user did not mention the dark theme.

No problem for me with a fresh Ubuntu 13.04 install. Using GIMP 2.8.4,
though, it seems the 2.8.6 version isn't in the Ubuntu repos.
~Still works for me. I am now on Ubuntu 13.10 with GIMP 2.8.6 (was
2.8.4 when I tested the previous version).


White theme works for me (gimp 2.8.6 on arch linux), but the dark one
fails with:


Windows

windows 7 - GIMP 2.8.6, same problem dark crashses GIMP, light, icons
do not show
~ Sorry for the the delay, and sorry, no luck yet, maybe im doing
something wrong? windows 7 64 bit GIMP 2.8.6

I already tested it on Windows XP, but when I choose the dark theme,
GIMP crashes, and when I choose the light theme, doesn't show any
single icon.

Does anybody tested this on Windows NT 6.X?


Mac

The dark theme crashes on Mac (10.8.4) (GIMP 2.8.6)

  Just for your information: if you open a terminal and just type gimp
  there, it will start GIMP, with the output linked to the terminal.
  So if ever you encounter error, they would be printed there.


Hmm.. well I will do that next time it crashes on me. but it does not
crash on me anymore.
 but the others still do. once I updated the theme I contacted them
and it still did I denoted that above by a ~.


  There seems to be a lot of missing icons in your set, and more
  problematic, several errors in the gtkrc.
  So that may explain why it does not work well (or at all) for some
  people (maybe it depends on the version of GTK+ installed). The best
  on your side would be to fix at least the gtkrc.


 well I can see how I messed some icons, there are a lot. as for the
gtkrc I kinda just took a bunch of different themes mashed them
together and ctrl found colors till switching them out got the look I
wanted. I honestly have no idea what I'm doing with these themes. I
did not know there was anything wrong with the gtkrc and have no idea
where to start. I really wanted this to be a GMIP only theme, there
seems to be a lot of GIMIP themes out there that can be used for many
applications and there for have a lot of extra stuff that GIMP dose
not need.

  In any case, if really GIMP crashes because of this, that's not
  normal. It should not crash on wrong input. Could you please open a
  bug report: https://bugzilla.gnome.org/enter_bug.cgi?product=GIMP



  Then a developer (maybe me) will look into it when we have some time,
  and we'll try to reproduce the crash.


 I will do so.


  By the way, you have not answered this either: do you have any good
  reproduction steps? You said in particular that some users have it
  crash, other not. Do you know how to make it crash for sure? Maybe if
  it is a GTK+ issue (highly probable if the crash happens during the
  gtkrc parsing), could you tell us which version of GTK+ it is?
  Put all the relevant information in the bug report please, as well as
  an archive of your theme.
  Thanks.


yes install my theme and see if it crashes GMIP :P I really am
confused about how the same theme can work on one OS and crash on
others. some people it crashes immediately, others it does not. some
the light theme works and others it dose not crash GIMP but none of my
icons show up.

I have no idea how to answer your GTK+ questions. All I know about GTK
is that its a desktop environment. again I just mashed some themes
together and prayed it worked. if your question is what version my
Ubuntu OS uses then I may be able to help, if you tell me how to find
that out.  if your asking what my users are using, what ever comes
with the windows and mac versions of GIMP I assume. if your asking
what version that gtkrc file is written under, then again I have no
idea. I do not even know what theme I originally took my gtkrc file
from.

I am sorry I could not be more help, I have only just started using
Linux as my only OS. I am quite new at this.
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] My plugin doesn't start anymore after upgrading mingw/gcc suite

[Michael Henning]

It's hard to help you without any additional information. I would
suggest that you grab mingw's gdb and try debugging the plugin with
that. You can try these instructions:
https://git.gnome.org/browse/gimp/tree/devel-docs/debug-plug-ins.txt
I forget if they work on windows.

Anyway, good luck!

On Sat, Oct 5, 2013 at 5:43 AM, Alessandro Francesconi
alessandrofrancesc...@live.it wrote:


 Anyone can give me help? I’m still blocked for this problem. As I said to 
 Partha in private, I can’t figure another reason about this, apart from a 
 GCC’s fault.
 The fact is that my code worked few minutes before upgrading to GCC 4.8.1, 
 then, without changes, the new compiler made it “invisible” to GIMP.



 Moreover, the plugin now crashes when queryied by GIMP at startup 
 (http://www.alessandrofrancesconi.it/bimp-fail.jpg).

 My system is Windows 8 64bit, GIMP 2.6.8.



 Can it be related to the 64bit environment? Never had problems before.






 Ale




 Da: Alessandro Francesconi
 Data invio: venerdì 4 ottobre 2013 11.12
 A: gimp-developer-list@gnome.org



 Hello everyone,

 This morning, on my Windows platform, I’ve decided to run a “mingw-get.exe 
 upgrade” command in order to give a fresh update to my compiling tools.

 The process finished fine and the GCC version changed from 4.7.2 to 4.8.1... 
 but I shouldn't have done it!


 I went to my plugin source code (it’s BIMP, by the way), then I run the usual 
 batch command in order to compile it with the “new” tools. The compiler ended 
 without errors, but now the plugin is disappeared from GIMP!

 One strange thing after the upgrade: the filesize of my plugin’s executable 
 changed from 270 KB to 320 KB... I think I have to add some new options to 
 the compiler, or what?


 This is the full command I use to compile my plugin: 
 https://github.com/alessandrofrancesconi/gimp-plugin-bimp/blob/master/makewin.bat


 Thanks for your attention
 ___
 gimp-developer-list mailing list
 List address:gimp-developer-list@gnome.org
 List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
 ___
 gimp-developer-list mailing list
 List address:gimp-developer-list@gnome.org
 List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Adapted and unadapted sRGB luminance values

[Michael Henning]

Sorry for the delay in replying; I wanted to take the time to properly
look at everything you've said.

Yes, Elle, you're right. I take what I said back; we should be using
the adapted values.

If anyone is still doubting this, you can try playing around with this
demo program I created:
http://ix.io/8ho

It creates lcms profiles for the babl RGB and Y formats, and then uses
lcms to convert from RGB to Y.

Here's the output:
(R, G, B) - Y
(1.00, 0.00, 0.00) - 0.222492
(0.00, 1.00, 0.00) - 0.716902
(0.00, 0.00, 1.00) - 0.060606
(0.50, 0.50, 0.50) - 0.50

On Mon, Sep 23, 2013 at 5:46 PM, Elle Stone l.elle.st...@gmail.com wrote:
 A technically correct luminance-based conversion to black and white is
 done using this formula:

 L = R*Yr + G*Yg + B*Yb

 where R, G, and B are the image RGB values for any given pixel and Yr,
 Yg, and Yb are the Y values from the image's actual ICC profile. If
 the profile white point isn't D50, the Y values are always adapted Y
 values. The image must be in a linear gamma version of the color
 space.

 So far I'm repeating what I've already said. Below are concrete
 examples showing that using the **un**adapted sRGB Y values results in
 the wrong Luminance values:

 Consider an image with a color block of the sRGB reddest possible
 red 16-bit integer color: (65535, 0, 0).

 Convert the sRGB image to a different ICC profile using relative
 colorimetric intent and the RGB values will change but the **meaning**
 of the RGB values will be the same. In other words, the new RGB values
 will point to the same XYZ coordinates as the previous sRGB RGB values
 pointed to. Here are some examples:

 According to the argyllcms xicclu utility, sRGB values (65535, 0, 0)
 are the same as XYZ (0.435837, 0.222366, 0.013916).

 Convert the sRGB image to WideGamut:
 Widegamut RGB values (38832, 6228, 766) are the same as XYZ (0.435838
 0.222362 0.013910)

 Convert the sRGB image to ProPhoto:
 ProPhoto RGB values (34671, 6442, 1105) are the same as XYZ (0.435843
 0.222371 0.013910)

 Convert the sRGB image to the Identity profile:
 Identity RGB values (29623 14573 1106) are the same as XYZ (0.435837
 0.222370 0.013921)

 Notice that for each profile's equivalent-to-sRGB-reddedst-red,  the
 XYZ Y value is almost identical to the sRGB ADAPTED Y value. The
 color's coordinates in XYZ space don't change upon converting the
 image from one color space to another using relative colorimetric
 intent (unless there is gamut clipping, but then only the clipped
 values are affected; I didn't mention black point compensation because
 for working spaces with 0 black points, using or not using blackpoint
 compensation makes no difference, and if it does, there' a problem in
 the code).

 The Y in a color's equivalent XYZ values  **is** a color's
 Luminance. If your method of calculating Luminance gives something
 other than the color's Y value in XYZ space, your method of
 calculating Luminance is wrong.

 Back to the formula for calculating Luminance:

 sRGB-unadapted: 65535 * 0.21265600 + 0 * 0.71515800 + 0 * 0.07218600 = 13936.4

 sRGB-adapted: 65535 * 0.22236633 + 0 * 0.71704102 + 0 * 0.06059265 = 14572.8

 WideGamut: 38832 * 0.25871277 + 6228 * 0.72470093 + 766 * 0.01658630 = 14572.5

 ProPhoto: 34671 * 0.28804016 + 6442 * 0.71195984 + 1105 * 0. = 14573.1

 Identity: 29623 * 0. + 14573 * 1. + 1106 * 0. = 
 14573.0

 In the above equations, the RGB values for the color of red specified
 by the reddest possible sRGB red were determined by eye droppering a
 red color block after doing the appropriate ICC profile conversions.
 As you can see, the Luminance value calculated by the UNadapted sRGB
 Y values is out of line with the other four calculated values.
 Notice that 14573/65535 is 0.22237, the ADAPTED red Y value for sRGB.
 If you did the same calculations for bluest sRGB blue and greenest
 sRGB green, you'd get the ADAPTED sRGB blue and green Y values.

 The actual eye droppered grayscale values for my four color test image
 (reddest sRGB red, bluest sRGB blue, and greenest sRGB green against
 an 18% gray background), after converting to black and white using
 Luminance, are as follows (ICC profile conversions done at 32-bit
 floating point, which is how I did the conversions, are more accurate
 than working with 16-bit values as given above):

 Profile WtPt  Red block   Green blockBlue
 block   18% Gray
 sRGB D65-unadapted   13936 46868 4731 
 12094
 sRGB D65-adapted   14573 46991 3971
   12094
 WideGamut D5014573  469913971
  12094
 ProPhoto D5014573  469913971
 12094
 Identity D50 14573  46991
 3971   12094

 The 18% gray value is the same for all five conversions because the
 ONLY 

Re: [Gimp-developer] List of dependencies (versions and configuration options) for GIMP on Windows

[Michael Henning]

As much fun as I'm sure you're all having debugging this, I think I've
seen this before. I already fixed this with my windows nightlies
(actually, scl reported it, so I guess he forgot about that).

There are two potential issues:
  1. fontconfig includes an absolute path to its config directory, so
when you move the files to a windows system it cannot find them.

  2. The config files themselves are symlinks, which may cause them to
not exist on windows, depending on how the files are packaged.

The solutions:
  1. Modify etc/fonts/fonts.conf to remove the absolute path and
replace it with a relative one (it should just say conf.d, not
long/path/and/then/conf.d). I compile fontconfig with this patch:
https://git.gnome.org/browse/gimp/tree/build/windows/jhbuild/patches/fontconfig-fix-config-dir.patch
You can achieve the same effect by modifying the config files by hand.

  2. Ensure the files in etc/fonts/conf.d/ exist. If not, copy the
files from share/fontconfig/conf.avail into that folder.

At the time I fixed this, Jernej's builds did not exhibit the problem
because they used an older version of fontconfig. I did not report
this upstream because it's a configuration issue, but now that I think
about it, the defaults should perhaps be changed on windows (or maybe
when cross compiling).

On Sun, Sep 22, 2013 at 9:09 AM, Jehan Pagès jehan.marmott...@gmail.com wrote:
 Hi,

 On Mon, Sep 23, 2013 at 12:49 AM, Sven Claussner scl.gp...@gmail.com wrote:
 On  22.09.2013 at 12:32 P.M., Jehan Pagès wrote:

 Thanks Sven, but that does not say what versions are used on GIMP
 2.8.4, official build, which was my question. :-)


 Sorry for being a bit terse, I'm in a rush ;-)

 You can find the official 2.8.4 build at

 http://sourceforge.net/projects/gimp-win/files/GIMP%20%2B%20GTK%2B%20%28stable%20release%29/GIMP%202.8.4/

 Running GIMP with the -v or --version parameter shows the versions
 of the used libraries.


 Oh thanks, I did not know this one! Jernej actually already sent me an
 archive with the dependency tree of his build. I was planning to check
 the .pc files. Fortunately I did not start. And your solution will be
 easier *and* more accurate. :-)

 You can also find the 2.8.4 sources at the Web-Git site:
 https://git.gnome.org/browse/gimp

 Yes the source, I already have them, no problem. :-)
 Thanks again.

 Jehan

 Kind regards,

 Sven

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

Re: [Gimp-developer] Adapted and unadapted sRGB luminance values

[Michael Henning]

I hope you don't mind; I reordered parts of your email when responding to it.

 Isn't the second (adapted) transform going to give us a D50 Y instead
 of a D65 Y?

 Yes, it will, and that's precisely what you want if you want to
 correctly calculate an sRGB image's Luminance values from its RGB
 values.

The main usage for this transform (D65 RGB - D65 Y, with the
unadapted values) is to convert color images to grayscale. It seems to
me that having a D65 grayscale image is correct, especially because
when converting back to RGB D65 we simply copy the Y value into each
of the components.

I haven't really looked at the other cases of the values you pointed
out yet, but none of those are widely used code paths. They should
probably be examined individually.

 D50 has two uses in an ICC profile: the profile illuminant and also
 the profile white point for profiles with D50 white points.

I don't think we should be accounting for the illuminant when
converting to grayscale.

 As an aside, you can't assume that any of today's LCD monitors are
 calibrated to match sRGB or even to have a D65 white point

Every monitor is different. D65 with the sRGB primaries is the same as
ITU‐R BT.709‐5 (HDTV), which I think is a reasonable approximation for
certain calculations. Nobody is claiming that our conversions are
exact for an profileless, uncalibrated monitor.

 So is there some
 other place in the babl/gegl/gimp code where there is an actual
 hard-coded matrix transform between two D65 color spaces? If so, which
 two D65 color spaces?

The YCbCr transform in babl might be wrong (assumes D65, in a case
where we don't want D65), but you already pointed that out, and I
wasn't really talking about that conversion.

 Well, what I really want babl/gegl/gimp to do is stop using sRGB as
 the one space to rule them all and instead, if there has to be a
 single internal color space, make it the D50 Identity color space ...

I think the main reason for choosing an sRGB-like space is because of
convenience. Many images are in sRGB, and it's nice to be able to
store them in 8-bits/channel without severe quality loss. People using
other color spaces are more likely to use high bitdepths, where the
profile choice is less critical for image quality.
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] gimp: gtk3-port

[Michael Henning]

Yes, gtk3-port is being actively developed; it just sometimes lags
behind the main development branch by a little bit.

Anyway, this issue should now be fixed.

On Sat, Sep 21, 2013 at 7:48 AM, podhorsky.ksj podhorsky@gmail.com wrote:
 Hello,

 I build gimp from branch gtk3-port, but now it shows me error:

 GIMP requires the GEGL operation gegl:over.
 This operation cannot be found. Check your
 GEGL install and ensure it has been compiled
 with any dependencies required for GIMP.

 gegl-git and all other dependencies are installed.

 Is gtk3-port still under development?

 Thanks for answer
 ___
 gimp-developer-list mailing list
 List address:gimp-developer-list@gnome.org
 List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Adapted and unadapted sRGB luminance values

[Michael Henning]

Both babl's RGB format and Y format are currently defined with a white
point of D65. Because of this, I believe the code's current luminance
values are correct.

Out of curiosity, how did you determine the Y values from the code in
gegl/operations/external/lcms-from-profile.c ? If you're somehow
dumping the icc profile and analyzing it, then it would make sense
that those are relative to D50 because icc mandates D50.

In other words, I think that the whitepoints are all currently
correct, because the constants in code are for converting between two
color spaces with D65, and the icc profile is relative to D50.

(As a side note, I believe some of the grayscale conversions are
currently very broken for other reasons. They operate in a gamma
space, but use constants that are meant for linear color spaces. I
meant to fix this before, but I forgot to at some point.)

On Sat, Sep 21, 2013 at 9:30 AM, Elle Stone l.elle.st...@gmail.com wrote:
 I was curious as to why the Babl/Gegl/Gimp code uses the unadapted
 sRGB luminance values rather than the adapted values.

 Quoting Lindbloom
 (http://www.brucelindbloom.com/index.html?WorkingSpaceInfo.html):

 Since the ICC specification and Adobe Photoshop both use a reference
 white of D50, the working space primaries that are specified relative
 to some other reference white must first be adapted to D50 before they
 may be used in a D50 environment, or be meaningfully compared with one
 another.

 If I understand him correctly, Poynton
 (http://www.poynton.com/PDFs/ColorFAQ.pdf) was talking about the
 conversion appropriate for sending signals to a monitor with a D65
 white point.  Y709 = 0.2125 R + 0.7154 G + 0.0721B

 Lindbloom unadapted and adapted sRGB Y values:
 unadpapted sRGB R, G, B luminance (Y):  0.212656 0.715158 0.072186
 adapted sRGB R, G, B luminance (Y):0.222491 0.716888 0.060621

 The sRGB profile created in
 gegl/operations/external/lcms-from-profile.c has values very close to
 the Lindbloom adapted values:  0.222488 0.716904 0.060608.

 All the code in Babl/Gegl/Gimp that I could locate uses values very
 close to the Lindbloom *un*adapted Y values:
 ./babl/babl/base/rgb-constants.h:  #define RGB_LUMINANCE_RED(0.212671)
 ./babl/babl/base/rgb-constants.h:  #define RGB_LUMINANCE_GREEN  (0.715160)
 ./babl/babl/base/rgb-constants.h:  #define RGB_LUMINANCE_BLUE   (0.072169)
 ./gegl/operations/common/snn-mean.c:#define RGB_LUMINANCE_RED(0.212671)
 ./gegl/operations/common/snn-mean.c:#define RGB_LUMINANCE_GREEN  (0.715160)
 ./gegl/operations/common/snn-mean.c:#define RGB_LUMINANCE_BLUE   (0.072169)
 ./gegl/operations/workshop/snn-percentile.c:#define RGB_LUMINANCE_RED
   (0.212671)
 ./gegl/operations/workshop/snn-percentile.c:#define
 RGB_LUMINANCE_GREEN  (0.715160)
 ./gegl/operations/workshop/snn-percentile.c:#define RGB_LUMINANCE_BLUE
   (0.072169)
 ./gegl/opencl/colors.cl.h:  #define RGB_LUMINANCE_RED(0.212671f)
 ./gegl/opencl/colors.cl.h:  #define RGB_LUMINANCE_GREEN  (0.715160f)
 ./gegl/opencl/colors.cl.h:  #define RGB_LUMINANCE_BLUE   (0.072169f)
 ./gimp/libgimpcolor/gimprgb.h:#define GIMP_RGB_LUMINANCE_RED(0.2126)
 ./gimp/libgimpcolor/gimprgb.h:#define GIMP_RGB_LUMINANCE_GREEN  (0.7152)
 ./gimp/libgimpcolor/gimprgb.h:#define GIMP_RGB_LUMINANCE_BLUE   (0.0722)
 ./babl/extensions/ycbcr.c:  luminance =  0.2126 * red + 0.7152 *
 green + 0.0722 * blue;
 ./babl/extensions/ycbcr.c:  luminance =  0.2126 * red + 0.7152 *
 green + 0.0722 * blue;
 ./gegl/operations/common/svg-saturate.c uses red:0.213 green:0.715 blue:0.072

 Elle

 --
 http://ninedegreesbelow.com

 Just because it's a standard, doesn't mean it's right.
 ___
 gimp-developer-list mailing list
 List address:gimp-developer-list@gnome.org
 List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Adapted and unadapted sRGB luminance values

[Michael Henning]

Those conversion factors are attempting to get a D65 Y from D65 RGB.

So, we currently do a conversion like this, using unadapted values:
D65 Y = 0.212656 * D65 Red + 0.715158 * D65 Green + 0.072186 * D65 Blue

And you want us to do this, using the adapted values:
Y = 0.222491 * D65 Red + 0.716888 * D65 Green + 0.060621 * D65 Blue

Isn't the second (adapted) transform going to give us a D50 Y instead
of a D65 Y?

On Sat, Sep 21, 2013 at 8:21 PM, Elle Stone l.elle.st...@gmail.com wrote:
 On 9/21/13, Michael Henning dra...@darkrefraction.com wrote:
 Both babl's RGB format and Y format are currently defined with a white
 point of D65. Because of this, I believe the code's current luminance
 values are correct.


 The whitepoint of an ICC profile might have a D65 white point without
 a chad tag, if it's a V2 profile. Or it might have a D50 white point
 with a chad (chromatic adaptation) tag if it's a V4 profile. Either
 way, the XYZ values are the adapted values, NOT the unadapted values.
 In other words D65 as the white point for the V2 profiles doesn't
 mean use the unadapted primaries, which means the unadapted Y
 values are wrong. So are the unadapted X and Z values.

 Out of curiosity, how did you determine the Y values from the code in
 gegl/operations/external/lcms-from-profile.c ?

 I put in a couple additional lines of code in the gegl file telling
 lcms to save the profile to disk. Then I recompiled gegl, retrieved
 the profile, and used iccToXml to examine the primaries. It's a bog
 standard sRGB V4 lcms-generated profile. If you would like to look at
 it, it's attached to this email.

   If you're somehow
 dumping the icc profile and analyzing it, then it would make sense
 that those are relative to D50 because icc mandates D50.


 That's kinda the point. If a person opens an sRGB image file with
 Gimp, that image's profile has the adapted primaries, not the
 unadapted primaries.

 In other words, I think that the whitepoints are all currently
 correct, because the constants in code are for converting between two
 color spaces with D65, and the icc profile is relative to D50.


 But that means the code is assuming a very odd color space, not the
 same sRGB as is used by the vast majority of all the sRGB images ever
 created. This includes all images to which Gimp assigns the built-in
 sRGB profile created by lcms. V2 or V4, lcms1 or lcms2, the sRGB
 primaries are the adapted primaries, which means the adapted R,G, and
 B Y values.

 So how can it be right that the babl/gegl/gimp code uses unadapted
 primaries for image processing, while operating on images that are
 created using the adapted primaries? If you assign an sRGB profile
 with unadapted primaries to an sRGB image that was created with a
 proper sRGB image, that image will have a false blue color cast. And
 if you use the unadapted Y values for Luminance desaturating in a
 linear gamma color space, the resulting image will be slightly wrong.

 (As a side note, I believe some of the grayscale conversions are
 currently very broken for other reasons. They operate in a gamma
 space, but use constants that are meant for linear color spaces.

 It's true that Luminance conversions to black and white in a nonlinear
 color space makes much more wrong results than merely using the
 unadapted Y values.  But the Y values for the Luminance desaturate
 code, for example, are still wrong. They should be the adapted values.

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

Re: [Gimp-developer] TIFF Deflate compression method writes proprietary/deprecated tag to file

[Michael Henning]

Fixed in master and 2.8. Thank you for reporting this.

commit cd4d5e6d32169e0d642010b992ad401244db354d
Author: Michael Henning
Date:   Fri Sep 20 19:05:18 2013 -0400

plug-ins: Use the standardized value for deflate compression in tiff-save.

Ironically, the standardized value is called COMPRESSION_ADOBE_DEFLATE,
while the vendor-specific value is called COMPRESSION_DEFLATE.


On Fri, Sep 20, 2013 at 12:10 PM, Federico federic...@gmail.com wrote:
 Hi.
 I noticed GIMP 2.8.4 is writing the proprietary ZIP/Flate compression code
 (0x80b2) when exporting images in TIFF format and selecting deflate
 compression.
 According to the TIFF Revision 6.0, Supplement 2 (
 http://partners.adobe.com/public/developer/en/tiff/TIFFphotoshop.pdf) the
 value for the Compression tag should be 0008.

 I can confirm Gimp is writing the proprietary tag by exporting a deflated
 tiff and running

 tiffdump 1.tif | grep Compression
 Compression (259) SHORT (3) 132946

 If I use imagemagick's mogrify to create the tiff
 mogrify -path /home/user/ -compress Zip -depth 8 -format tif fotografía7.tif

 I get
 tiffdump /home/user/fotografía7.tif | grep Compression
 Compression (259) SHORT (3) 18

 The compression algorithm is the same, only the code is changed for a
 standard value. As TIFF is used for long term archiving, the generating the
 files with the standard value is important for future implementations that
 may not understand the proprietary tag.

 Should I file a bug? Do you think it is important?

 Here's a section of the spec:

 Note:
 A proprietary ZIP/Flate compression code (0x80b2) has been used by some
 software vendors. This code
 should be considered obsolete. The compression used by the obsolete code is
 identical to that defined
 above. We recommend that TIFF implementations recognize and read the
 obsolete code, but only write the
 official compression code (8).
 ___
 gimp-developer-list mailing list
 List address:gimp-developer-list@gnome.org
 List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] refactor palette loading code

[Michael Henning]

wt: Your new patch looks good, so I committed it. Thanks!

As a side note, I modified the message slightly. We normally include
the general area of the commit (often the top level directory) as a
prefix to the commit message. Also, I removed the signed off by line
because we don't really use that.

The short paragraph probably wasn't necessary in this case (we know
what refactoring means), but I left that in anyway. :)

commit 198f2514ab03cd77c769b0cea9678fa0deba4f6e
Author: Warren Turkal w...@penguintechs.org
Date:   Sat Sep 14 23:46:28 2013 -0700

app: Refactor palette loaders.

I specifically moved the file opening/closing logic to the common
code. This makes the code easier to understand for me since there
is less duplication. In fact, this commit removes more lines than
it adds.

After I committed it, Mitch asked me to change the function names from
your patch on irc. You can see that commit here:
https://git.gnome.org/browse/gimp/commit/?id=d02dd9f0da778640a0a8a82420ee22f9a6efc943

On Mon, Sep 16, 2013 at 4:56 AM, Michael Schumacher schum...@gmx.de wrote:


 Gesendet: Montag, 16. September 2013 um 09:34 Uhr
 Von: Warren Turkal w...@penguintechs.org

 I am willing to do whatever is needed to contribute. However, it would be
 nice if the mailing list wouldn't block patches.

 Please keep in mind that those file would be sent out to every subscriber of 
 this mailing list, even those who would not want to receive them. Now imagine 
 people being subscribed to  10 mailing lists. Would you want to receive all 
 patches and bundles from all the projects you're subscribed to?

 The preferred way right now is to open bug reports in Bugzilla and attach 
 your patches there.

 Has anyone taken a look at maybe using gerrit? It's actually a pretty
 reasonable way to handle code changes when using git. It has a pretty nice
 code review workflow. Projects like Android and Libreoffice use it. As an
 example, here's a link
 https://gerrit.libreoffice.org/#/q/status:open,n,zto the Libreoffice
 instance.

 Might be worthwhile to discuss that with GNOME; it's their repository we're 
 using after all.
 They could be interesed in this especially for their GNOME Love bugs, see 
 https://wiki.gnome.org/GnomeLove


 --
 Regards,
 Michael
 ___
 gimp-developer-list mailing list
 List address:gimp-developer-list@gnome.org
 List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Nightly Build of GIMP

[Michael Henning]

Jehan:
These are my nightly builds. I build all of gimp's dependencies every
night from source. Right now I use cairo 1.12.14, and libpng 1.6.3.
All of the build options can be found around here:
https://git.gnome.org/browse/gimp/tree/build/windows/jhbuild/build.jhbuildrc#n133

This definitely sounds more like a cairo problem than a libpng
problem. I just realized that there's a minor upgrade of pixman
available (to 0.30.2), so I'll pull that in tonight because it might
have a bugfix.

I'm now cc'd on the bugreport you mentioned. We can continue this
discussion there.

  -- drawoc

On Wed, Sep 11, 2013 at 12:55 AM, Jehan Pagès
jehan.marmott...@gmail.com wrote:
 Hello people!

 Who takes care of the Nightly dev builds of GIMP here:
 http://nightly.darkrefraction.com/gimp/ ?

 I see we link this page on the official download page, so I guess
 that's someone from the team.
 I'd like to know what versions of libpng and cairo are used for these
 builds. Are these binaries taken from another project or self-built?
 Which exact version? With which build options?

 A user reported consistent crashes on Windows 7 32-bit, both for the
 master and gimp-2-8 nightbuilds, on simple resize/move events (Bug
 707653 ). On Windows 7 64-bit running these 32-bit binaries, I could
 reproduce very bad drawing bugs with the same binaries (no crash, but
 the user crash happens on expose events in his traces, so I think
 that's the same problem).

 But I could not reproduce this with my own Windows builds, both for
 master and gimp-2-8. After some tests, I see that the problem comes
 from cairo and/or libpng (basically I can take my own libpng15-15.dll
 and copy over libcairo-2.dll to the nightbuild prefix, and it would
 work).

 But I could not reproduce by recompiling myself libpng-1.6.3 and
 cairo-1.12.14. So I am wondering if the problem does not simply come
 from somehow broken dll in the nightbuilds. Thus I'd like to know how
 these have been build, which version, etc.
 Thanks.

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

Re: [Gimp-developer] Mac Gimp from git - App crash: Error (1007) creating CGSWindow

[Michael Henning]

I don't think we've seen this before. So, bugreport please!

On Sun, Aug 25, 2013 at 6:27 PM, Partha Bagchi parth...@gmail.com wrote:
 Gimp 2.9 built from git on Mountain Lion to support Snow Leopard and above.

 When working with large tiffs, I am getting an app crash with the following:

 Error (1007) creating CGSWindow

 (I can provide the full crash report if needed).

 My gtk version is 2.24.20.

 Is it worth filing a bug report or just wait for it sort itself out? :)



 Thanks!
 Partha
 ___
 gimp-developer-list mailing list
 List address:gimp-developer-list@gnome.org
 List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] GIMP 2.9.1 show every image as a transparent layer.

[Michael Henning]

Grab the latest version of gegl from git, then recompile and reinstall gegl.

You should continuously update your gegl and babl versions as you
update gimp. Otherwise, you can run into issues like this.

On Sat, Aug 10, 2013 at 1:59 PM, Hains van den Bosch
hvdbo...@cybercomm.nl wrote:
 Hello,

 I compiling gimp,babl and gegle from git with ubuntu 13.10.Since the 28-29th
 of july i have the problem that GIMP 2.9.1 shows every image(png,bmp,tiff
 etc.) only as a 100% transparent layer. Only the layer window shows the
 image well.Before that time it works fine.
 Also when i want to open a file and i click once on the file, the image is
 visible in the preview window for a very short time(approximately 0,25
 second) then it change into a chessboard.
 I build GIMP from stratch and delete/restore settings, but that does not
 work.
 GIMP 2.8.6 works fine, no problem.
 So GIMP 2.9.1 is completely useless at the moment.
 I am a beginner with C++ and not a expert with linux.So please be clear what
 i have to do.

 With kind regards

 Hains van den Bosch
 ___
 gimp-developer-list mailing list
 List address:gimp-developer-list@gnome.org
 List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] pygtk automake problem

[Michael Henning]

Line 204 of autogen.sh should look like this:
1.8*) automake_progs=automake-1.8 automake-1.9 automake-1.10
automake-1.11 ;;
Add your version of automake to the end, like this:
1.8*) automake_progs=automake-1.8 automake-1.9 automake-1.10
automake-1.11 automake-1.12 ;;

That should compile for you.

If you're not doing development, it might be better to grab the latest
tarball and just run configure on that, instead of running autogen.
Then your automake version won't matter.

On Sat, Aug 3, 2013 at 11:04 PM, Burnie West w...@ieee.org wrote:
 Hi -

 I'm trying to build gimp with pygtk; got (AFAIK) all the current stuff.

 But I'm hung up on the autogen.sh for pygtk.

 I executed command
 ./autogen.sh --prefix=$HOME  make -j4  make install

 System response:
 $ ./autogen.sh --prefix=$HOME  make -j4  make install
 checking for autoconf = 2.53...
   testing autoconf2.50... not found.
   testing autoconf... found 2.69
 checking for automake = 1.8...
   testing automake-1.8... not found.
   testing automake-1.9... not found.
   testing automake-1.10... not found.
   testing automake-1.11... not found.
 ***Error***: You must have automake = 1.8 installed
   to build PyGTK.  Download the appropriate package for
   from your distribution or get the source tarball at
 http://ftp.gnu.org/pub/gnu/automake/automake-1.8.tar.gz

 I'm a bit reluctant to downrev automake for this --

 My automake is -1.12.  What should I do?

   -- Burnie

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

Re: [Gimp-developer] Gimp git error?

[Michael Henning]

Well, you could open up app/sanity.c and comment out the line that
says gegl:seamless-clone, to disable the check, although then you'll
have a broken seamless clone tool.

It seems like the proper fix would be to try and make the seamless
clone op work on your computer. The error happens during loading, so
you'd need to run gimp from within gdb. It might help if you place a
breakpoint on g_warning and get a full trace (with variables) of that
when it breaks.

On Sat, Aug 3, 2013 at 6:00 PM, Partha Bagchi parth...@gmail.com wrote:
 Well, I build babl/gegl/gimp simultaneously and so they are all update. Just
 to rule out that it's an issue on my side, I completey wiped out both gegl
 and gimp and recloned them. Then I rebuilt the app. So, not sure the issue
 is on my side. Also, gdb cannot debug since gimp quits prior to starting.

 How do we disable seamless clone if necessary? Is it even necessary?

 Thanks,
 Partha



 On Sat, Aug 3, 2013 at 1:52 PM, Michael Henning dra...@darkrefraction.com
 wrote:

 The change in the gimp that caused this is that we now check to make
 sure you have certain required gegl ops installed. We did not do this
 until recently, so it's possible the seamless clone
  op was broken on your machine for a while, and we just caught it.

 I don't really know why your seamless clone op is broken. That error
 message on the console it too generic.

 If I were you, I would try wiping my prefix, running git clean, and
 then recompiling. If that doesn't help, then we need to do some
 debugging.

 Does anyone else with a mac build from git get the same error message?

 On Sat, Aug 3, 2013 at 7:12 AM, Partha Bagchi parth...@gmail.com wrote:
  No.
 
 
 
  On Sat, Aug 3, 2013 at 6:02 AM, scl scl.gp...@gmail.com wrote:
 
  On 02.08.13 at 3:51 PM, Partha Bagchi wrote:
 
  Just started getting this message this morning (all git pulls up to
  date):
 
  GEGL operation missing!
 
  GIMP requires the GEGL operation gegl:seamless-clone.
  This operation cannot be found. Check your
  GEGL install and ensure it has been compiled
  with any dependencies required for GIMP.
 
 
  GIMP master with Seamless Clone requires GEGL master.
  Could it be you used GEGLs gegl-0-2 branch?
 
  Kind regards,
 
  Sven
 
 
  __**_
  gimp-developer-list mailing list
  List address:gimp-developer-list@gnome.org
  List membership: https://mail.gnome.org/**mailman/listinfo/gimp-**
 
  developer-listhttps://mail.gnome.org/mailman/listinfo/gimp-developer-list
 
  ___
  gimp-developer-list mailing list
  List address:gimp-developer-list@gnome.org
  List membership:
  https://mail.gnome.org/mailman/listinfo/gimp-developer-list


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

Re: [Gimp-developer] Gimp git error?

[Michael Henning]

Quick correction: put the breakpoint on g_log, not g_warning.
g_warning is actually a #define.

On Sun, Aug 4, 2013 at 12:32 PM, Michael Henning
dra...@darkrefraction.com wrote:
 Well, you could open up app/sanity.c and comment out the line that
 says gegl:seamless-clone, to disable the check, although then you'll
 have a broken seamless clone tool.

 It seems like the proper fix would be to try and make the seamless
 clone op work on your computer. The error happens during loading, so
 you'd need to run gimp from within gdb. It might help if you place a
 breakpoint on g_warning and get a full trace (with variables) of that
 when it breaks.

 On Sat, Aug 3, 2013 at 6:00 PM, Partha Bagchi parth...@gmail.com wrote:
 Well, I build babl/gegl/gimp simultaneously and so they are all update. Just
 to rule out that it's an issue on my side, I completey wiped out both gegl
 and gimp and recloned them. Then I rebuilt the app. So, not sure the issue
 is on my side. Also, gdb cannot debug since gimp quits prior to starting.

 How do we disable seamless clone if necessary? Is it even necessary?

 Thanks,
 Partha



 On Sat, Aug 3, 2013 at 1:52 PM, Michael Henning dra...@darkrefraction.com
 wrote:

 The change in the gimp that caused this is that we now check to make
 sure you have certain required gegl ops installed. We did not do this
 until recently, so it's possible the seamless clone
  op was broken on your machine for a while, and we just caught it.

 I don't really know why your seamless clone op is broken. That error
 message on the console it too generic.

 If I were you, I would try wiping my prefix, running git clean, and
 then recompiling. If that doesn't help, then we need to do some
 debugging.

 Does anyone else with a mac build from git get the same error message?

 On Sat, Aug 3, 2013 at 7:12 AM, Partha Bagchi parth...@gmail.com wrote:
  No.
 
 
 
  On Sat, Aug 3, 2013 at 6:02 AM, scl scl.gp...@gmail.com wrote:
 
  On 02.08.13 at 3:51 PM, Partha Bagchi wrote:
 
  Just started getting this message this morning (all git pulls up to
  date):
 
  GEGL operation missing!
 
  GIMP requires the GEGL operation gegl:seamless-clone.
  This operation cannot be found. Check your
  GEGL install and ensure it has been compiled
  with any dependencies required for GIMP.
 
 
  GIMP master with Seamless Clone requires GEGL master.
  Could it be you used GEGLs gegl-0-2 branch?
 
  Kind regards,
 
  Sven
 
 
  __**_
  gimp-developer-list mailing list
  List address:gimp-developer-list@gnome.org
  List membership: https://mail.gnome.org/**mailman/listinfo/gimp-**
 
  developer-listhttps://mail.gnome.org/mailman/listinfo/gimp-developer-list
 
  ___
  gimp-developer-list mailing list
  List address:gimp-developer-list@gnome.org
  List membership:
  https://mail.gnome.org/mailman/listinfo/gimp-developer-list


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

Re: [Gimp-developer] Gimp git error?

[Michael Henning]

Let me clarify. After you start gdb, but before starting GIMP, type:

break g_log
set logging on
run

Then, whenever gdb stops the program (may happen a few times), type:

bt full
continue

Once the dialog box appears, close it and you're done. Then, find
gdb.txt and attach it here or put it on a pastebin.

Thanks.

On Sun, Aug 4, 2013 at 1:20 PM, Michael Henning
dra...@darkrefraction.com wrote:
 Quick correction: put the breakpoint on g_log, not g_warning.
 g_warning is actually a #define.

 On Sun, Aug 4, 2013 at 12:32 PM, Michael Henning
 dra...@darkrefraction.com wrote:
 Well, you could open up app/sanity.c and comment out the line that
 says gegl:seamless-clone, to disable the check, although then you'll
 have a broken seamless clone tool.

 It seems like the proper fix would be to try and make the seamless
 clone op work on your computer. The error happens during loading, so
 you'd need to run gimp from within gdb. It might help if you place a
 breakpoint on g_warning and get a full trace (with variables) of that
 when it breaks.

 On Sat, Aug 3, 2013 at 6:00 PM, Partha Bagchi parth...@gmail.com wrote:
 Well, I build babl/gegl/gimp simultaneously and so they are all update. Just
 to rule out that it's an issue on my side, I completey wiped out both gegl
 and gimp and recloned them. Then I rebuilt the app. So, not sure the issue
 is on my side. Also, gdb cannot debug since gimp quits prior to starting.

 How do we disable seamless clone if necessary? Is it even necessary?

 Thanks,
 Partha



 On Sat, Aug 3, 2013 at 1:52 PM, Michael Henning dra...@darkrefraction.com
 wrote:

 The change in the gimp that caused this is that we now check to make
 sure you have certain required gegl ops installed. We did not do this
 until recently, so it's possible the seamless clone
  op was broken on your machine for a while, and we just caught it.

 I don't really know why your seamless clone op is broken. That error
 message on the console it too generic.

 If I were you, I would try wiping my prefix, running git clean, and
 then recompiling. If that doesn't help, then we need to do some
 debugging.

 Does anyone else with a mac build from git get the same error message?

 On Sat, Aug 3, 2013 at 7:12 AM, Partha Bagchi parth...@gmail.com wrote:
  No.
 
 
 
  On Sat, Aug 3, 2013 at 6:02 AM, scl scl.gp...@gmail.com wrote:
 
  On 02.08.13 at 3:51 PM, Partha Bagchi wrote:
 
  Just started getting this message this morning (all git pulls up to
  date):
 
  GEGL operation missing!
 
  GIMP requires the GEGL operation gegl:seamless-clone.
  This operation cannot be found. Check your
  GEGL install and ensure it has been compiled
  with any dependencies required for GIMP.
 
 
  GIMP master with Seamless Clone requires GEGL master.
  Could it be you used GEGLs gegl-0-2 branch?
 
  Kind regards,
 
  Sven
 
 
  __**_
  gimp-developer-list mailing list
  List address:gimp-developer-list@gnome.org
  List membership: https://mail.gnome.org/**mailman/listinfo/gimp-**
 
  developer-listhttps://mail.gnome.org/mailman/listinfo/gimp-developer-list
 
  ___
  gimp-developer-list mailing list
  List address:gimp-developer-list@gnome.org
  List membership:
  https://mail.gnome.org/mailman/listinfo/gimp-developer-list


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

Re: [Gimp-developer] pygtk automake problem

[Michael Henning]

It should install into pygtk/2.0; that is normal. The 2.0 indicates
that it is API/ABI compatible with pygtk 2.0. As long as there are no
backwards-incompatible changes, the directory remains 2.0, even for
version 2.4.

Are you on linux? If you are, then the only things you should really
need to build yourself are babl, gegl, and gimp. Install your distro's
packages for everything else, and you should be good to go. If you
have issues with python, then you may need to do this before running
gimp's autogen.sh:

export PYTHON=/usr/bin/python2

Good luck.

On Sun, Aug 4, 2013 at 3:26 PM, Burnie West w...@ieee.org wrote:
 On 08/04/2013 10:41 AM, Burnie West wrote:

 And I already had pygtk/2.0 installed natively.

 But for some reason, even though the installation is in fact pygtk2-2.24.0,
 it installs in the directory pygtk/2.0 (Fedora 18), as I had noted earlier.
 I've very little experience with the configure script; indeed, little
 expreience with console scripting. But it appears the configure script
 cannot cope with this formulation, and I'm currently attempting to find out
 why.

 As my current intent is to work on python plugins (a particular one in
 fact), building My-gimp without python support is a non-starter. I'd already
 successfully built babl, gegl, and gimp-2.9.0 about a year ago, but had
 disabled the python section (as lightningismyname had suggested) and dropped
 that path.

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

Re: [Gimp-developer] Gimp git error?

[Michael Henning]

I forgot: for the instructions in my last email to work, you probably
need to compile glib with debugging symbols.

On Sun, Aug 4, 2013 at 6:05 PM, Partha Bagchi parth...@gmail.com wrote:
 Michael,

 Additional information: After I commented out seamless clone from sanity
 check, Gimp compiled and ran fine.

 I tried out LightiningIsMyName's youtube video and it works on the Mac
 fine without the need for this check. Of course, it's excruciatingly slow
 and takes forever on my speedy Mac for even a 10 MP image.

 Thanks,
 Partha



 On Sun, Aug 4, 2013 at 2:13 PM, Partha Bagchi parth...@gmail.com wrote:

 Michael,

 Sorry to be dense. But gimp stops running after you click OK on the dialog
 box and the gdb stack is empty. So, I am not sure what you are expecting in
 the logfile? gdb.txt shows exactly what I posted above.

 NU gdb 6.3.50-20050815 (Apple version gdb-1515) (Sat Jan 15 08:33:48 UTC
 2011)
 Copyright 2004 Free Software Foundation, Inc.
 GDB is free software, covered by the GNU General Public License, and you
 are
 welcome to change it and/or distribute copies of it under certain
 conditions.
 Type show copying to see the conditions.
 There is absolutely no warranty for GDB.  Type show warranty for
 details.
 This GDB was configured as x86_64-apple-darwin...Reading symbols for
 shared libraries .. done

 (gdb) break g_log
 Breakpoint 1 at 0x22d0e560408c1e0
 (gdb) set logging on
 Copying output to gdb.txt.
 (gdb) run
 Reading symbols for shared libraries
 +.+++
 done
 Reading symbols for shared libraries . done
 Reading symbols for shared libraries . done
 Reading symbols for shared libraries . done
 Reading symbols for shared libraries . done
 Reading symbols for shared libraries . done
 Reading symbols for shared libraries . done
 Reading symbols for shared libraries . done
 Reading symbols for shared libraries . done
 Reading symbols for shared libraries . done
 Reading symbols for shared libraries . done
 Reading symbols for shared libraries . done
 Reading symbols for shared libraries . done
 Reading symbols for shared libraries . done
 Reading symbols for shared libraries . done
 Reading symbols for shared libraries . done
 Reading symbols for shared libraries . done
 Reading symbols for shared libraries . done
 Reading symbols for shared libraries . done
 Reading symbols for shared libraries . done
 Reading symbols for shared libraries . done
 Reading symbols for shared libraries . done
 Reading symbols for shared libraries . done
 Reading symbols for shared libraries . done
 Reading symbols for shared libraries . done
 Reading symbols for shared libraries . done
 Reading symbols for shared libraries . done
 Reading symbols for shared libraries . done
 Reading symbols for shared libraries . done
 Reading symbols for shared libraries . done
 Reading symbols for shared libraries . done
 Reading symbols for shared libraries . done
 Reading symbols for shared libraries . done
 Reading symbols for shared libraries . done
 Reading symbols for shared libraries . done
 Reading symbols for shared libraries . done
 Reading symbols for shared libraries . done
 Reading symbols for shared libraries . done
 Reading symbols for shared libraries . done
 Reading symbols for shared libraries . done
 Reading symbols for shared libraries . done
 Reading symbols for shared libraries . done
 ---Type return to continue, or q return to quit---
 (After a couple of these screens I get:
 Reading symbols for shared libraries .. done

 (process:86394): GLib-GObject-WARNING **: invalid cast from '(null)' to
 'GTypePlugin'

 (process:86394): GLib-GObject-WARNING **: plugin pointer (0x10480df00) for
 type 'GeglChantseamless-clone-compose_c' is invalid
 Reading symbols for shared libraries .. done

 (process:86394): GLib-GObject-WARNING **: invalid cast from '(null)' to
 'GTypePlugin'

 (process:86394): GLib-GObject-WARNING **: plugin pointer (0x10206b010) for
 type 'GeglChantseamless-clone_c' is invalid
 Reading symbols for shared libraries . done
 Reading symbols for shared libraries . done

 After a couple of more screens, the dialog box appears:

 GEGL operation missing!

 GIMP requires the GEGL operation gegl:seamless-clone.
 This operation cannot be found. Check your
 GEGL install and ensure it has been compiled
 with any dependencies required for GIMP.

 When you press OK, you get:

 Program exited with code 01.
 (gdb) bt full
 No stack.
 (gdb)

 gdb.txt just contains the above other than a warning about liblzma.5.dylib
 which I know about.

 Thanks,
 Partha



 On Sun, Aug 4, 2013 at 1:37 PM, Michael Henning
 dra...@darkrefraction.com wrote:

 Let me clarify. After you start gdb, but before starting GIMP, type:

 break g_log
 set logging on
 run

 Then, whenever gdb stops

Re: [Gimp-developer] Gimp git error?

[Michael Henning]

The change in the gimp that caused this is that we now check to make
sure you have certain required gegl ops installed. We did not do this
until recently, so it's possible the seamless clone
 op was broken on your machine for a while, and we just caught it.

I don't really know why your seamless clone op is broken. That error
message on the console it too generic.

If I were you, I would try wiping my prefix, running git clean, and
then recompiling. If that doesn't help, then we need to do some
debugging.

Does anyone else with a mac build from git get the same error message?

On Sat, Aug 3, 2013 at 7:12 AM, Partha Bagchi parth...@gmail.com wrote:
 No.



 On Sat, Aug 3, 2013 at 6:02 AM, scl scl.gp...@gmail.com wrote:

 On 02.08.13 at 3:51 PM, Partha Bagchi wrote:

 Just started getting this message this morning (all git pulls up to date):

 GEGL operation missing!

 GIMP requires the GEGL operation gegl:seamless-clone.
 This operation cannot be found. Check your
 GEGL install and ensure it has been compiled
 with any dependencies required for GIMP.


 GIMP master with Seamless Clone requires GEGL master.
 Could it be you used GEGLs gegl-0-2 branch?

 Kind regards,

 Sven


 __**_
 gimp-developer-list mailing list
 List address:gimp-developer-list@gnome.org
 List membership: https://mail.gnome.org/**mailman/listinfo/gimp-**
 developer-listhttps://mail.gnome.org/mailman/listinfo/gimp-developer-list

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

Re: [Gimp-developer] gegl and spiro

[Michael Henning]

Currently, there is (almost) no benefit. Building gegl with spiro
support allows XML compositions to use spiro curves when input on the
gegl command line. I'm not entirely sure that works as I've never used
it, and I have a feeling nobody else has used it in a long time.

The spiro curves support used to be part of the old gegl editor, but
now that editor is gone.

So, building with spiro won't change gimp at all.

On Sat, Jul 27, 2013 at 6:21 PM, Elle Stone l.elle.st...@gmail.com wrote:
 What benefits are there from installing the spiro libraries for gegl to use?

 According to the spiro website:  http://libspiro.sourceforge.net/

 Using bézier splines an artist can easily draw curves with the same
 slope on either side of an on-curve point. Spiros, on the other hand,
 are based on clothoid splines which make it easy to maintain constant
 curvature as well as constant slope. Such curves will simply look
 nicer.

 I've never had the spiro libraries installed on my computer. They can
 be downloaded from sourceforge. What would be the benefits? What part
 of Gimp would draw nicer curves?

 Elle

 --
 http://ninedegreesbelow.com - articles on open source digital photography
 ___
 gimp-developer-list mailing list
 List address:gimp-developer-list@gnome.org
 List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] OSX Performance (screen redraw)

[Michael Henning]

The warning that said 'Geglconfig has no property named
'cache-size'. isn't related. That's just there because of the version
of gegl in use by the builds.

Because 2.8 doesn't use gegl for most operations, that wouldn't cause
your issue.

Sorry, I don't know what's causing this.

  -- drawoc

On Thu, Jul 11, 2013 at 10:41 PM, Pat David patda...@gmail.com wrote:
 To follow up, in case it helps anyone out, here is the output from the
 terminal when running the app:

 Pats-Air:MacOS pat$ ./Gimp
 Dir is .
  Appdir is /Users/pat/Downloads/Gimp-2.8.app
 removed /tmp/pb2.8 folder
 removed tmp/lib folder
 Hello - About to run Gimp - Standby
 CWD is /tmp/pb2.8/Gimp-2.8.app/Contents/MacOS
 pwd is /Users/pat
 Strip out the argument added by the OS...
 Cannot spawn a message bus without a machine-id: Unable to load
 /var/lib/dbus/machine-id or /etc/machine-id: Failed to open file
 '/var/lib/dbus/machine-id': No such file or directory

 (gimp-2.8:6567): GLib-GObject-WARNING **: g_object_set_valist: object class
 'GeglConfig' has no property named 'cache-size'
 /tmp/pb2.8/Gimp-2.8.app/Contents/Resources/share/gimp/2.0/themes/Small/gtkrc:18:
 Unable to locate image file in pixmap_path:
 ../Default/images/stock-error-64.png
 /tmp/pb2.8/Gimp-2.8.app/Contents/Resources/share/gimp/2.0/themes/Small/gtkrc:22:
 Unable to locate image file in pixmap_path:
 ../Default/images/stock-info-64.png
 /tmp/pb2.8/Gimp-2.8.app/Contents/Resources/share/gimp/2.0/themes/Small/gtkrc:26:
 Unable to locate image file in pixmap_path:
 ../Default/images/stock-question-64.png
 /tmp/pb2.8/Gimp-2.8.app/Contents/Resources/share/gimp/2.0/themes/Small/gtkrc:30:
 Unable to locate image file in pixmap_path:
 ../Default/images/stock-warning-64.png
 ** Message: pygobject_register_sinkfunc is deprecated (GtkWindow)
 ** Message: pygobject_register_sinkfunc is deprecated (GtkInvisible)
 ** Message: pygobject_register_sinkfunc is deprecated (GtkObject)

 ** (process:6580): WARNING **: Trying to register gtype 'GMountMountFlags'
 as enum when in fact it is of type 'GFlags'

 ** (process:6580): WARNING **: Trying to register gtype 'GDriveStartFlags'
 as enum when in fact it is of type 'GFlags'

 ** (process:6580): WARNING **: Trying to register gtype 'GSocketMsgFlags'
 as enum when in fact it is of type 'GFlags'


 The only part that looks possibly suspect/related to me is the
 GObject-WARNING about 'Geglconfig has no property named 'cache-size'.

 Could this be related?



 On Mon, Jul 8, 2013 at 8:40 AM, Pat David patda...@gmail.com wrote:

 Hi all,

 I wasn't sure if I should post here, but I figure it can't hurt.

 I'm running OSX 10.7.5 (Lion) w/ 4GB ram, and have been primarily using
 two builds from Simone and Partha.  (Partha's 2.8.6 build, and the latest
 from Simone for Lion 2.8.4 - 2.8.4p2)

 What I'm seeing is an incredibly slow screen/canvas redraw when doing
 actions that affect the entire layer.  For instance, here is a small
 screencast of turning a layer on and off in my system:

 http://www.youtube.com/watch?v=dxLlOJY7ZJs

 I've tried setting the tile cache size from 3GB to 1GB, and even down to
 512MB, but it makes no difference.

 I've found previous posts around about color management possibly being the
 culprit, but I've tried it both with/without color management enabled, and
 it appears to make no difference.

 The only thing I've noticed is that if I zoom into a much smaller region,
 things speed up quickly.  (It's actually faster to zoom in to about 300%,
 toggle a layer visibility or adjust curves, then zoom out - where the
 effect has been applied across the entire image layer, as opposed to trying
 to do while viewing the entire image).

 I saw a changelog that mentioned this might be fixed, so I'm worried I
 might be doing something wrong...

 --
 pat david
 http://blog.patdavid.net




 --
 pat david
 http://blog.patdavid.net
 ___
 gimp-developer-list mailing list
 List address:gimp-developer-list@gnome.org
 List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] The new linear and gamma precision choices

[Michael Henning]

Elle: Things are confusing now because the code isn't finished. A lot
of things will change before 2.10 is released.

Rest assured, we won't keep everything this way.

On Sun, Jul 7, 2013 at 5:23 PM, Elle Stone l.elle.st...@gmail.com wrote:
 Gimp from git allows the user to choose which image precision to use
 while editing the image. The choices used to be 8-bit, 16-bit, and
 32-bit integer, plus 16-bit and 32-bit floating point. The choices
 have recently doubled: for each image precision choice, the user must
 choose whether to work in a linear or a gamma color space. The
 default seems to be gamma rather than linear.

 I did some experimenting to see what these new precision choices might mean:

 The practical result of choosing linear vs gamma as your image
 precision depends on the image's actual RGB color space TRC (whether
 linear or true sRGB TRC or some other TRC) and it also depends on
 which operations you want to perform. Limited testing suggests that at
 present it affects blend modes but not blurring or gradients.

 CASE A: the image is in the regular sRGB color space

 If the image is already in the regular sRGB color space, then choosing
 gamma means for example that a soft-light blend of an image over
 itself will look like it was done in the regular sRGB color space. But
 choosing linear means it will look like the blend was done in a
 linear gamma version of the sRGB color space and the result will be
 darker than it would be if done in the regular sRGB color space. In
 both cases gradients look like regular sRGB gradients. And in both
 cases, blurring looks like it was done in a linear gamma version of
 the sRGB color space.

 CASE B: the image in a linear gamma version of the sRGB color space

 If the image is already in a linear version of the sRGB color space,
 then choosing gamma means that a soft-light blend of an image over
 itself will look like it was done in a *linear* gamma version of the
 sRGB color space. And choosing linear means it will look like the
 blend was done in a gamma=0.45 (approx) version of the sRGB color
 space. In both cases gradients look like linear gamma sRGB gradients.
 And in both cases blurring looks like it was done in a gamma=0.45
 version of the sRGB color space.

 CASE C: the image is in some color space other than sRGB

 Some color management background:

 The gamma precision refers to the regular sRGB matrix color space
 tone response curve. However, the sRGB matrix color space is not a
 true gamma color space. Its tone response curve (TRC) is composed of a
 linear section at the toe and a true gamma=2.4 section everywhere
 else.

 A linear gamma version of the sRGB color space is the regular sRGB
 color space with the regular sRGB TRC replaced with a  gamma=1.0 TRC.

 RGB matrix working spaces like sRGB or CIE-RGB or a ProPhoto-like
 color space, etc, are defined primarily by three things: their RGB
 Primaries, their Tone Response Curve, and their white point. Putting
 white point aside (lcms takes care of that behind the scenes), a color
 space's Primaries determine the reddest red, bluest blue, and greenest
 green that color space can contain. A color space's TRC determines how
 fast a color goes from dark to light as the RGB values go from 0 to
 max white (255 for 8-bit integer, 65535 for 16-bit integer, 1.0 for
 floating point).

 So linear sRGB is not the only linear gamma color space. You can have
 linear gamma versions of any working space. And you can also have, for
 example, a color space with the CIE-RGB primaries and the regular sRGB
 tone response curve. ProPhoto-like color spaces usually have a
 gamma=1.8 TRC but you can create a linear gamma version of a
 ProPhoto-like color space, and a version with the regular sRGB TRC.
 And so on.

 What happens if your image happens to be in a color space other than
 the regular sRGB color space?

 The Gimp gamma and linear precision code assumes the image has the
 regular sRGB TRC. The closer a color space's TRC is to the regular
 sRGB TRC, the more the resulting tonalities will be like case A above.
 The closer the color space's TRC is to being linear, the more the
 result's will be like CASE B above. And results will be more or less
 wrong to the extent that the color space's TRC deviates from the sRGB
 TRC.

 May I ask what is the point or reason for this new and confusing
 option of linear and gamma precision? I say confusing because it
 changes the mathematically expected behavior given the TRC of the
 image color space.

 I should probably confess that for my own image editing I use a
 version of babl/gegl/Gimp where the babl conversions between linear
 and regular sRGB are eliminated. That way I can choose which color
 space I want to work in and be confident of the results: linear gamma
 working space, linear gamma results; higher gamma working space,
 higher gamma results. I fear this out will not be viable for long.

 Elle, as usual, puzzled
 

Re: [Gimp-developer] Test some file plug-ins in master branch

[Michael Henning]

The premultiplied alpha issue should now also be fixed.

On Fri, May 24, 2013 at 10:10 PM, Michael Henning
dra...@darkrefraction.com wrote:
 Elle:
 I think I just fixed the two issues you mentioned (exporting with
 layers and importing grayscale tiffs). Could you grab the latest code
 and test those again, to confirm that they're fixed?

 (Note that there's an additional problem related to importing with
 premultiplied alpha that I'll haven't fixed yet.)

   -- drawoc

 On Fri, May 24, 2013 at 1:03 PM, Elle Stone l.elle.st...@gmail.com wrote:
 On 5/24/13, Mukund Sivaraman m...@banu.com wrote:
 The following file plug-ins have been revised to use GIMP's new API.
 I feel they need more testing as the changes are intrusive and the file
 types can support a variety of pixel formats. I have tested these to my
 satisfaction. Please test these if you can (master branch).

 * file-tiff-save (test saving grayscale, RGB and indexed TIFF files
   incl. 16-bits per channel in the case of non-indexed)

 Tiff vary a bit in their internal structure, depending on which
 software generates the tiff, yes? So I'm planning on testing tiffs
 from several sources.

 I'm using Gentoo Linux. I rebuilt babl, gegl, and Gimp 2.9 from git
 this morning. So far I've tested some old 8-bit and 16-bit single
 layer tiffs that were created using Photoshop CS2 under Windows 2K (I
 did say old!):

 *8-bit and 16-bit color tiffs opened and exported properly; I was able
 to open the exported files with showFoto and each file looked right
 and had its appropriate bit depth.

 *converting 8-bit tiff to 16-bit tiff and exporting worked.

 *converting tiff to indexed and exporting worked.

 *converting 8-bit and 16-bit color tiffs to grayscale and exporting
 worked; the exported file opened with showFoto and looked exactly as
 expected. However, opening the exported 8-bit and 16-bit
 color-to-grayscale tiffs (that Gimp has just exported) with Gimp
 instead of showFoto didn't work. The images were too light in
 tonality, looked like they had been given a gamma 2.2ish correction.
 Upon exporting the newly opened grayscale image under a new name, the
 exported image then was also wrong in showFoto (showFoto can't
 actually work with or save grayscale image, instead converts to RGB
 before displaying the image).

 *Tiffs can support multiple layers and higher than 16-bit precision,
 which is not to say that Gimp is obligated to support these options.
 Exporting a two-layer tiff didn't work. Only one layer was exported
 and only about a third of the image on that layer was exported
 properly. Also changing precision to 32-bit floating point and
 exporting as a tiff resulted in a 16-bit tiff.

 Elle
 ___
 gimp-developer-list mailing list
 gimp-developer-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gimp-developer-list
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Test some file plug-ins in master branch

[Michael Henning]

Elle:
I think I just fixed the two issues you mentioned (exporting with
layers and importing grayscale tiffs). Could you grab the latest code
and test those again, to confirm that they're fixed?

(Note that there's an additional problem related to importing with
premultiplied alpha that I'll haven't fixed yet.)

  -- drawoc

On Fri, May 24, 2013 at 1:03 PM, Elle Stone l.elle.st...@gmail.com wrote:
 On 5/24/13, Mukund Sivaraman m...@banu.com wrote:
 The following file plug-ins have been revised to use GIMP's new API.
 I feel they need more testing as the changes are intrusive and the file
 types can support a variety of pixel formats. I have tested these to my
 satisfaction. Please test these if you can (master branch).

 * file-tiff-save (test saving grayscale, RGB and indexed TIFF files
   incl. 16-bits per channel in the case of non-indexed)

 Tiff vary a bit in their internal structure, depending on which
 software generates the tiff, yes? So I'm planning on testing tiffs
 from several sources.

 I'm using Gentoo Linux. I rebuilt babl, gegl, and Gimp 2.9 from git
 this morning. So far I've tested some old 8-bit and 16-bit single
 layer tiffs that were created using Photoshop CS2 under Windows 2K (I
 did say old!):

 *8-bit and 16-bit color tiffs opened and exported properly; I was able
 to open the exported files with showFoto and each file looked right
 and had its appropriate bit depth.

 *converting 8-bit tiff to 16-bit tiff and exporting worked.

 *converting tiff to indexed and exporting worked.

 *converting 8-bit and 16-bit color tiffs to grayscale and exporting
 worked; the exported file opened with showFoto and looked exactly as
 expected. However, opening the exported 8-bit and 16-bit
 color-to-grayscale tiffs (that Gimp has just exported) with Gimp
 instead of showFoto didn't work. The images were too light in
 tonality, looked like they had been given a gamma 2.2ish correction.
 Upon exporting the newly opened grayscale image under a new name, the
 exported image then was also wrong in showFoto (showFoto can't
 actually work with or save grayscale image, instead converts to RGB
 before displaying the image).

 *Tiffs can support multiple layers and higher than 16-bit precision,
 which is not to say that Gimp is obligated to support these options.
 Exporting a two-layer tiff didn't work. Only one layer was exported
 and only about a third of the image on that layer was exported
 properly. Also changing precision to 32-bit floating point and
 exporting as a tiff resulted in a 16-bit tiff.

 Elle
 ___
 gimp-developer-list mailing list
 gimp-developer-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gimp-developer-list
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Featuring GIMP in the AMD Application Showcase

[Michael Henning]

There are a few issues with our listing. First, we're listed twice.
Like Alexandre said, the second listing has an incorrect version
number. Also, the link is broken on the second entry's learn more
button.

The first listing seems more accurate, so you may just want to delete
the second listing.

In any case, thanks for listing us.

On Thu, Apr 18, 2013 at 2:59 PM, Carney, Kristen kristen.car...@amd.com wrote:
 GIMP Developers,


 I'm happy to inform you that GIMP is featured in the Media section of AMD's
 heterogeneous computing application showcase. Check it out!
 http://developer.amd.com/community/application-showcase/media/


 Please let us know if we have accurately represented your software.


 Cheers!


 Kristen Carney

 Developer Evangelist  |  AMD


 ___
 gimp-developer-list mailing list
 gimp-developer-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gimp-developer-list

___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] how can i write gegl plugin ? or http://developer.gimp.org too old

[Michael Henning]

In addition to what Alexandre suggested, take a look at
plug-ins/common/goat-exercise.c
It's a simple example of how to use gegl from within a gimp plugin.

Also, a lot of the new functions do have some reference documentation,
which I think can be built if you pass --enable-gtk-doc to autogen.

Good luck.

   -- drawoc

On Tue, Feb 12, 2013 at 4:34 PM, Alexandre Prokoudine
alexandre.prokoud...@gmail.com wrote:
 On Wed, Feb 13, 2013 at 12:37 AM, Miroslav Talasek wrote:
 Hi i like gimp i use only it.
 I want to write alpha matting. I know that gegl library contain alpha
 matting from Jan Ruegg but it is still only in gegl (one year or more). I
 want to write plugin with two combo boxes (image and trimap selection) which
 call matting from gegl, but i cant find anything recent help/doc/tutorial.

 This is the way to hell,   http://developer.gimp.org is too old so how new
 developers start with gimp ? Where is recent doc to plugin api (with gegl) ?
 I want but i cant :(

 Simply put, there is none yet. GEGL-based GIMP plug-ins are a novelty,
 and as a small team we don't have the manpower to update dev
 documentation all that often.

 What you can do is:

 1) study what changes have been applied to the plug-ins that we ported
 to use GeglBuffer, e.g.
 http://git.gnome.org/browse/gimp/commit/plug-ins/common?id=07107fe214feaebf42dfa129fa3681c1e7b9bfd8
 2) ask us questions on IRC.

 Alexandre Prokoudine
 http://libregraphicsworld.org
 ___
 gimp-developer-list mailing list
 gimp-developer-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gimp-developer-list
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Cairo Issue

[Michael Henning]

I think this is a cairo bug. I filed a bugreport on their bugtracker:
https://bugs.freedesktop.org/show_bug.cgi?id=60519

   -- drawoc

On Wed, Feb 6, 2013 at 8:51 PM, Partha Bagchi parth...@gmail.com wrote:

 A new issue seems to have cropped up. Now I get the following error:

 This is a development version of GIMP.  Debug messages may appear here.

 Assertion failed!

 Program: C:\Win64\msys\opt\gimp-2.9\bin\gimp-2.9.exe
 File: ../../src/cairo-surface.c, Line 591

 Expression: image-is_clear

 I recall recently Mitch committed some cairo patches, but I can't find it.

 I can fix the above by modifying cairo-surface.c but I think there may be
 a deeper issue?

 Thanks,
 Partha


 ___
 gimp-developer-list mailing list
 gimp-developer-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gimp-developer-list

___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] cairo 1.12.10-1 not working with GIMP 2.8 or 2.9

[Michael Henning]

I think this is a cairo bug, not a gimp bug. It looks like the cairo
people have already bisected the commit, so a fix should likely appear
soon.

phani's thread is here:
http://lists.cairographics.org/archives/cairo/2013-January/023959.html

I can reproduce the problem, btw. (I'm also on arch here.)

  -- drawoc

On Tue, Jan 22, 2013 at 2:00 PM, phani listm...@phanisvara.com wrote:
 On Wed, 23 Jan 2013 00:28:25 +0530, phani listm...@phanisvara.com wrote:

 there's various complaints re. it in this report on the arch bug tracker:
 FS#33511 - [cairo] 1.12.10-1 makes icons go crazy
 https://bugs.archlinux.org/task/33511.


 sorry, wrong bug; i meant this one: FS#33463 - [cairo] 1.12.10 breaks
 Thunar's icons and thumbnails https://bugs.archlinux.org/task/33463


 --
 phani.
 ___
 gimp-developer-list mailing list
 gimp-developer-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gimp-developer-list
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] lcms high bit depth update: now that it works, adding and improving functionality

[Michael Henning]

You misunderstood my idea. I don't want babl to get specific
conversions for different ICC profiles; I want a generic mechanism to
take any ICC profile and turn it into a babl format. Øyvind indicated
that this is similar to how indexed formats already work (take a
palette and turn it into a babl format), so this wouldn't need vast
amounts of new code.

Part of why I suggested this is because it seems much more elegant
than tagging a newly loaded image as, say R'G'B'A when the image is
actually something else, like the code does now.

You can either place your patches on the bugtracker like you said, or
you can jump on irc and ask someone to apply them for you. You
probably want to separate your work out into one patch for each change
you make. (Although, feel free to lump a few small changes together if
they're related - it is possible to go overboard with the separate
into tiny patches mentality.)

  -- drawoc

On Sat, Jan 12, 2013 at 7:43 AM, Elle Stone l.elle.st...@gmail.com wrote:
 On 11/29/12, Øyvind Kolås pip...@gimp.org wrote:
 On Fri, Nov 30, 2012 at 7:28 AM, Elle Stone l.elle.st...@gmail.com wrote:
 So gathering the gist of this discussion, it would be useful to add
 the code for 16-bit floating point and 32-bit integer to the lcms
 plug-in?

 And presumably if/when the lcms.c plug-in disappears, this particular
 code could be transferred over (suitably modified, of course) to
 whatever takes its place?

 I do not know the details of GIMP, but if the icc conversion handling
 moves into the GIMP core rather than a plug-in a lot of the code can
 be kept. Maybe what makes most sense is turning the logic of these
 transformations into GEGL operations, (that could be called by the
 GIMP core, or be re-used also outside GIMP). This way we might also
 make the generic image loader in GEGL responsible for inserting color
 conversion operations for its internal graph.). Turning the core-logic
 of the lcms.c plug-in into gegl-ops should be possible in such a way
 that at first GIMPs way of invoking the lcms plug-in continues working
 while the lcms plug-in uses the graph API of GEGL rather than directly
 operating on GeglBuffers.

 Creating custom babl formats for specific ICC profiles is possible,
 and would take a similar form to how babl/GEGL/GIMP currently deals
 with indexed images. With such an option the lcms code would move into
 a babl extension or become part of babl - this might be within the
 scope of babl, but I do like it's scope smaller striving to mostly do
 conversions between different pixel layouts and well defined color
 representations.

 Even if babl could handle many of the more commonly used ICC profiles,
 Gimp/gegl would still need to be able to handle ICC profile
 conversions, because no matter how many specific ICC profiles babl is
 modified to handle, there will still be ICC profiles that babl can't
 handle. Consider custom or odd/unusual RGB working space profiles, the
 plethora of CMYK profiles, and custom input (eg camera, scanner),
 monitor, and output (eg printer) profiles. So it seems like creating
 custom babl formats for specific ICC profiles would mean a lot of
 extra code for babl, and Gimp/gegl would also need additional code to
 check to see whether the requested ICC profile conversion was already
 programmed into babl or not.


 Where can I find the proper babl type for 16-bit floating point and
 32-bit integer? And what are the corresponding gegl iterator babl
 formats for images with and without alpha channels? Is there a list
 somewhere?

 If you click Pixel formats here http://gegl.org/babl/#Vocabulary you
 should get a list of the pixel formats babl has built in. The way
 these formats are expressed are rather consistent; though I do see
 that there could be some improvements to the documentation of how to
 manually decode a format string.

 I looked at http://gegl.org/babl/#Vocabulary but didn't understand it.
 However, adding in support for 16-bit floating point turned out to be
 straightfoward:

   else if (type == babl_type (half))
 {
   if (has_alpha)
 {
   lcms_format = TYPE_RGBA_HALF_FLT;
   iter_format = babl_format (R'G'B'A half);
 }
   else
 {
   lcms_format = TYPE_RGB_HALF_FLT;
   iter_format = babl_format (R'G'B' half);
 }
 }

 How/where do I submit a patch? Should I open an lcms plugin
 enhancement bug report? Does Mitch want sequential small patches that
 make one change at a time? Or does he want a bunch of changes all at
 once?

 I also coded in the ability to assign an ICC profile to a grayscale
 image, and to convert grayscale images from one ICC profile to
 another. Unfortunately the display-filter-lcms.c module disables color
 management for the display of anything other than RGB images. However,
 upon exporting the Gimp-converted grayscale image, krita opens and
 displays the exported image correctly, and the 

Re: [Gimp-developer] Gimp gitsource Gimpcolorwheel.c

[Michael Henning]

You probably recently got an automake upgrade. This causes make to
ignore all changes to *.am files, and print a tiny warning at the top
of its output that nobody notices or reads.

Do git clean -xdf, then reconfigure + make, and all should be okay.

  -- drawoc

On Sun, Jan 6, 2013 at 3:40 PM, Partha Bagchi parth...@gmail.com wrote:
 Unless I am doing something wrong, gimpcolorwheel.c is missing from
 color-selector-wheel.lo

 Thanks,
 Partha


 ___
 gimp-developer-list mailing list
 gimp-developer-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gimp-developer-list

___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Exposure Operation

[Michael Henning]

This looks good.

The meta-op isn't really the right way to do things like this, so feel
free to trash that.

As for the point filter, you should make a git commit, and then use
git format-patch to make a patch.
Then, you can get your patch included in GEGL by either bothering
people on irc to review the patch (that's the fastest), or filing a
bug report.

The gamma value thing is just a matter of convention - if you apply a
gamma of x, then applying a gamma of 1/x will undo the change. I'm not
sure which is preferred (avoiding taking the reciprocal should have
slightly more numerical precision, and avoid dividing by zero.)

You might want to discuss vectorizing your ops with mitch or pippin
before you put a lot of work into it. If it decreases portability, it
might be better to leave the code as is and hope the compiler
autovectorizes.

If you have any questions/comments, feel free to hop on IRC and ask.

  -- drawoc

On Tue, Dec 18, 2012 at 3:03 PM, Felix Ulber f.ul...@web.de wrote:
 Hi all,
 I post this at the gimp-dev list cause I think more people read here and
 this is closely related to the progression of the Gimp Application itself,
 even if the core of all is GEGL.

 Being excited about the new high-bit depth capability I wrote an exposure
 operation. It is somehow inspired by the equal-named photoshop operation. A
 short explanation for anyone not that familiar with the use of it: This
 operation is mainly important for manipulating hdr images, i.e. floating
 point images containing values  1. Working with such images, most of the
 well-known operations (e.g. curves) doesn't work at all or at least don't
 really make sense as they are based on the assumption the image is in an
 absolute 0..1/black-white domain.

 The exposure operation has three components, that are applied in the
 following order:

 Exposure:   a multiplier, the usual way to manipulate a hdr images'
 brightness. This is implemented as a relative change, i.e. in a logarithmic
 way (like f-stops)
 Offset: a constant value added, this can be used to shift the
 black-level
 Gamma:  gamma-correction. In this case used to influence the mid-range
 values

 To summarize the components of the operation:

 out_val = in_val * (2^exposure)
 out_val += offset
 (clamp value to 0.0 because might have become negative)
 out_val = out_val^(1/gamma)

 Some more reading:

 http://www.earthboundlight.com/phototips/photoshop-cs2-exposure-adjustments.html
 http://www.francois-tarlier.com/blog/exposureoffsetgamma-photoshop-tool-to-shaders/


 This is one of my first things in gegl, so some questions came up, also some
 issues ihmo worth a discussion:

 As result values are not clamped in the positive direction, some thoughts
 about the parameters that are worth thinking about:

 Gamma parameter is restricted to a range of 0.01 to 10 for now. Some
 confusion came up about gamma calculation, cause I am sure gamma is
 pow(value, 1/gamma), but e.g. gegl:gamma operation use it without the
 inversion, also some other applications.

 Gain is not restricted for now, but cause it's exponential values get pretty
 high, soon exceeding MAX_FLOAT. In Photoshop, pixel values seem to be
 generally clamped to a value of 20 (or is just the palette no able to
 display more?) which seem a little bit to restricted to me. Especially in
 case of sunny day images (e.g. HDRI Sphere for cgi rendering).

 With negative offset values, negative pixel values may occur. This is
 normally not wanted and in some cases the reason certain filters are not
 suited well for hdr images. Values are getting clamped at 0.0 atm, but I
 cannot say that I am glad with that. Any suggestions on that?

 For my own interest I implemented this thing both as a gegl meta-operation
 and as a GeglOperationPointFilter operation. Apart from the fact, that doing
 things like pow(2, value) is already kinda wicked in a GEGL graph, I was
 really asking myself if the meta operation makes any sense at all
 speed-wise. Because this contains 5 to 6 nodes (without i/o).

 Next thing for me is to make the main code use vectorization.


 Code is here:

 http://pastebin.com/xYQYYXqX
 http://pastebin.com/Rq5HWhbF


 thanks for your interest
 Felix (aka. kjaft)



 ___
 gimp-developer-list mailing list
 gimp-developer-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gimp-developer-list

___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Development environment

[Michael Henning]

 Q: What is the tool that you use for Gimp development (ex: Vim, Emacs,
 Eclipse, Netbeans, Anjuta, ...)?

I use gedit and xterm, and then just alt-tab between them.

All revision control for me is done on the command line. Sometimes I
open up separate terminals for git-related stuff and for
building/testing.

$EDITOR is set to nano, which git uses for text editing.

Using a command line pastebin client can also be very useful at times.

 Q: Does your development environment support direct compilation (answer Yes
 or No)? If so please explain how in the note (e.g. IDE/editor feature or
 with plugin x, script y, ...).

I always build using the terminal.

(Gedit has a plugin to run arbitrary commands when you press certain
shortcut keys, but I don't use it.)

 Q: Does your development environment support code completion (answer Yes or
 No)? If so please explain how in the note (e.g. IDE/editor feature or with
 plugin x, script y, ...).

No. I've used IDE's that did this before, and found that automatic
features like this don't really help me much - a lot of the time if
the IDE tries to be smart, it just pisses me off and does something
I don't want it to.

I'd rather just type the code myself.

 Q: Does your development environment support documentation browser? (answer
 Yes or No)? If so please explain how in the note (e.g. IDE/editor feature or
 with plugin x, script y, ...).

I use firefox for documentation, in a separate workspace.

If I can't find something about the gimp or gegl api, I normally just
git grep for related code (function definitions, similar code, etc)
and read that until I find what I need to know.

 Q: Does your development environment support debugging? (answer Yes or No)?
 If so please explain how in the note (e.g. IDE/editor feature or with plugin
 x, script y, ...).

I use gdb in a terminal for that. For memory bugs I use valgrind.

 Q: Does your development environment support code refactoring? (answer Yes
 or No)? If so please explain how in the note (e.g. IDE/editor feature or
 with plugin x, script y, ...).

Sometimes I use find and replace within gedit. Not sure if that counts.

See answer about smart IDE's above.

 Q: Does your development environment support Bugzilla integration? If so
 please explain how in the note (e.g. IDE/editor feature or with plugin x,
 script y, ...).

I use firefox for bugzilla.

 Q: What are the special benefits of your development environment?

Simple to setup. Simple to get used to.

If you decide you don't like one specific component, you can swap it
out for another.

It starts up instantly.

 Q: What are you still missing?

Like elle, I'd like it if I could get gedit to have groups of
documents and open/close all of them at once.

gedit could also use a Save All button.

It's possible that there are extensions for this stuff, but I'm too
lazy to go looking for them.

 Q: Which additional comments do you have?

I've heard people say before that IDE's aren't popular among linux
users because on linux the entire OS fills the role of an IDE. I
couldn't agree more.

I like it when each application fills a single purpose instead of
having one app (an IDE) that tries to do everything well.
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] lcms high bit depth update: now that it works, adding and improving functionality

[Michael Henning]

As mitch and I discussed on irc, as the plan stands right now, the
GIMP won't have any working color profile.

Going forward, AFAIK, the image-mode-assign/convert color profile
menu entries should be removed from the lcms plugin, and everything
automatically converted to srgb/R'G'B' on import.

I think the best design in the end would be for babl to eventually get
icc profile support itself. Then different loader plugins could simply
tag their data with a babl format created using the icc profile, and
all the conversions would happen without a plugin stepping in.

 -- drawoc

(Øyvind: Just to be sure - it's sane to store srgb data with the babl
format R'G'B', right?)

On Wed, Nov 28, 2012 at 7:10 PM, Øyvind Kolås pip...@gimp.org wrote:
 On Thu, Nov 29, 2012 at 10:36 AM, Nicolas Robidoux
 nicolas.robid...@gmail.com wrote:
 It is my opinion that XYZ is not fully replaced by infinite gamut linear RGB
 if only because XYZ has a channel which is a proper luminance channel. RGB
 does not.

 Enough to deserve a place within GIMP? Don't know. If my (initial) inputs
 and (final) outputs are sRGB, linear RGB with sRGB primaries is a better all
 around choice. But not a full replacement when you use nonlinear filtering.

 Enough to deserve a place in babl/GEGL, but I think the ways they are
 going to be used (by image processing algorithms) is well enough
 covered without explicitly storing / confronting the user with an XYZ
 image mode.

 /Ø
 ___
 gimp-developer-list mailing list
 gimp-developer-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gimp-developer-list
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] A letter of complaint

[Michael Henning]

On Mon, Jul 23, 2012 at 11:37 PM, Akira Tanaka artfoundr...@yahoo.com wrote:

 Sorry if I was a wee bit too harsh about GIMP. I was in a bad mood that
 morning.

 Yeah, I've heard a lot of horror stories about Windows ME. Never had the
 (dis)pleasure of using it but I suppose...

Well, that's understandable. Everyone has a bad day every once in a
while. We'd appreciate it if you didn't take it out on us though - we
really are trying to make a good image editor.

If you can imagine, we certainly don't intend the GIMP to crash. Now
that you're in a better mood, if you were to post a message with more
details on the problem and less yelling, we might be able to help you
out.

(Though if you really do want to stick with the I will never use GIMP
software again for as long as I live thing, then that's also fine -
it's no skin off my teeth.)

Make sure you include the version of the GIMP you're using, what
operating system you're using, anything in specific that seems to
trigger the crash, and any other details you can think of.

You also might want to start a new thread - there are probably several
people ignoring this one.

-- drawoc

P.S. You forgot to hit reply all, so your last message didn't get
sent to the mailing list.
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] A letter of complaint

[Michael Henning]

 GIMP is, without a doubt, the most unreliable, poorly programmed,
 pathetic excuse for a software program ever conceived by a human being.

I suppose you've never used Windows ME

**shudder**
Just typing the name brings back memories.

I won't forget Windows ME.

I'll never forget.

Sometimes I get these nightmares where I turn on my computer and see
that  Windows ME startup screen again. I wait for hours for it to
boot, idly staring at the logo, mezmerized endlessly by that eternal
logo, and then finally...

BSOD!

I wake up screaming. I run to my computer, hit power, and am relieved
when the GRUB boot menu appears.

The screen no longer displays BSOD's, but I can never stop that shade
of blue or the white console text from burning in my mind.

I will be forever traumatized by the blue.

the blue.

That shade of blue.

the blue.

That shade of blue.

the blue.

That shade of blue.

the blue.

That shade of blue.

the blue.

That shade of blue.

the blue.

That shade of blue.

the blue.

That shade of blue.

the blue.

That shade of blue.

the blue.

That shade of blue.

the blue.

That shade of blue.

the blue.

That shade of blue.

the blue.

That shade of blue.

the blue.

That shade of blue.

the blue.

That shade of blue.

the blue.

That shade of blue.

the blue.

That shade of blue.

the blue.

That shade of blue.

the blue.

That shade of blue.

the blue.

That shade of blue.

the blue.

That shade of blue.

the blue.

That shade of blue.

THAT SHADE OF #FF BLUE. IT ETERNALLY BURNS MY MIND. OH GOD IT
DOESNT GO AWAY.

DAMN YOU WINDOWS ME! THAT SHADE OF BLUE! THAT SHADE OF BLUE! AUGH!! FOREVER!!!

ITS PAINFUL. ETERNAL. GOD, HELP ME, ITS STILL BLUE! AUGH!!!

  -- drawoc

the blue.

That shade of blue...
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] gimp 2.8 prohibitively slow

[Michael Henning]

There are a few performance improvements to color management already -
those will be available when 2.8.2 is released.

Look here for more details:
https://bugzilla.gnome.org/show_bug.cgi?id=645345

  -- drawoc

On Wed, Jul 18, 2012 at 12:30 PM, Vladimir Savic
vladimir.firefly.sa...@gmail.com wrote:
 On 07/18/2012 04:55 PM, Guillermo Espertino (Gez) wrote:

 On 18/07/12 10:45, Aaron Paden wrote:



 You can try turning off color management in your preferences (there's a
 bug in GIMP 2.8 that makes painting tools and selection widgets slower
 when color management is active)


 That actually works! Turning off Color management does increase performance.
 Can we expect this bug to be fixed in 2.8.x?


 and you can try with different tile
 memory settings but I'm afraid your system specs are low for high
 resolution painting in a program like GIMP.

 hth,

 Gez.


 ___
 gimp-developer-list mailing list
 gimp-developer-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gimp-developer-list
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] Multiply blend mode in GIMP

[Michael Henning]

Each pixel component has a value somewhere between 0 and 255. When you
multiply two together, it will have a value somewhere between 0 and
65,025 (255 squared). You need to divide by 255 so that maximum value
gets scaled back down to 255 (If you simply clamp it, the majority of
your pixels will be white).

Of course, when working with doubles or floats, 1.0 is normally the
maximum (Non-HDR) value, so no division is needed.

Hopefully that clears things up.
  -- drawoc

On Mon, Jul 9, 2012 at 3:21 PM, Calculemus calculemus1...@gmail.com wrote:
 I am reading this: docs.gimp.org/en/gimp-concepts-layer-modes.html

 and I wonder why is the formula for Multiply, E = (M * I) / 255?

 Why divide with 255, that is the part that confuses me.
 Should it not be just M * I and then clamp the result in range 0 to 255?

 Thanks

 ___
 gimp-developer-list mailing list
 gimp-developer-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gimp-developer-list

___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] (no subject)

[Michael Henning]

I can still reproduce this on latest master
(5835a730a3eef3cee579c50b250bb8ba15b77d7c), using the images that are
available for download at the bottom of that page.

Strangely, if you open the 16 bit tiff, and choose not to convert it
into the sRGB builtin colorspace, the image still displays with the
wrong gamma on canvas, but the thumbnail on the tab in single window
mode looks correct to me.

  -- drawoc

On Tue, Jun 19, 2012 at 10:05 AM, Simon Budig si...@budig.de wrote:
 Elle Stone (l.elle.st...@gmail.com) wrote:
 (4) Although Gimp 2.9 correctly opens 8-bit tiffs, when opening any
 16-bit tiff, the image is subjected to a roughly gamma=2.2 curve. All
 RGB colors are altered (it's not just a display problem), so the
 resulting image is too light.

 Hmm, I am not fully sure what is the right thing to do there. On June
 6th I did a change to the TIFF loading code, ensuring that the samples
 in the TIFF get treated as linear. Did you do your tests before or after
 that date?

 Thanks,
        Simon
 --
              si...@budig.de              http://simon.budig.de/
 ___
 gimp-developer-list mailing list
 gimp-developer-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gimp-developer-list
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list