Re: [Gimp-developer] Upgraded palette-sort.py plugin

2012-11-05 Thread David Gowers
I've finished making updates and have attached the latest version to the
bugreport https://bugzilla.gnome.org/show_bug.cgi?id=687552 . I'm happy
with the current functionality.

A screencast explaining the new functionality is available (47 minutes, 4
parts):

(in order:)
http://youtu.be/_8e5Uvhn6vs
http://youtu.be/Nb4mNs-2ARo
http://youtu.be/_1UprDMsPlw
http://youtu.be/p_NlcsTzmfk

The only material not covered in the screencast is the Index and Random
'channels', which were added after making that screencast. They are pretty
self-explanatory, but there's a short explanation of them in the
description of part 4 of the screencast.


On Sun, Nov 4, 2012 at 10:31 PM, David Gowers 00a...@gmail.com wrote:

 Done. I have a few more upgrades to make before it's finished, though --
 sorting a slice of the palette could be much easier in the common case.



 On Sun, Nov 4, 2012 at 2:17 PM, Joao S. O. Bueno gwid...@mpc.com.brwrote:

 There is no need putting this in the plug-in registry - since the
 paltete sort is a plug-in in the
 main GIMP tree.

 Your changes are welcome improvements - and we shoudl manage to merge
 them in for GIMP 2.10  -
 meanwhile you could attach both your version of the plug-in and a diff
 against what is
 GIMP master (or gimp2.8 if you dn't have master - it had not changed)
 - in a gimp bugzilla issue.

 (That way, people wanting to get the newer version before gimp 210 is
 out could just download it from there)


   js
  --


 On 3 November 2012 10:33, David Gowers 00a...@gmail.com wrote:
  Hi,
  I got tired of being unable to get any use out of the 'sort palette'
 plugin
  and made some major upgrades. I'm not quite ready to say this is 'done'
 yet
  -- it has some UI that I'm thinking about changing -- but it's fully
  functional and much more effective than the old plugin. Attached.
 
  These improvements include:
 
  * General cleanups (eg. don't use old python conventions like cmp
 functions)
 
  * Support for sorting by luma aka Y, S of HSL, L of HSL
 
  * If you have 'colormath' module installed, support for sorting by L of
  LAB/LCH, A of LAB, B of LAB, Chroma of LCH(ab), or Hue of LCH(ab).
 These are
  generally superior to their HSV/HSL/YIQ counterparts; I use them
  exclusively.
 
  * Option to sort only a selected slice of the palette (for example a
 color
  ramp that has become disorganized)
 
  * Option to quantize the sorting (so eg. you can sort into 6 distinct
 hue
  categories rather than 360.). Useful for subdividing the palette into
  sections.
 
  * Option to automatically find and sort individual 'partitions' (blocks
 of
  'constant' value in a given channel, after they are quantized.), in
 either
  the entire palette or a selected slice of it. Useful for sorting say 16
  different categories of Hue by Lightness -- each partition's contents
 are
  individually sorted, so this is quite different from what you get if you
  sort first by Hue and then by Lightness (with no partitioning).
 
 
  An example of usage:
  Starting from this palette:
 
  http://i.imgur.com/CH7JF.png
 
  I first sort the entire palette by LCH hue, so that the partitioning
 works
  best:
 
  http://i.imgur.com/YNmt7.png
 
  Then sort by LAB with LCH Hue partitioning(granularity 16):
 
  http://i.imgur.com/DXgVW.png
 
  The result is this palette, ordered along two dimensions:
 
  http://i.imgur.com/tGPjV.png
 
 
  I would have also posted this to the Plugin Registry, but I haven't
 figured
  out how!
 
  Feedback is welcomed (I hope I'm still subscribed to gimp-developer ;)
 
 
  ___
  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] Upgraded palette-sort.py plugin

2012-11-04 Thread David Gowers
Done. I have a few more upgrades to make before it's finished, though --
sorting a slice of the palette could be much easier in the common case.


On Sun, Nov 4, 2012 at 2:17 PM, Joao S. O. Bueno gwid...@mpc.com.br wrote:

 There is no need putting this in the plug-in registry - since the
 paltete sort is a plug-in in the
 main GIMP tree.

 Your changes are welcome improvements - and we shoudl manage to merge
 them in for GIMP 2.10  -
 meanwhile you could attach both your version of the plug-in and a diff
 against what is
 GIMP master (or gimp2.8 if you dn't have master - it had not changed)
 - in a gimp bugzilla issue.

 (That way, people wanting to get the newer version before gimp 210 is
 out could just download it from there)


   js
  --


 On 3 November 2012 10:33, David Gowers 00a...@gmail.com wrote:
  Hi,
  I got tired of being unable to get any use out of the 'sort palette'
 plugin
  and made some major upgrades. I'm not quite ready to say this is 'done'
 yet
  -- it has some UI that I'm thinking about changing -- but it's fully
  functional and much more effective than the old plugin. Attached.
 
  These improvements include:
 
  * General cleanups (eg. don't use old python conventions like cmp
 functions)
 
  * Support for sorting by luma aka Y, S of HSL, L of HSL
 
  * If you have 'colormath' module installed, support for sorting by L of
  LAB/LCH, A of LAB, B of LAB, Chroma of LCH(ab), or Hue of LCH(ab). These
 are
  generally superior to their HSV/HSL/YIQ counterparts; I use them
  exclusively.
 
  * Option to sort only a selected slice of the palette (for example a
 color
  ramp that has become disorganized)
 
  * Option to quantize the sorting (so eg. you can sort into 6 distinct hue
  categories rather than 360.). Useful for subdividing the palette into
  sections.
 
  * Option to automatically find and sort individual 'partitions' (blocks
 of
  'constant' value in a given channel, after they are quantized.), in
 either
  the entire palette or a selected slice of it. Useful for sorting say 16
  different categories of Hue by Lightness -- each partition's contents are
  individually sorted, so this is quite different from what you get if you
  sort first by Hue and then by Lightness (with no partitioning).
 
 
  An example of usage:
  Starting from this palette:
 
  http://i.imgur.com/CH7JF.png
 
  I first sort the entire palette by LCH hue, so that the partitioning
 works
  best:
 
  http://i.imgur.com/YNmt7.png
 
  Then sort by LAB with LCH Hue partitioning(granularity 16):
 
  http://i.imgur.com/DXgVW.png
 
  The result is this palette, ordered along two dimensions:
 
  http://i.imgur.com/tGPjV.png
 
 
  I would have also posted this to the Plugin Registry, but I haven't
 figured
  out how!
 
  Feedback is welcomed (I hope I'm still subscribed to gimp-developer ;)
 
 
  ___
  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


[Gimp-developer] 'Select all'/Feather causes segfault in histogram code

2012-08-17 Thread David Gowers (kampu)
Hi,
Select all, or Feather, causes gimp-2.9 to segfault inside the histogram code.
Which of the two it is, varies. A bit of messing around invoking free
select tool, Select menu items, or sometimes just Magic Wand will
immediately cause a crash.

I'm getting the impression that something's tiles get lost (and don't
invoke an immediate error condition) at some point prior to the crash,
because on occasion when using the free select tool, GIMP suddenly
starts acting as if there is no selection, no matter what I do.

Here's a stack trace:

#0  0x7fa1d5199d67 in waitpid () from /lib/libpthread.so.0
#1  0x7fa1d53c5f03 in g_on_error_stack_trace () from /lib/libglib-2.0.so.0
#2  0x7fa1d53c604f in g_on_error_query () from /lib/libglib-2.0.so.0
#3  0x0047e94d in gimp_eek ()
#4  0x0047eaf5 in gimp_fatal_error ()
#5  0x0047f06e in gimp_sigfatal_handler ()
#6  signal handler called
#7  0x006738fb in gimp_histogram_calculate ()
#8  0x0066640d in gimp_drawable_calculate_histogram ()
#9  0x00573b14 in gimp_histogram_editor_validate ()
#10 0x00573b3e in gimp_histogram_view_expose ()
#11 0x7fa1d9524d79 in ?? () from /lib/libgtk-x11-2.0.so.0
#12 0x7fa1d5ab4ec0 in g_closure_invoke () from /lib/libgobject-2.0.so.0
#13 0x7fa1d5ac5f40 in ?? () from /lib/libgobject-2.0.so.0
#14 0x7fa1d5acdadb in g_signal_emit_valist () from /lib/libgobject-2.0.so.0
#15 0x7fa1d5ace052 in g_signal_emit () from /lib/libgobject-2.0.so.0
#16 0x7fa1d963c75e in ?? () from /lib/libgtk-x11-2.0.so.0
#17 0x7fa1d9523760 in gtk_main_do_event () from /lib/libgtk-x11-2.0.so.0
#18 0x7fa1d918184c in ?? () from /lib/libgdk-x11-2.0.so.0
#19 0x7fa1d91817f3 in ?? () from /lib/libgdk-x11-2.0.so.0
#20 0x7fa1d917c7f7 in ?? () from /lib/libgdk-x11-2.0.so.0
#21 0x7fa1d917e9a1 in gdk_window_process_all_updates ()
#22 0x7fa1d917ea09 in ?? () from /lib/libgdk-x11-2.0.so.0
#23 0x7fa1d915c637 in ?? () from /lib/libgdk-x11-2.0.so.0
#24 0x7fa1d53ee475 in g_main_context_dispatch () from /lib/libglib-2.0.so.0
#25 0x7fa1d53ee7a8 in ?? () from /lib/libglib-2.0.so.0
#26 0x7fa1d53eeba2 in g_main_loop_run () from /lib/libglib-2.0.so.0
#27 0x0047e569 in app_run ()
#28 0x0047e1f0 in main ()

I'm refraining from posting this to bugzilla cause I have no idea
whether it's trivial, something already known that's gonna be fixed in
due course, or what. Which of those it looks like, I'd like to know
though.

David (hoping he's still subscribed to the gimp-dev list)
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list


Re: [Gimp-developer] What happened to daily digests in Gimp mailing lists?

2012-04-02 Thread David Gowers (kampu)
Hi Howard,

On Tue, Apr 3, 2012 at 10:10 AM, Howard Caluma hao.cal...@gmail.com wrote:
 Is there a way to make the mails sent to me appear as daily digest?
Yes. It's in your subscription options in the mailman web interface.

 Another problem is that
 some replies are deleted, separated or not shown to me but is only received
 by author of the topic. Is it in the reply and reply to all?
What you mean is not clear, but, yes, if you happen to hit reply
rather than reply to all, then the email goes only to the person you
are replying to and not to the mailing list.
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list


Re: [Gimp-developer] [GIMP] Question on linear and radial gradient

2012-03-01 Thread David Gowers (kampu)
On Thu, Mar 1, 2012 at 10:40 PM, Forsale Zhangjiang
forsale_zhangji...@yahoo.com wrote:
 Hello experts,

 I am confused by the callsĀ -gimp_linear_gradient and -gimp_radial_gradient
 used in GIMC. My question is, what are their functions respectively?

You'll have to ask the author of G'MIC -- those are functions defined
in GMIC, not GIMP.
If I look in ~/.gmic_def.1500, i can find the following code:

#@gimp Linear gradient : gimp_linear_gradient, gimp_linear_gradient
#@gimp : Starting color = color(0,0,0,255)
#@gimp : Ending color = color(255,255,255,255)
#@gimp : Swap colors = bool(0)
#@gimp : Angle = float(45,0,360)
#@gimp : Fade start = float(0,0,100)
#@gimp : Fade end = float(100,0,100)
#@gimp : sep = separator(), note = note(smallAuthor : iDavid
Tschumperl#233;/i.  Latest update :
i2010/12/29/i./small)
gimp_linear_gradient :
  -repeat @#
({w},{h}) -rm[-2]
($1^$2^$3^$4) ($5^$6^$7^$8)
-if $9 -rv[-2,-1] -endif
-r[-2,-1] @-3 -rm[-3]
-fade_linear $10,$11,$12
  -mv[-1] 0 -done

#@gimp Radial gradient : gimp_radial_gradient, gimp_radial_gradient
#@gimp : Starting color = color(0,0,0,255)
#@gimp : Ending color = color(255,255,255,255)
#@gimp : Swap colors = bool(0)
#@gimp : Fade start = float(0,0,100)
#@gimp : Fade end = float(100,0,100)
#@gimp : X-center = float(50,0,100)
#@gimp : Y-center = float(50,0,100)
#@gimp : sep = separator(), note = note(smallAuthor : iDavid
Tschumperl#233;/i.  Latest update :
i2010/12/29/i./small)
gimp_radial_gradient :
  -repeat @#
({w},{h}) -rm[-2]
($1^$2^$3^$4) ($5^$6^$7^$8)
-if $9 -rv[-2,-1] -endif
-r[-2,-1] @-3 -rm[-3]
100%,100% -=[-1] 1,$12%,$13% -distance[-1] 1 -_fade $10,$11
  -mv[-1] 0 -done
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list


Re: [Gimp-developer] Filtering image on parameter change

2012-02-12 Thread David Gowers (kampu)
On Mon, Feb 13, 2012 at 10:40 AM, Grzegorz Karch
grzegorz.ka...@gmail.comwrote:

 Hi,

 I'm working on a plugin for which I would like to have the image refreshed
 every time the user changes some parameter in the dialog. That is, instead
 of viewing changes in the preview window, I wouId like to see them in the
 working space, just like in the case of Brightness-Contrast filter (or any
 other in Colors menu). Could you give me any hints on which functions I
 need to use? Or is there any relevant example? I tried to look into the
 source code (gimpbrightnesscontrasttool.c, for instance) but I couldn't
 make head nor tail of it...

 The tools do that automatically cause they're tools.
Plugins don't and more-or-less can't. You'd be better off implementing your
plugin as a GEGL op that GIMP can access (I don't recall offhand whether
GIMP supports whatever ops are installed minus a blacklist, or just a fixed
list of ops.); then you would get this behaviour through the GEGL tool.
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list


Re: [Gimp-developer] image modes and indications

2012-01-26 Thread David Gowers (kampu)
On Fri, Jan 27, 2012 at 3:30 PM, c55 inator c55ina...@gmail.com wrote:

 Error messages and warnings in the status bar are incredibly easy to
 ignore... I would suggest something like pixelmator [screen 
 capture]http://cl.ly/3D16450D2W2k2H2J042I,
 which displays overlays on the canvas [here shown with keyboard shortcuts,
 but the same model can be applied to other notifications].  Displaying
 information with on-canvas pop-ups like this works well in my experience,
 as they don't waste any screen space while being there when needed.  Example
 of a pop-up used for dimensions http://cl.ly/2N3O141d3u3h1U3M1B40.


I'm in favor of this general model. MyPaint has recently got canvas
overlays, and they're, so far, used to display zoom level changes. I find
them both very readable, noticable, and also non-obtrusive. I think a lot
of the instructions and information we currently put in the status bar
could be usefully moved to an overlay -- tool usage instructions are a
prime example, look at the paths tool for an example of something that'll
really benefit hugely; and 'wrong mode' info is something I have to deal
with a fair bit, it would also be good there.

One other thing is, if we are going to be informing the user that the image
mode is wrong, we should offer them a chance to easily correct it.
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list