[wp-trac] [WordPress Trac] #22663: Performing a non-square rotate() with Imagick, then cropping, can result in incorrect Image

WordPress Trac noreply at wordpress.org
Fri Nov 30 22:49:43 UTC 2012


#22663: Performing a non-square rotate() with Imagick, then cropping, can result in
incorrect Image
-----------------------------+--------------------------
 Reporter:  DH-Shredder      |       Type:  defect (bug)
   Status:  new              |   Priority:  normal
Milestone:  Awaiting Review  |  Component:  Media
  Version:  trunk            |   Severity:  normal
 Keywords:  has-patch        |
-----------------------------+--------------------------
 Note:  This is only for *some* recent versions of ImageMagick.  Older ones
 seem to be a bit more sane, and work fine without any patch whatsoever.

 When ImageMagick performs certain operations, it sets its virtual page's
 x/y origin values to non-zero numbers and leaves them there, which can
 break some further operations that depend on the virtual page.

 In this case, when rotating in non 90 degree increments, Imagick doesn't
 set the x/y, which means that core doesn't run into this bug, since the
 built-in image editor only allows for 90 degree rotates in either
 direction.

 However, if you're a user of the API, and perform a "non-square" rotate,
 then a crop, you could end up with an image result that differs from what
 you'll get from GD.

 There are two ways of fixing this:
 - Update the virtual page with each update_size()
 - Update the virtual page immediately after a rotate() only

 The first is what I think we should land on eventually, because it will
 prevent plugins' methods from breaking core's accidentally (if they do not
 reset the page's values).  However, that would require an additional error
 message to be added, which means a new string.

 The second would fix the bug for anything core's APIs would do, but would
 depend on plugins handling resetting the page values appropriately in
 their own methods.  It is, however, a bit safer (and wouldn't require a
 string change), if this is something that might land for 3.5.

 I've attached patches for each method.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/22663>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software


More information about the wp-trac mailing list