|
|
Posted by Steve on 04/16/07 03:18
ok, throw the class away.
| // REMEMBER TO USE REFERENCE POINTER ONTO $image OBJECT TO ENSURE
| "static" CHANGE TO OBJECT AND NOT TO INSTANCE
this 'explanation' is totally off the charts as to being wrong. follow that
up with the magical 'global $sections' and you've got icing for the cake.
not to mention this class will leak like a fucking screen used to pan gold.
there is color allocation for every pixel, there is a count/sizeof operation
on this allocation inside a loop. next, it uses color averaging to derive
gray. last but certainly not least, this class totally ignores the fact that
images have alpha layers. do i dare mention that this class doesn't clean up
after itself? it relies on YOU to destroy the images IT creates among other
niceties.
for all the 'performance' reasons the brain-dead author gives for creating
this beast, he shows far more neglect in his code...which by default will
run more slowly that imagecopymergegray() since it isn't part of php native
code! plus, as you've already seen, it fucking blows up.
i'd look up imagecopymergegray() on php.net and see how the commenters there
are performing grayscale operations. they at least have the math
approximations for calculating gray a better match than ol' phil here.
btw imho, any class that simply has procedural code (simply a set of
similar/related functions) should be singletons. this is a perfect example.
i'd have named the class 'imaging' and given an interface called
getGrayscale...
$igg = imaging::getGrayscale($image);
all the height/width shit can be discovered via the one arg $image and
nothing else in that class needs to be stored by the object instance. that
may be just me, but as far as i am concerned, i'm already waaaay past strike
three here.
Navigation:
[Reply to this message]
|