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
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.
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/'
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
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.
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
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
Donate
