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?


Gimp-developer mailing list

Reply via email to