On 11/23/10 18:03, Torsten Neuer wrote: > Am 23.11.2010 16:11, schrieb bioster: >>> On 11/23/10 08:24, Patrick Horgan wrote: >> >>> What is the aim here? Unless I've missed the point, it seems like a >>> trade-off between computation time for the matrix and memory footprint >>> of storing all the possible values that matrix could hold. >> >>> That's fairly bit of memory to grab if there's not a real need. How long >>> does it take to calculate matrix each time? Is this even a noticeable >>> proportion of the time required to apply the filter to an image? >> >>> If I've got the wrong end of the stick, what is the problem with the >>> current code? >> >>> regards. >> >> I think they're talking about trading off between spending CPU time computing the matrix and spending memory storing it precomputed. >> >> I think I disagree with you about it being a "fair bit of memory". 30-40k of memory in't a big deal by today's standards, and when you put that beside a modestly sized image which can easily run a few megabytes, I would consider it entirely reasonable. That's assuming you release that memory after your unsharp tool is done. The computation time is probably in the same class... my computer is fairly brisk and I don't think the time spent computing the matrix is noticable. > > Don't forget about code size and the size of memory allocated for the > matrix - this also takes up a certain amount of memory. Maybe not > 30-40k, but the difference between run-time computed and pre-computed > values would not be that big, but... > >> So it's not that there's a "problem" with the current method, they're just pondering whether they can squeeze better performance out of it by making the tradeoff. > > And this is the real trade-off: trading maintainability of code - just > imagine someone wanted to increase the precision of the "radius" > parameter - for a minimum amount of speed. > > This function IS CALLED ONLY ONCE for the whole filtering progress! > > Which means that this is clearly the least important place for code > optimization in this plug-in, since the speed gained from making the > matrix pre-computed will dissolve into nothingness with growing images! > > How many microseconds does the computation of the matrix take ? > Did anyone evaluate this yet ? > > I mean, before starting to speculate about methods of optimization for a > certain part of code, one should first have a look at what can be gained > there - in this case: near zero. > > > Torsten > I agree , I thinks there's not much point unless someone benchmarks this and shows there is a real problem. However , in reading up on this I found this article suggesting that it is at least 2x faster to do this operation on luminosity in YUV rather than RGB and it often looks better by avoiding odd looking inverse colours. http://www.codeguru.com/cpp/g-m/gdi/gdi/article.php/c3675 I also note that the preview could be streamlined in some areas. 1/ clicking preview on and off clearly redoes the whole operation , this should probably be buffered if the params are the same as the last on state. Clicking on/off is a valid requirement to visually compare before and after. With a large radius this can be quite a long wait. (2-3s on a 2.4GHz Athlon) which impedes a clear comparison. The preview could be saved in a tile and simply restored if none of the parameters change and the window is not moved. 2/ dragging the preview box could poss benifit from storing the matrix but again this could be micro-seconds. 3/ a small drag of preview reverts the whole thing to unprocessed data and starts again. This is a waste of time if the drag is less than the whole preview window size. The drag could copy the already sharpened area and just work on the two rectangles that got dragged in. Keeping the already processed rect would also be a good visual feedback , especially when using the NESW crosshairs to drag the window. some quick experimenting seems to indicate that this is common behaviour on ALL filter previews. While many are fast enough (on fastish processors) convolution based filters can be rather slow. since unsharp is the most useful sharpen filter it may merit some work , especially if it would benefit across all filters. /gg _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
