Re: [Gimp-developer] unsharp mask
On 11/23/2010 06:17 PM, g...@catking.net wrote: > On 11/24/10 02:04, Patrick Horgan wrote: >>If it was, then "If I've got >> the wrong end of the stick" would mean, "If something >> bad is happening to me". My brain never stops! lol! >> >> >> best regards, >> >> Patrick > I think the basic idea is one of making a mistake by picking up a stick > by the wrong end , which is covered in shit. Really! My word. That's graphic. That's ok. This IS a list having to do with graphics. > I don't know the exact origin. It's a bit like "when the shit hits the > fan". I don't think you're supposed to ask who's fan and where did the > shit come from and how come it gets near the fan anyway? Well at least the image of the metaphor is clear. You know that if shit hits a fan it's bad, but wrong end of a stick just isn't as obvious. > It's just a colourful expression which is a bit more fun that saying "if > I'm mistaken". > > > We're all agreed that avoiding calculating the matrix is pretty > pointless. Any thoughts on what I said about the previews? Sounded important and made me think that if no one else looks into it by the time I finish all the other things I'm doing for various projects it would be fun and worthwhile looking into. Really, why wouldn't you cache the result of all that work? I'm getting to a point in my life where it's about time to get back into graphics and catch up with OpenGL (just got the new SuperBible), and learn gegl. Need to get a paying job soon too. Can't work for equity forever. Anyone need a good linux C/C++ systems programmer? lol! Patrick ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] unsharp mask
On 11/24/10 02:04, Patrick Horgan wrote: > If it was, then "If I've got > the wrong end of the stick" would mean, "If something > bad is happening to me". My brain never stops! lol! > > > best regards, > > Patrick I think the basic idea is one of making a mistake by picking up a stick by the wrong end , which is covered in shit. I don't know the exact origin. It's a bit like "when the shit hits the fan". I don't think you're supposed to ask who's fan and where did the shit come from and how come it gets near the fan anyway? It's just a colourful expression which is a bit more fun that saying "if I'm mistaken". We're all agreed that avoiding calculating the matrix is pretty pointless. Any thoughts on what I said about the previews? /gg/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] unsharp mask
On 11/23/2010 09:03 AM, Torsten Neuer wrote: > ... elision by patrick ... > 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. That's true. > 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 ? It's minimal, you wouldn't have to evaluate it to tell that. Inspection of the algorithm is enough. Sorry, didn't mean to cause an uproar! I was just being playful with code when someone was asking about the convolution matrix, and my brain took off down a tangent. No one in the conversations suggested that there was a problem, or that we make any changes to the code. We were just discussing one of the details about the algorithm and alternate ways of doing it. It's fun to talk about algorithms and the tradeoffs between calculation vs tables. No one said that there was a problem that had to be fixed. The tradeoffs are minimal, although your point about the maintainability of the code changing if someone wanted to change (not just increase, any change) the precision of the radius is the only point I've seen that could really differentiate between the choices. That's always an important consideration in design of stuff like this, "Would the precision of the input parameters ever change?" Thanks for bringing that into the discussion and thanks for joining the discussion. > 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. No one _was_ talking about optimizing. It was just a sort of fun water cooler discussion about code. It's true, that in this case there's not much to differentiate between the choices, but it's important to think about choices like this because we're not always maintaining code, sometimes we're writing new code. One of my favorite things about this plugin is the clarity of the code and the documentation. There's even one routine written twice, once in a clear way, disabled, and then again in an optimized way with a comment that it's the same algorithm as the clear one with loop invariants hoisted out of the loop. What a great way for a developer to communicate. Much better than the usual code with no comments. Patrick ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] unsharp mask
On 11/23/2010 03:50 AM, g...@catking.net wrote: > ... elision by patrick ... > 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? You're right. When the image of the plugin is only 7k or so, and the dynamically allocated memory for the matrix is 1/99th of the size of the static array, in comparison it's a fair bit. The only place we'd care about it would be at initial load of the plugin. It's still kb vs mb or gb of an image, so it's not a lot in real terms. The time to calculate the matrix each time is not noticeable on any modern computer. Shoot, running it 100 times to make the include file was only a few milliseconds. The only reason I looked at it was because someone was talking about it and I wondered whether it was wasted time to calculate it each time the radius was less than 10. It filled in time while my brain was figuring out a templating problem in the background. It was a fairly meaningless exercise to avoid being annoyed at something I _couldn't_ figure out just then. My brain is really content to stay busy solving meaningless problems for fun though;) To really know, you'd have to do tests each way to see if it really made any difference either way, and I suspect it doesn't. It's certainly not what holds anything up in the user's experience of the plugin. For a few, it might make a difference in comprehensibility, but I doubt it. A comment that says what the method calculates, vs a similar comment that the table is the result of such calculations doesn't seem much of a difference. > If I've got the wrong end of the stick, what is the problem with the > current code? I like that expression. Clearly means, "If I'm wrong" only longer and more colorful. I wonder where it came from? I don't think I've heard it before. Is it from a particular region of the world? Growing up in Texas we had a LOT of cool expressions. What kind of stick is it? What would you do with the right end of the stick? What happens to you if you have the wrong end of the stick? Just what the heck IS the metaphor? If someone is getting beaten the wrong end of the stick would be the one hitting you and the right end would be the end being held by the person using it, but clearly, that's not the metaphor! If it was, then "If I've got the wrong end of the stick" would mean, "If something bad is happening to me". My brain never stops! lol! best regards, Patrick ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] unsharp mask
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@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] unsharp mask
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 signature.asc Description: OpenPGP digital signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] unsharp mask
>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. 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. -- bioster (via gimpusers.com) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] unsharp mask
On 11/23/10 08:24, Patrick Horgan wrote:
> On 11/22/2010 01:26 PM, Ofnuts wrote:
>>
>> Well, I wondered too: the radius slider goes from 0 to 120 in .1 steps
>> so that would be only 1200 values to pre-calculate.
> They only do it for numbers less than 10 and the length varies with the
> radius (from a low of 5 to a high of 45) as well. The total number of
> entries would be 2520 * 8 bytes for a gdouble so it would only need
> 20,160 bytes of storage, ideally but since C doesn't have variable
> length arrays you'd have to declare the array as something like:
>
> static gdouble global_cmatrix[100][45];
>
> which would make the length 4500*8=36000 bytes but of course you'd have
> to store the length of each as well. If you wanted to you could store
> them as unsigned chars, so it would be another 100 bytes, or a total of
> 36100 bytes. In a trial it really added 36831 bytes. How would that
> affect the usability of the plugin? I've attached an include file that
> has the matrices you would need. Then you could use:
>
> static gint
> gen_convolve_matrix (gdouble radius,
> gdouble **cmatrix_p)
> {
> *cmatrix_p=global_cmatrix[(int)((radius*10)-.5)];
> return cmatrix_lens[(int)((radius*10)-.5)];
> }
>
> I don't know if it would be a good idea or not.
>
> Is it true though that the user interface only _allows_ values in tenths
> or is it that it only displays values in tenths but returns values in
> between?
>
> Patrick
>> ___
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.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
