imagick does not keep transparency of png

Elgg 2.3.10,  Plugin imagick 1.0

I upload png image with transparent areas. The imagick transform it to jpg and the transparent areas to black.

If possible I prefer to keep it png with transparency. If not than jpg with the transparent areas to white.

I would greatly appreciate any help.

Thanks

  • The imagick transform it to jpg

    It's not Imagick but Elgg/ImageService and Elgg/EntityIconService which saves an entity icon in .jpg format always.

    And as you know JPG doesn't support transparent background.

  • Thank you RvR, but I do not understand.

    When I deactivate imagic plugin, Elgg keeps the transparency of PNG. So, it is maybe not Elgg's fault.

    In addition, with Tidypics plugin set to imagic it keeps the transparency intact. 

    Also, exactly the same  problem (with imagic) is mentioned in many places. e.g. the following links:

    https://stackoverflow.com/questions/9022842/imagick-converting-a-png-to-jpg-transparent-background-turns-black?rq=1

    https://stackoverflow.com/questions/7719178/imagemagick-transparent-png-background/19783665

    The imagic plugin is very simple. It has only start.php (see below), so, I believe it might be  simple to solve my problem with some plugin, but I do not know how.

    <?php
    
    
    // register default elgg events
    
    elgg_register_event_handler('plugins_boot', 'system', 'imagick_plugins_boot');
    
    
    /**
    
     * Act on plugins boot
    
     *
    
     * @return void
    
     */
    
    function imagick_plugins_boot() {
    
    
    if (!extension_loaded('imagick')) {
    
    // imagick isn't loaded so don't do anything
    
    return;
    
    }
    
    
    $sp = _elgg_services();
    
    $sp->setFactory('imageService', function($sp) {
    
    $imagine = new \Imagine\Imagick\Imagine();
    
    return new \Elgg\ImageService($imagine, $sp->config);
    
    });
    
    }

     

     

     

  • Any suggestion how to overcome this problem?

    Thank you

  • I think you can't take Tidypics as an example here. Tidypics keeps the image format unchanged when resizing/creating the thumbnails and it uses the Imagick php extension directly (or GD or ImageMagick command line tools depending which image library you have selected in the Tidypics settings).

    The Imagick plugin of Coldtrick relies on the Imagine library that comes with Elgg core (vendor/imagine/). The Imagine library is provides an API that allows the image file operations to be called with the same set of functions when using either the GD php extension (as Elgg does by default) or alternatively the Imagick php extension (with the Imagick plugin on Elgg 2.3 installed).

    I don't know if the Imagine library offers any additional options that would be necessary when using the Imagick php extension / Imagick plugin to handle transparency correctly. The other possibility is that it's a bug in the Imagine library. It seems the version of Imagine that comes bundled with Elgg 2.3 is quite outdated (version 0.6.3 whereas on https://github.com/avalanche123/Imagine/releases the latest available version os 1.2.0). It might be worth trying the new release to see if the problem with transparency persists. The only problem when doing so might be that version 1.2.0 is maybe not fully backward compatible with version 0.6.3 and might require changes in Elgg core to work.

    Maybe you could open an issue in the Imagick plugin respository at github to make the Coldtrick guys aware of the problem. They might know what to do - at least surely better than I do.

  • Thank you iionly for the detailed and useful guidance.

  • As @RVR said Elgg saves an entity icon in .JPG format always, and JPG does not support transparent background.

    However, the fact is that with GD php extension, Elgg retain the transparency of PNG even though the image file name has JPG suffix. The reason for this is that Elgg does not transform PNG to JPG. It just replaces the suffixes, i.e PNG -> JPG. I checked this phenomena (replacing the suffixes) outside Elgg's environment and found the same. The browsers (Chrome, FF and IE) retain the transparency and animation of PNG and GIF, even though the suffix of the files is JPG.

    @iionly said:

    Tidypics keeps the image format unchanged when resizing/creating the thumbnails and it uses the Imagick php extension directly

    Now we know that Elgg also keeps the format unchanged (changes only the suffix - which is not the best practice IMHO). I believe it is possible to build a plugin that replicates the functionality of Tidypics, and handle all the images of Elgg through Imagick php extension directly. In this way the problem with the PNG transparency will be solved. 

    Could someone suggest how to do it?

    Thank you very much.

  • I think it wouldn't be that easy to write such a plugin. The point is: Elgg core makes use of the Imagine library to use the same set of API functions regardless if GD or Imagick php are used. Imagine "translates" the functions accordingly. Also, Elgg most likely currently expects that the images (profile images, entity icons and file thumbnails) have the jpg suffix regardless what file type the files really are. If the png files would now suddenly saved with png extensions they would probably not getting served.

    The problem with the image file creation could probably be solved by replacing all Elgg core actions with modified versions that use their own set of image resizing functions (like Tidypics does). Probably the output file type issue could also be fixed somehow - but don't ask me for any details as I wouldn't have them right now.

    The question is if it couldn't be solved by improving the Imagick plugin and/or using a newer version of the Imagine library as Elgg core currently does. These questions might be best answered by the Coldtrick guys as they might know best. Unfortunately, I can't provide any more help currently just due to lack of detailed knowledge.

  • Unfortunately, the new version of Imagine does not solve the problem.

    Anyway, thank you very much.