You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Problem with MESH transform /w transparent background #254
This may apply to other transformations as well, but I've specifically observed it using the MESH transform.
The problem is that when performing multiple transformations, "garbage" from previous transformations begins appearing in the image, as shown here:
In the above image, the image in the middle is the desired result... everything around it should be transparent, but is instead filled with the results of previous transform operations.
I was eventually able to fix this by using memset to clear the memory allocated by ImagingNewBlock in Storage.c.
I'd be happy to submit a fix for this, but I have two questions:
Is this the appropriate solution?
How would I write a test for this? It happens inconsistently, and the severity seems to vary between systems (e.g., on a micro AWS instance with 512MB of memory, it happens frequently, but on my development machine with 12GB of memory, I haven't observed it once).
First glance, it looks like a bug from using uninitialized memory. If ImagingNewBlock isn't clearing the memory, and it's allocating it from previously allocated and recently freed memory, then you'd get just this sort of thing. And I'd certainly expect it more on a machine with more memory pressure.
As for a test, I'd start with posting what you did to make that image. I'd think that if the non-transformed region contains anything other than whatever the background should be initialized to, then we'd have a test failure, though admittedly, a passed test isn't always going to mean that the bug is fixed. But it will be useful to run on resource constrained machines to stress test.
I can submit a fix (it's a one liner) but I haven't had time to implement a test for the problem yet. It doesn't look like there are any tests for transform at the moment, so I'll need to create a new one. Would you like me to submit the fix on its own or wait until I can submit it with an appropriate test?
Activity
wiredfool commentedon Jun 20, 2013
First glance, it looks like a bug from using uninitialized memory. If ImagingNewBlock isn't clearing the memory, and it's allocating it from previously allocated and recently freed memory, then you'd get just this sort of thing. And I'd certainly expect it more on a machine with more memory pressure.
As for a test, I'd start with posting what you did to make that image. I'd think that if the non-transformed region contains anything other than whatever the background should be initialized to, then we'd have a test failure, though admittedly, a passed test isn't always going to mean that the bug is fixed. But it will be useful to run on resource constrained machines to stress test.
aclark4life commentedon Jun 29, 2013
@nikmolnar Got anything we can include in 2.1.0?
nikmolnar commentedon Jul 1, 2013
@aclark4life Sorry, I haven't had a chance to come back to this yet. When's 2.1.0 due?
aclark4life commentedon Jul 1, 2013
Today, else you can target 2.2.0 in 3 months.
nikmolnar commentedon Jul 1, 2013
Ok, I'll aim for 2.2.0. Thanks.
aclark4life commentedon Sep 28, 2013
@nikmolnar Time to hit the mark! 2.2.0 goes out in 3 days, else 2.3.0 or Future for this one
nikmolnar commentedon Sep 29, 2013
I can submit a fix (it's a one liner) but I haven't had time to implement a test for the problem yet. It doesn't look like there are any tests for transform at the moment, so I'll need to create a new one. Would you like me to submit the fix on its own or wait until I can submit it with an appropriate test?
wiredfool commentedon Sep 30, 2013
Send the fix, someone else might be able to pull together a test.
Fix for python-pillow#254
Merge pull request #348 from nikmolnar/master
Merge pull request python-pillow#254 from radarhere/auditwheel