On Thu, 2004-02-05 at 17:12, David Neary wrote:

9) A decent image browser/thumbnail viewer + cover-sheet support

This sounds a bit like the old GUASH (which I have started to port to GTK+ 2.x/GIMP 2.0) but I'm not sure what you mean by "cover-sheet support".

On Thu, 5 Feb 2004, Kevin Cozens wrote:

Date: Thu, 05 Feb 2004 19:25:41 -0500 From: Kevin Cozens
To: gimp-devel
Subject: Re: [Gimp-developer] Tentative 2.2 feature list

On Thu, 2004-02-05 at 17:12, David Neary wrote:

9) A decent image browser/thumbnail viewer + cover-sheet support

This sounds a bit like the old GUASH (which I have started to port to GTK+ 2.x/GIMP 2.0) but I'm not sure what you mean by "cover-sheet support".

Incidentally this was recently requested amongst the comments on gnomedesktop.org (or was it bugzilla) and I suggested using one of the many thumbnail browserst that already have this functionality (gThumb has it I think) but that it would be great if GIMP also had this functionality.

take a bunch of thumbnails and create a new image that consits of those thumbnails layed out in rows and columns much like a photographic contact sheet that is sometimes provided if you get traditional photographs developed.

The latest version of Adobe Photoshop includes a Thumbnail browser (methings they felt Paint Shop Pro biting at their heels) so expect to hear lots of complaints about the GIMP not having a Thumbnail browser anymore. Good luck with the GUASH revival, and I encourage anyone who has ideas on how to make GQView, gThumb, F-spot or any other thumbnail browser work better with the GIMP.

Sincerely

Alan Horkan http://advogato.org/person/AlanHorkan/

PS As soon as I get my hands on an evaluation copy of Photoshop I'll be filing a truckload of enhancements requests including one with many screenshots of PhotoMerge (and if you dont know what that is yet then I encourage you to look at the best of the rest and steal ideas for the GIMP).

Kevin Cozens wrote:

On Thu, 2004-02-05 at 17:12, David Neary wrote:

9) A decent image browser/thumbnail viewer + cover-sheet support

This sounds a bit like the old GUASH (which I have started to port to GTK+ 2.x/GIMP 2.0) but I'm not sure what you mean by "cover-sheet support".

http://bugzilla.gnome.org/show_bug.cgi?id=132532

Photographers make these a lot to have a nuber of photos in an array on paper. Perhaps this should/could be done at the gimp-print level, but it should integrate nicely into the thumbnail viewer...

By the way, Sven has also been talking about doing a thumbnail viewer based on libgimpthumb. I don't know what stage it's at though. In any case, updating GUASH to 2.0 should be a fairly quick job, good luck - perhaps some code clean-up would be nice too? :)

Cheers, Dave.

Hi,

David Neary writes:

That said, here's what I think is a reasonable target feature set for 2.2:

1) Migration to GTK+ 2.4, including - File selector upgrade (allows things like bookmarks) - remove all GtkOptionMenus
- use GtkActions for shortcuts

Agreed.

2) Cut & Paste across other applications including at least - image/pnm (raw, uncompressed data) - image/png (compressed data, slower copies) - image/svg+xml (sodipodi, OO Draw and InkScape would be cool)

Some of this is already there (SVG drops are supported) and I think it's reasonable to attempt to finish this for 2.2.

3) Edit patterns in-place
4) Save as GIMP Pattern saves direct to ~/.gimp-1.3/patterns (same for "Save as GIMP brush)

This would be nice but I don't think it's a blocker for 2.2. If someone wants to give it a try, fine. Not sure if it should be on the list though.

5) Preview widget to replace GimpOldPreview

That's a rather large change. If we get someone interested and a proposal for an implementation is posted early enough, then it should probably go in.

6) User-defined presets for most plug-ins

Can you explain this further? Actually I don't like the idea of doing it the way we've done it for PNG now. I'd rather attempt to develop a new PDB that can be used alternatively. That redesigned PDB would then bring default values, user-defined presets and lots of other nice things to all plug-ins using it. Did anyone check how far libpdb has come? Would be nice if we could base our efforts on it.

7) Move from SIOD to guile for script-fu

Guile or another interpreter or fix the current implementation. All nice but we keep asking for this for years now and I don't see it happen until summer. Let's say, it would be nice to have but it shouldn't block 2.2.

On the list of "maybe" stuff, there's: 9) A decent image browser/thumbnail viewer + cover-sheet support

This can be developed outside GIMP. There's no need to put it on our TODO list.

10) Macro recorder, if anyone has ideas on how it can be done with the current PDB/undo system

I don't think it can be done with the current system but it should be considered for a PDB redesign which could be part of 2.2 (see above).

I also doubt that it makes sense to tackle layer groups and layer effects in 2.2. The timeframe is way too short for these.

On the policy side, here's how I would like things to be handled in 2.1.x:
- Every feature added to CVS has a bug # associated with it

How is that more useful than annoying?

Sven

Hi,

Sven Neumann wrote:

David Neary writes:

3) Edit patterns in-place
4) Save as GIMP Pattern saves direct to ~/.gimp-1.3/patterns (same for "Save as GIMP brush)

This would be nice but I don't think it's a blocker for 2.2. If someone wants to give it a try, fine. Not sure if it should be on the list though.

I'm interested in doing this, I think it's a very nice feature.

It would also fit nicely into "hiding" system brushes as described in bug #118742 - http://bugzilla.gnome.org/show_bug.cgi?id=118742

5) Preview widget to replace GimpOldPreview

That's a rather large change. If we get someone interested and a proposal for an implementation is posted early enough, then it should probably go in.

David Odin has said he would like to do this for 2.2, which is why it's on the list.

6) User-defined presets for most plug-ins

Can you explain this further? Actually I don't like the idea of doing it the way we've done it for PNG now. I'd rather attempt to develop a new PDB that can be used alternatively. That redesigned PDB would then bring default values, user-defined presets and lots of other nice things to all plug-ins using it. Did anyone check how far libpdb has come? Would be nice if we could base our efforts on it.

The idea I had (knowing that this is a big change) is to export the serialisation stuff to libgimp, have plug-ins which want presets extend GimpPlugIn which will implement the serializable interface. The plug-ins should then move from a structure of options (as they currently have) to GObject properties for options they want serialised. Then we could re-use the widgets that are in place in the core in the plug-ins.

I won't be able to do this myself, but it would be a very nice feature for someone to take on, if that plan sounded reasonable.

7) Move from SIOD to guile for script-fu

Guile or another interpreter or fix the current implementation. All nice but we keep asking for this for years now and I don't see it happen until summer. Let's say, it would be nice to have but it shouldn't block 2.2.

Agreed. But someone could claim this now, and make it the thing they do for 2.2 - given the work that mitch did recently in further separating out siod from script-fu, this should be a fairly small job.

I also doubt that it makes sense to tackle layer groups and layer effects in 2.2. The timeframe is way too short for these.

They were on the list as stuff which would be possible, if someone claimed them now and started working on a proposal between now and the middle of March when we will branch.

On the policy side, here's how I would like things to be handled in 2.1.x:
- Every feature added to CVS has a bug # associated with it

How is that more useful than annoying?

"feature" = "big change which might introduce bugs" - this will allow cross-referencing later. It will also make it more transparent for people following from a distance, or website maintainers, to maintain a list of features in 2.2. The ChangeLog is far too voluminous to serve as a feature tracker. Bugzilla is made for that.

It will also help to see if people are starting big features just before a feature freeze, so that we can maybe bump things before there's a big block of unstable code committed.

It might be annoying - it's certainly something I'd like to see tried. It's intended to help us work on stuff that's on the planned feature list too.

Cheers, Dave.

Hi again,

Dave Neary wrote:

Sven Neumann wrote:

David Neary writes:

5) Preview widget to replace GimpOldPreview

That's a rather large change. If we get someone interested and a proposal for an implementation is posted early enough, then it should probably go in.

David Odin has said he would like to do this for 2.2, which is why it's on the list.

As a matter of interest, why do we not simply take the old GtkPreview code an rename it GimpPreview, put it in libgimpwidgets and use that? Just wondering.

Cheers,
Dave.

Hi,

Dave Neary writes:

The idea I had (knowing that this is a big change) is to export the serialisation stuff to libgimp, have plug-ins which want presets extend GimpPlugIn which will implement the serializable interface. The plug-ins should then move from a structure of options (as they currently have) to GObject properties for options they want serialised. Then we could re-use the widgets that are in place in the core in the plug-ins.

I won't be able to do this myself, but it would be a very nice feature for someone to take on, if that plan sounded reasonable.

If we did this (and I think it's way too much of a change for 2.2), then it should be done right. Doing it right means coming up with an API (probably similar to GimpConfig in the core) that also fits the needs of the redesigned PDB since we will want to reuse that API for it as well.

Agreed. But someone could claim this now, and make it the thing they do for 2.2 - given the work that mitch did recently in further separating out siod from script-fu, this should be a fairly small job.

What Mitch did there was to prepare the SIOD implementation for an update to the latest released version which is at least two years newer that what we are using now.

Sven

Hi,

Dave Neary writes:

As a matter of interest, why do we not simply take the old GtkPreview code an rename it GimpPreview, put it in libgimpwidgets and use that? Just wondering.

Because the old GtkPreview code is not what we would like to see as a GIMP preview widget? It shares a few characters in the name but that's about where the similarity ends.

Sven

Hi,

Sven Neumann wrote:

Dave Neary writes:

As a matter of interest, why do we not simply take the old GtkPreview code an rename it GimpPreview, put it in libgimpwidgets and use that? Just wondering.

Because the old GtkPreview code is not what we would like to see as a GIMP preview widget? It shares a few characters in the name but that's about where the similarity ends.

Ah - I recalled you saying on several occasions that you didn't understand why GtkPreview had been deprecated, that you thought it was a very good widget. I must have misunderstood.

Cheers, Dave.

On Fri, Feb 06, 2004 at 12:38:33PM +0100, David Neary wrote:

5) Preview widget to replace GimpOldPreview

That's a rather large change. If we get someone interested and a proposal for an implementation is posted early enough, then it should probably go in.

David Odin has said he would like to do this for 2.2, which is why it's on the list.

To be more precise, since the GTK+ team has deprecated GtkPreview, I would have like to see if the gimp couldn't have its own widget for this. I won't promise it will be done on time, though. Let's put this on the "maybe included" list.

Regards,

DindinX

On Fri, Feb 06, 2004 at 01:16:28PM +0100, David Neary wrote:

Hi,

Sven Neumann wrote:

Dave Neary writes:

As a matter of interest, why do we not simply take the old GtkPreview code an rename it GimpPreview, put it in libgimpwidgets and use that? Just wondering.

Because the old GtkPreview code is not what we would like to see as a GIMP preview widget? It shares a few characters in the name but that's about where the similarity ends.

Ah - I recalled you saying on several occasions that you didn't understand why GtkPreview had been deprecated, that you thought it was a very good widget. I must have misunderstood.

It looks so. While it is true that GtkPreview has been deprecated without a replacement widget without a good reason (in my opinion, and obviously in Sven's opinion too), GimpOldPreview is much more than only a wrapper around GtkPreview. Besides, we (I ?) could do a better job by integrating GimpPreview (or whatever its name will be) more with gimp's internal.

Regards,

DindinX

Hi,

David Odin writes:

To be more precise, since the GTK+ team has deprecated GtkPreview, I would have like to see if the gimp couldn't have its own widget for this. I won't promise it will be done on time, though. Let's put this on the "maybe included" list.

GtkPreview is still available, there's nothing that keeps us from using it.

What we are aiming for is a lot more complex than what GtkPreview is providing. The goal is to have a widget that can zoom and pan. It should also provide an API that allows to use the same image processing routines for the preview as are used for the drawable. The plug-in author shouldn't have to care much about the preview.

Sven

Hi,

David Odin writes:

It looks so. While it is true that GtkPreview has been deprecated without a replacement widget without a good reason (in my opinion, and obviously in Sven's opinion too), GimpOldPreview is much more than only a wrapper around GtkPreview. Besides, we (I ?) could do a better job by integrating GimpPreview (or whatever its name will be) more with gimp's internal.

Integrating with GIMP's internal? There's no need for such a widget in the GIMP core (and we have GimpPreview in the core already). What we are looking for is a preview widget that is especially modeled for the need of GIMP plug-ins. How would this integrate with internals? I guess I somehow misunderstood you here.

Sven

On Fri, Feb 06, 2004 at 03:45:21PM +0100, Sven Neumann wrote:

Hi,

David Odin writes:

To be more precise, since the GTK+ team has deprecated GtkPreview, I would have like to see if the gimp couldn't have its own widget for this. I won't promise it will be done on time, though. Let's put this on the "maybe included" list.

GtkPreview is still available, there's nothing that keeps us from using it.

If needed, yes.

What we are aiming for is a lot more complex than what GtkPreview is providing. The goal is to have a widget that can zoom and pan. It should also provide an API that allows to use the same image processing routines for the preview as are used for the drawable. The plug-in author shouldn't have to care much about the preview.

Exactly, selection and layers handling should be there two.

But please, see my other mail.

Regards,

DindinX

On Fri, Feb 06, 2004 at 04:02:37PM +0100, Sven Neumann wrote:

Hi,

David Odin writes:

It looks so. While it is true that GtkPreview has been deprecated without a replacement widget without a good reason (in my opinion, and obviously in Sven's opinion too), GimpOldPreview is much more than only a wrapper around GtkPreview. Besides, we (I ?) could do a better job by integrating GimpPreview (or whatever its name will be) more with gimp's internal.

Integrating with GIMP's internal? There's no need for such a widget in the GIMP core (and we have GimpPreview in the core already). What we are looking for is a preview widget that is especially modeled for the need of GIMP plug-ins. How would this integrate with internals? I guess I somehow misunderstood you here.

Sorry. I haven't been clear enough here. GimpPreview as I see it should be able so show exactly the same thing as a Drawable, but with a different scale. For instance, it should be able to show the composited image, with a background layer or whatever. This sort of thing could involve more than just gdkrgb functions, that's why I said this _could_ use more gimp's way of rendering than gtk's.

Anyway, this isn't clear in my mind for now. I'll propose a draft on this list as soon as I have more valuable thing to show.

Regards,

DindinX

Hi,

David Odin writes:

Anyway, this isn't clear in my mind for now. I'll propose a draft on this list as soon as I have more valuable thing to show.

I hope you are aware that there is an implementation already. We were not happy with the API and some implementation details but it is definitely worth to at least have a look at it:

http://refocus.sourceforge.net/preview/gimppreview.html

Sven

Hi,

Sven Neumann wrote:

David Odin writes:
What we are aiming for is a lot more complex than what GtkPreview is providing. The goal is to have a widget that can zoom and pan.

This would be cool.

It
should also provide an API that allows to use the same image processing routines for the preview as are used for the drawable. The plug-in author shouldn't have to care much about the preview.

I'm not sure what you mean by this - wouldn't the preview just be a copy of the drawable which gets rendered? What API is needed? I have trouble following the problems you see.

Cheers,
Dave.

On Fri, Feb 06, 2004 at 04:51:28PM +0100, Sven Neumann wrote:

Hi,

David Odin writes:

Anyway, this isn't clear in my mind for now. I'll propose a draft on this list as soon as I have more valuable thing to show.

I hope you are aware that there is an implementation already. We were not happy with the API and some implementation details but it is definitely worth to at least have a look at it:

http://refocus.sourceforge.net/preview/gimppreview.html

I wasn't aware of this. I'll have a look. Thanks.

DindinX

Hi,

Dave Neary writes:

I'm not sure what you mean by this - wouldn't the preview just be a copy of the drawable which gets rendered? What API is needed? I have trouble following the problems you see.

I'm a bit confused now since we discussed all details of the widget several months ago. It might be worth to dig out that discussion again because it had a very good list of requirements.

The main point is that of course since you want to preview a plug-in's result, the plug-in shouldn't have to run the complete drawable thru whatever pixel manipulation routines it applies. There wouldn't be a need for a preview widget then, you could simply apply the effect. The preview widget needs to be smart enough to cause only the visible area to be processed (from an idle handler so that the GUI remains responsive). For a zoomed preview it needs to pass scaled data to the plug-in's pixel manipulation routines which may then have to adapt to the scale ratio that is applied. Ideally the same pixel manipulation routines of the plug-in should be used for rendering the actual result on the drawable as for rendering the preview. Since we don't want to introduce major changes to the plug-in, the preview API should probably provide a fake drawable that the plug-in can work on.

Sven

At 06:18 AM 02/06/2004, Sven wrote:

7) Move from SIOD to guile for script-fu

Guile or another interpreter or fix the current implementation. All nice but we keep asking for this for years now and I don't see it happen until summer. Let's say, it would be nice to have but it shouldn't block 2.2.

I have started to look at Guile to see how easy/difficult it would be to use it as an eventual replacement for Script-Fu. In the short-term, while looking at the source for Script-Fu/SIOD in the GIMP, I think that some a series of minor patches can help to improve the reporting of error messages. I need to run some additional tests by breaking some scripts and testing error reports.

10) Macro recorder, if anyone has ideas on how it can be done with the current PDB/undo system

I don't think it can be done with the current system but it should be considered for a PDB redesign which could be part of 2.2 (see above).

While researching Guile as a replacement for Script-Fu, I ran across an article relating to the PDB system. Someone (I forget who) stated they thought that instead of developing the PDB system, the GIMP should have used a system based on CORBA(?). One of the reasons cited for it not being done back then was the lack of open source versions or sufficiently mature implementations IIRC.

I don't know much about CORBA other than hearing about it in relation to Windows stuff. Would the features of something based on a CORBA-like system be any better than the existing PDB system? I know this would be a lot of work so any change here would be for a GIMP version > 2.2.

Also, IIRC, wasn't some of the work being done in the 2.x series meant to clean things up in ways that would make it easier to do the Macro recorder at some point in the future?

Cheers!

Kevin. (http://www.interlog.com/~kcozens/)

Owner of Elecraft K2 #2172 |"What are we going to do today, Borg?" E-mail:kcozens at interlog dot com|"Same thing we always do, Pinkutus: Packet:ve3syb@ve3yra.#con.on.ca.na| Try to assimilate the world!" #include | -Pinkutus & the Borg

At 07:06 AM 02/06/2004, Sven wrote:

What Mitch did there was to prepare the SIOD implementation for an update to the latest released version which is at least two years newer that what we are using now.

The most recent copy of SIOD I could find was from 1998, IIRC. So, if the current SIOD part of Script-Fu is indeed from 2 years earlier, would it make sense in the short term to update the copy of SIOD currently used in the GIMP until a replacement for the whole Script-Fu system is available?

Cheers!

Kevin. (http://www.interlog.com/~kcozens/)

Owner of Elecraft K2 #2172 |"What are we going to do today, Borg?" E-mail:kcozens at interlog dot com|"Same thing we always do, Pinkutus: Packet:ve3syb@ve3yra.#con.on.ca.na| Try to assimilate the world!" #include | -Pinkutus & the Borg

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Feb 6, 2004, at 7:25 pm, Kevin Cozens wrote:

While researching Guile as a replacement for Script-Fu,

Guile is a nasty beast. Gnucash is one of the hardest to compile and keep working applications just because of their use of guile. I'm not really sure you want that amount of fun...

- --
Servus,
Daniel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iQEVAwUBQCP36DBkNMiD99JrAQL+5ggAiym8DW502bSXPPILWmrL9dhQ4YYhEOhO ybp0iSHI8CRUMae+r2D9RYiSQ7iHiHsccYq49FjUMoFO65TwpuFayGAY8X5aeIZm 46C2wfx7+o3KDdkDq69Ws6uEfjtiosNxWSJqKQ0B6MCy8ZaUG9+WrXrIfwQUYtbh +w5wblGnPeO7Xi0xHcYP4o/gNwXb/8zBGO60ZlgxjKnFWhDR3gXKVUnMpa/K8oYn /MTQE1vHXWY3pcsmEbl1JcmzFYerUhniAX2V2+3AMT8B0rAemlTqcoXkzd8I1f6N VBmUH34dvmvPf/X8k2YxHxUarTiMUy3ENtkWT5GYpIkkIICi8QObmQ== =1vwE
-----END PGP SIGNATURE-----

Hi,

Kevin Cozens writes:

At 07:06 AM 02/06/2004, Sven wrote:

What Mitch did there was to prepare the SIOD implementation for an update to the latest released version which is at least two years newer that what we are using now.

The most recent copy of SIOD I could find was from 1998, IIRC. So, if the current SIOD part of Script-Fu is indeed from 2 years earlier, would it make sense in the short term to update the copy of SIOD currently used in the GIMP until a replacement for the whole Script-Fu system is available?

Yes, I think it would be worthwhile to update SIOD to that version. This would probably help to make you more familiar with the current implementation and it could be done in the short timeframe we've setup for GIMP-2.2.

Sven

In regard to: Re: [Gimp-developer] Tentative 2.2 feature list, Sven Neumann...:

The most recent copy of SIOD I could find was from 1998, IIRC. So, if the current SIOD part of Script-Fu is indeed from 2 years earlier, would it make sense in the short term to update the copy of SIOD currently used in the GIMP until a replacement for the whole Script-Fu system is available?

Yes, I think it would be worthwhile to update SIOD to that version. This would probably help to make you more familiar with the current implementation and it could be done in the short timeframe we've setup for GIMP-2.2.

As I recall, the SIOD that's part of gimp is not a "stock" version of SIOD, as there were various bugs detected and fixed in SIOD in the 0.99.x and 1.2.x gimp releases. There *may* be fixes in the gimp's custom SIOD that never got back into the mainline SIOD. That means that using a newer SIOD *might* cause some regressions.

I'm not trying to dissuade anyone from making the change, I'm just trying to give whoever does it a "heads up" that they may want to see if they can detect if there are any fixes that should be forward-ported into the new SIOD gimp swallows.

Tim

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Feb 7, 2004, at 1:14 am, Tim Mooney wrote:

As I recall, the SIOD that's part of gimp is not a "stock" version of SIOD, as there were various bugs detected and fixed in SIOD in the 0.99.x
and 1.2.x gimp releases. There *may* be fixes in the gimp's custom SIOD that never got back into the mainline SIOD. That means that using a newer SIOD *might* cause some regressions.

Do we know which version exactly? If so, it might make sense to either use a revision control system or fine grained diffs between that and the current version to bring The GIMP up-to-date instead of simply importing the new version and papering over the problems...

- -- Servus,
Daniel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iQEVAwUBQCQynDBkNMiD99JrAQL+wwf/Y7MPmsYqgXQpzROjxV59jj94StiumMZ8 DaMxsi5p9N7RDIrnEIleVz3MB3HPjWUSGDmFigi7w3Usyci4EzRbNwAtLJbGgNZp f2ulIZbMcAkr8pYHh/V4FU1RNmpW2gd61oiYM7xmHLOxFFas4tVzOuUmv1bvKE/8 89S6siYy8LuLe+FId0gitUM1Wy0qH4MrL8gV/CXRTK4pg6zgAJxTSICFiSvJx2KV vyKdmSp+0vptBniqY25hVv/s0HD+2S1qaJC0ok9RLkv6VvG/aF61ZHFf//WS0b28 3iHXZy/gVnkFins48qsIkLmHrpM8UHQWtK/ewUaJxGicUOvr9adYQQ== =g4it
-----END PGP SIGNATURE-----

On Fri, 2004-02-06 at 19:34, Daniel Egger wrote:

On Feb 7, 2004, at 1:14 am, Tim Mooney wrote:

As I recall, the SIOD that's part of gimp is not a "stock" version of SIOD, as there were various bugs detected and fixed in SIOD in the 0.99.x
and 1.2.x gimp releases. There *may* be fixes in the gimp's custom SIOD that never got back into the mainline SIOD. That means that using a newer SIOD *might* cause some regressions.

Do we know which version exactly?

The current SIOD used in the GIMP is "Release 3.2X MAR-96". The latest copy of SIOD I found was a tarball named siod-3.2.tar.gz and it says "Release 3.2 12-JUN-96".

I plan to compare the two versions to see what the differences are rather than just drop this other version in to place. I will also check the CVS log files to check for any bugs that may have been fixed in GIMP's current SIOD that may not have been passed back to the SIOD developers.

From: Sven Neumann

What we are aiming for is a lot more complex than what GtkPreview is providing. The goal is to have a widget that can zoom and pan. It should also provide an API that allows to use the same image processing routines for the preview as are used for the drawable. The plug-in author shouldn't have to care much about the preview.

Does this mean you continue with the plugins which create their own dialog and all interactive manipulation happens there, like gfig?

I wish plugins like gfig would operate on the image/view, not in separate window like now.

There are consequences: -Need for multirate images (MIP images) for low resolution preview -Plugin's preview area can be given as a rectangle on the image (just like 3D modellers allows user to define the area which is rendered)
-Plugins can make data layers on the image (gfig would make a vector layer)

MIP images would mean that large images may be efficiently edited at lower resolution. The operations are reflected to high resolution images later or when the system is idle enough.

If a plugin wants a separate preview to its dialog, then that is just a new view to the image, embedded to the dialog.

Regards, Juhana

Hi,

Juhana Sadeharju writes:

What we are aiming for is a lot more complex than what GtkPreview is providing. The goal is to have a widget that can zoom and pan. It should also provide an API that allows to use the same image processing routines for the preview as are used for the drawable. The plug-in author shouldn't have to care much about the preview.

Does this mean you continue with the plugins which create their own dialog and all interactive manipulation happens there, like gfig?

GFig is supposed to be completely replaced by the vectors tool sooner or later so that's probably not a good example.

I wish plugins like gfig would operate on the image/view, not in separate window like now.

We are mainly seeking for a short-term solution here that allows to add a preview to existing plug-ins w/o too many changes. What you are asking for is pluggable tools. This was attempted in the 1.3 series but we backed this change out because it exposed too much internals that are not yet in the state where we want anything but the core to work with it.

MIP images would mean that large images may be efficiently edited at lower resolution. The operations are reflected to high resolution images later or when the system is idle enough.

A GEGL-based GIMP is supposed to allow exactly that but we will have to do some rather major changes before this becomes real.

Sven

On Fri, 06 Feb 2004 16:51:28 +0100 Sven Neumann wrote:

Hi,

David Odin writes:

Anyway, this isn't clear in my mind for now. I'll propose a draft on this list as soon as I have more valuable thing to show.

I hope you are aware that there is an implementation already. We were not happy with the API and some implementation details but it is definitely worth to at least have a look at it:

http://refocus.sourceforge.net/preview/gimppreview.html

The major points in the discussion were that some people did not like the way that the preliminary version of the preview tried to prevent recursive updates and that the names did not start with GIMP.

As far as I can tell these points have been fixed in the first official release.

Ernst Lippe

Hi,

Ernst Lippe wrote:

Sven Neumann wrote:

http://refocus.sourceforge.net/preview/gimppreview.html

The major points in the discussion were that some people did not like the way that the preliminary version of the preview tried to prevent recursive updates and that the names did not start with GIMP.

As far as I can tell these points have been fixed in the first official release.

As a matter of interest, do you do any optimisation based on the current viewport in the preview? Do you generate a viewport-sized (+ margin, say) drawable from the original drawable that you pass to the function connected to the "update-preview" signal?

Cheers, Dave.

Hi,

Ernst Lippe writes:

http://refocus.sourceforge.net/preview/gimppreview.html

The major points in the discussion were that some people did not like the way that the preliminary version of the preview tried to prevent recursive updates and that the names did not start with GIMP.

As far as I can tell these points have been fixed in the first official release.

As far as I remember the major problematic point was the fact that the preview creates temporary drawables in the core instead of handling the preview completely on the plug-in side. Has this been addressed as well?

Sven

On Wed, 18 Feb 2004 10:18:58 +0100 Dave Neary wrote:

Hi,

Ernst Lippe wrote:

Sven Neumann wrote:

http://refocus.sourceforge.net/preview/gimppreview.html

The major points in the discussion were that some people did not like the way that the preliminary version of the preview tried to prevent recursive updates and that the names did not start with GIMP.

As far as I can tell these points have been fixed in the first official release.

As a matter of interest, do you do any optimisation based on the current viewport in the preview? Do you generate a viewport-sized (+ margin, say) drawable from the original drawable that you pass to the function connected to the "update-preview" signal?

Something like this was present in the old preview, I deliberately removed it because it was an unnecessary overhead for some plug-ins.

The first question that you face when you want to add this, should the drawable be scaled or not?

There is not much point in using an unscaled drawable because the plug-in could easily extract it from the original image, and there is no performance advantage by doing it in the preview. Also, I have added a utility function to the preview (gimp_preview_get_temp_drawable) for doing this, so it is very easy for the programmer to do this in the signal handler.

If you want to send a scaled drawable, for several algorithms this is simply useless overhead because they can't use it. There are many plug-in algorithms that are not scale-invariant in the sense that the scaled version of their output is different from the output when they use a scaled input. Also several algorithms have an output area that is different from their input area. Yet another class of algorithms are those that simply generate a new image that is independent from the input image. For all these classes of algorithms a scaled drawable is simply useless overhead. So when you really want to let the preview generate a scaled drawable, it should definitely be optional. In that case there would be yet another parameter for the preview, and the internal code would have to be more complicated (at the moment it only draws directly to the underlying GtkImage and that should be modified to write to the drawable as well). Also, I am not convinced that there would be a real performance advantage, for most plug-ins that I have seen, the plug-in algorithm itself will be the main bottle-neck.

For those algorithms that really want a scaled drawable there is another utitility function (gimp_preview_get_scaled_drawable).

Ernst Lippe

On Wed, 18 Feb 2004 13:51:40 +0100 Sven Neumann wrote:

Hi,

Ernst Lippe writes:

http://refocus.sourceforge.net/preview/gimppreview.html

The major points in the discussion were that some people did not like the way that the preliminary version of the preview tried to prevent recursive updates and that the names did not start with GIMP.

As far as I can tell these points have been fixed in the first official release.

As far as I remember the major problematic point was the fact that the preview creates temporary drawables in the core instead of handling the preview completely on the plug-in side. Has this been addressed as well?

No, the preview itself does not generate any temporary drawables. However there is a utility function for the plug-in to generate such temporary drawables, when it finds that more convenient, but in that case it is the responsibility of the plug-in and not of the preview. It can function perfectly without any temporary drawables.

Ernst Lippe

Hi Ernst,

Ernst Lippe wrote:

Dave Neary wrote:

As a matter of interest, do you do any optimisation based on the current viewport in the preview? Do you generate a viewport-sized (+ margin, say) drawable from the original drawable that you pass to the function connected to the "update-preview" signal?

>

The first question that you face when you want to add this, should the drawable be scaled or not?

The kind of logic I would have thought might be reasonable is:

1) if the original drawable is zoomed out, do a messy scale of the original to give the new drawable (accuracy isn't *hugely* important in general in this case), then take the tiles containing the part of that drawable that will be visible in the viewport, and generate a drawable from them, and apply the transform to that.

2) If the original drawable is at 100% or greater, then calculate the pixels that will be in the viewport, take the tiles containing that bounding box, generate a drawable from them, apply the filter, then expand the result as necessary to bring it up to the scale ratio.

For example, say I'm doing a blur on a 400% zoomed copy of an image, and the viewport (256x256, say) is showing pixels (0,0) -> (64,64). In this case I take all the tiles that box covers (easy enough in this case, it's just 1 tile), make a new drawable with those tiles, apply my blur (on a 64x64image it should be quick), and zoom the result to 256x256.

If I'm blurring a 25% zoomed copy, the easiest way is to do the scale on the image first, blur that with a radius r * 0.25, and show the result.

In the former case (zoomed in), I'm not blurring 90% of the image data that won't ever be displayed in the viewport, and in the latter I'm doing a "good enough" zoom on scaled image data (with no interpolation). Also, as long as the zoom ratio doesn't change, I keep my reference zoomed drawable around so that I don't have to re-do the calculation/zoom every time I pan around in the viewfinder.

How does that sound?

There is not much point in using an unscaled drawable because the plug-in could easily extract it from the original image, and there is no performance advantage by doing it in the preview.

The performance advantage is surely in performing the preview calculation on a (possibly small) subset of the total image data, isn't it?

> Also, I have

added a utility function to the preview (gimp_preview_get_temp_drawable) for doing this, so it is very easy for the programmer to do this in the signal handler.

Yes, I'd noticed - that could be one way of doing this, I guess. It would be nice to avoid plug-in programmers having to repeat this logic, though.

Cheers, Dave.

Hi,

Ernst Lippe writes:

No, the preview itself does not generate any temporary drawables. However there is a utility function for the plug-in to generate such temporary drawables, when it finds that more convenient, but in that case it is the responsibility of the plug-in and not of the preview. It can function perfectly without any temporary drawables.

Well, if the plug-in needs to allocate temporary drawables in order to conveniently display a preview, than this is a problem of the preview.

One of the design requirements of the preview is to provide a convenient way for plug-ins to preview their results. Convenient means that it should be possible to reuse the existing pixel manipulations routines without or with small changes. Allocating temporary drawables in the core is in my opinion not a viable solution for this problem.

It should however be possible to keep the temporary drawables completely on the plug-in side. To achieve this, the GimpDrawable wrapper would have to know whether it needs to get the tiles from the core (via shared memory or over the pipe) or allocate them in the plug-in process. I think this change would be rather straight-forward.

Sven

On Wed, 18 Feb 2004 15:18:49 +0100 Dave Neary wrote:

Hi Ernst,

Ernst Lippe wrote:

Dave Neary wrote:

As a matter of interest, do you do any optimisation based on the current viewport in the preview? Do you generate a viewport-sized (+ margin, say) drawable from the original drawable that you pass to the function connected to the "update-preview" signal?

>

The first question that you face when you want to add this, should the drawable be scaled or not?

The kind of logic I would have thought might be reasonable is:

1) if the original drawable is zoomed out, do a messy scale of the original to give the new drawable (accuracy isn't *hugely* important in general in this case), then take the tiles containing the part of that drawable that will be visible in the viewport, and generate a drawable from them, and apply the transform to that.

2) If the original drawable is at 100% or greater, then calculate the pixels that will be in the viewport, take the tiles containing that bounding box, generate a drawable from them, apply the filter, then expand the result as necessary to bring it up to the scale ratio.

For example, say I'm doing a blur on a 400% zoomed copy of an image, and the viewport (256x256, say) is showing pixels (0,0) -> (64,64). In this case I take all the tiles that box covers (easy enough in this case, it's just 1 tile), make a new drawable with those tiles, apply my blur (on a 64x64image it should be quick), and zoom the result to 256x256.

If I'm blurring a 25% zoomed copy, the easiest way is to do the scale on the image first, blur that with a radius r * 0.25, and show the result.

In the former case (zoomed in), I'm not blurring 90% of the image data that won't ever be displayed in the viewport, and in the latter I'm doing a "good enough" zoom on scaled image data (with no interpolation). Also, as long as the zoom ratio doesn't change, I keep my reference zoomed drawable around so that I don't have to re-do the calculation/zoom every time I pan around in the viewfinder.

How does that sound?

I don't think that this is the best approach for this specific case, and I don't think that it can be generalized for several other algorithms.

First of all you need a larger input area otherwise the image near the edges of the preview are incorrect. Because in most cases the preview image will be small, such defects are very noticable because a large part of the preview is "close to the edge". But the actual size of the margin depends on the blur radius, so when you want the preview to provide the scaled data, there should also be some mechanism to tell the preview how large this extra margin should be.

Second, actually there are very few algorithms that are truely scale-independent, in fact the only real algorithms that I have seen that are really scale independent are those where every output pixel was completely determined by the corresponding input pixel (i.e. the output pixel was independent from all other input pixels). So at best it is approximately scale-independent and we should hope that the difference is not too great, so that it is not visible to the user. Probably when your input image is already slightly blurred, i.e. it does not contain any sharp edges the difference will not be really noticable. But when the image does contain sharp differences there can be an important visual difference: consider an image with alternating black and white pixels (they alternate in both horizontal and vertical) when the image is zoomed at 50% and then blurred the result is either completely black or completely white, but never the true value which is simply grey. Of course this is an highly artificial example but I have noticed similar effects in real images.

Also with this approach you will probably get some very obvious visual effects when you zoom in or out. When you are zooming you expect that the image simply gets bigger or smaller, when there are other differences (and almost by definition you will get these when you run the algorithm on scaled data) the image will seem to "flicker" during the zoom. It is surprising how sensitive our brains are to such minute differences. In my experience this flickering is highly annoying, it does not feel "smooth". Of course your own milage may vary in this respect, but perhaps you should try it yourself.

Another point is that is not possible to generalize this to other algorithms, e.g. what would you do with a sharpen filter that only looks at the immediate neighbour pixels? If you only show the scaled version of the original image (which seems to be the only reasonable solution) you will give a wrong impression of the effects of the plug-in.

When you want to add a preview to some plug-in I would strongly suggest that you first implement it without any scaling in the plug-in. It is a lot easier to implement and it is guaranteed to give consistent results. If you are really convinced after this first step, that it gives a horrible performance, you could try to implement a new version that uses scaled data. After that you can at least compare the two versions and determine if it was really worth all the effort and how much the quality of the preview has deteriorated.

There is not much point in using an unscaled drawable because the plug-in could easily extract it from the original image, and there is no performance advantage by doing it in the preview.

The performance advantage is surely in performing the preview calculation on a (possibly small) subset of the total image data, isn't it?

Yes, but that is something that the plug-in algorithm should do, because it is the only place where you can determine what inputs are needed to generate a specific output area. Think for example of some whirl plug-in, to compute a given output area it will only need a subpart of the original image, but it can be very difficult to determine what part is really needed. So it is the responsibility of the plug-in algorithm to compute only a specific output area.

Anyhow, a good plug-in should already have the functionality to compute the outputs for a given area (gimp_drawable_mask_bounds), so it should not be too difficult to modify this to use the area that was determined by the preview.

Ernst Lippe

On Wed, 18 Feb 2004 16:19:06 +0100 Sven Neumann wrote:

Hi,

Ernst Lippe writes:

No, the preview itself does not generate any temporary drawables. However there is a utility function for the plug-in to generate such temporary drawables, when it finds that more convenient, but in that case it is the responsibility of the plug-in and not of the preview. It can function perfectly without any temporary drawables.

Well, if the plug-in needs to allocate temporary drawables in order to conveniently display a preview, than this is a problem of the preview.

The decision if the plug-in "needs" the temporary drawable is made by its designer and it is certainly not forced by the preview. It is perfectly possible to draw a row of pixels on the preview (indeed for a very long period that has been the only way you could draw on the preview, support for drawables is a recent addition). If a plug-in designer writes a plug-in in such a way that it can only output to a drawable, then it will always have to allocate a temporary drawable (unless you want to mess around with the original input drawable, which sound pretty horrible). But when the internal datastructures for the algorithm can be used to construct a single row for the preview there is no reason to use a temporary drawable.

One of the design requirements of the preview is to provide a convenient way for plug-ins to preview their results. Convenient means that it should be possible to reuse the existing pixel manipulations routines without or with small changes. Allocating temporary drawables in the core is in my opinion not a viable solution for this problem.

It should however be possible to keep the temporary drawables completely on the plug-in side. To achieve this, the GimpDrawable wrapper would have to know whether it needs to get the tiles from the core (via shared memory or over the pipe) or allocate them in the plug-in process. I think this change would be rather straight-forward.

But unless I am mistaken, this temporary drawable has only a limited functionality, because you cannot use any of the "core" operations on it.
So I am not really certain if it would be worth the effort.

Furthermore, this functionality would only be needed for those plug-in algorithms where it is difficult to compute an entire row of pixels, and actually I cannot remember that I have ever seen one. So if you have some good examples, perhaps the problem could also be solved by changing the interface of the preview, e.g. adding support for drawing tiles on the preview.

Anyhow, it does not have any real impact on the preview. At most, I would have to change a few lines in two of the helper functions.

Ernst Lippe

Hi,

Ernst Lippe writes:

The decision if the plug-in "needs" the temporary drawable is made by its designer and it is certainly not forced by the preview. It is perfectly possible to draw a row of pixels on the preview (indeed for a very long period that has been the only way you could draw on the preview, support for drawables is a recent addition). If a plug-in designer writes a plug-in in such a way that it can only output to a drawable, then it will always have to allocate a temporary drawable (unless you want to mess around with the original input drawable, which sound pretty horrible). But when the internal datastructures for the algorithm can be used to construct a single row for the preview there is no reason to use a temporary drawable.

So you are seeing the GimpPreview as just a widget that plug-ins can draw on. However our goal is to provide a way to add a preview to plug-ins basically w/o changing their code. The change should be limited to the plug-in dialog and a few hooks here and there. Your preview widget could be part of this infrastructure since it provides a way to draw pixels to the screen, but in its current state, it certainly doesn't meet the goals I outlined above.

One of the design requirements of the preview is to provide a convenient way for plug-ins to preview their results. Convenient means that it should be possible to reuse the existing pixel manipulations routines without or with small changes. Allocating temporary drawables in the core is in my opinion not a viable solution for this problem.

It should however be possible to keep the temporary drawables completely on the plug-in side. To achieve this, the GimpDrawable wrapper would have to know whether it needs to get the tiles from the core (via shared memory or over the pipe) or allocate them in the plug-in process. I think this change would be rather straight-forward.

But unless I am mistaken, this temporary drawable has only a limited functionality, because you cannot use any of the "core" operations on it.
So I am not really certain if it would be worth the effort.

I don't see how core operations would be useful at all. The only use of the temporary drawable is to allow the preview to be rendered using the same GimpPixelRgn routines that are used to render the final result.

Furthermore, this functionality would only be needed for those plug-in algorithms where it is difficult to compute an entire row of pixels, and actually I cannot remember that I have ever seen one. So if you have some good examples, perhaps the problem could also be solved by changing the interface of the preview, e.g. adding support for drawing tiles on the preview.

Basically any plug-in that works on pixel rows is less than optimal and should be rewritten at some point. Good plug-ins are supposed to work on tiles rather than rows. If our preview widget encourages the plug-in author to work on a row-by-row basis, then we will never get plug-ins that operate on the pixels in the most efficient way.

Sven

Hi,

Sven Neumann wrote:

Ernst Lippe writes:

The decision if the plug-in "needs" the temporary drawable is made by its designer and it is certainly not forced by the preview.

So you are seeing the GimpPreview as just a widget that plug-ins can draw on. However our goal is to provide a way to add a preview to plug-ins basically w/o changing their code. The change should be limited to the plug-in dialog and a few hooks here and there. Your preview widget could be part of this infrastructure since it provides a way to draw pixels to the screen, but in its current state, it certainly doesn't meet the goals I outlined above.

It is certainly a step in the right direction, though, and I think that it is something that we should try to use (and improve) during the 2.1 cycle. It is more than a simple widget that you draw on too - you get feedback from the widget about which pixel region is currently in the viewport, and you can quite easily generate a drawable from that which you pass to your filter function.

Given that there are now 2 developers interested in working on this (Ernst and dindinx) I think there is a good chance that working together on it (in GIMP CVS, so that we get some feedback from the plug-in authors who use it too) we will have a nice to use preview widget by 2.2

Cheers, Dave.

Hi,

Ernst Lippe wrote:

Dave Neary wrote:

1) if the original drawable is zoomed out, do a messy scale of the original to give the new drawable (accuracy isn't *hugely* important in general in this case), then take the tiles containing the part of that drawable that will be visible in the viewport, and generate a drawable from them, and apply the transform to that.

2) If the original drawable is at 100% or greater, then calculate the pixels that will be in the viewport, take the tiles containing that bounding box, generate a drawable from them, apply the filter, then expand the result as necessary to bring it up to the scale ratio.

How does that sound?

First of all you need a larger input area otherwise the image near the edges of the preview are incorrect.

That's a minor implementation issue - we can take the drawable used to generate the preview to be the viewport +/- some arbitrary amount of pixels, or perhaps take 1 tile more than we need in the horizontal and vertical direction.

part of the preview is "close to the edge". But the actual size of the margin depends on the blur radius, so when you want the preview to provide the scaled data, there should also be some mechanism to tell the preview how large this extra margin should be.

This assumes that the preview should be precise. One of the merits of the preview, though, is that it is an impression of the effect and renders quickly - quick and dirty should be OK. Of course, there's a compromise to be made in there. But I don't think plug-in previews need to be 100% exact.

But when the image does contain sharp differences there can be an important visual difference: consider an image with alternating black and white pixels (they alternate in both horizontal and vertical) when the image is zoomed at 50% and then blurred the

When the image is zoomed to 50%, the image itself is either grey or all black/white (depending on the scaling algorithm we use) - if it's grey, then so will the blur be. That said, I get the point.

Also with this approach you will probably get some very obvious visual effects when you zoom in or out.

Again, I see the point. And I agree that your proposal to start with unscaled data and see how slow it is before moving on to scaled copies is reasonable.

Yes, but that is something that the plug-in algorithm should do, because it is the only place where you can determine what inputs are needed to generate a specific output area. Think for example of some whirl plug-in, to compute a given output area it will only need a subpart of the original image, but it can be very difficult to determine what part is really needed. So it is the responsibility of the plug-in algorithm to compute only a specific output area.

Good point. But shouldn't the preview widget cater to the most common case, while allowing the plug-in to address the less common case? I would prefer to see all convolution based plug-ins (that are essentially local) and render plug-ins (where the result is entirely predefined by a seed) to have a nice easy way of generating a preview that consisted of more or less 1 or 2 function calls, and have a more complicated API to allow things like whorl and the like to calculate their effects using a preview widget, with some more work.

Anyhow, a good plug-in should already have the functionality to compute the outputs for a given area (gimp_drawable_mask_bounds), so it should not be too difficult to modify this to use the area that was determined by the preview.

It would be nice to move some of this common code into the preview widget itself, so that the common case doesn't have to worry about it.

Cheers, Dave.

Sven Neumann wrote:

> So you are seeing the GimpPreview as just a widget that plug-ins can > draw on. However our goal is to provide a way to add a preview to > plug-ins basically w/o changing their code. The change should be > limited to the plug-in dialog and a few hooks here and there.

I thought I'd repeat this, because it's a major design constraint. (Also, a very good idea.)

I think it's clear that some plugins (e.g. sharpen, noise removal) will require a small, unzoomed region of the image to judge the effect, while others (e.g. whirl, colourise) require a small version of the entire image.

For the first group: if the plugin uses gimp_drawable_mask_bounds correctly, then it should work correctly if the preview reports only a small masked area.

For the second group: if the plugin is scale-independent, then it should work correctly if the preview reports a small image.

On Thu, 19 Feb 2004 16:45:45 +0100 Dave Neary wrote:

Hi,

Ernst Lippe wrote:

Dave Neary wrote:

1) if the original drawable is zoomed out, do a messy scale of the original to give the new drawable (accuracy isn't *hugely* important in general in this case), then take the tiles containing the part of that drawable that will be visible in the viewport, and generate a drawable from them, and apply the transform to that.

2) If the original drawable is at 100% or greater, then calculate the pixels that will be in the viewport, take the tiles containing that bounding box, generate a drawable from them, apply the filter, then expand the result as necessary to bring it up to the scale ratio.

How does that sound?

First of all you need a larger input area otherwise the image near the edges of the preview are incorrect.

That's a minor implementation issue - we can take the drawable used to generate the preview to be the viewport +/- some arbitrary amount of pixels, or perhaps take 1 tile more than we need in the horizontal and vertical direction.

For the current preview it is even a non-issue, it only becomes relevant when you expect that the preview should give you an already scaled image. Even when the preview should generate a scaled image, I think that you should think very carefully about the margins. I don't like the idea of having fixed margins because then you are taking a design decision in a place where it does not belong, it obviously belongs in the plug-in and not in the preview. How do you handle the case where part of the margins fall outside the drawable? The "normal" solution would to supply zeroes for these areas, but there are several plug-in algorithms that are convolutions and they usually have a nasty behaviour when there are too many zero's around. I think that in any case the preview should always give the absolute image coordinates of the area that must be rendered to the plug-in, there are several plug-in's that need this information (most "warping" plug-in's need it). Wouldn't it be confusing to the implementor when the area that they are supposed to render is different from the input area?

part of the preview is "close to the edge". But the actual size of the margin depends on the blur radius, so when you want the preview to provide the scaled data, there should also be some mechanism to tell the preview how large this extra margin should be.

This assumes that the preview should be precise. One of the merits of the preview, though, is that it is an impression of the effect and renders quickly - quick and dirty should be OK. Of course, there's a compromise to be made in there. But I don't think plug-in previews need to be 100% exact.

This is a decision for the plug-in maker, but I believe that the preview should be as accurate as possible. It is probably a bias from my background, my main plug-in does some pretty slow computations, and therefore badly needs a preview. I really hate it, when I discover, after a long period of waiting, that I chose the wrong parameters because of a defect in the preview process.

In some cases it may be a valid decision, I am just arguing that it should not be the "default" decision that can be taken without further analysis, because the implicit assumption "users will never see the difference" is in general wrong

Yes, but that is something that the plug-in algorithm should do, because it is the only place where you can determine what inputs are needed to generate a specific output area. Think for example of some whirl plug-in, to compute a given output area it will only need a subpart of the original image, but it can be very difficult to determine what part is really needed. So it is the responsibility of the plug-in algorithm to compute only a specific output area.

Good point. But shouldn't the preview widget cater to the most common case, while allowing the plug-in to address the less common case? I would prefer to see all convolution based plug-ins (that are essentially local) and render plug-ins (where the result is entirely predefined by a seed) to have a nice easy way of generating a preview that consisted of more or less 1 or 2 function calls, and have a more complicated API to allow things like whorl and the like to calculate their effects using a preview widget, with some more work.

Yes, but the most general solution is simply to let the plug-in work on unscaled data and leave the scaling to the preview. This works for all plug-ins. When you look at it this way a plug-in algorithm that is scale-independent is only a special case.

Also you are assuming here that convolutions are scale-independent, this would only be true if we were dealing with continuous images, convolutions are in general not scale-independent when you deal with images that consist of discrete pixels. This may not be very important when you are only considering "blurring convolutions" but there are also several convolutions that are "sharpening" convolutions and for these convolutions there is a big difference. Also in many cases it is not at all obvious how you should scale the convolution matrix (e.g. the sharpen plug-in) or it could be quite expensive to compute the new convolution matrix (e.g. my own refocus plug-in).

Anyhow, a good plug-in should already have the functionality to compute the outputs for a given area (gimp_drawable_mask_bounds), so it should not be too difficult to modify this to use the area that was determined by the preview.

It would be nice to move some of this common code into the preview widget itself, so that the common case doesn't have to worry about it.

Honestly, I don't see any advantage with respect to code complexity. What you are proposing will introduce unnecessary dependencies between the preview and the plug-in. When the plug-in requirements are simple, my solution is also simple in most cases it will only require a single function call to obtain the scaled area. When the plug-in requirements are not simple, it is not at all certain that the plug-in developer will be satisfied with any standard solution. So letting the preview generate a scaled image will only increase the complexity of the whole system because you will create new dependencies between the components.

When I look at any design decision, there are two major aspects: correctness and simplicity. In most cases these are clearly related, it is in general pretty difficult to show that a decision is correct when it is not simple. Feeding scaled data to a plug-in at first sight appears to fail at both points, in general the outputs will be less correct than simply scaling the unscaled outputs, and it is more complex because in general you will have to adapt the plug-in algorithm to a specific scale.

So when you look at the whole idea, the whole reason behind it is that you believe that it is faster. Now, in virtually all cases, performance is far less important than correctness and simplicity. I have seen a lot of systems over the years, and it is pretty rare that you encounter a case in practice where performance is really a serious issue, most problems are related to correctness (bugs) and simplicity (maintenance). Most optimizations only improve performance with some constant factor, and in most cases you can achieve the same performance increase by buying a new computer. There is no equally simple solution to problems with correctness and simplicity.

Now when you look at the performance argument for feeding scaled data, it only becomes relevant when the preview is zoomed out. Actually, I have serious doubts whether that should happen often. For most plug-ins users are main interested in small size reductions, e.g. it is very difficult to judge the effects of a plug-in when the preview shows an reduced version of the entire image. I would expect that in most cases users are most interested to see the result at 100% for the most relevant parts of their image.

The only category of plug-ins that I can see for which it would be useful to see a scaled version of the entire image are the warping/whirling plug-ins that perform non-local transformations on the image, but unfortunately for these transformations using scaled inputs can give highly misleading results. In most cases these algorithms will magnify certain parts of the image. Now think of what will happen when the plug-in magnifies a certain area with a certain factor and you view the output reduced with the same factor. When you use unscaled inputs to the algorithm, you will see outputs that are highly similar to the original input area, but when you supply the plug-in with scaled data you will mainly see the artifacts of the scaling algorithm.

The bottom-line is that I really think that the default decision should really be to use unscaled data and that you should only use scaled data after a carefull analysis.

Ernst Lippe

On Thu, 19 Feb 2004 16:00:08 +0100 Sven Neumann wrote:

Hi,

Ernst Lippe writes:

The decision if the plug-in "needs" the temporary drawable is made by its designer and it is certainly not forced by the preview. It is perfectly possible to draw a row of pixels on the preview (indeed for a very long period that has been the only way you could draw on the preview, support for drawables is a recent addition). If a plug-in designer writes a plug-in in such a way that it can only output to a drawable, then it will always have to allocate a temporary drawable (unless you want to mess around with the original input drawable, which sound pretty horrible). But when the internal datastructures for the algorithm can be used to construct a single row for the preview there is no reason to use a temporary drawable.

So you are seeing the GimpPreview as just a widget that plug-ins can draw on.

Basically, yes.

However our goal is to provide a way to add a preview to plug-ins basically w/o changing their code.

It is an interesting idea, but when you look at the requirements for the preview as they were discussed last year (see http://refocus.sourceforge.com/preview/requirements.html) it was not part of the list.

If you would have proposed it as a requirement at that stage I would have rejected it, because I simply think that it is infeasible as it stands.

There are several point that you will virtually always have to change when you want to add a preview to an existing plug-in, and in some cases (some plug-ins have pretty messy code) these changes have to be rather drastic. A few points:
* How do you detect that parameters have been changed? Users will expect that the preview gets updated when they change some parameters. Many plug-ins do not need to detect this at the moment because the values only become relevant when the user presses the OK button. When rewriting such a plug-in you will have to add modification detection code, and you will also have to modify the code that collects the current values of the parameters and runs the underlying algorithm with these parameters. Some plug-ins completely mix their business logic with their GUI and in these cases it might require quite a bit of work to fix this. * Current plug-ins assume that they can write the results back to the input drawable. So you will either need to coerce to write back their results somewhere else or you will have to mess around with the original drawable (probably some hidden global "preview-mode" switch). * Current plug-ins are not very flexible in the area that they render. Some always generate the entire drawable, and others generate the area from gimp_drawable_mask_bounds. For the latter category you could of course think of a hack that changes the output of gimp_drawable_mask_bounds based on some hidden global "preview-mode" switch, but then you will also have to consider the consequence of this decision for all other places where this function may be used, not to mention the fact that the whole idea of global mode switches is inherently ugly.

So I don't think that should try to find some solution without rewriting, but to find some framework that could easily fit a large set of the current plug-ins.

The change should be
limited to the plug-in dialog and a few hooks here and there.

Unless there have been some major changes to the GIMP plug-ins since I last looked at them, I believe that this idea is not very realistic.

Your
preview widget could be part of this infrastructure since it provides a way to draw pixels to the screen, but in its current state, it certainly doesn't meet the goals I outlined above.

One of the design requirements of the preview is to provide a convenient way for plug-ins to preview their results. Convenient means that it should be possible to reuse the existing pixel manipulations routines without or with small changes. Allocating temporary drawables in the core is in my opinion not a viable solution for this problem.

It should however be possible to keep the temporary drawables completely on the plug-in side. To achieve this, the GimpDrawable wrapper would have to know whether it needs to get the tiles from the core (via shared memory or over the pipe) or allocate them in the plug-in process. I think this change would be rather straight-forward.

But unless I am mistaken, this temporary drawable has only a limited functionality, because you cannot use any of the "core" operations on it.
So I am not really certain if it would be worth the effort.

I don't see how core operations would be useful at all. The only use of the temporary drawable is to allow the preview to be rendered using the same GimpPixelRgn routines that are used to render the final result.

Uh, are you saying here that we can simply ignore those plug-ins that call any of the core tool operations or other plug-ins?

Furthermore, this functionality would only be needed for those plug-in algorithms where it is difficult to compute an entire row of pixels, and actually I cannot remember that I have ever seen one. So if you have some good examples, perhaps the problem could also be solved by changing the interface of the preview, e.g. adding support for drawing tiles on the preview.

Basically any plug-in that works on pixel rows is less than optimal and should be rewritten at some point. Good plug-ins are supposed to work on tiles rather than rows.

I am afraid that with this definition there are very few "good" plug-ins.

If our preview widget encourages the plug-in author to work on a row-by-row basis, then we will never get plug-ins that operate on the pixels in the most efficient way.

Like I said, I don't object to adding a tile-based interface as well, it is just that I have not yet seen any plug-in that needed it.

Now obviously you have a problem with having to allocate temporary drawables in the GIMP core just for the sake of previewing.

But what is the problem? Is it just a performance issue? As far as I have seen, it is not a serious issue, I have a pretty slow computer and the performance of the preview is quite acceptable. In most cases the drawables are pretty small, much smaller than the real images. In general I am pretty skeptical about design decisions that sacrifice simplicity for performance's sake, in the long term that is generally a bad strategy (yes there are some cases where it is a correct decision but you should always analyze them pretty carefully).

So what is the simplest solution for the plug-ins?

Most existing plug-ins will write their output only to their input drawable. But for the preview we don't want to modify the original drawable, but the plug-in must somehow be coerced to write its output to something that the preview could read. If you really don't want to change the plug-ins algorithm at all the only solution is to somehow intercept the modifications to the original drawable and route them to the plug-in. This appears to be a different solution than you proposed, and I think that it would be very messy, you would have to change the functions that operate on the drawable to check if they should operate on the real drawable or that they should send their result to some other structure that could be used with the plug-in. Then the plug-in would have to somehow set a switch that is associated with this drawable to indicate if it is in "preview-mode" or not. This entire approach looks pretty messy, and it can't see how it could work for plug-ins that invoke any of the core painting tools or other plug-ins. So on the face of it this approach does not look very promising.

Another approach is to rewrite each plug-in so that it can use an output data-structure that is different from the input drawable. The most obvious solution is to give the plug-in a second output drawable that could be different from the input drawable. For most plug-ins that I have seen this is a fairly easy modification. I guess that you have also been thinking along these lines. So here is were your proposal comes in. My first objection against it, is that it appears to break the existing semantics of a drawable because most operations that are valid for a drawable are not valid for a temporary drawable. Also this makes the existing code more complicated, the cache manager must also be able to handle tiles that are never sent to the GIMP core, and there must be some kind of error handling for unsupported operations on these temporary drawables. I don't know how complicated this would be but it certainly won't make the existing code more simple. Another problem for which I don't see an easy solution is how many tiles should be cached for the drawable. After all when you are worried about performance you are probably not very happy when the temporary drawable has the same number of tiles as the original image. A possible solution is to allocate only a single fixed tile for the entire temporary drawable, but in that case this solution is only usable for plug-in algorithms that can compute individual tiles in a single pass. I believe that such plug-ins are only a very small fraction of the total set of existing plug-ins. So, unless you consider it OK to keep all tiles for the temporary drawable in core, it seems that there must be some additional function call to "commit" a certain tile. At this moment I don't see an easy method that the cache manager could use to determine this, a possible solution would be to use gimp_tile_unref, but then you would have to be very careful not to call this function inside the other pixel region routines, e.g. during a gimp_pixel_rgn_get_row.

A slightly different solution for the temporary drawable problem would be to define a new object that can handle both rendering to the tiles of a drawable as well as rendering to some local set of tiles. Essentially this object would have an interface that is very similar to the pixel-region interface. I have implemented something similar for my refocus plug-in and I consider it more elegant that changing the existing semantics of a drawable. After all, in cases where you could successfully use temporary drawable, you are only using a very limited part of the drawable functionality, effectively you are assuming that a drawable is simply a collection of tiles. Of course the plug-ins must be rewritten so that they use the new function calls instead of the old pixel region functions, but it seems that you could easily achieve most modifications with a simple textual substitution.

Still I am not very convinced that it is really worth the effort. There are only very few tile-based plug-ins for which "temporary drawable" might be the best approach. A large number of the plug-ins generate data on a row basis and for these plug-ins it might be both simpler and faster (no tile overhead) to simply write the generated rows to the preview.

So you are completely correct when you say that preview plug-in does not solve all of your plug-in problems.

But I remain quite skeptical of your implicit suggestion that the overhead due to using a real drawable is important. When you look at the total sequence of events that is normally used to generate a new content of the preview there are quite a number of steps:
* X generates a mouse event.
* The mouse event gets routed to GTK (involves at least one process swap, I am not completely certain if the window manager is involved as well).
* GTK processes the event and routes it to the preview. * Preview allocates a new drawable (actually it could reuse the previous drawable when it has the same size). * Preview calls the plug-in to render a new image. * Preview draws the image on the pixbuf. * GTK draws the pixbuf on the screen via X. So when you look at the whole process I really doubt that the drawable is in general a serious bottle-neck. Of course, I can be convinced otherwise if you could show me some good timing measurements.

Ernst Lippe

Hi,

Ernst Lippe writes:

However our goal is to provide a way to add a preview to plug-ins basically w/o changing their code.

It is an interesting idea, but when you look at the requirements for the preview as they were discussed last year (see http://refocus.sourceforge.com/preview/requirements.html) it was not part of the list.

I am pretty sure this point was mentioned. IIRC it has already been discussed on GimpCon 2000 and I think it's the basic and most important design requirement.

There are several point that you will virtually always have to change when you want to add a preview to an existing plug-in, and in some cases (some plug-ins have pretty messy code) these changes have to be rather drastic.

Without going into much details of your answer, it is clear that you completely missed my point. Of course there are some changes needed to the plug-in code. How large the changes are depends on the quality of the code, mainly in the user interface parts of it. When I said that only few changes should be needed when adding a preview, I was assuming an otherwise well-designed and well-written plug-in.

The point I was trying to make is that the actual image manipulation algorithm should not have to be touched. For the code that operates on the actual pixels, there must not be a difference between rendering the result or rendering the preview. This means that this routine can always work on a GimpDrawable and doesn't need to care if this struct wraps a real drawable or just some preview data. The preview doesn't even need to be tile-based (I think you said it would have to be). Plug-ins usually don't see any tiles, they work on pixel regions and that's exactly the API that they should be using when rendering a preview.

I don't see how core operations would be useful at all. The only use of the temporary drawable is to allow the preview to be rendered using the same GimpPixelRgn routines that are used to render the final result.

Uh, are you saying here that we can simply ignore those plug-ins that call any of the core tool operations or other plug-ins?

Yes. I think this is a safe assumption for the general case. Not too many plug-ins call other plug-ins. In the GIMP source tree there is not a single one that would need a preview and calls other plug-ins.

Basically any plug-in that works on pixel rows is less than optimal and should be rewritten at some point. Good plug-ins are supposed to work on tiles rather than rows.

I am afraid that with this definition there are very few "good" plug-ins.

That is correct, but if we provide a preview API that encourages to write good plug-ins, this number will increase. If our preview API is modeled after the bad sort of plug-ins, we will never get a reasonable codebase in the plug-ins directory. Of course my proposal also allows for a row-based algorithm since GimpPixelRgn provides that as well.

Now obviously you have a problem with having to allocate temporary drawables in the GIMP core just for the sake of previewing.

But what is the problem? Is it just a performance issue? As far as I have seen, it is not a serious issue, I have a pretty slow computer and the performance of the preview is quite acceptable. In most cases the drawables are pretty small, much smaller than the real images. In general I am pretty skeptical about design decisions that sacrifice simplicity for performance's sake, in the long term that is generally a bad strategy (yes there are some cases where it is a correct decision but you should always analyze them pretty carefully).

Performance is not the primary concern here. The problem is that if we encourages plug-ins to allocate temporary drawables in the core, we would have to add a framework that makes sure that these drawables aren't leaked. One of the main reasons to keep plug-ins as separate processes is to ensure that a badly written plug-in doesn't make the GIMP core leak memory. I am pretty sure that temporary drawables created by plug-ins will eat up our tile-cache quite fast.

In the long run we will have to improve how resources allocated by plug-ins are handled in the core. The core should be able to undo all operations in case a plug-in crashes and it should free all floating resources when a plug-in finishes it's job. If such a framework is in place, we can easily change the preview code to optionally allow a preview in the image window. The plug-in will then simply work on a core drawable and this can happen completely transparently.

Most existing plug-ins will write their output only to their input drawable. But for the preview we don't want to modify the original drawable, but the plug-in must somehow be coerced to write its output to something that the preview could read. If you really don't want to change the plug-ins algorithm at all the only solution is to somehow intercept the modifications to the original drawable and route them to the plug-in. This appears to be a different solution than you proposed, and I think that it would be very messy, you would have to change the functions that operate on the drawable to check if they should operate on the real drawable or that they should send their result to some other structure that could be used with the plug-in. Then the plug-in would have to somehow set a switch that is associated with this drawable to indicate if it is in "preview-mode" or not. This entire approach looks pretty messy.

What is messy about this approach? If we implement this in libgimp, the plug-in will not see much about it. It will ask for a preview drawable and either work on that or on the original drawable. Large parts of the plug-in will not even be able to tell the difference. To me this seems to be a rather elegant approach.

Another approach is to rewrite each plug-in so that it can use an output data-structure that is different from the input drawable. The most obvious solution is to give the plug-in a second output drawable that could be different from the input drawable.

No, that would mean making changes to the plug-in algorithm which is exactly what I don't want to see happening. I don't understand why an output drawable would be necessary at all.

For most plug-ins that I have seen this is a fairly easy modification. I guess that you have also been thinking along these lines. So here is were your proposal comes in. My first objection against it, is that it appears to break the existing semantics of a drawable because most operations that are valid for a drawable are not valid for a temporary drawable. Also this makes the existing code more complicated, the cache manager must also be able to handle tiles that are never sent to the GIMP core, and there must be some kind of error handling for unsupported operations on these temporary drawables. I don't know how complicated this would be but it certainly won't make the existing code more simple.

The existing code in libgimp is darn simple. I am not afraid of making it a bit more complex.

A slightly different solution for the temporary drawable problem would be to define a new object that can handle both rendering to the tiles of a drawable as well as rendering to some local set of tiles. Essentially this object would have an interface that is very similar to the pixel-region interface. I have implemented something similar for my refocus plug-in and I consider it more elegant that changing the existing semantics of a drawable. After all, in cases where you could successfully use temporary drawable, you are only using a very limited part of the drawable functionality, effectively you are assuming that a drawable is simply a collection of tiles. Of course the plug-ins must be rewritten so that they use the new function calls instead of the old pixel region functions, but it seems that you could easily achieve most modifications with a simple textual substitution.

I don't see why this goal cannot be achieved using the existing pixel-region interface.

But I remain quite skeptical of your implicit suggestion that the overhead due to using a real drawable is important. When you look at the total sequence of events that is normally used to generate a new content of the preview there are quite a number of steps:
* X generates a mouse event.
* The mouse event gets routed to GTK (involves at least one process swap, I am not completely certain if the window manager is involved as well).
* GTK processes the event and routes it to the preview. * Preview allocates a new drawable (actually it could reuse the previous drawable when it has the same size). * Preview calls the plug-in to render a new image. * Preview draws the image on the pixbuf. * GTK draws the pixbuf on the screen via X. So when you look at the whole process I really doubt that the drawable is in general a serious bottle-neck. Of course, I can be convinced otherwise if you could show me some good timing measurements.

As I said before, I don't think performance is the problem.

Sven