[Gimp-developer] Running a batch script, failing under cron

2005-04-26 Thread Dov Kruger
We are running a conversion script in gimp 1.2 under RedHat Enterprise
Edition 3. If we run the perl script interactively, it works. However,
when run in cron, it does not, though it worked under cron on another
production server running RedHat 7. It appears that the reason is that
cron fails to find the script, but I cannot prove that. It simply
doesn't do anything in gimp, and returns without any displayed error
message.

Perhaps we should be using 2.0, but installation has always been a
massive headache, and we get incomplete installs due to failures in the
print libraries, the only solution that I got a response about was
building without printing, so I'd prefer to make this work with our
existing setup, unless someone is feeling like being particularly
helpful and resolving this ongoing problem with gimp builds for us.

While we're at it, if you notice any massive inefficiencies in our
script, I'd love to make it run faster, since it is executed 3000 times
a day, soon to be 6000, then 24000.

The following file is the gimp script, which works both under gimp-2.0
and gimp-1.2:

(define
  (dl-png2transindexed2 file)
  (let*
  (
   (img (car 
 (file-png-load 1 file file)
 )
)
   (d (car (gimp-image-active-drawable img)))
   )
(gimp-layer-add-alpha (car (gimp-image-get-active-layer img)))
(gimp-by-color-select d '(255 255 255) 0 2 0 0 0 0)
(gimp-edit-clear d)
(gimp-convert-indexed img 0 0 255 0 0 )
(file-png-save 1 img d file file 0 6 0 0 0 1 1)
(gimp-image-delete img)
)
)
 
(script-fu-register dl-png2transindexed2
Toolbox/Xtns/Script-Fu/png2transindexed2
png2indexed2
Dov Kruger Elena Zagrai
(c) 2004 Stevens Institute of Technology
2004-02-25

SF-FILENAME File file.png
)


A test shell script that illustrates the problem with cron:

#!/bin/sh
echo 'foo'
/usr/bin/gimp --no-splash --console-messages --no-interface -b
'(dl-png2transindexed2 T26nyharaspeedtop.png)' '(gimp-quit 0)'
echo bar


___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


[Gimp-developer] Re: Gimp-developer Digest, Vol 26, Issue 44

2004-11-30 Thread Dov Kruger
I can't subscribe so as to submit a contest entry, probably because of
massive beating on the site Hopefully later on it will come back
Better to just send all submissions to Sven via email ;-) ok, just a
small joke.

D

On Tue, 2004-11-30 at 15:02,
[EMAIL PROTECTED] wrote:
 Send Gimp-developer mailing list submissions to
   [EMAIL PROTECTED]
 
 To subscribe or unsubscribe via the World Wide Web, visit
   http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
 or, via email, send a message with subject or body 'help' to
   [EMAIL PROTECTED]
 
 You can reach the person managing the list at
   [EMAIL PROTECTED]
 
 When replying, please edit your Subject line so it is more specific
 than Re: Contents of Gimp-developer digest...
 
 
 Today's Topics:
 
1. Re: 2.2 splash screen competition (David Neary)
2. Re: Re: 2.2 splash screen competition (Sven Neumann)
3. Re: Re: [Gimp-user] Re: [Gimp-announce] 2.2 splash
   screen competition (Carol Spears)
4. Re: Re: [Gimp-user] Re: [Gimp-announce] 2.2 splash
   screen competition (Manish Singh)
5. Re: 2.2 splash screen competition (David Neary)
6. Re: 2.2 splash screen competition (Manish Singh)
7. Re: 2.2 splash screen competition (David Neary)
8. Re: 2.2 splash screen competition (Manish Singh)
 
 
 --
 
 Date: Tue, 30 Nov 2004 15:34:04 +0100
 From: David Neary [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]
 Subject: [Gimp-developer] Re: 2.2 splash screen competition
 Message-ID: [EMAIL PROTECTED]
 In-Reply-To: [EMAIL PROTECTED]
 References: [EMAIL PROTECTED]
 Content-Type: text/plain; charset=iso-8859-15
 MIME-Version: 1.0
 Precedence: list
 Message: 1
 
 Hi all,
 
 After a false start, the GIMP Splash Contest is now officially
 open!
 
 The contest runs until next Sunday, Midnight. Splash screens
 should be the same size as jimmac's logo and have a pale band
 across the bottom roughly the same size. Otherwise, knock
 yourselves out!
 
 Competition entries should be attached to the live.gnome.org wiki
 page at http://live.gnome.org/GnomeArt_2fGimpSplashContest - you
 will need to create a wiki account. We will definitely have some
 kind of (small) prize sponsored, details will follow during the
 week (but the real reason you are doing it is the glory, right?)
 
 Good luck to everyone! And don't forget, spread the news!
 
 Cheers,
 Dave Neary.
 
 -- 
 David Neary,
 Lyon, France
E-Mail: [EMAIL PROTECTED]
 CV: http://dneary.free.fr/CV/
 --
 
 Date: Tue, 30 Nov 2004 16:06:03 +0100
 From: Sven Neumann [EMAIL PROTECTED]
 To: David Neary [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]
 Subject: Re: [Gimp-developer] Re: 2.2 splash screen competition
 Message-ID: [EMAIL PROTECTED]
 In-Reply-To: [EMAIL PROTECTED] (David Neary's message of Tue,
  30 Nov 2004 15:34:04 +0100)
 References: [EMAIL PROTECTED] [EMAIL PROTECTED]
 Content-Type: text/plain; charset=us-ascii
 MIME-Version: 1.0
 Precedence: list
 Message: 2
 
 Hi,
 
 David Neary [EMAIL PROTECTED] writes:
 
  The contest runs until next Sunday, Midnight. Splash screens
  should be the same size as jimmac's logo and have a pale band
  across the bottom roughly the same size. Otherwise, knock
  yourselves out!
 
 Actually, the band at the bottom doesn't necessarily have to be pale.
 GIMP 2.2 checks the color of the bottom area of the splash and chooses
 a suitable level of gray for the text overlay. The area at the bottom
 should however not have too much contrast or the text will become
 unreadable. Your best bet is that you try to use your image as a
 splash with a GIMP-2.2 pre-release. http://www.gimp.org/about/splash/
 tells you how to do that.
 
 
 Sven
 --
 
 Date: Tue, 30 Nov 2004 09:13:23 -0800
 From: Carol Spears [EMAIL PROTECTED]
 To: Sven Neumann [EMAIL PROTECTED],
   GIMPDev [EMAIL PROTECTED]
 Subject: Re: [Gimp-developer] Re: [Gimp-user] Re: [Gimp-announce] 2.2 splash
   screen competition
 Message-ID: [EMAIL PROTECTED]
 In-Reply-To: [EMAIL PROTECTED]
 References: [EMAIL PROTECTED] [EMAIL PROTECTED]
   [EMAIL PROTECTED] [EMAIL PROTECTED]
   [EMAIL PROTECTED] [EMAIL PROTECTED]
 Content-Type: text/plain; charset=us-ascii
 MIME-Version: 1.0
 Precedence: list
 Message: 3
 
 On Tue, Nov 30, 2004 at 11:11:21AM +0100, Sven Neumann wrote:
  
  I wouldn't wait for this to happen if I was you. The news system
  hasn't been resurrected for several months so I am pretty sure that
  the contest section has a similar unsolveable problem. We should use
  what's available but sorry, the mailing-lists won't work.
  
 from the Changelog.  
 
 2004-11-29  Helvetix Victorinox  [EMAIL PROTECTED]
 
 * Cut over to the new (old) news system.
 
 
 let me see if i can sum up what has happened.  please correct 

[Gimp-developer] Re: High-performance gimping

2004-11-12 Thread Dov Kruger
Thanks to all who responded with useful comments.

It isn't entirely clear from the comments when gimp starts up, but the
tiling cache should indeed be almost as large as physical memory,
allowing some for other uses (such as the OS).

Increasing to 1500Mb on a 2G system was a huge improvement. I have not
sought to tune that number, not doing enough of these to make that
worthwhile. The undo suggestion of Alastair Robinson is also probably
very good for continued manipulation.

As I think the original posting indicated, allowing virtual memory to do
the work, is for whatever reason not the answer.

I suggest modifying the documentation to read something like:

Increasing tile memory cache will continue to yield benefits until you
totally saturate physical memory. If you can afford to give nearly all
your physical memory to gimp while you are running it, and you need to
process large images, then do so.

thanks,
Dov


 If the OS has better virtual memory than what available to gimp, then
you would want to use that one. In Linux, I think in most cases, you
would want to use the (often in multiple disks) swap partitions/files
available to the OS.

Evidently not, as in my first post.


___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


[Gimp-developer] comparing gimp speed

2004-11-11 Thread Dov Kruger
I noticed that gimp is very slow for large images compared with
Photoshop. We were recently processing some 500Mb images, and on a fast
machine with 2Gb, gimp is crawling along, while on a slower machine with
only 512 Mb, photoshop is considerably faster.  I attributed it to a
massive amount of work in photoshop, using sse instructions, etc. but
then noticed that the default viewer in redhat allows me to load images
far faster even than adobe, and zoom in and out with the mouse wheel in
realtime.

Granted, because you are editing the image, not just displaying it,
there has to be some slowdown, but I wondered if there is any way I can
tweak gimp, do I somehow have it massively de-optimized. When I first
set up gimp-2.0, I tried both 128 and 512 Mb tile cache sizes. 512 seems
to work a lot better, but it's still pretty bad. Any idea as to the area
of the speed advantage of Adobe?

thanks,
Dov

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


[Gimp-developer] error in code....

2004-06-04 Thread Dov Kruger
Based on advice from this forum, the script now reads:

(define
  (dl-png2transindexed2 file)
  (let*
  (
   (img (car 
 (file-png-load 1 file file)
 )
)
   (d (car (gimp-image-active-drawable img)))
   )
(gimp-layer-add-alpha (car (gimp-image-get-active-layer img)))
(gimp-by-color-select d '(255 255 255) 0 2 0 0 0 0)
(gimp-edit-clear)
(gimp-convert-indexed img 0 0 255 0 0 )
(file-png-save 1 img d file file 0 6 0 0 0 1 1)
)
)

This yields the following error:

Error while executing
(dl-png2transindexed2
/home/dkruger/dev/matlab/sdv4/longislandsaltL10T24.png)
ERROR: too few arguments (see errobj)

First of all, since it's probably obvious what I'm doing wrong, an
answer is always appreciated, but I'd like to know if there is any
mini-debugger available, or any way of seeing which line is the cause of
the error. The error message says to see errorobj but I didn't see
anything on the console, or a menu in the fu section that would show me
the underlying cause.

thanks to all!

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] error in script-fu code....

2004-06-04 Thread Dov Kruger
Carol suggested that removing the interactive flag from png-save might
help. If I do that, I get an error that directly says that a parameter
is missing from png-save, which is at least perfectly understandable.
The script, with Carol's suggestion commented out, is below.

Anyone else with an answer, or with a good way to see where bugs in
fu-scripts are in general?

thanks,
Dov


(define
  (dl-png2transindexed2 file)
  (let*
  (
   (img (car 
 (file-png-load 1 file file)
 )
)
   (d (car (gimp-image-active-drawable img)))
   )
(gimp-layer-add-alpha (car (gimp-image-get-active-layer img)))
(gimp-by-color-select d '(255 255 255) 0 2 0 0 0 0)
(gimp-edit-clear)
(gimp-convert-indexed img 0 0 255 0 0 )
(file-png-save 1 img d file file 0 6 0 0 0 1 1)
;(file-png-save img d file file 0 6 0 0 0 1 1)
)
)
 
(script-fu-register dl-png2transindexed2
Toolbox/Xtns/Script-Fu/png2transindexed2
png2indexed2
Dov Kruger Elena Zagrai
(c) 2004 Stevens Institute of Technology
2004-02-25

SF-FILENAME File file.png
)


___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


[Gimp-developer] correct parameters for select-color?

2004-06-03 Thread Dov Kruger
As per Sven's suggestion, instead of plugin color to alpha, I want to
try replacing every occurrence of white pixels with transparent.
The documentation in the browser suggests something like the following:

 (gimp-by-color-select d '(255 255 255) 0 2 0 0 0 0)

This should select color white, but I don't know how to make the
selection transparent. Searching the calls in the browser for functions
containing alpha and trans didn't yield anything obvious.

Also, with apologies for my ignorance, Sven suggested looking at the
interactive menu, but I don't understand how to select color white
interactively, much less replace it.
If I select menu selection-color the tool changes on the main gimp
window, but I don't see a way to request color white, or make the
selection, and once that's done, how do I make it transparent?

I have seen functions that take the alpha layer and turn it to color,
but how do I programmatically make the alpha layer?

I searched for a while on color selection, but most selections out there
seem to involve selecting a region and doing some photo retouching. Any
pointers would be greatly appreciated.

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


[Gimp-developer] re: color to alpha is slow

2004-06-02 Thread Dov Kruger
Hello fellow gimpers,

Apologies if this is not the correct group, but the users email seems
geared towards people who use menus, not code.

We are using gimp to batch process 3000 or so images per day
generated from an oceanographic forecasting system. We need to make the
background color of a 24bit png image transparent, and turn it into an 8
bit image because Internet Explorer can't handle alpha transparency
evidently, more reason to use Mozilla. You might ask, why are we doing
this? Answer: by pulling static background out of our maps, we achieve a
massive bandwidth reduction on our forecast website, see
http://onr.dl.stevens-tech.edu/webnyhos3 for the original, and
http://onr.dl.stevens-tech.edu/wwwnyhos1/index3.html for the
experimental transparent version.

We currently execute a script-fu that turns all white pixels
transparent, then turns the 24-bit-per-pixel image into indexed mode
with 255 colors, setting color 0 transparent. It seems to take
approximately 1 second per image, and the images are not all that big
(some are as little as 15k, though the bigger maps, like Long Island,
are as big as 150k). We do 100 at a time in a script, because the
command line literally gets too long after a while -- we could probably
increase that number to 500 or even decrease it, but the dominant factor
seems to be the time it takes to do these operations. The machine is a
2.6Ghz P4 with 2Gb of RAM, the raw CPU should be capable of a lot more
than this, and I allocated 500M in the gimp configuration, could some
garbage collection problem be an issue?

I suspect that color-to-alpha is the slow part. Is there anything we can
do to speed this up, like convert the image to indexed, and just make
color 0 transparent? Any help with code to programmatically make color
entry n transparent would be great, we didn't find any reference to
that.

Oh, and to everyone who works on gimp, you guys kick serious butt! What
a tool!

thanks,
Dov

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer