[wp-trac] [WordPress Trac] #6821: ImageMagick support

[WordPress Trac]

#6821: ImageMagick support
----------------------------+-----------------------
 Reporter:  matt            |       Owner:
     Type:  task (blessed)  |      Status:  assigned
 Priority:  normal          |   Milestone:  3.5
Component:  Upload          |     Version:  2.5
 Severity:  normal          |  Resolution:
 Keywords:                  |
----------------------------+-----------------------

Comment (by DH-Shredder):

 Posted [attachment:Initial_Proposal.php] as a topic for conversation.

 I'm currently still working on an implementation of resize for GD (then
 ImageMagick) as a proof-of-concept, but wanted to post this in the
 meantime.

 It's very much a work in progress, since going from a completely image-in-
 memory-then-save process is significantly different than avoiding any
 images in memory, and doing as few system calls as possible, for something
 like `convert`.

 It does have one characteristic of an image container, and accepts a file
 as initial input for instantiation of the class.  This was done so that
 wp_load_image can use it as a replacement or creation of a new image, and
 should help with integration into current code.

 It's posted as an interface, but will likely end up as an abstract base
 class, so that common content and decisions on what the best Editor to use
 can be made appropriately.

 I'd thought about including functions like truecolor_to_palette(), but
 decided against it because not all Editors need to make this an extra
 step.  In ImageMagick, it's just another parameter for file
 conversion/creation that can go along with a resize, for instance.

 Questions/Ponderings:
 * Streams are currently being handled by changing what is output by the
 functions, which isn't great.  Any suggestions as to how to handle this
 case the best?
 * Another option to having an Output File as an optional parameter would
 be to defer all changes until .save() is called, which is (I believe) what
 Scribu had initially suggested.  What seems best / thoughts on an even
 better way to do it?
 * It's easy enough to default to the "best" class, and use that, but
 unsure on the best approach to detect/automatically use secondary tools
 for only specific methods.  Ideas?

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/6821#comment:27>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software