Problem with MESH transform /w transparent background · Issue #254 · python-pillow/Pillow · GitHub
Skip to content

Problem with MESH transform /w transparent background #254

Closed

Description

@nikmolnar

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:
image

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:

  1. Is this the appropriate solution?
  2. 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).

Thanks,
_Nik

Activity

  1. wiredfool commented on Jun 20, 2013

    @wiredfool
    Member

    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.

  2. aclark4life commented on Jun 29, 2013

    @aclark4life
    Member

    @nikmolnar Got anything we can include in 2.1.0?

  3. nikmolnar commented on Jul 1, 2013

    @nikmolnar
    ContributorAuthor

    @aclark4life Sorry, I haven't had a chance to come back to this yet. When's 2.1.0 due?

  4. aclark4life commented on Jul 1, 2013

    @aclark4life
    Member

    Today, else you can target 2.2.0 in 3 months.

  5. nikmolnar commented on Jul 1, 2013

    @nikmolnar
    ContributorAuthor

    Ok, I'll aim for 2.2.0. Thanks.

  6. aclark4life commented on Sep 28, 2013

    @aclark4life
    Member

    @nikmolnar Time to hit the mark! 2.2.0 goes out in 3 days, else 2.3.0 or Future for this one

  7. nikmolnar commented on Sep 29, 2013

    @nikmolnar
    ContributorAuthor

    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?

  8. wiredfool commented on Sep 30, 2013

    @wiredfool
    Member

    Send the fix, someone else might be able to pull together a test.

  9. added a commit that references this issue on Sep 30, 2013
  10. added a commit that references this issue on Sep 30, 2013
  11. added a commit that references this issue on Sep 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    BugAny unexpected behavior, until confirmed feature.

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions