Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 29473 invoked from network); 27 Jul 2007 12:17:31 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 27 Jul 2007 12:17:30 -0000 Received: (qmail 49506 invoked by uid 500); 27 Jul 2007 12:17:29 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 49432 invoked by uid 500); 27 Jul 2007 12:17:29 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@cocoon.apache.org List-Id: Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 49421 invoked by uid 99); 27 Jul 2007 12:17:29 -0000 Received: from Unknown (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 27 Jul 2007 05:17:29 -0700 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [195.54.101.71] (HELO proxy1.bredband.net) (195.54.101.71) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 27 Jul 2007 12:17:23 +0000 Received: from kurono.home (83.227.131.3) by proxy1.bredband.net (7.3.127) id 46A848D60009611F for dev@cocoon.apache.org; Fri, 27 Jul 2007 14:17:00 +0200 From: joakim@verona.se To: dev Subject: imageop suggestion Date: Fri, 27 Jul 2007 14:17:00 +0200 Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Checked: Checked by ClamAV on apache.org The imageop block is quite useful for image operations, much more so than the imagereader in the core. It would be nice if it could be released. However there seems to be some problems with rotation code. I mostly managed to get lots of black areas, and spurious image fragments in the rotated image. I had a look at the cocde and its not obvious what a rotation should do, which I think is the root cause of the problem. (that is, what should be the bounding box, where should the anchor for rotation be etc) I propose hiding the general rotation operator, and implementing a rotate-at-right-angle operator. This special case is IMHO the most useful type of rotation, its obvious how it should work, and could be more easily implemented and perhaps optimized. I can implement this if the list decides this is a good idea. (I will probably anyway for my own needs). The general rotation operator could be tackledd later, but wouldnt be necessary for release. -- Joakim Verona