Re: calling script-fu from perl script
Thus spoke Marc Lehmann > Not in the current architecture. The caller is blocked until the called > plug-in has finished. That would be the preferred design, but my tests don't seem to bear this out. Again, I could be misinterpreting the results, though I'm fairly certain I'm not. > However, are you sure that the layer you used to calldrop-shadow is still > valid after drop-shadow returns? If not, then this would explain why the > example above works (and this would be the right fix). The basic code looks like this: script_fu_old_photo($drawable, 0, 1, 1, 1, 0); sleep(2); $drawable = gimp_image_get_active_layer($img); script_fu_drop_shadow($drawable, "8", "8", "15", [0,0,0], "100.0", 1); If I remove the sleep() call then Gimp crashes. If I make the sleep() call only 1 second, various results occur. If I don't use the call to gimp_image_get_active_layer(), with or without the delay, then Gimp crashes. The call to gimp_image_get_active_layer() makes sense - script_fu_old_photo() probably updates the image in a way that the drawable ID for the flattened image has changed. The need for the 2 second delay tells me that the blocking you mention isn't happening. In fact, I can watch part of the drop shadow actually being performed on the image *before* any visible results from old_photo happen - all before Gimp crashes. Weird, but that's what I'm seeing. If I change the sleep() to 1 second, I get results that pretty much prove the issue: The rest of my script (which you've not seen yet and I only added after I found that the delay workaround actually worked) copies in a tile that it pastes into the main image, moves to the bottom layer and then flattens the whole thing. With a 1 second delay all of this pasting, moving and flattening actually occurs - but *before* the shadow layer from drop_shadow is placed in the image. You can see this by looking at the layers dialog after the script completes. It has the flattend old photo/tile bg image layer over a black shadow layer. Two layers, in an image that my script flattened, and no errors are produced. So, I'm fairly certain the blocking is not happening. > Could it be that the whole problem was just your script re-uzsing a drawable > id that didn't exist after drop-shadow returns? i.e. does drop-shadow really > lave the layer alone or does it create a new one? It was partially, but the delay (via sleep(2)) does seem to be mandatory. Blocking does not appear to be happening. > (Iny case, gimp shouldn't crash) True. Still, my misuse of a valid drawable was unexpected for the Gimp. There may be some error checking that could be done to prevent the crash, I suppose. My bigger concern in this particular case is the serializing of the calls. I can work around this issue with the delay, but it might be necessary (if this can't be addressed before 1.2 is released) to make a note that serializing of calls to plug-ins from plug-ins is not guaranteed. BTW, if anyone wants a copy of the script I'm using that shows this let me know. -- Michael J. Hammel The Graphics Muse [EMAIL PROTECTED] http://www.graphics-muse.com -- Everything should be made as simple as possible. But not simpler. -- Albert Einstein.
Re: TGA plug-in patch
On Mon, Sep 11, 2000 at 01:17:25AM +0200, Marc Lehmann wrote: > On Sun, Sep 10, 2000 at 07:16:22PM +0100, Nick Lamb <[EMAIL PROTECTED]> wrote: > > > strange to do, it is a supported feature of the file format and OpenGL > > > > apply the patch and (b) I don't think Gimp should offer too many > > features that work around uncommon errors in other systems at a cost of > > If the abovce is true and the file format indeed supports this (in the > spec, if any), then this is not an "error" but "valid but uncommon". Ah no, writing images to TGA with "flip-vertical" flag set is both valid and common, almost universal in fact. But not being willing or able to load top-down images like Gimps would be an uncommon error, I've never yet seen anything that can't cope. The spec, such as it is says to look at the flag and obey it -- no confusion there. The patch is for _writing_ TGA files, and like TIFF there's plenty of wacky things you legally _can_ write to a TGA file, I am offering the opinion that we should generally shield users from the dozens of valid yet unimportant TGA options, and set them for our convenience, as we do with TIFF. I don't think it makes sense to have a dialog like this: [x] Top-left start [ ] Top-right start [ ] Bottom-right start [ ] ... [x] R-G-B [ ] B-R-G [ ] R-B-G [ ] B-R-A-G [ ] Mysteriously allocate but don't use colourmap [ ] Make alternate scanlines inverted for some reason [ ] Write four channels, but then only use three Given that the image will look the same in Gimp either way, have (almost) the same file size, load and look the same in any other working image app... I want to have a genuine REASON to add any options like this before I risk confusing users further. Still, a good reason may be forthcoming and if it is I'll happily integrate this patch or one like it. Nick.
Re: TGA plug-in patch
On Sun, Sep 10, 2000 at 07:16:22PM +0100, Nick Lamb <[EMAIL PROTECTED]> wrote: > > strange to do, it is a supported feature of the file format and OpenGL > > apply the patch and (b) I don't think Gimp should offer too many > features that work around uncommon errors in other systems at a cost of If the abovce is true and the file format indeed supports this (in the spec, if any), then this is not an "error" but "valid but uncommon". -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: calling script-fu from perl script
On Sun, Sep 10, 2000 at 02:56:07PM -0500, "Michael J. Hammel" <[EMAIL PROTECTED]> wrote: > plug-ins from another plug-in. Since the plug-ins run as separate > processes, the calling plug-in continues running after each call to another > plug-in. Not in the current architecture. The caller is blocked until the called plug-in has finished. However, are you sure that the layer you used to calldrop-shadow is still valid after drop-shadow returns? If not, then this would explain why the example above works (and this would be the right fix). > I don't see how you can "fix" this problem with the Gimp and maintain the Could it be that the whole problem was just your script re-uzsing a drawable id that didn't exist after drop-shadow returns? i.e. does drop-shadow really lave the layer alone or does it create a new one? (Iny case, gimp shouldn't crash) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: calling script-fu from perl script
> Highly interesting indeed. Now, what gimp-perl does (when you pass in a > drawable instead of both image and drawable) is this: > > if (sv_derived_from (sv, PKG_DRAWABLE)) > arg->data.d_image = gimp_drawable_image_id(unbless(sv, PKG_DRAWABLE, >croak_str)); > > i.e. it calls gimp_drawable_image_id (or gimp_layer_get_image_id > etc..) to get the image, which in turn calls the the pdb function > gimp_drawable_image without any caches. This means that, temporarily, gimp > returns "-1" as the image id and later the correct one. I did some more experimenting today and found that the following code works: # Apply an "old photo" look to it. The sleep() is a delay to allow the # script to finish before we try to run any other plug-ins on it. script_fu_old_photo($drawable, 0, 1, 1, 1, 0); sleep(2); $drawable = gimp_image_get_active_layer($img); # Apply the Drop Shadow filter to it. script_fu_drop_shadow($drawable, "8", "8", "15", [0,0,0], "100.0", 1); What this tells me is that the problem has to do with calling multiple plug-ins from another plug-in. Since the plug-ins run as separate processes, the calling plug-in continues running after each call to another plug-in. The first called plug-in can change the make up of the image drawables *after* the second plug-in is called. That, understandably, is a bad thing and unexpected results are likely. So plug-ins which call other plug-ins - especially plug-ins that add or delete layers from an image - need to pause for those plug-ins to complete and then make sure they have the current active drawable for the image being worked on before calling the next plug-in. I don't see how you can "fix" this problem with the Gimp and maintain the ability for interactive users to work on multiple images while plug-ins are running. The only possible option is to add some sort of "serialize plug-ins" feature that can be turned on and off from within a plug-in. Doesn't sound easy. -- Michael J. Hammel The Graphics Muse [EMAIL PROTECTED] http://www.graphics-muse.com -- Memory is a Net - Oliver Wendell Holmes, Sr.
Re: TGA plug-in patch
On Sat, Sep 09, 2000 at 07:45:17PM -0400, Brandon wrote: > Below is a patch to add support for saving TGA files upside down. > Although it sounds > strange to do, it is a supported feature of the file format and OpenGL > expects its > textures to be upside down. Support already exists for reading such files > but it > was impossible to save them. The spirit is appreciated, but (a) The TGA filter is being reworked at present and may (in my tree) no longer resemble the original enough to apply the patch and (b) I don't think Gimp should offer too many features that work around uncommon errors in other systems at a cost of confusing users... Did you want this to make a specific application go faster? Or because of a bug in someone else's TGA loader that means you can't load images the right way up? I know that OpenGL's internal store doesn't resemble a TGA very much, but I'd argue that the vertical orientation is the least of your troubles. Nick.
Re: calling script-fu from perl script
On Sun, Sep 10, 2000 at 01:23:31PM -0500, "Michael J. Hammel"
<[EMAIL PROTECTED]> wrote:
Hmm, a serialization issue is unlikely, since all the other plug-ins seem
to work, and script-fu never could be called reliably. If this, however,
is indeed the case than this change is probably quite new (maybe somebody
hacked locking lately?)
> > drawable instead of both image and drawable) is this:
>
> Is there a way to pass in the image id?
Just pass it in at the usual position.
> I tried, but I get error messages
Did you pass in a valid image, or did you try to pass in a number? The latter
might not work reliably. You can also try to use the all-explicit syntax,
i.e.
(RUN_INTERACTIVE, $image, $drawable, ...
> when I try to pass the image id as the first parameter. Do you pass the
> image id and drawable id's as a list?
No, you pass them "as usual".
>
> > i.e. it calls gimp_drawable_image_id (or gimp_layer_get_image_id
> > etc..) to get the image, which in turn calls the the pdb function
> > gimp_drawable_image without any caches. This means that, temporarily, gimp
> > returns "-1" as the image id and later the correct one.
>
> Ick. If this is true then there is a timing issue here where plug-ins
> can't call other plug-ins.
you could check this hypothesis by doing something like this:
for (0..29) {
print "IMAGE ID: ", ${$drawable->image}, "\n";
select undef, undef, undef, 0.1;
}
this (untested) snippet prints out the image id of your drawable ten times
a second. Just insert it after the call to drop_shadow (i.e. where you
formerly added the delay).
When the image id changes from -1 to something else we have found the
problem.
--
-==- |
==-- _ |
---==---(_)__ __ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e|
-=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
Re: calling script-fu from perl script
Thus spoke Marc Lehmann > Thanks for the reply ;) I posted it to gimp-developer because i seems this > is a generic gimp bug and hope somebody else can add more. It does sound like a problem with how Script-Fu (and maybe plug-ins in general) are serialized. > > Looks like the image id gets changed somehow. Ideas? > > Highly interesting indeed. Now, what gimp-perl does (when you pass in a > drawable instead of both image and drawable) is this: Is there a way to pass in the image id? I tried, but I get error messages when I try to pass the image id as the first parameter. Do you pass the image id and drawable id's as a list? > i.e. it calls gimp_drawable_image_id (or gimp_layer_get_image_id > etc..) to get the image, which in turn calls the the pdb function > gimp_drawable_image without any caches. This means that, temporarily, gimp > returns "-1" as the image id and later the correct one. Ick. If this is true then there is a timing issue here where plug-ins can't call other plug-ins. > Here I have to give up and hope this rings a bell for somebody more tied > to the internals of gimp id management. I'm going to try calling C plug-ins instead of Script-Fu, and variations on the same, to see if there is one specific area where this happens. Thanks for looking into this, Mark. -- Michael J. Hammel The Graphics Muse [EMAIL PROTECTED] http://www.graphics-muse.com -- Try again. Fail again. Fail better. -- Thomas Beckett
Re: TGA plug-in patch
>Below is a patch to add support for saving TGA files upside down. >Although it sounds strange to do, it is a supported feature of the >file format and OpenGL expects its textures to be upside down. Support >already exists for reading such files but it was impossible to save >them. As far as I know OpenGL expects its textures to be in RGBA format while TGA saves in ABGR so you have to do some extra work per pixel anyway, and then you can just as well read them in upside down, can't you?
