Re: [Gimp-developer] Layer Groups

2008-03-24 Thread Joseph Miller
I apologize that I did not make this fully clear when I sent this to the
list.  I have had people ask questions about the usablity of this script.
This script is ugly and cumbersome.  It is not made to be very robust and it
does little error checking.  It is clunky and not designed to be integrated
into a release of The Gimp.  It's only purpose is for people who, in the
interim where native layer groups are not available, need this functionality
or that it would greatly speed their graphics process.  I do not mean for
this to become a full-featured solution.

-Joseph

On Fri, Mar 21, 2008 at 3:38 PM, Joseph Miller [EMAIL PROTECTED]
wrote:

 Hello,
 I am new to this list.  I have been in need of layer groups and I couldn't
 find any GIMP functionality to use them the way I needed to.  Maybe this is
 in development for a later version of GIMP or a version I don't have.  I'm
 running 2.4.2 on Ubuntu Gutsy.  I have written a Script-Fu plugin which
 will fudge this functionality.  It groups layers by the first word in their
 name.  Please forgive my programming, you'll see I'm horrific at best with
 Script-Fu.  It's slightly messy, but should be pretty readable and may be a
 great start for someone else looking at this functionality as well.  I look
 forward to your comments.  You can download the script at

 http://www.calcmaster.net/personal_projects/gimp/

 -Joseph

___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


[Gimp-developer] Feature idea for GSoC - Separate+ Plugin integration.

2008-03-24 Thread Guillermo Espertino
First of all, sorry if this is the wrong place or moment to post this.
II think that integrating the separate+ plugin to Gimp would be a great 
GSoC project. The lack of CMYK color has been a longstanding request and 
this plugin is the only tool that approaches that possibility atm.
It would be very useful to have the plugin integrated to the open and 
save dialogs, adding lzw compression to the output, improving the 
usability/accesibility of the plugin interface, etc.
More complex enhancements would be: adding extra options for separation 
(black generation, UCR and GCR, point gain, curves, etc).
This would be really useful for print people and would -imo- stop a 
little the crying for native CMYK in gimp, giving more time to focus in 
porting to GEGL to finally reach that goal, maybe with less of the 
repetitive noise of people's ranting.

Regards,
Gez.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Feature idea for GSoC - Separate+ Plugin integration.

2008-03-24 Thread Sven Neumann
Hi,

On Mon, 2008-03-24 at 13:34 -0300, Guillermo Espertino wrote:
 First of all, sorry if this is the wrong place or moment to post this.
 II think that integrating the separate+ plugin to Gimp would be a great 
 GSoC project.

Doesn't sound like it would be worth making this a GSoC project. In
particular because that would mean that it would definitely not make it
into GIMP 2.6.

As far as I can see all that is needed for integration of the seperate+
plug-in is someone who volunteers to review the code and the user
interface and to propose it for inclusion on this list. As we wanted to
have this plug-in in 2.4 already, I wonder why this has still not
happened yet.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Feature idea for GSoC - Separate+ Plugin integration.

2008-03-24 Thread Sven Neumann
Hi,

On Mon, 2008-03-24 at 18:01 +0100, Sven Neumann wrote:

 As far as I can see all that is needed for integration of the seperate+
 plug-in is someone who volunteers to review the code and the user
 interface and to propose it for inclusion on this list.

An alternative that we should consider would be to integrate the
functionality into the TIFF save plug-in. But I will leave it up to
whoever evaluates and proposes the plug-in here to consider this option.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Porting colormap editor to Cairo

2008-03-24 Thread Olof-Joachim Frahm
Sven Neumann wrote:
 next time, please reply to the list instead of only responding to my
 email address. We should keep this discussion on the list.
I hope this time my client does the right thing, *grr*

 This would be a little bit ugly though. Perhaps with some more
 refactoring, a cleaner solution can be found.
One thing what could be done is representing the current colormap as a
palette and therefore as a entry in the list of palettes. That would be
quite similiar to the four internal gradients, only that it requires a
bit more support (the colormap has no named entries, reflecting the
changes on the palette to the actual colormap for the image, and so on).
The colormap editor wouldn't be necessary anymore.
I'd think this is useful because it eliminates one additional dialog and
fits more with the rest of the palette system, plus maybe other
special palettes could be implemented.

Regards,
Olof


pgp3Ij7UhLclY.pgp
Description: PGP signature
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Feature idea for GSoC - Separate+ Plugin integration.

2008-03-24 Thread Joao S. O. Bueno
Hi Guillermo,

On Mon 24 Mar 2008 14:01:00 Sven Neumann wrote:
 Hi,

 On Mon, 2008-03-24 at 13:34 -0300, Guillermo Espertino wrote:
  First of all, sorry if this is the wrong place or moment to post this.
  II think that integrating the separate+ plugin to Gimp would be a great
  GSoC project.

 Doesn't sound like it would be worth making this a GSoC project. In
 particular because that would mean that it would definitely not make it
 into GIMP 2.6.

 As far as I can see all that is needed for integration of the seperate+
 plug-in is someone who volunteers to review the code and the user
 interface and to propose it for inclusion on this list. As we wanted to
 have this plug-in in 2.4 already, I wonder why this has still not
 happened yet.


So, adding on to this  - while only reviewing the code and the UI might be 
much less than expected for a whoe GSoC project, I perceive this as a 
valuable idea.

Maybe adding to this review the implementation of some, or even more, 
of the features suggested could do for a Google Summer of Code.

Guillermo, I would encourage you towards formalizing this application -
try to summarize objectively what exists today and what do you plan to 
implement. Also, try some guestimates  on a time frame for completing 
each task. 

The idea, bellow, of integrating it to the GIMP TIFF save plug-in is great and 
would make it really feel like part of GIMP. So, take a look at GIMP's TIff 
plug-in and giver your say on it.

And of course, the separate plug-in should take into account ICC color profile 
magement, as implemented in the GIMP core (I reall don't know if it aready 
does that).

And least - have in mind that the chances of approval depend very much on a 
favorable review of your proposal by the GIMP developers. You got  some 
critics on your first e-mail,  and some ideas as well. So use those in your 
favor and come up with a propose everyone here should like.

regards,
js
--

 Sven

 On Mon, 2008-03-24 at 18:01 +0100, Sven Neumann wrote:
  As far as I can see all that is needed for integration of the seperate+
  plug-in is someone who volunteers to review the code and the user
  interface and to propose it for inclusion on this list.

 An alternative that we should consider would be to integrate the
 functionality into the TIFF save plug-in. But I will leave it up to
 whoever evaluates and proposes the plug-in here to consider this option.


 ___
 Gimp-developer mailing list
 Gimp-developer@lists.XCF.Berkeley.EDU
 https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] tile ref count balance warning

2008-03-24 Thread Brennan Sellner
On Wed, 27 Feb 2008, Bill Skaggs wrote:
 It isn't tile *allocation* that matters here, it is tile *locking*,
 and locking only happens in one place, tile_lock() in
 app/base/tile.c.  It should be pretty straightforward for
 you to throw some debugging code in there.

 As I wrote before, though, tile locking happens *a lot*.
 Many internal operations lock tiles transiently, and also
 any time tile data is transferred to a plugin, the tile is
 locked during the process.  You might consider experimenting
 with an image small enough to fit entirely within a single
 tile (i.e., less than 64x64), if you are going to play with this
 stuff without getting flooded.

My apologies for the delay; I've had to do quite a bit of travelling 
lately.

As Bill suggested, I instrumented tile_lock().  The coffee stain plugin is 
definitely leaking tiles, and plug_in_gauss_iir appears to be the culprit, 
although I haven't dug any deeper.  Running the coffee stain 
plugin from the UI repeatably results in leaked tiles (the more stains, 
the greater the leak; at least 5 always results in a leak).  I haven't 
been able to cause leaks from the UI by using only Gaussian blur, although 
Liam has apparently observed this.

Unfortunately, I don't have the time (or Scheme experience) to dig 
further.  There doesn't appear to be a Bugzilla bug open for this; shall I 
file one against the plugins component?

Thanks to everyone for the help tracking this down!

-Brennan
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


[Gimp-developer] batch-processing gallery

2008-03-24 Thread Joshua Stratton
I recently setup a proposal for Google Summer of Code that involves a
gallery-style batch processor--a separate window that could display various
sorting routines on images based on brightness, size, energy level, etc.
Images could be grouped into sets that could be batch-processed like having
all the selected or stacked images normalized to filtered with a sepia
effect.  I was wondering if anyone would find this useful.

I know several applications already provide some of this functionality
outside of GIMP, but I believe they can be done better.  For example, Dave's
batch processor provides batch-processing in GIMP in the form of a plugin,
but lacks visual thumbnails of the various images.  Other applications don't
have the cross-platform penetration that GIMP has.


Thanks,
Josh
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer