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;
> 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)
> 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
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
Gimp-developer mailing list