Image.Image->apply_matrix is not always very useful...
I'm a little busy myself, otherwise I would provide a patch, my suggestion is that someone adds a function that does this to Image.Image:
Image.Image convol(Image.Image i, array(array(array(array(float)))) foo) { Image.Image ret;
array(array(array(array(int)))) foo1= ( array(array(array(array(int)))) ) (foo[*][*][*][*]*100000);
for(int x=0;x<3;x++) { array(int) c1=({ 0,0,0 }); c1[x]=255;
array(array(array(int))) foo2=foo1[*][*][x];
for(int y=0;y<3;y++) { array(array(int)) foo3=foo2[*][*][y]; int sum=`+(0, @ foo3*({}));
array(int) c2=({ 0,0,0 }); c2[x]=255;
Image.Image tmp; tmp=i->gray(@c1)->apply_matrix(foo3,0,0,0, sum?100000.0/sum:1.0)*c2;
if(ret) ret+=tmp; else ret=tmp; } } return ret; }
I've need a function like this twice now, so I think it would be useful. Also, the implementation above is grossly inefficient..
If anybody knows a faster way to do the same thing with the currently available Image operations, let me know.
Possible extentions to this function: o Add the results to an image to avoid the clipping that would occur if you did the addition afterwards. o Add x-stride and y-stride to allow it to compute only every x:th and y:th pixel to allow scaling in the same step. (Is it even possible to scale an image without averaging right now?)
(I assume that when you say "transform", you mean "fourier-transform") Transforming/multiplying/transforming is only faster for fairly large kernels. Weather it is more accurate or not depends on what you're doing, and on the size of the kernel and transforms.
When it comes right down to it, I don't really care *how* it does it.
/ Fredrik (Naranek) Hubinette (T minus 2 weeks)
Previous text:
No, apply_matrix has a few deficiencies:
1) There is no way to make the red channel of the input affect the green channel of the input.
2) There is no way to supply a different divisor for each channel, which makes operations that has a different gamma for each channel impossible.
Because of these two things, the convol() function has to separate the channels and do 9 different calls to apply_matrix to achive the operation I want. One for each combination of {R,G,B} -> {R,G,B}.
Probably the best way to implement the functionality I want is to extend apply_matrix so that it can:
a) Accept floats as well as integers b) Accept a 3x3 matrices as wel as 3x1
Disclaimer: It's possible that some of this already works, but is undocumented... :)
/ Fredrik (Naranek) Hubinette (T minus 2 weeks)
Previous text:
pike-devel@lists.lysator.liu.se