Re: Re: ext/imagick BC break (was: Re: [PEAR-DEV] PHP Magick version 0.5a Released!)

Hi I introduced the copy_* functions, because of some memory-leak issues and because gd and imlib did it more or less the same way. But from what I can see looking at Michaels code, the memory issues are not an issue with his implementation and his approach is ok. about imagick_list_magickinfo(). It would be nice, if there would be a solution to know, which imageformats are supported. Meaning, I can ask within PHP imagick_is_supported("GIF") and it returns true or false. I think, that was the whole idea back then. It was not implemented very well and most certainly just a quick hack :) parsing phpinfo() is certainly not an option for that. just my 0.02 swiss fränklis chregu On Tue, 2002-11-26 at 16:33, Michael Montero wrote: > Quick review, I will work on the doc. and forward around. Will shoot for > today (althought most of the doc. is already below). These functions are > supported: > > PHP_FUNCTION(imagick_border); > PHP_FUNCTION(imagick_frame); > PHP_FUNCTION(imagick_resize); > PHP_FUNCTION(imagick_sample); > PHP_FUNCTION(imagick_crop); > PHP_FUNCTION(imagick_rotate); > PHP_FUNCTION(imagick_shear); > PHP_FUNCTION(imagick_oilpaint); > PHP_FUNCTION(imagick_annotate); > PHP_FUNCTION(imagick_convert); > > I haven't looked at each specifically but there is a chance the parameter > order changed. UNLESS (and I believe Christian and I followed this > standard) the handle is the first parameter and the subsequent parameters > match the order in which they are passed to the ImageMagick functions. I > looked at imagick_resize (old one) and the new one and they are dead on. > > These functions have been made backward compatible: > > PHP_FUNCTION( imagick_read ) ; /* => imagick_readimage() */ > PHP_FUNCTION( imagick_write ) ; /* => imagick_writeimage() */ > PHP_FUNCTION( imagick_free ) ; /* => imagick_destroyhandle() */ > > These have been deprecated: > > PHP_FUNCTION( imagick_add_resource ) ; > PHP_FUNCTION( imagick_list_magickinfo ) ; > PHP_FUNCTION( imagick_new ) ; > PHP_FUNCTION( imagick_init ) ; > PHP_FUNCTION( imagick_copy_sample ) ; > PHP_FUNCTION( imagick_copy_resize ) ; > PHP_FUNCTION( imagick_copy_crop ) ; > PHP_FUNCTION( imagick_copy_shear ) ; > PHP_FUNCTION( imagick_copy_rotate ) ; > PHP_FUNCTION( imagick_copy_morph ) ; > PHP_FUNCTION( imagick_dump ) ; > > A few explanations: > > imagick_add_resource() and imagick_list_magickinfo() aren't entirely > necessary anymore. The phpinfo() will list everything that > imagick_list_magickinfo() would dump to a file. If anyone disagrees, I > can implement the function but I'd rather the data in phpinfo() then > requesting PHP to dump a file. imagick_add_resource() will be supported > in SOME fashion with regard to image lists. I believe this will use the > ImageMagick push functions and should appear perhaps today. If I CAN make > this function backwards compatible I will. > > imagick_new() has no meaning...to create a new handle you either have to > create a canvas or read an image. Currently you can read an image from a > file and by the time we're done from a blob of data as well. You can > create a canvas of a specified size and color. Coming soon will be > creating a canvas with a tiled background created from a custom image. > > imagick_init() isn't necessary anymore. ImageMagick needs to be > initialized but I have removed the need for the user to remember doing > this. The module will initialize itself and clean up after itself. > > imagick_copy* functions are too ambitious. The ImageMagick library is > enormous and writing a corresponding copy function for every operation, in > my opinion, is a wasted efforted (again, based solely on the number of > functions available in ImageMagick). Instead, I support this: > > <? > $existing_handle = imagick_readimage( "./image.jpg" ) ; > $new_handle = imagick_clonehandle( $existing_handle ) ; > > // now execute a function on the cloned handled > ?> > > In other words, instead of the function creating a new handle and > returning it to you, you'd create a new handle and operate on it. > > imagick_dump(): I thought about this a lot. This essentially writes the > image file out, then reads it and writes it to the browser. This seems > like a lot of effort if all the user wants to do is work on an image and then > just display it. You can achieve this with the new API by doing: > > <? > $handle = imagick_readimage( "./image.jpg" ) ; > > header( "Content-type: " . imagick_getmimetype( $handle ) ) ; > print $image_data = imagick_image2blob( $handle ) ; > ?> > > If you want to write the file you can do so at another point or not do it > at all. > > If anyone disagrees with this assessment let me know. I can put some work > into some of it. However, I'm pretty opposed to the copy functions. > There would need to be something like 20 or 30 (perhaps more) in addition > to the same functions that operate on image itself without copying it. This > seems like far too much to support. It makes more sense to me to let the > user clone the handle when that's what they want and start operating on a > different image entirely. > > Let me know what you think. > > On Tue, 26 Nov 2002, Alan Knowles wrote: > > > Michael Montero wrote: > > > > >I will clearly document how to go from the BC version to the new one. > > > > > can you give a 2-3 line overview of the differences: > > functions have different arguments/order? > > missing functions? > > (lots of new ones I presume :) ... > > > > phpmole uses it to do resize/rotate etc. > > Regards > > Alan > > > > > > > > > > > > > > > >On Mon, 25 Nov 2002, Christian Stocker wrote: > > > > > > > > > > > >>Hi > > >> > > >>As mentioned in the mail by Michael, we will replace pecl/imagick with his > > >>version, as I think, he has much more to offer than my code (and much more > > >>time to support it right at the moment :) ). I will still support the > > >>extension and hopefully contribute to it. > > >> > > >>Therefore here comes the big WARNING: > > >> > > >>The commits (and finally releases) in the next few days will break BC of > > >>pecl/imagick! Therefore, if anyone is using this extension and really > > >>really needs BC should stand up now and maybe we will have a look what we > > >>can do :) But since it's clearly stated as alpha and experimental, noone > > >>should be surprised by that > > >> > > >>Anyway, have a nice evening and check out Michael's work. > > >> > > >>christian > > >> > > >> > > >> > > >>On Mon, 25 Nov 2002, Michael Montero wrote: > > >> > > >> > > >> > > >>>Just released some more functionality. The major push right now is join > > >>>my efforts with those of Christian Stocker to get one single module into > > >>>PEAR. Christian and I have been working that. Please see the latest > > >>>changes below...they are significant. > > >>> > > >>> - functions added: > > >>> imagick_getcanvas() > > >>> imagick_blur() > > >>> imagick_despeckle() > > >>> imagick_edge() > > >>> imagick_emboss() > > >>> imagick_enhance() > > >>> imagick_gaussianblur() > > >>> imagick_medianfilter() > > >>> imagick_motionblur() > > >>> - one major change - renamed everything to imagick*; I've joined > > >>> my efforts with Christian Stocker who had a previously written > > >>> but smaller extension > > >>> - magick_getcanvas() allows you to create a blank image to draw on > > >>> - changed comment header in imagick.h to match the one in > > >>> imagick.c > > >>> - added Christian Stocker to credits > > >>> - moved over to Christian Stocker's config.m4, removed the need > > >>> for gen_configm4 > > >>> - rewrote INSTALL to reflect new config.m4 > > >>> - slight modifications to config.m4 to get it to work properly > > >>> - added package.xml > > >>> - removed ChangeLog, everything is now in package.xml > > >>> - removed imagick_free_reason() and imagick_free_description() > > >>> since they are no longer necessary > > >>> - preceded all internal functions with _php_ > > >>> - created imagick_read() for backward compatibility with old > > >>> extension > > >>> - created imagick_write() for backward compatibility with old > > >>> extension > > >>> > > >>> > > >>> > > >>> > > >> > > >> > > > > > > > > > > > > > > > -- christian stocker | bitflux GmbH | schoeneggstrasse 5 | ch-8004 zurich phone +41 1 240 56 70 | mobile +41 76 561 88 60 | fax +41 1 240 56 71 http://www.bitflux.ch | chregu@bitflux.ch | gnupg-keyid 0x5CE1DECB