Stumped: Huge Files Created On Image Resize

Have a client who wants certain images resized to a maximum dimension.

I have a routine that captures an uploaded image (after it is built into the image pair with a type of 'A' (alternate).

The original file has properties of:

file size = 3129097

image_x = 2448

image_y = 3264

The maximum dimension desires is: 2048 so this gives new image properties of

new_x = 1536

new_y = 2048

However, when

list($new_content, $format) = fn_resize_image($original_filename, $new_x, $new_y);

$new_content is a whopping 18491412 bytes

I'm sure there is something simple here that I'm missing. But I would certainly expect the $new_content to be smaller than the original file size and not some multiplier of it.

Any insights would be greatly appreciated. Been scratching my head far to long for this somewhat simple task.

P.S. If I do look at the image size, it does show the proper new dimensions of 1536 X 2048..

Please check the 'Thumbnail format' setting on the 'Settings'-'Thumbnails' page in the administrator area. Maybe there is another format, and the generated image has more size due to this setting.

Try to switch from Imagick to GD or wise versa and check the result

I'm not calling the fn_generate_thumbnail function, I am calling fn_resize_image function. Hence, thumbnail sizes should not come into play. Regardless, all the thumbnail settings are 150 or less (note that this is a detailed image resize with maximum dimension of 2048).

As I said, a fn_get_image_size() shows the proper dimensions after the resize, but the resulting filesize is huge.

The convert_to settings are set to "original" (Same as source setting) and the jpeg_quality is set to 80.

Thumbnails generated on the site do not seem to have this problem. Hence, I'm trying to determine what I'm doing wrong that is causing it to generate such a huge $new_content.

I can't see any reason for this filesize increase to occur. I'm using the built in functions and not using the image libraries directly.

I'm not calling the fn_generate_thumbnail function, I am calling fn_resize_image function. Hence, thumbnail sizes should not come into play. Regardless, all the thumbnail settings are 150 or less (note that this is a detailed image resize with maximum dimension of 2048).

If you look at the fn_resize_image in the app/finctions/fn.images.php file, you can see, that it does use this setting.

I can't see any reason for this filesize increase to occur. I'm using the built in functions and not using the image libraries directly.

You do not use, but CS-Cart does use image libraries. And according to the code of this function, it uses GD directly to filter the resized image.

Honestly. I also do not see any reason for this issue.

I have made a quick search in the Google and found that similar problems occur in WordPress and Drupal systems. Really strange issue....

From my reading of fn_resize_image, it uses 2 of the settings for thumbnails.

1) Whether to connvert new image to same or different format ("Same as source") which equates to "original" in the function.

2) The Jpeg compression quality which is set to 80.

I do not see anywhere that thumbnail sizes come into play.

I too cannot see why this should/would be happening. But it is. It's as if the vendor settings are not inheriting the setting set by the admin.

Update: It seems that the issue is the function fn_get_mime_content_type is returning 'application/octet-stream' rather than 'image/jpeg' for the jpeg file. fn_resize_images() set the "from file extension" parameter to false.

So I'm not sure how to correctly address this. Not sure whether to add the 'appliation/octet-stream' to return 'jpg' in the fn_get_image_extension() function or whether to set the 'get from extension' parameter to 'true' in fn_resize_image().

I'm thinking changing the parameter to true would be the least impactful method.

Details of what the various functions/settings/returns are from resizing an image are below. I will submit a defect the fn_get_mime_content_type() function is not returning the proper type for a downloaded jpg file (which I find really hard to believe). But the data is what the data is.

[Wed, 25 Nov 2015 22:58:11 +0300]
fn_resize_image: src=images/detailed/2/2015-08-03_13_1its-zg.47.25.jpg
fn_get_mime_content_type:application/octet-stream
fn_get_image_extension(fn_get_image_extension()=
fn_resize_image: format=png, settings:Array
(
    [thumbnail_background_color] => #ffffff
    [convert_to] => original
    [jpeg_quality] => 80
    [product_lists_thumbnail_width] => 150
    [product_lists_thumbnail_height] => 150
    [product_details_thumbnail_width] => 280
    [product_details_thumbnail_height] =>
    [product_quick_view_thumbnail_width] => 220
    [product_quick_view_thumbnail_height] =>
    [product_cart_thumbnail_width] => 120
    [product_cart_thumbnail_height] =>
    [category_lists_thumbnail_width] => 60
    [category_lists_thumbnail_height] =>
    [category_details_thumbnail_width] => 120
    [category_details_thumbnail_height] =>
    [category_detailed_image_width] =>
    [category_detailed_image_height] =>
)
ar_resize_image: orig_x=3264, x=2048, orig_y=2448, y=1536, path=images/detailed/2/2015-08-03_13_1its-zg.47.25.jpg strlen(new_content)=15158069

images/detailed/2/2015-08-03_13_1its-zg.47.25.jpg old_size=891487, new_size=15158069

After changing the "use extension" parameter to true, things run nice and fast and the results are what's expected.

[Wed, 25 Nov 2015 23:15:40 +0300]
fn_resize_image: src=images/detailed/2/2015-07-25_15_au8c-c3.28.57.jpg
fn_get_mime_content_type:image/jpeg
fn_get_image_extension(fn_get_image_extension()=
fn_resize_image: format=jpg, settings:Array
(
    [thumbnail_background_color] => #ffffff
    [convert_to] => original
    [jpeg_quality] => 80
    [product_lists_thumbnail_width] => 150
    [product_lists_thumbnail_height] => 150
    [product_details_thumbnail_width] => 280
    [product_details_thumbnail_height] =>
    [product_quick_view_thumbnail_width] => 220
    [product_quick_view_thumbnail_height] =>
    [product_cart_thumbnail_width] => 120
    [product_cart_thumbnail_height] =>
    [category_lists_thumbnail_width] => 60
    [category_lists_thumbnail_height] =>
    [category_details_thumbnail_width] => 120
    [category_details_thumbnail_height] =>
    [category_detailed_image_width] =>
    [category_detailed_image_height] =>
)
ar_resize_image: orig_x=3264, x=2048, orig_y=2448, y=1536, path=images/detailed/2/2015-07-25_15_au8c-c3.28.57.jpg strlen(new_content)=305009

images/detailed/2/2015-07-25_15_au8c-c3.28.57.jpg old_size=824032, new_size=305009

So the real issue seems to be in the library that determines the mime-type of the file.

Not sure why images uploaded from my Nexus 5 phone to dropbox and then uploaded are not seen by the library as "image/jpeg' but they aren't.

Changing the argument for whether to resolve from file extension to 'true' seems to have addressed the issue. But it's not a final solution. Someone needs to dig into the libarary to determine why it is not identifying the file correctly. But I've spent far too much time digging out the source of the problem....

Note that my choice to change the 2nd parameter (use file extension to determine type) won't work on downloaded files since they have no file suffix (but the problem of miss-identification exists for those files too).

I need this to work properly so I guess I'll have to dig into the library to diagnose it.

It appears that PHP 5.6.15 has fileinfo disabled by default. Hence the finfo class is not present and the mime_file_types function is deprecated in lieu of the finfo class.

Hence, unless the filetypes are used, the function will always return application/octet-stream.

Seems like this is pretty important to detect during installation and/or upgrade since not having mime type detection available can have disastrous impact to file sizes created when thumbnails are created.