Re: [Gimp-developer] Gimp2 plugin porting problems
On Monday 03 May 2004 13:39, Stephan Menzel wrote: > G'day! > > On Sunday 02 May 2004 21:32, Jean-Luc wrote: > > There is a patch for refocus on sourceforge. > > If was built for 1.3 but I have applied it and, with this patch applied, > > the plugin works for me [tm] with gimp 2.0.1. > > > > You can find the patch at: > > http://sourceforge.net/tracker/?atid=535004&group_id=72588&func=browse I think that I have found cause of the Stephan's problem. My plugin used GTK-2, so in the makefiles I had to use some tricks to get the correct include path and libraries. I could not directly use the output of the old gimptool, because that used the wrong GTK versions. I did not have time to look at the patch at sourceforge, but it seems like Stephan is linking with the old version of the libgimp libraries. The obvious solution is to simply use the outputs from gimptool-2 instead of my hacked version. I am afraid that I don't have the time right now to suggest a good solution (anyhow I don't have Gimp-2 installed, so I can't test any modifications). Ernst Lippe ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] plug-in preview widget (another try)
On Monday 24 May 2004 19:11, Federico Mena Quintero wrote: > This is the right way to go. I'd say the list of requirements for a > preview widget for the GIMP are at least the following: > > 1. Have a way for the filter to specify whether the preview can zoom or > not; this is for filters which are not scale-invariant. Still, special > cases like blurring need to be able to zoom in and out, but cheat when > computing the preview: > > - scale the original image by 1/N > - blur with a radius of 1/N pixels > - draw that as the zoomed-out preview > > That is, it won't show exactly the same result as if you did > > - blur the original image with a radius of N pixels > - scale the result by 1/N > - draw that as the zoomed out preview > > but it will be pretty useful anyway. > > 2. Be able to request rendering of only the previewed area, and only > scrolled-in areas after that. Say the preview is (with, height) pixels > large and it starts at offset (xofs, yofs). When the plug-in's GUI > starts up, the preview emits a notification saying, "render the area at > (xofs, yofs, width, height)". If the user then scrolls the preview by > 10 pixels to the left, the preview should emit a notification saying, > "render the area at (xofs - 10, yofs, 10, height)". That is, rendering > of the preview should be incremental based on scrolling. > > 3. Normally the preview doesn't need to hand image data to the filter > --- the latter already knows how to get it using pixel regions. Still, > it would be useful to provide some sort of of > > gimme_temporary_pixel_region_for_zoomed_image (image, zoom_factor, ...) > > This is for filters which can display a zoomed preview and which don't > need to process the original image data, like color mapping plug-ins. > > 4. Support resizing the preview. Previews with a fixed size of 128 > pixels are not useful when you are a graphic designer with a wide-screen > monitor. > > 5. Support automatic compositing of images with opacity information > against a checkerboard --- this should just use the user preference for > image windows. > > I hope this is a useful starting point for designing an API. From what > I saw, Ernst Lippe's code seems to handle a lot of this stuff already. > It would be a lot easier to just resurrect that code and bring it up to > date rather than to write something from scracth. As far as I can see my preview widget can satisfy all of your requirements. > I don't think an API for super-slow filters is even worth considering. > People should just learn to write faster code :) That's not always possible. There are several classes of interesting algorithms, e.g. most image enhancement techniques, that are inherently slow. Also the fact is, that most current plug-ins are indeed not very efficient. But especially with slow algorithms you desperately need a preview. And even with a fast algorithm there will be cases when the user is probably faster, e.g. while scrolling or zooming a large preview image. So I certainly believe that slow algorithms are an important use case for the design of a preview. Ernst Lippe ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] plug-in preview widget (another try)
On Saturday 22 May 2004 14:54, Sven Neumann wrote: > geert jordaens <[EMAIL PROTECTED]> writes: > > Signals : > > 1. preview_draw : draw preview area from current preview buffer. > > 2. preview_update: Call-back for rendering function followed by > > preview_draw or call preview_draw from callback. > > (if possible send signal > > preview_draw from within callback to display rendering progress). > > 3. preview_changed : Call-back to determine which part of the > > drawable that must be rendered for preview. > > (after scrollbar position changed) > > I don't think any of this should be part of the GimpPreview widget. > IMO it's the plug-in's job to push the pixel data to the preview, not > the preview's job to request it. But the position of the previewed area and the current magnification are inherently properties of the preview itself. It seems pretty logical to make scroll and zoom buttons part of the preview widget and in that case it is the preview widget that will detect if the position or scale has been changed. So the most logical design is to let the preview call the plug-in algorithm and not the other way round. I can see nothing wrong with using signals in this case, because they are more flexible than the other standard solution of having call-back functions. Do you really propose that the plug-in itself handles all the GUI interactions for scrolling, zooming and resizing and that it also is responsible for recording the current position and scale and size of the preview? This seems very unelegant, to say the least. Also how do you handle plug-ins that have multiple previews? > Such a framework can be added later > as I outlined in the proposal I just sent to the list. The preview > widget itself doesn't need to know about the drawable it previews, nor > what part of it is previewed. It just displays a buffer the size of > the preview and that's it. Perhaps we optionally need an API that > allows to keep the buffer outside the preview widget. That would allow > the plug-in to render a larger version and implement scrolling by > changing the offset into the buffer. How are you going to decide the correct size for this area? When you make it substantially larger than the previewed area the response to user actions will become slower. It will happen frequently that this buffer will become invalid, e.g. when some parameters of the algorithm have been changed, when the user zooms out, when the image is scrolled over a larger distance. The only case where such a larger buffer might be useful is when the user only scrolls by very small amounts and in my experience that does not occur often. So having a larger buffer makes the design of the plug-in more complicated (how should it determine the "right" size for this buffer), it will cause a performance hit on many normal preview operations. Ernst Lippe ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] plug-in preview widget (another try)
On Saturday 22 May 2004 22:40, Nathan Carl Summers wrote: > On 22 May 2004, Sven Neumann wrote: > > So this API would allow you to queue a redraw even after the buffer is > > only halfway written. Of course you would also have to run the main > > loop for the redraw to actually happen. Anyway, I consider this rather > > bad style. IMO, if the preview takes considerable time, then it > > shouldn't be shown halfway done but instead the progress API should be > > used to draw a progress indicator in place of the preview. What do > > others think? > > There are a lot of image applications that perodically update the > preview. In fact, this is essentially what the gimp color balance tools > do -- load a large image and adjust the sliders intermittantly and you can > watch the previews go by. There are good arguments for incremental > update, and good arguments for a progressbar. For very slow plug-ins incremental updates are better, because the user can sooner detect and remedy any problems with the parameter setting or the correct scroll position sooner. It is especially useful during scrolling because it is frequently possible to determine from a small part of the new image if you are at the desired position or not. When the preview image only shows a progress-bar you loose this type of immediate feedback. (In my current version of the preview incremental updating does not work, even though I call gtk_widget_queue_draw on it. Like Sven indicated, I would probably need to call back to the GLib main loop) > But I think the real issue here is that slow previews should be computed > in small chunks in an idle handler so as to not impede interactivity. Another very important issue is how these computations can be halted when the image that is being computed has become obsolete. In my experience this happens very frequently. Ernst Lippe ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] plug-in preview widget (another try)
On Tuesday 25 May 2004 14:57, Sven Neumann wrote: > Hi, > > Ernst Lippe <[EMAIL PROTECTED]> writes: > > Do you really propose that the plug-in itself handles all the GUI > > interactions for scrolling, zooming and resizing and that it also is > > responsible for recording the current position and scale and size of > > the preview? This seems very unelegant, to say the least. Also how > > do you handle plug-ins that have multiple previews? > > No, I want to use the GtkScrolledWindow API for the scrolling and the > standard GtkWidget API for resizing. What do you mean with the GtkScrolledWindow API? Do you want to actually use GtkScrolledWindow with some image widget inside it that shows the rendered image (that is pretty expensive when the rendered image is large) or do you just want to implement a new widget that has the same API? > I want to completely leave > scaling out of this first basic widget. It will allow us to get rid of > GtkPreview and that's the main problem we need to solve now. Of course > it's a good idea to think beyond that and I agree that we will need a > more complex preview widget than what I proposed to start with. But zooming is actually a pretty complicated issue, and it will have a profound influence on your API. > However this is all not finished and I am open for other ideas. > Actually I am not too happy with the proposed API, especially the fact > that the buffer is outside the preview and how scrolling would have to > be handled. So I am perfectly willing to reconsider it. > > What is the point about plug-ins that have multiple previews? I fail > to see the problem; perhaps you can explain it to me. The point is that when you maintain many important parameters such as size and scale outside the previews you will have to keep track of which data belongs to which preview and you will have to hunt around to find the neccessary data. This is messy. > > I am currently trying to come up with a proposal for > GimpDrawablePreview, an extension to the GimpPreview interface that > should allow plug-ins to reuse their rendering function for the > preview. One of your main objections against my API was that it would require modifications to the rendering function (because I believed they were pretty minor, that was no problem for me but apparently you thought that this was unacceptable). As an alternative you proposed some alternatives, like temporary drawables and some global mode switch that caused all drawing operations to use a temporary drawable when that drawable was in "preview-mode". When you insist that the rendering functions may not be changed at all, you will probably have to come up with something like this. Finding a framework that allows this, should be the major design challenge at this point. It will require some important changes in the Gimp core. This design item will have a very big influence on the preview's API. So why don't you tackle this point first? So far you have not presented a detailed design solution. Instead of finding some quick ad hoc solution for a few plug-ins I would say that it is much more important to get this one right. I am afraid that your proposals so far sounded like horrible hacks in my ears, but perhaps if would work them out in more detail I might be convinced otherwise. Of course, when your real problem is how to add a nice functional preview to a few plug-ins, I know an easy solution :) > > How are you going to decide the correct size for this area? > > When you make it substantially larger than the previewed area > > the response to user actions will become slower. It will happen > > frequently that this buffer will become invalid, e.g. when > > some parameters of the algorithm have been changed, when the > > user zooms out, when the image is scrolled over a larger > > distance. The only case where such a larger buffer might > > be useful is when the user only scrolls by very small amounts > > and in my experience that does not occur often. So having > > a larger buffer makes the design of the plug-in more complicated > > (how should it determine the "right" size for this buffer), > > it will cause a performance hit on many normal preview operations. > > I agree but it certainly doesn't hurt to allow this kind of use. > That's why I say that we need a simple but very flexible widget > first. Most plug-ins will never use it's API but access it on a higher > level. But if a plug-in wants to do non-standard things, then it > shouldn't have to start with a GtkDrawingArea again. But an API where the preview simply tells the plug-in "give me this area at this magnification" is very flexible. When the plug-in decides that it is better to render a larger area and cache it, it can do so if it really wants to. Ernst Lippe ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] plug-in preview widget (another try)
On Monday 24 May 2004 09:26, Sven Neumann wrote: > Hi, > > Nathan Carl Summers <[EMAIL PROTECTED]> writes: > > There are a lot of image applications that perodically update the > > preview. In fact, this is essentially what the gimp color balance tools > > do -- load a large image and adjust the sliders intermittantly and you > > can watch the previews go by. > > Sure, but the question is if we expect the small preview area of a > plug-in to behave in that way? I'd say the answer is no. Why? The primary function of the preview is to preview the effects of certain parameters on the image. It seems only logical that the preview updates as soon as possible after a parameter change. When the plug-in algorithm is fast enough, I see no reason why the preview should not be updated automatically. The only alternative that I see is to have some separate "Update preview" button, but that is just awkward for the user. Ernst Lippe ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] File location for plug-in auxiliary files
The installed version of a plug-in can contain other files than just the executable, e.g. help files and locale files. When the user has root permissions these files can be installed on the standard locations for the system, but where should these files be installed when that is not the case? The most logical place appears to be ~/.gimp-x.x/myplugin/. An alternative is to group help-files and locale info for all locally installed plug-ins together in ~/.gimp-x.x/help and ~/.gimp-x.x/locale. A related problem is how to find the local installation directory for the user, in ancient times this used to be ~/.gimp but this was changed (in 1.1?) to ~/.gimp-x.x. Gimptool does not return this directory even though it uses it for --install. So I would like to propose that a --gimpdir option be added to gimptool (It is a bit difficult a the moment because gimptool just mysteriously vanished from CVS). Greetings, Ernst ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Layers, dialogs and other bits of love on Valentines Day
Marc Lehmann wrote: > I'd like to remind people that corba is not the only way to go, as there > is also dco and especially MCOP (which was designed for realtime and > multimedia applications). While CORBA might indeed be the best choice, it > mustn't be choosen just because it has more letters ;-> > >http://space.twc.de/~stefan/kde/arts-mcop-doc/ > > (the author couldn't get corba to work reliably (timing constraints) so he > choose to implement something suited for data transfer). It depends largely on what you try to achieve. When you just need a protocol for communication between plug-ins and Gimp that are all running on the same machine, you are free to choose any non standard protocol you like. However, if you want to interface with other applications you must choose a protocol that is a real standard. Basically for the next few years there are only two real candidates in this area: CORBA and (I hate to admit it) Microsoft's DCOM/COM+. I have worked with both, and CORBA is a mature standard with some good implementations. Other protocols like KDE's DCOP or MCOP as you mentioned are not serious standards. Using shared memory is only useful when the two processes are running on the same machine and you could still define a CORBA interface to set it up. So if we want to open Gimp for a distributed environment I think CORBA is the right way to go. Greetings, Ernst ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Layers, dialogs and other bits of love on Valentines Day
Marc Lehmann wrote: > I'd like to remind people that corba is not the only way to go, as there > is also dco and especially MCOP (which was designed for realtime and > multimedia applications). While CORBA might indeed be the best choice, it > mustn't be choosen just because it has more letters ;-> > >http://space.twc.de/~stefan/kde/arts-mcop-doc/ > > (the author couldn't get corba to work reliably (timing constraints) so he > choose to implement something suited for data transfer). It depends largely on what you try to achieve. When you just need a protocol for communication between plug-ins and Gimp that are all running on the same machine, you are free to choose any non standard protocol you like. However, if you want to interface with other applications you must choose a protocol that is a real standard. Basically for the next few years there are only two real candidates in this area: CORBA and (I hate to admit it) Microsoft's DCOM/COM+. I have worked with both, and CORBA is a mature standard with some good implementations. Other protocols like KDE's DCOP or MCOP as you mentioned are not serious standards. Using shared memory is only useful when the two processes are running on the same machine and you could still define a CORBA interface to set it up. So if we want to open Gimp for a distributed environment I think CORBA is the right way to go. Greetings, Ernst ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Layers, dialogs and other bits of love on Valentines Day
Marc Lehmann wrote: > > On Sat, Feb 24, 2001 at 01:58:06AM +0100, Ernst Lippe <[EMAIL PROTECTED]> wrote: > > protocol for communication between plug-ins and Gimp that are all > > running on the same machine, you are free to choose any non standard > > protocol you like. > > It's free software. You are always free to use whatever you like. Nobody > can force you to use some specific protocol for _network_ connections > because it exists. No, but i believe that distribution is a nice thing to have, e.g. to be able to communicate with scanners/printers that are not attached to your local machine or to be able to communicate with some 3D rendering application that is running on a powerful server somewhere. So I am very much in favor of a protocol that can handle network connections. > > Other protocols like KDE's DCOP or MCOP as you mentioned are not serious > > standards. > > Well, naming something "not a serious standard" is not a serious statement > ;) (Why?) Too few arguments perhaps? All right, what properties should a "good" standard have: * It must be unambiguous and clear. This is hard work that usually takes several iterations to get right. * It must be accepted by a large part of the target audience. * There must be good technical support for it in the form of tools and applications and additional documentation (tutorials etc.). CORBA scores good on these points. Its only drawback is that there are no really good open source implementations at the moment (there are good commercial ones), but I am certain that they will come. How do DCOP and MCOP score on these criteria? > > Using shared memory is only useful when the two processes are running on > > the same machine and you could still define a CORBA interface to set it > > So if we want to open Gimp for a distributed environment > > This is true. But so far everybody who tried it seemed to have given up. Why? Because of some inherent shortcomings in CORBA or in the implementations that they have used? > Anyway, you call something "not a serious standard" which you obviously > haven't even read. I have read them, and I am afraid that I was not very impressed with them as standard documents. As I said above, writing a good standard document is really hard work. > I was talking about MCOP, not shared memory. Yes, > MCOP is extremely fast with shared memory. It also also quite fast with > TCP (compare the average size of a corba packet with the mcop case for > example. And I am talking reality here, not "but in theory CORBA could"). There is no such thing as the size of a corba packet, it is highly dependent on the implementation you're using and the situation. > The only pre-existing argument in favour of CORBA is, in fact, that gnome > uses it and to be very compatible with gnome you must base your software > on corba. This argument might be a very important one (e.g. KDE doesn't > use CORBA ;) since there are strong historical ties between gnome and > gimp (the mother of it all). It does not mean that not thinking about > alternatives is verboten. My argument is simply that CORBA is a good standard. > In fact, calling MCOP "not serious" without having looked at it just shows > that most people do not even *think* about possible alternatives but just > run blindly into some direction. I looked at the MCOP documentation. I have been using CORBA in some real world applications and it works. > Remember that I am not advocating MCOP here, but rather thinking > critically about CORBA, it's usefulness and it's application. Just because > CORBA was done by OMG *must* not mean to use it blindly. Otherwise we > could just as well also follow windows instead of trying to innovate (the > gimp menus, for one thing, are definitely non-standard. I would love them > to become standard. But as they are, they are not a "serious standard" > because neither a standards agency advocates them nor are they widely > used). > > For example, what has CORBA done to gnome so far? All I see is a > bewildering multitude of apis that most people don't understand. Gnome > really *has* become a mega-API with functions for each and everything and > then some. In practise this leads to hard-to-factor components because > nobody understands the dependencies anymore. A famous example of this is > the annoying stubbornness of many gnome applications to start a whole > bunch of other processes (the gnome-panel for example), without being > asked for. This leads to strange effects sometimes: > >On my neighbours display (often an IRIX machine) I can see the 4Dwm >environment together with - for him - a quite useless gnome-panel >and other gimmicks he cannot tur
Re: [Gimp-developer] [patch] unbelievable speedup for bumpmap...
The speedup that you see is probably mainly caused by better caching. There is a bug in the tile cache size for the plugin. The cache is under most circumstances too small and this means that every requested tile is not in the cache and must be transmitted from the main gimp process (SLOW). Effectively this means that every tile of the drawable is read and written gimp_tile_height (normally 64) times. Your modification is better, I expect that every tile is read and written gimp_tile_height/BLOCKS = 2 times (but when a selection is used it will normally be 3 times). This could be somewhat improved by setting BLOCKS = gimp_tile_height, when the selection starts at a y-position that is a multiple of gimp_tile_height (e.g. when there is no selection) every tile will probably be read/written once, but when the selection starts at a different position, every tile will still be read/written twice. I used a different approach that gives speedups similar to yours but that should read/write every tile only once. The solution is pretty simple: just enlarge the cache size. What is the problem with the cache size? The current code uses: gimp_tile_cache_ntiles (2 * (drawable->width + gimp_tile_width () - 1) / gimp_tile_width ()); The idea here is to cache one row of tiles for the source drawable and one row for the destination drawable. But this is not enough because there is no room in the cache for the bitmap tiles! There is a smaller problem here too, when a selection is used, it is overkill to have a cache for the full width of the drawable. I've attached a patch with my modifications. I hope that someone examines them critically and incorporates them into the distribution. I prefer my approach because it should give better performance and it keeps the code cleaner. Other improvements are still possible. I expect that it should be possible to rewrite the algorithm such that the tile cache contains only 3 tiles. From what I see the algorithm is the same in the horizontal and vertical direction. The current implementation uses 3 extra buffer-rows so when we add 3 extra buffer-columns it should be possible to rewrite the algorithm so that it processes one tile at a time instead of a full row. Thanks for pointing out a pretty big performance problem with the plug-in. Greetings, Ernst <[EMAIL PROTECTED]> patchfile
Re: [Gimp-developer] [patch] Major speedup for whirl&pinch plugin
I think this is yet another tile-cache problem. Georg Acher wrote: > > On Thu, Apr 05, 2001 at 12:45:52PM -0500, Kelly Martin wrote: > > > Hm, it does not. The issue with whirlpinch is that there's only a > > weak locality relationship between destionation pixels (which are > > iterated across the image) and source pixels (which are fetched with > > the pixel fetcher). I haven't looked too closely at your blocking > > That is right, but destination and source for themselves have good locality > (ie. the next pixel isn't 500 pixels away from the last). This is an important observation. > > > patch, but I suspect that much the same improvement would be had by > > using a pixel region (which respects tiles) to iterate across the > > destination region. I agree, but the current algorithm writes two rows (top and bottom) at the same time, so it is not immediately possible to use the standard pixel region iterator. > > That is possible... Is there a filter that definitely uses the pixel region > stuff? Most filters I have seen only use one row, which may not be enough > "locally", since it uses only one pixel but has to fill a whole cacheline > (4/8 pixel). I will try whether I can speed up bumpmap also, since this > takes also the magical 30s and is much more often used in scripts than the > whirl&pinch module. > > I don't know how large a tile is, but since IMHO the major impact of > blocking seems to come from the CPU cache, I suspect that is too big for > older CPUs. I have done the whirl&pinch blocking thing about three years ago > (and forgot to send the patch), and tried it on an Alpha21164 and a P5. I think you're looking in the wrong direction here. Similar to the bumpmap (see my other message) I strongly suspect that the tile-cache is too small. You can check this for yourself by profiling your code. I expect that there is hardly any difference in processor time between your version and the original but that there is an important difference in the number of calls to gimp_tile_get and gimp_tile_put. (Sorry, did not try that myself). Requesting tiles from the main Gimp process is pretty expensive, it involves several context switches and a lot of copying. This is orders of magnitude slower than copying data within the plugin process from the tile cache to some other buffer. The whirlpinch plugin uses a cache size that is only big enough to handle the output tiles, there is no room for input tiles. This leads to a series of cache misses and horrible performance. Your modifications improve the cache-hit ratio because it processes larger chunks of data. However, it is not a fundamental solution. The easiest short time solution is to increase the cache size with the number of input tiles that are needed to compute one row of the output (I don't know if this can be easily determined). The more fundamental solution is to rewrite the algorithm so that it works on a tile by tile basis. In that case the minimum cache size is only 2 (for the output tiles) plus the number of input tiles that are needed to compute one output tile. Of course it is better to use a somewhat larger cache size because adjacent output tiles can use the same input tiles. Greetings, Ernst <[EMAIL PROTECTED]> ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [patch] unbelievable speedup for bumpmap...
Kelly Martin wrote: > > If the algorithm is pixel-by-pixel (each output pixel depends only on > exactly one input pixel from each region being iterated over, and > those regions are all the same size) there is absolutely no excuse not > to use the pixel region iterator, which will automagically minimize > tile accesses to the lowest number possible. > IIRC, the bumpmap > drawable need not be the same size as the input/output drawable, The sizes may be different indeed and there also an option for tiling (repeating) the bitmap. > so a > pure region iterator cannot be used, but at least using the region > iterator for the input & output would limit the use of direct fetches > to the bumpmap drawable. > When the output pixel depends on neighboring pixels (e.g. I strongly suspect that bumpmap uses a 3 x 3 neighborhood) the region iterator does not work very well. Sometime ago I wrote a piece of code that can handle neighborhoods without fetching tiles twice. I needed this because I was applying convolutions where I needed a neighborhood of say 20x20. Basically what my code does is maintain a buffer that holds two rows of tiles plus some extra for the vertical neighborhood. It handles those nasty details like adding borders and fetching tiles. It works for my plugin but it must still be documented and some missing features must still be implemented. There are several filters where it could potentially be used, so if anyone is interested I could try to clean it up. Greetings, Ernst ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Convolution in the Gimp core
Austin Donnelly wrote: > > Actually, the core could do with a tile convolution, since currently > it copies data into a tempbuf before convolving it. This makes some > tools more effificient (or incorrect) eg iscissors. I'd love to see convolution in the Gimp core. I've written some code that is pretty well optimized for larger convolution matrices, that might be useful. But there are several design issues that must be sorted out like: * What data type for the convolution matrix? the current core only seems to support integers, for my applications I found that floating points are really necessary. * How to handle image boundaries? Treating pixels outside the image as zero gives in many case undesirable results, my code also supports mirroring but several other options are possible. * What sizes of convolution matrices must be supported? This is an important issue. When you want to support larger matrices (e.g. 20x20) the most efficient approach is to copy the tile that you are processing and (parts of) neighboring tiles into a buffer and perform the convolution on the contents of the buffer. In this way the inner loops of the convolution can be much better optimized. When the size of the matrix is small (say 3x3) it could be more efficient to use the data from the tile directly (without copying) and to treat the boundaries of the tile as a special case. I am willing to do a large part of the coding, but only when there is enough support for this issue from the "core" Gimp developers. Greetings, Ernst <[EMAIL PROTECTED]> ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Convolution in the Gimp core
Austin Donnelly wrote: > > On Sunday, 8 Apr 2001, Ernst Lippe wrote: > > > Austin Donnelly wrote: > > > Actually, the core could do with a tile convolution, since currently > > > it copies data into a tempbuf before convolving it. This makes some > > > tools more effificient (or incorrect) eg iscissors. > > > > I'd love to see convolution in the Gimp core. > > We already have convolution code in the core. However, it uses the > copying technique, and doesn't deal with tile boundaries at all (much > less image boundaries). > As far as i can see i does some image boundary handling, by simply copying the source pixels near the boundary. > I do think a proper tile-based convolver is needed, and I think the > developers would support such a move. Unfortunately, I don't have the > time to co-ordinate this :( > > > I am willing to do a large part of the coding, but only when there is > > enough support for this issue from the "core" Gimp developers. > > I think there is support. Thanks for your moral support. But what i am looking for is someone to help making design decisions, like the points that i mentioned in my previous message. I don't think that that is a very time-consuming job, there are not any really difficult issues and i expect that only minor changes to the code are needed. Is anyone currently responsible for the convolution code? Greetings, Ernst <[EMAIL PROTECTED]> ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Preview requirements
A preview widget for plug-ins is one of these items that has been on the Gimp todo list for a long time. In order to get some feedback from other developers we have compiled a list of requirements for a preview widget. The list is based on our own experiences and previous discussions on this mailing list. Our goal is a preview widget that could be used by most plug-ins. We would like to hear your opinions on the following points: * Is the list complete? * Are the requirements sufficiently clear? * Are there any unnecessary requirements? We are currently working on the API and a prototype implementation. Our current implementation is based on Shawn Amundson's GimpPreview widget. It covers most of the requirements in this list, but is still mainly alpha code. When there are no major additions to these requirements we hope to publish an API proposal in the next weeks. greetings, Ernst Lippe <[EMAIL PROTECTED]> Maurits Rijk <[EMAIL PROTECTED]> Requirements for a GIMP plug-in preview widget == This document gives a possible list of requirements for a preview widget that can be used by GIMP plug-ins. This is the version 1.0. This document was written by Maurits Rijk <[EMAIL PROTECTED]> and Ernst Lippe <[EMAIL PROTECTED]>. Requirement 1. A plug-in author must be able to write a single version of the rendering function that can both be used for rendering to the plug-in and for rendering to the final drawable. Far too many plug-ins that have a preview contain two different versions of the rendering algorithm: one for the preview and another one for the final result. For plug-ins that don't have a preview yet it is very desirable that the interface for generating a rendered image for the preview is very similar to the interface for generating the final results. Requirement 2. The preview must support a GUI for scrolling through the image. There are two possible GUI styles: dragging in the preview and using scrollbars. These could also be combined. Open issue: Scrollbars make the widget visually bigger and makes its internal structure more complicated. The alternative of giving the preview widget two GtkAdjustments, that can be used by the developer to "wrap" the widget with scroll-bars, does not work when the preview widget has a visible scroll-bar and/or zoom controls. Scroll-bars will not be supported in the first release of the preview widget. Requirement 3. When dragging can be used to scroll the preview it should show a "move" cursor in the preview image. This gives visual feedback to the user that the image can be scrolled. Requirement 4. During scrolling the preview should optionally show a (possibly scaled) version of the original image. In many cases rendering algorithms are too slow to support real-time scrolling. It must be possible to turn this feature off. This would be better when the rendering algorithm is fast and when the rendered result bears little resemblance to the original image. Requirement 5. The preview must support zooming. Viewing a rendered image at different scales is very useful for a wide range of plug-ins. Open issue: Should the preview accept arbitrary floating point numbers as scale factors or should it only accept a more limited set of different magnifications, e.g. of the form 1/n and n, where n is an integer. The latter approach can be more efficient in the implementation. It would even be more efficient when the preview only accepted only a limited set of magnifications, e.g 1/16, 1/15, ... 1/2, 1, 2, ... 16, because specialized code could be written for each magnification. Requirement 6. The preview must contain an optional GUI for zooming. A standard GUI for zooming the preview increases the uniformity of plug-ins and makes life easier for plug-in writers. It must be possible to hide the zooming GUI for previews that either don't support zooming or use a different interface. Open issue: What should the GUI look like? A commonly used approach is to have a "+" and "-" button and a label to show the current scale. Another suggestion was to use spin-buttons. Because it seems most desirable that the scaling factors are more or less exponential the standard Gtk spinbuttons are not very useful. The first release of the preview widget will use "+" and "-" buttons. Requirement 7. The preview must be able to handle both scaled and unscaled rendered data. In some cases the rendering algorithm may be able to produce a scaled version of its outputs. In many cases the rendering algorithm cannot easily produce scaled data and then the preview should do the scaling. Requirement 8. The scaling algorithm must be stable under scrolling. The user must have the impression of scrolling through a fixed scaled version of the image. When the scaling algorithm is not stable, the preview will flicker du
Re: [Gimp-developer] Preview requirements
On 26 Feb 2003 14:24:17 +0100 Sven Neumann <[EMAIL PROTECTED]> wrote: > Hi, > > Ernst Lippe <[EMAIL PROTECTED]> writes: > > > There are two possible GUI styles: dragging in the preview and using > > scrollbars. These could also be combined. > > > > Open issue: Scrollbars make the widget visually bigger and makes its > > internal structure more complicated. The alternative of giving the > > preview widget two GtkAdjustments, that can be used by the developer to > > "wrap" the widget with scroll-bars, does not work when the preview > > widget has a visible scroll-bar and/or zoom controls. Scroll-bars > > will not be supported in the first release of the preview widget. > > I don't understand the problem here. IMO using two adjustments to > control the displayed area is very convenient and makes it perfectly > easy to add scroll-bars. I'd suggest you try to come up with an API > that uses adjustments. Perhaps you could outlines what problems you > see here. The point is the following. In the current implementation the preview widget consists of the following components from top to bottom: the image, the progress bar and the zoom controls. When scrollbars should be added the horizontal scrollbar should be located between the progress bar and the image. So it is not possible to add scrollbars by simply wrapping the entire current preview but the preview itself must be modified. Adding scrollbars makes the layout algorithm more complex. I am not a great fan of using scrollbars for the preview. They make the widget a lot bigger and scrollbars are not easy to use with small previews. When there really is an overwhelming demand for scrollbars, we will probably add them. BTW, the most recent implementation uses adjustments for the position and the scale. > > Open issue: What should the GUI look like? A commonly used approach is > > to have a "+" and "-" button and a label to show the current scale. > > Another suggestion was to use spin-buttons. Because it seems most > > desirable that the scaling factors are more or less exponential the > > standard Gtk spinbuttons are not very useful. The first release of > > the preview widget will use "+" and "-" buttons. > > please consider to use the icons provided by GTK+: > > http://developer.gnome.org/doc/API/2.0/gtk/gtk-Stock-Items.html#GTK-STOCK-ZOOM-IN-CAPS > http://developer.gnome.org/doc/API/2.0/gtk/gtk-Stock-Items.html#GTK-STOCK-ZOOM-OUT-CAPS OK. > > Requirement 10. The preview must emit a signal when the user has > > scrolled or zoomed the preview. > > > > This signal can be used to synchronize multiple previews (e.g. see > > Filter Pack). This signal should contain information about the new > > position and/or scale. This signal will be emitted before the preview > > attempts to update the rendered image. The signal will only be > > emitted when the preview was scrolled by the user via the GUI. The > > signal will not be emitted when scrolling or zooming through the API. > > I'd suggest not to include information about the new position and/or > scale in the signal but to provide a way to retrieve this information > from the preview widget. This is just my default multi-threading paranoia. When you have multiple variables that can be updated in a multi-threading environment, it is in general wise to use copies that are known to be consistent with one another. I don't really know how Gtk uses threading, so perhaps it is not useful to include the information. > Actually if you go for two adjustments and > expose them in your API you don't need to deal with signals at all > since it should be sufficient to connect to the "value_changed" and > "changed" signals of the two adjustments. The reason for a separate signal is that this makes it possible to distinguish between between modifications that are initiated by the user via the preview GUI and modifications that were initiated programmatically via the API. When this distinction is never important the requirement could be dropped. > > Requirement 12. The preview must support an API to scroll the preview > > and change the magnification. > > > > This functionality is needed to synchronize multiple previews. > > and again you get this all for free if you go for two adjustments. > Synchronizing two previews would boil down to synchronizing the > preview's adjustements. When you have an API call to change both coordinates at the same time, this makes it easier to avoid unnecessary refreshes, otherwise the widget might try to refresh itself between modification of the first and second coordinate. greetings, Ernst ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Preview requirements
On Wed, 26 Feb 2003 14:17:21 +0100 Øyvind Kolås <[EMAIL PROTECTED]> wrote: > * Ernst Lippe <[EMAIL PROTECTED]> [030226 14:04]: > > > Non-requirement 1. Preview the rendered results in the original image > > window. > > > > The rendered image should be shown in the original image window. > > > > Comment: This is one of the suggestions from the GUAD3C meeting. It > > does not seem relevant for the preview widget. > > It is relevant in terms of providing a consistent user interface, the > place in a plug-in's GUI it is natural to place a toggle that controls > wether the canvas is updated with the preview or not. Is in relation to > other preview controls. I am not convinced that this toggle button really logically belongs to the preview widget. > The code neccesary to do this at the moment is quite complex, and > involves creating temporary layers, messing with the undo state of gimp > and such. The preview code already wants to be a "proxy" for rendering > smaller previews using the same API calls as for already modifying the > actual image, it thus seems like a natural place to add, or at least > think about such functionality. I don't see that there is much common code between the preview widget and the code for showing the result in the original canvas. In the ideal world both would be part of a standard Gimp preview library. But for the time being I don't have time to work on this. greetings, Ernst ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Preview requirements
On Thu, 27 Feb 2003 00:49:50 +0100 "Branko Collin" <[EMAIL PROTECTED]> wrote: > Sometimes, a rendering algorithm is very slow. I know this all too well. > A user should be able > to switch off the automatic rendering of a preview. I don't think this is part of the preview widget. It calls the plug-in to do the rendering and that seems the proper place to make the decision about rendering a new image or not. greetings, Ernst ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Preview requirements
On 26 Feb 2003 17:29:37 +0100 Sven Neumann <[EMAIL PROTECTED]> wrote: > Hi, > > Ernst Lippe <[EMAIL PROTECTED]> writes: > > > The point is the following. In the current implementation the preview > > widget consists of the following components from top to bottom: the image, > > the progress bar and the zoom controls. When scrollbars should be added > > the horizontal scrollbar should be located between the progress bar and > > the image. So it is not possible to add scrollbars by simply wrapping > > the entire current preview but the preview itself must be modified. > > Adding scrollbars makes the layout algorithm more complex. > > IMO the preview widget should only be the preview, nothing else. If > possible it should expose two adjustments so that you can easily add > scrollbars. Progress-bar, zoom-control and scrollbars don't belong to > the preview widget itself. They can be added by a composite widget. That is already in my current design. There is a bare preview widget that can do scaling and scrolling but has no GUI for these operations. There is another composite widget that can include a progress bar and zoom buttons. Having a standard composite widget makes life easier for developers and gives more uniformity among the plug-ins. > > > Actually if you go for two adjustments and > > > expose them in your API you don't need to deal with signals at all > > > since it should be sufficient to connect to the "value_changed" and > > > "changed" signals of the two adjustments. > > > > The reason for a separate signal is that this makes it possible to > > distinguish between between modifications that are initiated by the > > user via the preview GUI and modifications that were initiated > > programmatically via the API. When this distinction is never > > important the requirement could be dropped. > > Why should a widget behave differently if changed by the user or > programmatically via the API? That sounds like a broken concept. Why? This is simply a method to get a hook for trapping operations that the user has performed on the GUI of the widget. A set of previews that you want to synchronize is an example of a constraint based system where you want to solve a set of constraints among multiple objects. The naive implementation of such a system is to let each object synchronize with all others when its value is changed. In general this is not a very good architecture: * It is expensive, you need at least n * (n - 1) synchronizations. * It frequently leads to oscillatory behaviour. As an example where you could get funny behavior, take two previews that show the area around a certain point at different magnifications. Assume that the user scrolls in preview A. Now A will update the position of B. Because B is updated it will attempt to update A's position. In all implementations that I can think of there are choices for the scale factor such that the new position for A is different from the position that was set by the user. So A's position changes again and A will try to update B a second time. Eventually, this will probably stabilize, but when there are 3 previews with different magnifications there are probably cases where the oscillations never stabilize. The standard solution for these problems is to have some central arbitrator that makes global decisions for all objects. When you have a seperate signal for user operations this is a nice hook for such an arbitrator. It is of course possible to implement an arbitrator without these signals but its implementation seems a lot messier. Probably you would need some global arbitration flag and change the way that "value-changed" signals are handled based on the value of this flag. You would also have to be careful about subsequent operations by the user before the arbitration computations are finished. > > > > Requirement 12. The preview must support an API to scroll the preview > > > > and change the magnification. > > > > > > > > This functionality is needed to synchronize multiple previews. > > > > > > and again you get this all for free if you go for two adjustments. > > > Synchronizing two previews would boil down to synchronizing the > > > preview's adjustements. > > > > When you have an API call to change both coordinates at the same time, > > this makes it easier to avoid unnecessary refreshes, otherwise the widget > > might try to refresh itself between modification of the first and second > > coordinate. > > you will have to delegate the actual refresh to idle functions anyway > so that shouldn't be a problem. I've worked quite a bit with Delphi that
Re: [Gimp-developer] Preview requirements
On 01 Mar 2003 17:39:56 +0100 Sven Neumann <[EMAIL PROTECTED]> wrote: > Hi, > > Ernst Lippe <[EMAIL PROTECTED]> writes: > > > A set of previews that you want to synchronize is an example of a > > constraint based system where you want to solve a set of constraints > > among multiple objects. The naive implementation of such a system is > > to let each object synchronize with all others when its value is changed. > > In general this is not a very good architecture: > > * It is expensive, you need at least n * (n - 1) synchronizations. > > * It frequently leads to oscillatory behaviour. > > > > As an example where you could get funny behavior, take two previews that > > show the area around a certain point at different magnifications. > > Assume that the user scrolls in preview A. Now A will update the > > position of B. Because B is updated it will attempt to update > > A's position. In all implementations that I can think of there > > are choices for the scale factor such that the new position for > > A is different from the position that was set by the user. > > So A's position changes again and A will try to update B a > > second time. Eventually, this will probably stabilize, but > > when there are 3 previews with different magnifications there > > are probably cases where the oscillations never stabilize. > > > > The standard solution for these problems is to have some > > central arbitrator that makes global decisions for all objects. > > > > When you have a seperate signal for user operations this is > > a nice hook for such an arbitrator. > > It is of course possible to implement an arbitrator without these > > signals but its implementation seems a lot messier. Probably > > you would need some global arbitration flag and change the way > > that "value-changed" signals are handled based on the value of > > this flag. You would also have to be careful about subsequent > > operations by the user before the arbitration computations > > are finished. > > we usually solve this problem blocking the signal handlers when doing > the update: > > http://developer.gnome.org/doc/API/2.0/gobject/gobject-Signals.html#g-signal-handlers-block-by-func > > This is IMO cleaner and simpler than adding an extra signal. But blocking the signals on a GtkAdjustment only prevents the propagation of signals, it does not prevent an update of the underlying value. When the signal handlers are not sufficiently fast it is possible that the user has scrolled or zoomed while the signal handlers were blocked. In that case the underlying adjustment of the preview in which the user performed the operation will be updated but other components will not be notified. With scrolling this might be acceptable but with zooming the differences in magnification between multiple, supposedly synchronized, previews are very obvious. The only fundamental solution would be to block all updates by the user to each preview adjustment. I don't think that that this can be done on the adjustements themselves, the only solution I can see at the moment is to "freeze" all GUI components that could modify these adjustments. greetings, Ernst ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Preview requirements
On Sat, 01 Mar 2003 12:46:57 +0100 Michael Natterer <[EMAIL PROTECTED]> wrote: > Ernst Lippe <[EMAIL PROTECTED]> writes: > > > On 26 Feb 2003 17:29:37 +0100 > > Sven Neumann <[EMAIL PROTECTED]> wrote: > > > > > Hi, > > > > > > Ernst Lippe <[EMAIL PROTECTED]> writes: > > > > > > > The point is the following. In the current implementation the preview > > > > widget consists of the following components from top to bottom: the image, > > > > the progress bar and the zoom controls. When scrollbars should be added > > > > the horizontal scrollbar should be located between the progress bar and > > > > the image. So it is not possible to add scrollbars by simply wrapping > > > > the entire current preview but the preview itself must be modified. > > > > Adding scrollbars makes the layout algorithm more complex. > > > > > > IMO the preview widget should only be the preview, nothing else. If > > > possible it should expose two adjustments so that you can easily add > > > scrollbars. Progress-bar, zoom-control and scrollbars don't belong to > > > the preview widget itself. They can be added by a composite widget. > > > > That is already in my current design. There is a bare preview widget > > that can do scaling and scrolling but has no GUI for these operations. > > There is another composite widget that can include a progress bar and > > zoom buttons. Having a standard composite widget makes life easier for > > developers and gives more uniformity among the plug-ins. > > > > > > > Actually if you go for two adjustments and > > > > > expose them in your API you don't need to deal with signals at all > > > > > since it should be sufficient to connect to the "value_changed" and > > > > > "changed" signals of the two adjustments. > > > > > > > > The reason for a separate signal is that this makes it possible to > > > > distinguish between between modifications that are initiated by the > > > > user via the preview GUI and modifications that were initiated > > > > programmatically via the API. When this distinction is never > > > > important the requirement could be dropped. > > > > > > Why should a widget behave differently if changed by the user or > > > programmatically via the API? That sounds like a broken concept. > > > > Why? This is simply a method to get a hook for trapping operations that > > the user has performed on the GUI of the widget. > > > > A set of previews that you want to synchronize is an example of a > > constraint based system where you want to solve a set of constraints > > among multiple objects. The naive implementation of such a system is > > to let each object synchronize with all others when its value is changed. > > In general this is not a very good architecture: > > * It is expensive, you need at least n * (n - 1) synchronizations. > > * It frequently leads to oscillatory behaviour. > > > > As an example where you could get funny behavior, take two previews that > > show the area around a certain point at different magnifications. > > Assume that the user scrolls in preview A. Now A will update the > > position of B. Because B is updated it will attempt to update > > A's position. In all implementations that I can think of there > > are choices for the scale factor such that the new position for > > A is different from the position that was set by the user. > > So A's position changes again and A will try to update B a > > second time. Eventually, this will probably stabilize, but > > when there are 3 previews with different magnifications there > > are probably cases where the oscillations never stabilize. > > > > The standard solution for these problems is to have some > > central arbitrator that makes global decisions for all objects. > > > > When you have a seperate signal for user operations this is > > a nice hook for such an arbitrator. > > It is of course possible to implement an arbitrator without these > > signals but its implementation seems a lot messier. Probably > > you would need some global arbitration flag and change the way > > that "value-changed" signals are handled based on the value of > > this flag. You would also have to be careful about subsequent > > operations by the user before the arbitration computations > > are finished. > > You should make yourself familiar wi
Re: [Gimp-developer] Preview requirements
On 03 Mar 2003 11:54:42 +0100 Michael Natterer <[EMAIL PROTECTED]> wrote: > Again, you should understand how GObject signals work. They operate > purely synchronously. A signal handler cannot be "too slow" because > the only thing your program is doing while emitting the signal is > emitting the signal. When the call to g_signal_emit() returns all > handlers have been called in order of connection. But signal handlers can do anything they want, and so I assumed that they could also could also somehow invoke the main loop to process new events. I know at least one signal handler that works in this way. The rendering function for my preview indirectly calls the gtk main loop to process new events, because the user must be able to scroll and zoom the preview even while the rendering function is executing. But from your comments I guess that this is an exceptional case and that this is something that "good" signal handlers will not do. > The solution I propose is simply updating the preview in an idle > function. This way you can change the underlying model as often > as you like and the idle logic will make sure subsequent changes > are compressed into a single update of the GUI. > > Actually, the preview should update itself when it gets exposed. GTK > already compresses and idles updates of the GUI, so everything that > should be needed is calling gtk_widget_queue_draw() or > gtk_widget_queue_draw_area() on the parts of the preview you want to > update and the "expose" handler will do it's job of re-rendering at > just the right time, namely immediately before the stuff is drawn to > screen. This seems a good idea. I have just rewritten my widget this way and it appears to be working fine. greetings, Ernst ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] caching considerations in gegl
On Tue, 11 Mar 2003 09:46:49 + "Adam D. Moss" <[EMAIL PROTECTED]> wrote: > The idea > of rehash-on-dirty would be to catch identical tiles, even > accidentally-identical tiles (like great masses of transparent > tiles, presuming that you scrub the RGB data of a transparent > pixel; the row-hints stuff has been doing this and potentially > breaking the ill-advised anti-erase feature for 100 years now > and no-one has complained) Perhaps because no-one knew, you should not have told us this. I think that the user should be able to edit the alpha channel independent from the other channels. I don't think that it is unreasonable that a user initially makes some parts of the layer transparent, then makes some other edits to the layer and finally decides that the transparency boundaries should be slightly different, e.g. slightly more feathered. In most cases this will work fine but when some of the tiles have been scrubbed this will not work for these tiles. In my mental model the alpha information is simply one of the "color" channels, that are all completely independent from one another. What I find particularly nasty is that scrubbing could happen at unexpected moments and this makes it very difficult to reproduce any bugs that are related to this "feature". If it is really desirable to remove color information from transparent pixels, this must have a predictable behavior. The logical place seems to be the operations that modify the alpha channel, e.g. erase. These operations should set the color channels to 0 for transparent pixels. In this way you get at least reproducable behavior. Finally, when everybody believes that scrubbing by the tile manager is a great idea, I have another one: delete all tiles from the image that are completely obscured by higher layers. After all, like the color information in transparent pixels, these tiles do not contribute anything to the final image, so it seems very reasonable delete them. Also I suggest that a good random number generator is used to decide when these tiles are deleted :) greetings, Ernst Lippe ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] caching considerations in gegl
On Tue, 11 Mar 2003 17:12:14 +0100 Raphaël Quinet <[EMAIL PROTECTED]> wrote: > On Tue, 11 Mar 2003 16:38:13 +0100, Ernst Lippe <[EMAIL PROTECTED]> wrote: > > On Tue, 11 Mar 2003 09:46:49 + > > "Adam D. Moss" <[EMAIL PROTECTED]> wrote: > > I think that the user should be able to edit the alpha channel independent > > from the other channels. I don't think that it is unreasonable that a user > > initially makes some parts of the layer transparent, then makes some other > > edits to the layer and finally decides that the transparency boundaries > > should be slightly different, e.g. slightly more feathered. In most cases > > this will work fine but when some of the tiles have been scrubbed this > > will not work for these tiles. > > I think that it _is_ unreasonable to expect this to work. Why? Normally operations on the alpha don't influence the state of the other color components, so I don't really see why it would be reasonable to assume that changing to full transparency is a priori different. Also it is the simplest way to implement the whole thing. > If the user > wants to change the transparency boundaries, then the correct way to > do it would be to undo the steps that have shrunk the visible area > (and then it does not matter if the transparent tiles used in the > following steps have been scrubbed or not). The point was that fiddling with the boundaries as a final step after you have made other modifications to the layer looks like a pretty normal scenario to me. In your proposal it is safe to make the area smaller, but there is no way to make it bigger or use a slightly different feathering. The only way to undo a wrong initial decission is to undo all subsequent edit steps. I am very certain that I would not be too happy about having to start all over again. > You seem to imply that > the user would use the "anti-erase" option as a normal feature. Why not? It is very easy to give good semantics for this feature. > I always considered the "anti-erase" feature to be evil. > Ideally, the average user should see no difference if we suddenly > decided that the GIMP should work with pre-multiplied alpha (in which > all color information is definitely lost when making a pixel > transparent). But how do you handle the case when a user would try to make a transparent pixel non-transparent. This pixel should then get a color, but which one? White and black are possible choices, and in most cases the user will want neither of them. Perhaps every operation that potentially could change a transparent pixel should have an additional argument that specifies the color for those pixels? > So I think that we should not suggest that the alpha > channel is like any other channel. Making a pixel fully transparent > should be considered as a destructive operation for the corresponding > RGB data (or let's say that the behavior is unspecified, which is a > good description of what happens now). In general unspecified behavior is not a nice thing to have (I am almost tempted to write EVIL). In most cases where a system has unspecified behavior the user makes assumptions on how it works and is unpleasantly surprised when in a few cases the system, for unknown reasons, behaves very differently. I think that we both have reasons to be unsatisfied with the current implementation. The main point for me is that the current implementation leads to irreproducible behaviour. When it is desirable to remove all color information from transparent pixels the right place to implement this is in the operation that modifies the alpha and not somewhere hidden in the tile caching. greetings, Ernst Lippe ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] caching considerations in gegl
On Tue, 11 Mar 2003 19:05:03 +0100 Raphaël Quinet <[EMAIL PROTECTED]> wrote: > On Tue, 11 Mar 2003 18:20:34 +0100, Ernst Lippe <[EMAIL PROTECTED]> wrote: > So don't do that, then! ;-) Nobody should rely on unspecified > behavior. But how should an end-user know that this is unspecied behavior? I could not find anything in the documentation that came with my version of the GIMP :) > One day, someone could decide that the GIMP would work > better by compressing tiles on-the-fly in memory and clearing the RGB > data of fully transparent pixels in order to improve the compression. > And then all hacks that were relying on unspecified behavior would > suddenly break. Who is to blame? Not the GIMP developer, IMHO. Who else do you think an end-user is going to blame? Remember that end-users are in general horrible beings: they believe that they know what they want to do and they even believe that the GIMP is simply a tool that they could use. When that tool does not do what they want it is always the tool that is wrong. Another problem with end-users is that they don't really want to learn new things. The first time they will notice that the GIMP removes color information is when they start using it for a serious job with large images. For unknown reasons end-users tend to have an extremely low frustration tolerance when they are working on jobs that they consider serious (this might have something to do with these things that they call deadlines). Instead of being grateful that they have learned that they were sinning, they will usually start complaining: "But it works fine on this part of the image" or "But it worked 5 minutes ago". > The one to blame is the one who has used a feature that was not supposed > to be used. But why does it have an unerase then? > We could of course specify that all fully transparent pixels are > always set to black. But this is not done currently because this > would imply a small (or maybe not so small) performance penalty. But how great is that penalty? At least this gives consistent behavior. greetings, Ernst Lippe ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: caching considerations in gegl
On Tue, 11 Mar 2003 17:08:43 -0800 Daniel Rogers <[EMAIL PROTECTED]> wrote: > David Necas (Yeti) wrote: > > But then I, as a user, don't care about alpha, and what > > I really care about is transparency. So everything what was > > said can be repeated, only s/alpha/transparency/. My need > > for pixels retaining their properties even in invisible > > state didn't disappear. > > I think that is an excellent point, and a big vote for using > un-premultiplied images (in fact, the only vote for using > unpremultiplied images) As Nick Lamb already noted, there is another good argument against pre-multiplied alpha: loss of precision. When you're using a single byte per color that could be a serious problem. greetings, Ernst Lippe ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] New version of the preview requirements
This is the new version of the plug-in preview requirements. Compared with the preview version a few requirements have been dropped (which is something that does not happen too often in requirements discussions). One of the other results of the discussion was that we decided to split the preview into two widgets: * a "convenience" preview widget with bells and whistles, such as zoom buttons, progress-bar and scroll-bars (yes, even those). * a bare bones preview image widget that shows the actual preview and has support for scaling and zooming. At the moment we have an implementation that supports all the requirements in the list (writing requirements after you've implemented a system is a perfect way to satisfy all system requirements). At the moment we are still working on it, but we hope to publish the API real soon now. greetings, Ernst Lippe <[EMAIL PROTECTED]> Requirements for a GIMP plug-in preview widget V1.1 === INTRODUCTION This document gives a possible list of requirements for a preview widget that can be used by GIMP plug-ins. This document was written by Maurits Rijk <[EMAIL PROTECTED]> and Ernst Lippe <[EMAIL PROTECTED]>. HISTORY This version reflects the results of the discussion on the Gimp-developer mailing list in February 2003. All requirements about signals, that should be emitted when the user when the user scrolls or zooms with the GUI, have been dropped for the moment. REQUIREMENTS REQUIREMENT 1: A plug-in author must be able to write a single version of the rendering function that can both be used for rendering to the plug-in and for rendering to the final drawable. Far too many plug-ins that have a preview contain two different versions of the rendering algorithm: one for the preview and another one for the final result. For plug-ins that don't have a preview yet it is very desirable that the interface for generating a rendered image for the preview is very similar to the interface for generating the final results. REQUIREMENT 2: The preview must support a GUI for scrolling through the image. There are two possible GUI styles: dragging in the preview and using scrollbars. These can also be combined. REQUIREMENT 3: When dragging can be used to scroll the preview it should show a "move" cursor in the preview image. This gives visual feedback to the user that the image can be scrolled. REQUIREMENT 4: During scrolling the preview should optionally show a (possibly scaled) version of the original image. In many cases rendering algorithms are too slow to support real-time scrolling. It must be possible to turn this feature off. This would be better when the rendering algorithm is fast and when the rendered result bears little resemblance to the original image. REQUIREMENT 5: The preview must support zooming. Viewing a rendered image at different scales is very useful for a wide range of plug-ins. REQUIREMENT 6: The preview must contain an optional GUI for zooming. A standard GUI for zooming the preview increases the uniformity of plug-ins and makes life easier for plug-in writers. It must be possible to hide the zooming GUI for previews that either don't support zooming or use a different interface. REQUIREMENT 7: The preview must be able to handle both scaled and unscaled rendered data. In some cases the rendering algorithm may be able to produce a scaled version of its outputs. In many cases the rendering algorithm cannot easily produce scaled data and then the preview should do the scaling. REQUIREMENT 8: The scaling algorithm must be stable under scrolling. The user must have the impression of scrolling through a fixed scaled version of the image. When the scaling algorithm is not stable, the preview will flicker during the scroll, which is highly annoying. In most cases this is caused by rounding errors. It is surprisingly difficult to write a good scaling algorithm due to these numerical problems. REQUIREMENT 9: During zooming the preview should attempt to keep the center of the previewed image at the same position. This is similar to the visual behaviour of zooming with a camera. REQUIREMENT 10: The preview must support an API to scroll the preview and change the magnification. This functionality is needed to synchronize multiple previews. REQUIREMENT 11: The preview must be able to halt the rendering algorithm. Frequently, the user will perform actions like scrolling or zooming that makes the image, that is being rendered by the rendering function, obsolete. There must be some way for the preview to inform the rendering function that it can stop. REQUIREMENT 12: The user must be able to continue scrolling and zooming even when the rendering function is still rendering a new image. With slow rendering algorithms it is intolerable when the widget "locks up" during rendering. When the user scrolls or zooms
Re: [Gimp-developer] New version of the preview requirements
On 19 Mar 2003 18:47:11 +0100 Sven Neumann <[EMAIL PROTECTED]> wrote: > Hi, > > Ernst Lippe <[EMAIL PROTECTED]> writes: > > > At the moment we have an implementation that supports all > > the requirements in the list (writing requirements after > > you've implemented a system is a perfect way to satisfy > > all system requirements). > > > > At the moment we are still working on it, but we hope > > to publish the API real soon now. > > It would be really nice to see something in CVS soon. This would avoid > that already written code is lost due to hardware problems (this has > happened before). It would also assure that the preview makes it into > the next version and isn't hold off by the feature freeze that is > coming really soon now. Maurits fully agrees with you. But at the moment my distribution already contains multiple files: * Two widgets * Two support modules * Gtk-doc documentation files for the previous. * A plug-in test bed for the preview. * Three example plug-ins that use the preview. Maurits has written some additional code that I would like to include as well, but I believe it will need some modifications. Also, I would really like to include some sort of tutorial and a simple example (no, these are not written yet). At the moment my development environment is nicely organized for my own developments, I've got a standard Gnu distribution with autoconf, automake, gtk-doc. Altogether I've got 44 files in CVS just for this project. I can't imagine that you would be very pleased to add all of them to Gnome CVS. Another point is that the current name of the widget is GimpPreview and for some reason I don't think that you will like that name (even though my widget is a direct descendant of Shawn's widget that was written somewhere in 1998). In my experience renaming or reorganizing files after you've added them to CVS is something you should generally try to avoid. Another issue is that I can't compile the current CVS version of the GIMP anymore, because you've upgraded to the most recent version (2.2) of glib etc. Yes, I know that this sounds lame, but over the years I've grown increasingly tired of always trying to use the latest and greatest version of everything, because in most cases, I had to spend a lot of effort to upgrade a myriad of libraries after which I had to conclude that the whole thing would not work on my system anyway. I think that several other plug-in developers are in the same position, so I don't believe that they would mind if they could get a preview that was not yet in the official CVS. Also I don't think that you have to worry about hardware failures too much, I just sent Maurits a full distribution of my stuff. Earthquakes are very rare in the Netherlands, we are generally more afraid of floods and AFAIK I live sufficiently high above sea-level. All this does not mean that I would not like to see my preview in the GIMP CVS ASAP. I'd really like to have the preview and at least a few of the plug-ins in the official 1.4 distribution. (BTW is there already a new deadline? I believe that it was originally scheduled for the end of last year). So, the bottom-line is, that I really would like to see the widget in the CVS but that it would not be wise to do so before other people have commented on it. Also, like Nick Lamb remarked today, it is not very useful to put brilliant new stuff in CVS, when there is no real support and follow-up. greetings, Ernst P.S. Don't worry too much. I have been working on this preview for about four years and I believe that its code is much better shape than e.g. most of the GIMP plug-ins. Previews are very important for a nice GUI but developers will only use them when they are easy to use and well-documented. After my discussions with Maurits and the Gimp-developer list I made some drastic modifications such as splitting the original widget into two different widgets. I'd like to keep that freedom for a little while. When there is enough support for its API, I could have it ready for CVS in a few days. The code compiles cleanly with GTK+-2.0 and GIMP 1.3.12 and it has decent gtk-doc documentation. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New version of the preview requirements
On Thu, 20 Mar 2003 10:55:49 +0100 Sven Neumann <[EMAIL PROTECTED]> wrote: > Ernst Lippe <[EMAIL PROTECTED]> writes: > > Another point is that the current name of the widget is GimpPreview > > and for some reason I don't think that you will like that name > > (even though my widget is a direct descendant of Shawn's widget > > that was written somewhere in 1998). > > we should discuss this. Generally GimpPreview is perfectly acceptable > as a name but since we use it in the core already we should consider > to look for another name to avoid confusion. Maurits has suggested to use GimpEffectPreview, which sounds OK, but other suggestions are welcome. > > All this does not mean that I would not like to see my preview > > in the GIMP CVS ASAP. I'd really like to have the preview and > > at least a few of the plug-ins in the official 1.4 distribution. > > (BTW is there already a new deadline? I believe that it was > > originally scheduled for the end of last year). > > I don't think it has ever been scheduled with a fixed date. It's ready > when it's ready but we are now trying to push things a bit. I'm > putting some pressure on you just to let you know that we'd rather > like to see a working-yet-not-perfect plug-in preview widget than no > plug-in preview widget at all. Of course I am flattered by your interest. At the moment both the API and the internal architecture are not fixed as far as I am concerned. I want the preview to be both both flexible and easy to use for plug-in developers. There have been other attempts to develop a preview widget in the past. Shawn wrote his GimpPreview widget ages ago, but even though it had a lot of nice features, I know only one plug-in (yep, that's mine) that really used it. I am not really certain why it failed: too complicated, not flexible enough, not enough documentation or publicity? I'd really like to avoid the same trap and that's why I am trying to follow the slow and sometimes boring path through requirements, design and implementation. We'll publish the API for comments as soon as Maurits has finished reviewing the most recent version. As soon as there is sufficient support for the API (I don't expect a real concensus, but I'll really try to incorporate good suggestions) the API will be frozen, and you could probably get a first, probably not fully functional, version within a week. greetings, Ernst ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Plug-in preview API proposal
As promised here is my API proposal for a plug-in preview widget. You can find it at http://refocus.sourceforge.net/preview. Please examine it critically, this should be a preview that should be usable for a very wide range of plug-ins. Because I would like to reuse this proposal (or what is left of it after the discussion) for the final documentation I also welcome minor comments such as spelling mistakes, grammar corrections, coding errors and such. greetings, Ernst Lippe <[EMAIL PROTECTED]> ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Plug-in preview API proposal
On Mon, 31 Mar 2003 19:58:29 +0200 Sven Neumann <[EMAIL PROTECTED]> wrote: > Hi, > > Ernst Lippe <[EMAIL PROTECTED]> writes: > > > As promised here is my API proposal for a plug-in preview widget. > > You can find it at http://refocus.sourceforge.net/preview. > > > > Please examine it critically, this should be a preview that > > should be usable for a very wide range of plug-ins. > > > > Because I would like to reuse this proposal (or what is left of it > > after the discussion) for the final documentation I > > also welcome minor comments such as spelling mistakes, grammar > > corrections, coding errors and such. > > one thing that I noted at first glance is the namespace. It is > absolutely unacceptable to have any types or function names in the > GIMP API that don't have a GIMP prefix. I'd even prefer to have > everything that is related to this widget be under the same > namespace. Unfortunately GimpPreview is already taken, so we either > need to change the name of the core object or find a new one for the > plug-in preview. I fully agree that the names must be changed. The problem is how? Maurits suggested GimpEffectPreview, which is not a bad name, but I don't really like having to preview every function with gimp_effect_preview_ . I know it is a bit old-fashioned but I still think that source code should be readable on a tty with 80 characters. greetings, Ernst Lippe P.S. Of course the most logical solution is to change the name of the core widget. My widget is derived from Shawn Amundson's GimpPreview widget that was written in 1998, and that was long before some GIMP developer tried to claim that name. It is clear that this is an obvious infringement of our trademark. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Plug-in preview API proposal
On Mon, 31 Mar 2003 11:21:06 -0800 (PST) Nathan Carl Summers <[EMAIL PROTECTED]> wrote: > On 31 Mar 2003, Sven Neumann wrote: > > > > I'd even prefer to have everything that is related to this widget be > > under the same namespace. Unfortunately GimpPreview is already taken, so > > we either need to change the name of the core object or find a new one > > for the plug-in preview. > > (off-the-cuff) Perhaps GimpThumbnail? It is a nice short name, but I have the impression that a thumbnail is a reduced size version of the original image, and for most plug-ins I would expect that the preview normally shows a small part of the image at its real size. greetings, Ernst Lippe ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Plug-in preview API proposal
On Mon, 31 Mar 2003 20:17:51 +0200 Sven Neumann <[EMAIL PROTECTED]> wrote: > Hi, > > Ernst Lippe <[EMAIL PROTECTED]> writes: > > > As promised here is my API proposal for a plug-in preview widget. > > You can find it at http://refocus.sourceforge.net/preview. > > In the section "Design" in "Calling the render function" you state: > > A somewhat smarter version of this preview used a different > approach. The rendering function had to call back to the GTK main > loop, so it could process new events. > > I wouldn't call this a smart version since this is something that you > better not try to implement. Why do you want to drive the GTK+ main > loop yourself? This only leads to really complicated behaviour (as you > seem to have experienced yourself). The easiest approach to this > problem seems to be to split the rendering function into small > chunks. Instead of calling some function that processes events, the > render function returns after computing a small tile of the preview > image. The standard GTK+ main loop takes back control, user events are > processed and if it ever becomes idle again, the list of invalid tiles > is examined and the render function is called with the next area to > update. Did you consider this approach? Yes, and I did not like it. One of the goals for this preview was that it should be easy to use the same function for rendering to the preview and to the final image. In many cases it is not too difficult to convert an existing rendering algorithm so that it will only render a specific area of the final result. But many plugin algorithms have a considerable setup time, which means that there is a lot of overhead when you call the rendering function for each output tile. The only way to avoid this overhead is to make interface more complicated, analogous to the GimpPixelRegions, there should be an _init interface that the preview uses to inform the plug-in about the total area that it wants, and a _render_tile interface that tells the plug-in that it should render a specific tile. If you want to rewrite an existing rendering function to this new interface you will have to make major changes. (Essentially this is very similar to the steps that you have to make when you want to change a recursive function into an iterative function. It is always possible, but the results are generally completely unreadable.) Basically, what you will have to do is to record local variables in functions in some global structure, and to retrieve these values when you have to compute the next tile. To summarize, if the preview should ask the plug-in to render individual tiles (and when the preview is zoomed out or when the preview is large there can be a large number of tiles that must be rendered) it will either be inefficient for some plug-ins or plug-in authors will have to implement a complicated interface. As a plug-in author, I believe that my proposed interface is very natural. I have already converted a few plug-ins and that was fairly straight-forward. I definitely would not like having to rewrite those plug-ins in such a way that they could efficiently compute individual tiles. Also I must say that I am a bit disappointed that calling the GTK main loop is so expensive (or that there apparently is no other way to process new GUI events). Giving control to the main event loop at regular intervals during computations is a standard solution to avoid freezing of the GUI in cooperative multi-tasking systems. greetings, Ernst Lippe ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Plug-in preview API proposal
On Mon, 31 Mar 2003 22:50:00 +0200 Sven Neumann <[EMAIL PROTECTED]> wrote: > Hi, > > Ernst Lippe <[EMAIL PROTECTED]> writes: > > > P.S. Of course the most logical solution is to change the name of > > the core widget. My widget is derived from Shawn Amundson's GimpPreview > > widget that was written in 1998, and that was long before some > > GIMP developer tried to claim that name. It is clear that > > this is an obvious infringement of our trademark. > > I quick grep through the sources shows that we'd have to change more > than 150 files and I doubt that this could safely be done by a naive > search-and-replace operation. So this is probably not a reasonable > option. Irony is always difficult on a written medium like e-mail. (I should have included some smileys) Of course, I know that this was not a very realistic option, but perhaps it might trigger the core developers to think about a good name for this preview :) greetings, Ernst Lippe ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Plug-in preview API proposal
On Tue, 01 Apr 2003 13:59:21 +0200 Sven Neumann <[EMAIL PROTECTED]> wrote: > Hi, > > Ernst Lippe <[EMAIL PROTECTED]> writes: > > > The only way to avoid this overhead is to make interface more > > complicated, analogous to the GimpPixelRegions, there should > > be an _init interface that the preview uses to inform the plug-in > > about the total area that it wants, and a _render_tile interface > > that tells the plug-in that it should render a specific tile. > > I don't think the GimpPixelRgn API is overly complicated. I didn't say it was, I only claimed that my current interface is simpler. > Of course an > iterative API as I propose it needs an iterator structure but I don't > see how this approach would be overly complicated. Because you force the developer to write his rendering function as a finite state machine. FSM's are difficult to read and maintain. For really simple plug-ins this is not a big problem, but for algorithms that make several passes over the data this will soon become a mess. (I don't know if there are any plug-ins that use recursive functions but converting those into FSM's is not very pretty because they will have to maintain their own stacks explicitely.) Also when you discover at some later stage that a certain function your program is taking to much time you will have to completely rewrite plus all the functions that directly or indirectly call it. In my API this is much easier, you simply add the ProgressUpdater as an extra argument and call it at the right places. What I expect is that most plug-in developers simply don't want to go through all this trouble. The final result is that these plug-ins will regularily freeze the GUI. This is really terribly frustrating, because you have to wait until the computer is finished with computing something that you don't want. > > If you want to rewrite an existing rendering function to this > > new interface you will have to make major changes. (Essentially > > this is very similar to the steps that you have to make when > > you want to change a recursive function into an iterative function. > > It is always possible, but the results are generally completely > > unreadable.) Basically, what you will have to do is to record > > local variables in functions in some global structure, and > > to retrieve these values when you have to compute the next > > tile. > > Exactly. This is something every good plug-in should do anyway. Most > plug-ins already render on a tile-by-tile basis or at least do it > row-by-row. Shouldn't it be relatively easy to make this a function > which is called from the main-loop? That depends on the amount of book-keeping that that function has to do. All local variables must be moved into global structs, all loops must be broken into separate pieces, the code becomes less localized because related item get scattered everywhere, etc. > > Also I must say that I am a bit disappointed that calling the > > GTK main loop is so expensive (or that there apparently is > > no other way to process new GUI events). Giving control to > > the main event loop at regular intervals during computations > > is a standard solution to avoid freezing of the GUI in > > cooperative multi-tasking systems. > > sure, but it is usually done by returning to the main event loop, not > by driving it manually. As far as I can tell that is the only way that I can get GTK to process new user actions. If that is not allowed, programmers are forced to write all computing intensive operations as FSM's, which I would find completely unacceptable for a GUI toolkit. > If you do the latter, you introduce the need > to write reentrant functions. This is usually not necessary in a > single-threaded environment and I don't think we should put that > burden on the plug-in developers. As you said in your document, using > global variables is a bad habit but since you looked at some plug-ins > you know that it is rather common. I agree that your API may look > natural (after a much needed cleanup) but I fear that most plug-in > authors will not understand the implications of the design. I really did not think that re-entrancy would be a real problem. Anyhow, it can be eliminated by a little more bookkeeping in the preview, in such a way that at all times there is at most one instance of the rendering function active. This will slightly reduce the responsiveness of the preview, but otherwise I don't see any problems with this. greetings, Ernst ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Plug-in preview API proposal
On Tue, 01 Apr 2003 12:54:18 +0200 "David Necas (Yeti)" <[EMAIL PROTECTED]> wrote: > What about something like GimpProofView? > - it't not longer than GimpThumbnail > - it resembles GimpPreview > - "proof" is a relatively good word (though mostly used > in printing only, in this sense) > - the "view" is just a tag, but "proof" alone is strange > > It's quite easy to invent new words and phrases for me, > thanks to my miserable English ;-) but "proof view" seems > to be already invented, according to Google. I can't find it in my Webster's, but proof does have the right connotation, after all the preview is a preliminary version of the final results. greetings, Ernst Lippe ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Plug-in preview API proposal
On Wed, 02 Apr 2003 15:30:04 +0200 [EMAIL PROTECTED] wrote: > > Sven Neumann <[EMAIL PROTECTED]> wrote: > > >anyway. Now if only we could come up with a good name for the core > >widget ... > > May I suggest "GimpMiniview"? Yes, you may :) But it sounds like something tiny. Actually when you zoom in and use a large preview it can be much bigger than the original image. greetings, Ernst Lippe ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Plug-in preview API proposal
Even though I fully agree that the only serious problem in my API proposal is the name of the widget, I'd really like to get more input from more people about my API proposal. Especially, I would like to hear remarks from other plug-in developers, because they are after all the intended audience for this widget. (I somehow have the feeling that Sven is not really an average plug-in developer:). So for all average (and especially the below-average) plug-in developers: * Do you miss any features? * Is the documentation sufficient? * Would you use it? Of course I would also like some inputs about the discussion about using iterators in the rendering function. greetings, Ernst P.S. I just modified my preview so that the re-entrancy problem has been eliminated. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Preview widget name
My Webster's lists prevue as a synonym for preview (to me this appears to be the original French root of the word). Does GimpPrevue sound very weird for native English speakers? greetings, Ernst Lippe ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Plug-in preview API proposal
On Thu, 03 Apr 2003 02:15:42 +0200 "David Necas (Yeti)" <[EMAIL PROTECTED]> wrote: > On Thu, Apr 03, 2003 at 01:15:31AM +0200, Ernst Lippe wrote: > > P.S. I just modified my preview so that the re-entrancy problem has > > been eliminated. > > Excuse me, but which reentrancy problem has been eliminated? > Does it mean the render function no longer needs to be > reentrant? Yes, just added some book-keeping to preview, and it seems to work. > > Regards, > > Yeti > > > P.S.: Regarding the name, when I've seen the last > suggestions, GimpWWAAN (Widget Without Any Acceptable Name) > seem to be the most accurate... :-) On the contrary, there appear to be lots of acceptable names. I am suprised that nobody has suggested YetAnotherGimpPreview :) greetings, Ernst ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Preview widget name
On Wed, 02 Apr 2003 16:05:52 -0800 Jeshua Lacock <[EMAIL PROTECTED]> wrote: > > On Wednesday, April 2, 2003, at 03:41 PM, Kevin Myers wrote: > > > Personally I don't think that it sounds too bad at all, especially > > considering the lack of other decent alternatives suggested so far... > > Hello Kevin, > > I think the average American will think it was translated funky and > assume it is the work of an amateur. Of course, this is just my humble > opinion. But it is the work of an amateur, up till now nobody has offered me any payment for it. What's worse I now realize that it is possible that some literate americans (yes, they do exist) might assume that it was written by some Frenchman, which might be dangerous in the present circumstances. greetings, Ernst ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Preview widget name
On Thu, 03 Apr 2003 02:00:22 +0200 Branko Collin <[EMAIL PROTECTED]> wrote: > What do the two different GimpPreviews do? If they are so alike, why > are there two different versions? Please explain it to me as if I did > not understand programming at all (which I don't, so it will be very > easy for me to play my part :-)). There is a large difference. The GimpPreview in the GIMP is used internally, and is not avalaible to plug-ins (I you are really as naive as you pretend, I should probably should have called the plug-ins "filters"). My preview is intended for plug-ins and contains severeal bells-and-whistles, that might be usefull for plug-ins. > As an aside: on your intropage, you end half of the sentences without > and the other half with full-stops. I hope you mean the initial table of contents (I already started looking at the "Introduction" page, but that one looked mostly OK). That is just intended as some help to future software archeologists so that they can determine in which order these pages were written :) But I will immediately admit that my punctiation is horrible. BTW, I have the feeling that most americans would not use the term "full-stop". So I suspect, that you originate from that part of the world that thinks that "Europe" and "the continent" as synonyms. greetings, Ernst ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Preview widget name
On Fri, 04 Apr 2003 00:05:47 +0200 Branko Collin <[EMAIL PROTECTED]> wrote: > Perhaps you two are using different meanings for 'amateur': one being > 'unpaid', the other 'low-quality'. Of course, in the old days, > amateur meant 'noble', 'high-quality', because an amateur was > something who did not need to do something for a living. The word > 'amateur' had a similar meaning that 'hacker' does among hackers. Actually, it was a very implicit reference to the original roots of the word. It is derived from a latin root (amare?) that means "to love", like the french verb "aimer". And especially when you see the mess that IT "professionals" can sometimes create, I don't think that amateur is such a negative term at all. greetings, Ernst ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] The first official release of the new GimpPreviewwidget
After an intolerable long wait, I just released the first official version of the new GimpPreview plug-in widget. You can find it at "http://refocus.sourceforge.net/preview";. It has changed considerably compared with the previous proposal. I have completely eliminated the entire event-id business. In the new version at most one instance of the rendering function can be active. Also all names have been changed to start with GimpPreview. For the time being, I have made this a separate distribution instead of submitting it directly to the Gimp CVS. The main reason is that this makes it easier for developers to test it. It contains several example plug-ins (spread, pixelize and colorify) and a simple test plug-in. The distribution also contains a tutorial, design document and Gtk-doc documentation. Although I can imagine that some persons would be highly reluctant to make any comments, I would like to encourage everyone, especially all plug-in developers, to examine it critically. At the moment there is no installed user-base and it should be fairly easy to change things. greetings, Ernst Lippe ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The first official release of the newGimpPreview widget
On Wed, 11 Jun 2003 13:45:20 +0100 "Adam D. Moss" <[EMAIL PROTECTED]> wrote: > Ernst Lippe wrote: > > After an intolerable long wait, I just released the first official version > > of the new GimpPreview plug-in widget. > > You can find it at "http://refocus.sourceforge.net/preview";. > > I've given it a cursory scan and it looks pretty good to me > (interface and functionalitywise, that is, since any cosmetic > details are a minor issue). Thanks. > It's always good to see people writing docs as well as code! Lack of good documentation has always been one of my main frustrations when using software. On the other hand, writing documentation is hard work, I've spent a lot more time on updating the documentation than I've spent on updating the code. > I quite look forward to using this at some point. > > I really suspect that if there are practical flaws in the design > then they're more likely to become apparent when authors try > to apply the widget to a wide variety of plugins, rather than > simply by reading the design docs. I think that you are right. But at least there are now a few example plug-ins that the users can play with to see if the user interface is OK. BTW, I forgot to mention in my previous post that I am of course highly interested in all experiences of developers that have tried to use this widget. greetings, Ernst Lippe ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Blur filter
On Thu, 19 Jun 2003 16:46:13 -0700 (PDT) Joel Eduardo Rodriguez Ramirez <[EMAIL PROTECTED]> wrote: > Actually I would like to colaborate with a new filter also > (as Bowie), but mine idea is in the direction of: > ``Inverse Image Filtering with Conjugate Gradient'' > > http://people.cornell.edu/pages/zz25/imgcg/ As far as I know nobody tried to implement conjugate gradient filtering as a GIMP plug-in. One of the main reasons I think is that it is not easy to give an efficient implementation. The running time is quadratic in the number of pixels in the image which means that it is too slow to use it on the normal sized images. I would expect that any realistic implementation should use the algorithm on small parts of the image and then somehow combine the results. So, this is not a trivial plug-in to write. Also you should not over-estimate what techniques like conjugate gradient filtering can do. The examples that most authors give are highly artificial. In the page that you referred to the convolution is known exactly and there was no noise in the blurred image. In real life this never happens. First of all you hardly ever know the exact details of the blurring convolution. Most deconvolution algorithms give very disappointing results unless you have a very good approximation of the blurring convolution. Second, almost all images contain noise and this has disastrous effect on the deconvolution. Most deconvolution algorithms tend to amplify the noise to an extreme degree. For example, when using the unmodified inverse deconvolution the end result is normally completely dominated by noise. Although conjugate gradient filtering is not so extremely sensitive to noise, like all deconvolution techniques its results will deteriorate rapidly even when there are only very small errors in the input. A few years ago, when I started with my own deconvolution plug-in I examined several existing algorithms. My own conclusion was that this is a difficult subject. Most of the best algorithms are simply too slow for practical applications. I finally selected FIR Wiener filtering as a practical compromise. The running time is linear in the number of pixels in the image, and in virtually all cases its results are much better than those of similar plug-ins like unsharp mask or sharpen. If you are interested you can find it at http://refocus.sourceforge.net. greetings, Ernst Lippe ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Blur filter
On Fri, 20 Jun 2003 23:58:03 -0700 Joel Rodriguez <[EMAIL PROTECTED]> wrote: > Thanks for your attention to the matter Esnst: > > it is enough information to get me going :) > > I will take a close look at the link which by the way looks very impressive, > the approach was thinking was not conjugate gradient itself, but a variant > of constrained optimization: > > http://www-fp.mcs.anl.gov/otc/Guide/SoftwareGuide/Categories/constropt.html > > particularly the least squares solution, for which I'm familiar with: > > http://www.sbsi-sol-optimize.com/products_lssol.htm > > P.S. wont bother for a while, thanks for your attention, yesterday's > tequila, > some times make me feel that P=NP,..he,... :) Oh, but that is a valid feeling even when you're sober, nobody has proved that they are different. It might be wise to wait with reading the rest of this post until you have fully recovered :) But when you have recovered, I would advice you to study Fourier Analysis. I found it very helpful in explaining why deconvolution is so difficult. One important fact is that a convolution can be described as a multiplication in the Fourier domain, i.e. the Fourier transform of the result is equal to the multiplication of the Fourier transform of the input times the Fourier transform of the convolution. Now this implies that the inverse operation (the deconvolution) can be described in the Fourier domain as a division by the Fourier transform of the convolution. But in virtually all cases the Fourier transform of the convolution contains some values that are very small. In the case that your convolution is circular symmetric, it is possible to prove that its Fourier transform must contain at least one value that is equal to zero. It is obvious that when the Fourier transform of the convolution contains any zeroes, that there cannot be an exact inverse because division by zero is undefined. Also the small values in the Fourier transform cause problems: when you divide by a small number that is of course equivalent to multiplying with a big number, in other words the inverse of the convolution will greatly magnify all errors in the image that correspond with the small valued component. This also helps to explain why least square minimizations frequently give horrible results. Take an image for which the Fourier transform only contains values that are significantly different from zero for the components where the Fourier transform is close to zero. It should be clear that the result of convolving this image with the convolution gives a result where every pixel is almost equal to zero. Because convolution is a linear operation, when you add this image A to another image B and then apply the convolution, the end result must be equal to the sum of the convolution of A plus the convolution of B. But because the convolution of A is almost zero, it is easy to see that the convolution of A + B is almost equal to the convolution of B. But this means that the least square criterion is not very well defined, because when some multiple of A is added to an image the least squares distance will only change by a very small amount. In practice this means, that I can have two completely different images, one that shows a "normal" image and another one that completely looks like random noise. But when I use a convolution on both images the result can be almost identical. The problem with least squares optimization is that this procedure cannot distinguish between these two images. This is the reason that least squares optimization procedures do not perform well, often the optimal solution visually completely looks like random noise. Most techniques that are based on least squares minimization are iterative and do not attempt to find the real minimum. Normally they require user intervention to determine the number of iterative steps. Perhaps this explanation is a bit too convoluted, but I think that it contains some important points. Feel free to ask when you have any problems. greetings, Ernst Lippe ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Blur filter
On Sun, 22 Jun 2003 13:17:49 -0700 Joel Rodriguez <[EMAIL PROTECTED]> wrote: > >In practice this means, that I can have two completely different > >images, one that shows a "normal" image and another one that > >completely looks like random noise. But when I use a convolution > >on both images the result can be almost identical. The problem with > >least squares optimization is that this procedure cannot > >distinguish between these two images. > > I almost agree with you, in the sense that the forward modeling Fourier analysis > based > technique might not be sufficient, although the least squares method (as a hole) > might be. > > Might be if there is a way to incorporate such image information that characterizes > it, > in some other way or aside Fourier analysis, such information (invariant measures) > could > be incorporated into a least squares reconstruction task as regularization scheme > technique. > > although the above sentence it is not a fact to my knowledge. To my knowledge it is a fact. Perhaps the following explanation might help. Given a convolution C and a blurred image B, the least squares technique tries to find an image I such that the least squares distance between C(I) and B is minimal. In my previous post I describe how you could construct an inverse of C, let's call it D. Now for all images X it is true that C(D(X)) = X, therefore I=D(B) is the least square solution because C(I)=C(D(B))=B. When the Fourier transform of C contains any zero coeficients, the inverse D is not uniquely determined. In fact, I can choose arbitrary values for the coefficients in the Fourier transform of D that correspond with the zero coeficients in C. This is true because you can describe convolution in the Fourier domain by multiplication of the coeficients. When I multiply a value by zero the end result is always zero. So when the Fourier transform of C contains zero coeficients there are an infinite number of least square solutions, and the least square criterium alone cannot select one of them. Even when the Fourier transform does not contain zero coeficients the least squares solution is generally not a visually good solution because it is extremely sensitive to errors. The problem is that C frequently contains some small coeficients, the corresponding coefficients in D are therefore very large. But this means that D will greatly magnify any errors in the corresponding Fourier coeficients of the blurred image B. So even very small changes in B will have a great impact on the least square solution I=D(B). In practice this means that in general you don't want to use the true least square solution because it is highly unstable. greetings, Ernst Lippe ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: [CinePaint-dev] GIMP/CinePaint fileincompatibility
On Wed, 09 Jul 2003 18:42:08 +0200 Sven Neumann <[EMAIL PROTECTED]> wrote: > Him > > "Robin Rowe" <[EMAIL PROTECTED]> writes: > > The plan is for CinePaint to move away from this undocumented and > > incompatible XCF format we inherited -- and can't properly support > > -- to a new XML-ish file format that will be called CPX. I am still > > designing that, but have already documented the basic format. It > > should replace gbr too. > > You might then be interested to hear that we started to discuss a new > file format for GIMP more than 3 years ago and came up with an XML > based design as well. More details will probably be made up at the > GIMP developers conference next month. Couldn't both teams try to find a common format? After all XML is quite flexible and it should be easy to flag the extensions that are not supported by the other program. Both programs have a lot in common. Users will really appreciate it when they can easily exchange data between the two programs. (I know this is probably not quite the right moment to suggest this) greetings, Ernst Lippe (PS. Robin I would apreciate it if you could forward this message to the cinepaint-developers list. I think that this is an important issue for both groups of developers.) ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] the user installer
On Wed, 09 Jul 2003 20:50:14 +0100 (BST) Alan Horkan <[EMAIL PROTECTED]> wrote: > The user does not need to know about the General Public License (it does > not apply unless you want to distribute modified versions). The GPL also applies to unmodified programs. For example, users may not give copies of the binaries to other without telling them that it is GPL-ed and giving them access to the sources. I am not a great fan of licenses either, but from a legal point it is really important to inform all users about their license. greetings, Ernst Lippe ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Tentative 2.2 feature list
On Fri, 06 Feb 2004 16:51:28 +0100 Sven Neumann <[EMAIL PROTECTED]> wrote: > Hi, > > David Odin <[EMAIL PROTECTED]> 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Tentative 2.2 feature list
On Wed, 18 Feb 2004 10:18:58 +0100 Dave Neary <[EMAIL PROTECTED]> wrote: > Hi, > > Ernst Lippe wrote: > > Sven Neumann <[EMAIL PROTECTED]> 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Tentative 2.2 feature list
On Wed, 18 Feb 2004 13:51:40 +0100 Sven Neumann <[EMAIL PROTECTED]> wrote: > Hi, > > Ernst Lippe <[EMAIL PROTECTED]> 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: GIMP preview widget (was tentative 2.2 feature list)
On Wed, 18 Feb 2004 15:18:49 +0100 Dave Neary <[EMAIL PROTECTED]> wrote: > > Hi Ernst, > > Ernst Lippe wrote: > > Dave Neary <[EMAIL PROTECTED]> 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 orig
Re: [Gimp-developer] Re: Tentative 2.2 feature list
On Wed, 18 Feb 2004 16:19:06 +0100 Sven Neumann <[EMAIL PROTECTED]> wrote: > Hi, > > Ernst Lippe <[EMAIL PROTECTED]> 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 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP preview widget (was tentative 2.2 feature list)
On Thu, 19 Feb 2004 16:45:45 +0100 Dave Neary <[EMAIL PROTECTED]> wrote: > Hi, > > Ernst Lippe wrote: > > Dave Neary <[EMAIL PROTECTED]> 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 u
Re: [Gimp-developer] Re: Tentative 2.2 feature list
On Thu, 19 Feb 2004 16:00:08 +0100 Sven Neumann <[EMAIL PROTECTED]> wrote: > Hi, > > Ernst Lippe <[EMAIL PROTECTED]> 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
