{"issue":{"pull_request":{"diff_url":null,"html_url":null,"patch_url":null},"state":"open","user":{"avatar_url":"https://secure.gravatar.com/avatar/d38343994d650e09acf2861e4b5db41a?d=https://a248.e.akamai.net/assets.github.com%2Fimages%2Fgravatars%2Fgravatar-140.png","gravatar_id":"d38343994d650e09acf2861e4b5db41a","url":"https://api.github.com/users/ptone","login":"ptone","id":40845},"milestone":null,"assignee":null,"labels":[],"updated_at":"2011-11-13T22:43:43Z","closed_at":null,"comments":5,"url":"https://api.github.com/repos/jdriscoll/django-imagekit/issues/63","body":"f570bd0d7f57004550f54702c06fea1226f5be41 changed the way images were opened, and wraps the original copy method with one that tries to preserve extra imagekit related info.\r\n\r\nhowever this results in the image data being retained somehow in memory - I'm not sure exactly how or where.\r\n\r\ncommenting out this line:\r\n\r\n```img.copy = types.MethodType(_wrap_copy(img.copy), img, img.__class__)```\r\n\r\nresults in a substantially reduced memory footprint\r\n\r\nI've created a quick sample app/project to demonstrate this - if you watch the process memory - you can see it climb.\r\n\r\nhttps://github.com/ptone/imagefoobar (note this is using the new Django 1.4/trunk layout)\r\n\r\ncc @lettertwo ","html_url":"https://github.com/jdriscoll/django-imagekit/issues/63","title":"wrapping Image.copy causing an adverse impact on memory use","number":63,"id":2195140,"created_at":"2011-11-10T06:06:03Z"},"action":"created","comment":{"user":{"avatar_url":"https://secure.gravatar.com/avatar/523b00c3c60e634c61e7b121a66b3902?d=https://a248.e.akamai.net/assets.github.com%2Fimages%2Fgravatars%2Fgravatar-140.png","gravatar_id":"523b00c3c60e634c61e7b121a66b3902","url":"https://api.github.com/users/lettertwo","login":"lettertwo","id":210630},"updated_at":"2011-11-13T22:43:43Z","url":"https://api.github.com/repos/jdriscoll/django-imagekit/issues/comments/2724983","body":"Haha, @matthewwithanm beat me to this one by a few mins. Here are my thoughts anyway:\r\n\r\n> * there is no way to ensure that the customized img instance will be preserved through the pipeline and be available by the time it gets to a processor that would use exif\r\n\r\nWell, that is the nature (and even the point) of the pipeline--to manipulate the data as it moves through. The problem we're addressing with this `copy` wrapper is that PIL strips the metadata arbitrarily. If a processor chooses to strip it, that is ok.\r\n\r\n> * this is essentially monkeypatching the copied instance with a private method\r\n\r\nYes, it is gross. We found this to be the least bad of the approaches we considered when writing it. We'll all have to ponder this one a bit more.\r\n\r\n> * I've not seen how/where this 'app' attribute is used?\r\n\r\nThe `app` property (as defined by `PIL`'s `JpegImagePlugin`) is a map of metadata markers commonly found in JPEG files. These common markers include APP0 (indicates metadata conforming to the JFIF standard), APP1 (indicates metadata conforming to the EXIF standard), and COM (indicates text comments embedded in the image).\r\n\r\nSee Wikipedia's article on [JPEG files](http://en.wikipedia.org/wiki/JPEG#JPEG_files) for further explanation.\r\n\r\nWhile there is seperate access for metadata that conforms to the EXIF standard (the `_getexif` method), the JFIF standard (frequently used by image editing software) may also encode metadata via these markers (color profiles, embedded thumbnails, etc).\r\n\r\nSince we are making an effort to conserve the EXIF metadata, it makes sense to also conserve the JFIF metadata. While none of the processors packaged with ImageKit (so far) make use of JFIF metadata, it's entirely possible that some processor in the future may want access to that metadata during processing, in which case, it should be made available.\r\n","id":2724983,"created_at":"2011-11-13T22:43:43Z"}}