Hi there,

I've been experimenting with GIMP plug-ins. At present, I'm following the tutorial's example:-
http://developer.gimp.org/writing-a-plug-in/3/myblur5.c

My question is this; "How can I use GimpDrawable-functions on a preview window without modifying the original image?"

To clarify:- In the example, blur() is passed a Drawable (from the main image itself), and uses it to make an "input" GimpPixelRgn (rgn_in). The raw pixel info from rgn_in is then processed and written as more raw pixels, to a different GimpPixelRgn, rgn_out.

Rgn_out forms the basis of the preview: gimp_drawable_preview_draw_region (GIMP_DRAWABLE_PREVIEW (preview), &rgn_out)

However, I want to annotate the PREVIEW (*without* modifying the original image's drawable) using gimp_pencil(). That requires a GimpDrawable, but rgn_out- i.e. the processed pixels which are used to create the preview's contents- is in GimpPixelRgn format. How do I draw on the output window?

Getting the Drawable associated with the preview widget via gimp_drawable_preview_get_drawable() simply returns the main image's drawable, which we already have. Drawing to this (a) messes up the *original* image, and (b) has no effect on the preview (since that is taken from the processed rgn_out data).

Any help would be appreciated, thank you.

- triffid@oink.co.uk

______________

sven@gimp.org wrote:
:On Sun, 2006-12-03 at 12:05 -0800, triffid@oink.co.uk wrote: :> However, I want to annotate the PREVIEW (*without* modifying the :> original image's drawable) using gimp_pencil(). That requires a :> GimpDrawable, but rgn_out- i.e. the processed pixels which are used to :> create the preview's contents- is in GimpPixelRgn format. How do I draw :> on the output window?
:
:It would help a lot if you could simply tell us what you actually want :to achieve before going into implementation details. I have the feeling :that all you want to do is to draw something on the preview window.

That's exactly right; I realise that my original question got bogged down with specifics- sorry.

Put simply, I want to use the high-level Drawable functions to draw a line or arrow on the preview window. The tutorial example only uses the pixel-level functions. It's not clear how- or if- I can use (e.g.) gimp_pencil() and friends.

:If that is true, then you definitely don't want to use :gimp_pencil() or similar functions.

Umm... that's *exactly* what I wanted to do. But from your reply I guess that (a) it's not possible, or (b) it's a bad idea...?

- triffid@oink.co.uk

______________

sven@gimp.org wrote:
:> :If that is true, then you definitely don't want to use :> :gimp_pencil() or similar functions. :>
:> Umm... that's *exactly* what I wanted to do. :> But from your reply I guess that (a) it's not possible, or (b) it's a bad idea...? :
:Anything is possible and there are often multiple ways to achieve one's :aim. That's also the case here. But unless you give us some details :about the plug-in you are writing, I can't tell which way would be best :in your case. And I am not going to waste my time explaining all of :them.

What I'm writing is straightforward- it's a linear (i.e. one-dimensional) unsharp mask. (I'm probably not the first to do this, but it's a good learning opportunity, and it confirmed my hunch that it would work better against motion blur than the standard version). The line is supposed to illustrate the angle and size of the convolution.

I didn't give any specific details, nor post my code, because I assumed that- once explained- the problem would be a general one with a straightforward answer. At the time, I thought it was easier to use the standard example, which was cleaner and simpler than my code but still illustrated the point.

I apologise if it sounds like I'm making a big deal of this, or that it's a major hurdle; it's not. For a one-off, it would probably be simple to write a crude pixel-based line function myself. But it would be silly to keep doing this every time *if* there was already a simple way of using the existing facilities.

Anyway, I'll tidy up my code and post relevant parts here soon. In the meantime, thank you for your help.

- triffid@oink.co.uk

______________

sven@gimp.org wrote:
:On Sun, 2006-12-03 at 14:52 -0800, triffid@oink.co.uk wrote: :
:> What I'm writing is straightforward- it's a linear (i.e. one-dimensional) unsharp :>mask. (I'm probably not the first to do this, but it's a good learning opportunity, :>and it confirmed my hunch that it would work better against motion blur than the :>standard version). The line is supposed to illustrate the angle and size of the :>convolution. :
:In that case you probably want to draw on the preview window without :fiddling with the buffers that the preview widget uses. Just connect :after the expose-event handler and use GDK or Cairo drawing API to draw :on the preview area.

That's great, thanks (also to David Gowers for his response too).

I'm still a relative novice with GTK- I learned what little I know in order to write this filter's dialog box- but I'll be taking a look at that.

In the meantime, I've uploaded the linear unsharp mask filter code (first version) and some example images here:- http://home.freeuk.com/misacham/temp/mask.htm

(Note (a) the images are fairly large and (b) Yes, I know the filter code is slow and could probably be *much* faster; one thing at a time).

Like I said, I'd be very surprised if I was the first to think of this, but I wanted to play around with the idea on my own anyway. It's hardly a miracle cure for motion blur, but the results were pretty good; it certainly beats two-dimensional USM for that purpose.

- triffid@oink.co.uk

______________