Re: [PEPr] Images::Imagick proposal, functionnals

> => Managing the greedyness > > Some functions are very greedy, like for exemple oilpaint, medianfilter, > reducenoise, etc.. very *far* more greedy than all the other ones. > I think it could be a good idea to add a switch to provide the possibility > to disallow those for a web usage. > The default could be allow greedy funcs of course, and a switch like this: > $im->allowGreedyFuncs(FALSE); > or > $im->disallowGreedyFuncs(); > (or perhpas a name with 'slow' I don't know) > > I had this in mind for when I would have start the web interface of Conjure. This is a good point, and I know about this issue. But not allowing a user to use methods would mean to hack the source of the class - and this is something you don't want to do. I see no other way to prevent a user from using specific functions. Keep in mind that pecl-imagick would hardly find it's way on a shared hosting server. I think this lies in the responsibility of the server-admin. > I have seen giving the image filename to the constructor Image_Imagick() is > not optional, while it is in loadImage(). I have fixed this. The idea was to call the imagick-functions for reading the image after the object is created, so that you can return an error if the read fails. It is now optional in both methods. The user can decide where he wants to submit the image-name. > What about common IM starting images with: > xc, gradient, plasma, plasma ? [1] > And the Anthony Thyssen's technics? > echo "P3 2 2 255\n0 220 240 0 140 150 0 140 150 0 80 80" | \ > convert -geometry 512x512 - miff:- | display > > Yes I know all those above are just bringing pecl::imagick to segFault, > but I think you should consider the shining futur where it will work, > like in the mature Perl IM api. > I know that php-imagick hardly lacks compared to the IM's Perl equivalent, > but IMHO we should provide the blob functions even if those seg-faults on > these entries, and if the user trys a blob('plasma:fractal') say him it is > not available yet in pecl-imagick, if he trys a glob('gradient:#0f8-#08f') > writing a macro to provide this until this one would be implemented in > pecl-IM, and if the user trys a blob('xc:#38B') redirect it to getCanvas. > > Creating images base with blobs is a very common thing for every-day IM users. Well, I have to think about this one. Do you need those in your Conjure? > Nevertheless it *is* possible to create an image from scratch yet in pecl->IM > with the base function getCanvas, and then to enhance it further with all the > draw functions. > The IM bezier draw functions have not been writen yet, but it is yet possible > to blob a dynamicly generated SVG string into the blob IM-pecl function. > It does work. > In this case too, the constructor should not be feed with an image filename. Image_Magick was designed to let the user manipulate an image. Maybe a second class will handle this better? Btw the constructor doesnt need a filename anymore ;) > Back to the filename entry problem in loadImage() the img-file-name to load > is optional, which I find quite illogical. > > I have just wrote the loadImageData() function which I will have to use in > Image_Magick_Conjure, I have also added printImage() build on image2blob > which other user will need to send img to browser without caching it (img > from a DB or else). > I don't know what would be the good name for this one tmp name 'printImage', > I have not checked yet how it is named in Perl-IM (not have to cut-past it, > but should be interesting), also have to check how the equivalent is called > in php-GD. > Idem for the loadImageData() name which is the style name of this current > class. Wouldn't the standard blob() name be preferable? Well, image2blob and vice versa blob2image sounds just fine for me. Do you just need to get the bytes in raw format out of the db? An echo blob2image() should work then, shouldn't it? > For the filename entry, perhaps it should be optional in the constructor, > and necessary in the loadImage() method? What do you think? > On this at first I though when an img filename is given to the constructor, > it should call, loadImage(), but then now I think a user could also want to > given the new image-name he want to create and does not exists yet, then use > gradient:, annotate, dyn-svg or draw, and then saveImage This is what the class can do now. It just lacks the appropriate methods which are not in the class right now. > So I 100% trust in you for this part to be correct ;-) So do I ;)