Love Fuel?    Donate

FuelPHP Forums

Ask your question about FuelPHP in the appropriate forum, or help others by answering their questions.
fuelphp 1.9-dev: imagemagick not working on PHP 7.1.8
  • Hi,
    I recently upgraded to fuelphp 1.9-dev from 1.7.
    I manage to make everything work, almost ;-)
    I tried all the day to make "imagemagick" to work, but I got an error :-(

    If I do for example:
    $imgpath = '/Users/gwenael/Documents/www/myproject2/public/imgfiles/image.jpeg';
    $imgLoaded = Fuel\Core\Image::load($imgpath);
    or
    $imgLoaded = Image::load($imgpath);
    I got the error:
    A non well formed numeric value encountered
    COREPATH/classes/image/imagemagick.php @ line 31

    If I swicth to PHP 5.4.45, it works again, but I reallly need PHP 7!
    Am using MAMP 4.2.

    in image.php my config is:
    'driver' => 'imagemagick',
    'imagemagick_dir' => '/opt/ImageMagick/bin/',

    Any idea how to solve this problem?
    Thank you for any help :-)
    Gwen
  • HarroHarro
    Accepted Answer
    Odd that it works in 5.4.

    line 31 contains: md5(time() * microtime()) which is weird to say the least, as microtime() returns a string with two numeric values. It must be because of silent conversion in PHP < 7.

  • Thank you for this fast fix!
    I did some tests and it works fine, youpi :-)
    Gwen
  • Hi, again me.

    I have some issues with the Image class in general :-/
    I installed the last version of Mamp 4.4.1 with PHP 7.2.1. with my fuelphp 1.9-dev.
    In my "image.php" config, am using "imagemagick" which is already in MAMP
    (Version: ImageMagick 6.9.6-2):

    // My driver
    'driver' => 'imagemagick',
    'imagemagick_dir' => '/Applications/MAMP/Library/bin/'

    // My presets
    'presetresize' => array(
        'quality' => 75,
        'actions' => array(
            array('resize', 600, null, true, true),
            array('save', '$1')
        )
    ),
    'presetrotate' => array(
        'quality' => 75,
        'actions' => array(
            array('rotate', 90),
            array('save', '$1')
        )
    ),

    Nothing is happening when I do one of these (whatever the Driver am using "imageMagick" or "gd"):
    Fuel\Core\Image::load($path_img_server)->rotate(90);
    Fuel\Core\Image::load($path_img_server)->resize(600, null, true, true);

    Only "presets" are working, these 2 commands lines are working for both library:
    Fuel\Core\Image::load($path_img_server)->preset('presetrotate',$path_img_server);
    Fuel\Core\Image::load($path_img_server)->preset('presetresize',$path_img_server);


    Some additional issues:
    In my tests, am using an image with an exif Orientation of 6 with dimension of 1200 x 1800
    (similar of these sample: http://sample.li/exif-orientation/)

    There are some differences between gd and imagemagick results.

    When I rotate with imageMagick:
    - I obtain an image rotated with some additional pixel (1802 x 1202)
    - In the MAC finder I see the result as a "landscape",
    - In Firefox, I see the image corrected as a "portrait"

    When I rotate with GD:
    - I obtain an image rotated 1200 x 1800
    - In the MAC finder I see no differences, it stays as a "portrait",
    - In Firefox, I see the image corrected as a "portrait" as well


    Any idea what it could be?
    Thank you for your help
    Gwen
  • Can you tell me which of those examples I have to use to reproduce this? 

    You have checked your php logs for errors I assume, the fuel codebase hasn't been fully tested against PHP 7.2 yet.
  • I did new tests with this picture for example:
    http://sample.li/exif-orientation/Portrait_6.jpg
    (450x600, Orientation exif=6)

    // My presets
    'presetresize' => array(
        'actions' => array(
            array('resize', 300, null, true, true),
            array('save', '$1')
        )
    ),
    'presetrotate' => array(
        'actions' => array(
            array('rotate', 90),
            array('save', '$1')
        )
    ),

    // And after I do this:
    Fuel\Core\Image::load($path_img_server)->preset('presetrotate',$path_img_server);

    1st problem: only presets are working
    2nd problem: different behaviour between gd and imageMagick
    => gd is working properly, imagemagick not

    I do not have any error in my php logs
  • Thanks.

    Just to be clear: presets work for both gd and imagemagick, or only with gd? And calling ->rotate()->save() doesn't work for both?
  • I've ran my tests, with both gd and imagemagick.

    In both cases, everything in my test rotates fine, except your Portrait_6 image with gd. With imagemagick, it did rotate fine.

    It looks like GD takes the exif information into account. As Portrait_6 is taken 90 degrees counter-clockwise, rotating it 90 degrees makes it upright. Imagemagick seems to ignore exif information.

    I'm running ImageMagick 6.9.9-27 Q16 x86_64 2017-12-23, GD version 2.2.5, and PHP 7.1.14.
  • HarroHarro
    Accepted Answer
    By passing "-auto-orient" to Imagemagick's convert, it behaves the same as gd, taking exif info into account.

    p..s I used this to test:

    $result = Image::load(DOCROOT.'assets/img/Portrait_6.jpg')
        ->rotate(90)
        ->save(DOCROOT.'assets/img/Portrait_6_rotated.jpg');

    so not using presets.
  • Thank you!,
    I did a lot of tests

    My config:
    GD 2.6.5
    ImageMagick 6.9.6-2
    PHP 7.1.8

    True, when I add ->save(myfile) at the end, then it works,
    before it was not necessary, strange.

    // I remarked also that the filename parameter given to save method is mandatory
    // (for both gd and imagemagick)
    // This work =>
    $result = Image::load(DOCROOT.'uploads/tests/Portrait_6_rotated.jpg')
        ->rotate(90)
        ->save(DOCROOT.'uploads/tests/Portrait_6_rotated.jpg');
    // Here nothing is happening =>
    $result = Image::load(DOCROOT.'uploads/tests/Portrait_6_rotated.jpg')
        ->rotate(90)
        ->save();

    You did something great by adding "-auto-orient" to imageMagick!
    I tested all the Exif possibilities (1-2-3-4-5-6-7-8) with both library and it works :-)
    Just I need to proceed differently according to the image driver am using...

    // with "imageMagick"
    I simply do ->save('mypicture.jpg') on pictures
    => and then it corrects automatically the orientation according to the exif orientation
    => the final result is an image with the correct orientation
    => the final result is that the image exif value is set to "1"

    // With GD I need to do differently
    according to the Exif value I apply different actions before save()
    1: I do nothing
    2: horizontal flip
    3: 180° rotate left
    4: vertical flip
    5: vertical flip + 90 rotate right
    6: 90° rotate right
    7: horizontal flip + 90 rotate right
    8: 90° rotate left
    => And the the final result is an image with the correct orientation
    => with gd we loose the exif value, but it's normal

    Have a nice evening
    Gwen
  • This sounds like an issue in GD, you seem to have a much newer version that I have.

    I don't see a difference in behaviour here between the GD, Imagemagick and Imagick drivers. Having to do things differently defeats the purpose of being able to transparently switch drivers depending on the target platform for your app.

    So more debugging is needed.

    What I do find is that GD seems to remove EXIF information on image style operations, which might acccount for unexpected behaviour on images already processed? So probably not related to the GD version, but a limitation of the GD library.
  • Like you said, it's more like a GD limitation.
    GD is not taking in consideration the exif orientation.
    All the solutions I found for GD was to do a "exif_read_data" to extract this information,
    and only after to rotate and/or flip the image when necessary (no Exif at then end, but it's fine)

    With ImageMagick it's much easy (thanks to "-auto-orient"):
    When he founds an exif orientation:
    - he is correcting the orientation of the image
    - then he is updating the Exif data orientation (value=1).
    - If no Exif orientation data found, no Exif information added

    I agree with this article "EXIF Orientation Handling Is a Ghetto":
    https://www.daveperrett.com/articles/2012/07/28/exif-orientation-handling-is-a-ghetto/

    Thanks again

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion